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