View
231
Download
0
Category
Preview:
Citation preview
Engenharia de Software
Aula09 – Validação de software
Roteiro
• Introduzir verificação e validação de software.
• Inspeção de programa• Análise estática.• Processo de desenvolvimento de software
Cleanroom
Verificação X Validação
• Verificação:– O software cumpre com suas especificações– ”Estamos construindo certo o produto?"
• Validação:– O software deve estar de acordo com o que o
usuário deseja.– ”Estamos construindo o produto certo?"
Processo V & V
• É um processo que engloba todo o ciclo de vida– V & V deve ser aplicado em cada estágio no
processo de desenvolvimento.– É um processo de revisão de documento, inspeção
de código até chegar nos testes do software.• Tem dois objetivos principais:
– A descoberta de defeitos no sistema– Assegurar se o sistema é ou não utilizável em uma
situação operacional.
Verificação • Inspeções de software - preocupadas com a
análise estática das representações do sistema para descobrir problemas (verificação estática))– Pode ser complementadas por alguma análise
automática do texto de origem de um sistema ou dos documentos associados.
• Teste de software - preocupado com a execução e observação do comportamento do produto (verificação dinâmica).– O sistema é executado com dados de teste e o seu
comportamento operacional é observado.
Verificação
Testes de programas
• Pode revelar a presença de erros e NÃO a ausência
• Um teste bem sucedido é um teste que descobre um ou mais erros.
• É a única técnica de validação para requisitos não funcionais (desempenho, confiabilidade)
• Deve ser usado em conjunto com a verificação estática para uma cobertura total das atividades de V&V
Tipos de Testes• Os testes de defeito
– Testes projetados para descobrir inconsistências entre o programa e sua especificação.
– Um teste bem sucedido é aquele que revela a presença de defeitos em um sistema.
• Testes estatísticos– Usado para testar o desempenho e a confiabilidade
do programa.– Confiabilidade: número de falhas no sistema, etc– Desempenho: Tempo de execução, tempo de
resposta, etc.
Metas de V & V
• Verificação e validação deve estabelecer a confiança de que o software é “adequado a seu propósito”.
• Isso NÃO significa que o programa tenha que ser livre de defeitos.
• Ao invés disso, significa que o sistema deve ser suficientemente bom para o uso pretendido. O tipo de uso irá determinar o grau de confiança que será necessário.
Confiança de V & V• Depende do propósito do sistema, as
expectativas do usuário e o ambiente de mercado.– Função do software
• O nível de confiança depende do tipo de sistema e o quanto é importante para a organização.
– Expectativas do usuário• Usuários tinham poucas expectativas de certos tipos de
software. Hoje eles são mais exigentes. – Ambiente de mercado
• Colocar um produto no mercado pode ser mais importante do que encontrar todos os defeitos no programa.
Testes e depuração• Testar e depurar um programa são atividades
distintas.• Verificação e validação e teste estão
preocupados em estabelecer a existência de defeitos em um programa.
• Depuração está preocupada com a localização e remoção desses defeitos.
• Depuração envolve a formulação de uma hipótese sobre o comportamento do programa e testar essa hipótese para encontrar o erro no sistema.
Processo de depuraçãoO teste ocorre antes e descobre a ocorrência do erro
Planejamento de V & V• Planejamento cuidadoso é necessário para
obter sucesso nos processos de inspeção e teste.
• O planejamento deve iniciar no começo do processo de desenvolvimento.
• O processo de planejamento deve decidir sobre o equilíbrio entre as abordagens estáticas e dinâmicas.
• O planejamento de testes se ocupa em estabelecer os padrões para o processo de testes.
Planejamento de V & V
Requirementsspecification
Systemspecification
Systemdesign
Detaileddesign
Module andunit codeand tess
Sub-systemintegrationtest plan
Systemintegrationtest plan
Acceptancetest plan
Service Acceptancetest
Systemintegration test
Sub-systemintegration test
Estrutura de um Plano de Testes• O processo de teste• Facilidade de rastreamento dos requisitos
– Testar individualmente os requisitos• Itens a serem testados
– O que vai ser testado• Cronograma de testes• Procedimentos de registros de testes
– Como o resultado dos testes vão ser documentados• Requisitos de hardware e de software• Restrições
Inspeções x Testes• Inspeções e testes são técnicas de verificação
complementares.• Ambas devem ser utilizadas no processo de
V&V.• Inspeções podem verificar a conformidade com
uma especificação mas não a conformidade com os reais requisitos do usuário.
• Inspeções não podem verificar as características não funcionais tais como desempenho, usabilidade, etc.
Inspeções no programa• Revisão cuidadosa, linha por linha, do código
fonte do programa.• Objetivo é a DETECÇÃO de defeitos (não
correção)• Defeitos podem ser erros lógicos, anomalias no
código que podem indicar uma condição errônea (por ex. uma variável não inicializada) ou a não conformidade com padrões organizacionais.
Pré-condições para a inspeçãode programa• Uma especificação precisa deve estar
disponível.• Os membros da equipe de inspeção devem
estar familiarizados com os padrões organizacionais.
• Código sintaticamente correto deve estar disponível.
• Uma lista de erros deve ser preparada• Gerente deve aceitar que a inspeção aumentará
os custos no começo do processo de software.
Processo de inspeção de programa
Inspectionmeeting
Individualpreparation
Overview
Planning
Rework
Follow-up
Planejamento Introdução Preparação Reunião Retrabalho Acompanhamento Individual de inspeção
Checklist para inspeção deprogramas
• Lista de erros comuns deve ser usada para dirigir a inspeção.
• Lista de erros são dependentes da linguagem de programação
• Quanto mais “fraca” é a checagem de tipos pela linguagem, maior é a lista de erros mais comuns.
• Exemplos: inicialização, nomeação de constantes, término de laços, limites de vetores, etc.
Checklist
Taxa de inspeção (IBM)• Cerca de 500 declarações/hora durante revisão
geral• 125 declarações/hora durante preparação
individual• 90-125 declarações/hora podem ser
inspecionadas durante a reunião• Inspeção é portanto um processo caro• Contudo, o esforço requerido para a inspeção é
menor do que a metade o esforço de teste exigido para defeitos equivalentes.
Análise estática automatizada• Analisadores estáticos são ferramentas de
software para o processamento do código fonte.• Percorrem o texto do programa e tentam
descobrir potenciais condições erradas e chamar a atenção da equipe de v&v.
• São bastante eficaz como um auxílio às inspeções de programas. É um complemento, porém não substitui as inspeções.
Checagem da análise estática
Uso da análise estática
• Útil quando a linguagem não faz checagem adequada de tipos e, por isso, muitos erros não são detectados pelo compilador (C)
• Menos eficaz para linguagens que possui forte checagem de tipos e podem, portanto, detectar muitos erros durante a compilação (Java).
Desenvolvimento de software Cleanroom• Filosofia de desenvolvimento que tem como
base evitar defeitos pelo uso de um rigoroso processo de inspeção.
• Objetivo: Conseguir um software sem nenhum defeito.
• Processo de desenvolvimento baseado em:– Especificação formal.– Desenvolvimento incremental.– Programação estruturada.– Verificação estática usando rigorosas inspeções de
software.– Teste estatístico do sistema.
Processo Cleanroom
Desenvolvimento incremental
Especificação formal e Inspeções
• O modelo baseado em estados é a especificação e o processo de inspeção checa o programa com relação a esse modelo.
• A abordagem utilizada para o desenvolvimento tem como base transformações bem definidas, que tentam preservar a exatidão em cada transformação, para uma representação mais detalhada.
• Argumentos matemáticos (não provas) são usados para aumentar a confiança no processo de inspeção.
Equipes no processo Cleanroom
• Equipe de especificação. Responsável pelo desenvolvimento e pela manutenção da especificação do sistema.
• Equipe de desenvolvimento. Responsável por desenvolver e verificar o software. O software não é executado durante esse processo.
• Equipe de certificação. Responsável pelo desenvolvimento de um conjunto de testes estatísticos para exercitar o software após o seu desenvolvimento (certificação da confiabilidade do software).
Avaliação do processo Cleanroom
• Resultados na IBM tem mostrado que os softwares possuem bem menos erros (2,3 erros para mil linhas de código)
• Avaliação mostra que o processo não é mais caro do que outras abordagens.
• Menos erros do que em um processo de desenvolvimento tradicional.
• Uso do processo tem sido restrito a organizações tecnologicamente avançadas.
Referência• Sommerville, Ian
– Cap 15
Recommended