aula12

Verificação e validação

Engenharia de Software 2o. Semestre de 2005

UNIVERSIDADE ESTADUAL PAULISTA

INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS

Verificação e validação

●

Asseguram que o software

cumpra com suas

especificações e atenda às

necessidades dos usuários

Objetivos

● Introduzir verificação e validação de software. ● Descrever o processo de inspeção de programa ● Explicar análise estática.

● Introduzir o processo de desenvolvimento de

● Verificação:

”Estamos construindo certo o produto?"

● O software cumpre com suas especificações ● Validação:

”Estamos construindo o produto certo?"

● O software deve estar de acordo com o que o

usuário deseja.

● É um processo que engloba todo o ciclo de vida

- V & V deve ser aplicado em cada estágio no processo de desenvolvimento.

● Tem dois objetivos principais:

• a descoberta de defeitos no sistema

• Assegurar se o sistema é ou não utilizável em uma situação operacional.

● 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.

● 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

● Os testes de defeito

• Testes projetados para descobrir defeitos no sistema.

• 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 podem ter poucas expectativas de certos tipos de software

• Ambiente de mercado

» Colocar um produto no mercado pode ser mais importante do que encontrar todos os defeitos no programa.

● 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.

O processo de depuração

Localizar erros Projetar reparo de erros Reparar erros Refazer os testes de programa Resultados

dos testes Especificação

Casos de testes

● 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.

A estrutura de um plano de teste

● O processo de teste

● Facilidade de rastreamento dos requisitos ● Itens a serem testados

● Cronograma de testes

● Procedimentos de registros de testes ● Requisitos de hardware e de software ● Restrições

Inspeções de software

● Envolve pessoas examinando uma

representação de software para descobrir anomalias e defeitos.

● Não há a necessidade de execução do sistema,

assim pode ser usada antes da implementação.

● Pode ser aplicada a qualquer representação do

sistema (requisitos, projeto, dados de teste, etc.)

Sucessos da inspeção

● Muitos defeitos diferentes podem ser

descobertos em uma única inspeção. No teste, um defeito pode mascarar outros, assim várias execuções são necessárias.

● A reutilização do conhecimento do domínio e da

programação é benéfica, uma vez que revisores provavelmente já viram os tipos de erros que

ocorrem com freqüência em linguagens de programação específicas e em determinados tipos de aplicações.

Inspeções e 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 de 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ção

de 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

Processo de inspeção de

programa

● Planejamento e introdução

• Visão geral do sistema, apresentado à equipe de inspeção.

● Preparação Individual

• Cada membro da equipe estuda a especificação e procura defeitos no código.

● Reunião de Inspeção

• Durante a inspeção, os erros descobertos são anotados.

● Retrabalho

• Modificações são feitas para corrigir os erros descobertos.

Checklist para inspeção de

programas

● 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.

Classe de defeitos Checagem de inspeção

Defeitos nos dados Todas as variáveis do programa são iniciadas antes de seu uso? Todas as constantes foram denominadas

O limite superior de vetores deve ser igual ao tamanho do vetor ou ao tamanho –1?

Se as strings de caracteres são utilizadas, um delimitador é explicitamente designado?

Existe alguma possibilidade de overflow de buffer

Defeitos de controle Para cada declaração condicional, a condição está correta? Cada laço está certo para terminar?

As declarações compostas estão corretamente entre parênteses? Em declarações ‘case’, todos os casos são levados em conta?

Se um identificador break é requerido após cada caso em declarações ‘case’, esse identificador foi incluído?

Defeitos de entrada/saída

Todas as variáveis de entrada são utilizadas?

Todas as variáveis de saída tem um valor designado antes de saírem? Entradas inesperadas podem fazer com que os dados sejam

corrompidos?

Defeitos de interface Todas as chamadas de funções ou métodos tem o número correto de parâmetros?

Os tipos formais e reais de parâmetros combinam? Os parâmetros estão na ordem certa?

Defeitos de

Gerenciamento de armazenamento

Se uma estrutura encadeada é modificada, todos os ponteiros foram corretamente redesignados?

Se o armazenamento dinâmico é utilizado, foi alocado espaço correto? O espaço é explicitamente liberado, depois que não é mais necessário?

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

Classe de defeitos Checagem da análise estática

Defeitos em dados Variáveis utilizadas antes da inicialização Variáveis declaradas, mas nunca utilizadas

Variáveis atribuídas duas vezes, mas nunca utilizadas entre as atribuições

Possíveis violações de limites de vetor Variáveis não declaradas

Defeitos de controle Código inacessível

Condições que nunca se tornam verdadeiras

Defeitos de entrada/saída Análise de condições que afetam um valor de variável. Defeitos de interface Desacordo quanto ao tipo de parâmetro

Desacordo quanto ao número de parâmetros Não utilização dos resultados de funções Funções e procedimentos não chamados Defeitos de gerenciamento

De armazenamento

Ponteiros não designados Aritmética de ponteiro

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).

● 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.

Desenvolvimento de software

Cleanroon

O processo Cleanroon

Especificar formalmente o sistema Desenvolver perfil operacional Definir incrementos do software Construir programa estruturado Verificar código formalmente Integrar incremento Projetar testes estatísticos Testar sistema integrado Retrabalho devido a erros

Desenvolvimento Incremental

Estabelecer requisitos Especificação formal Desenvolver incremento de software Entregar o software

Pedido de mudança de requisitos Especificação

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.

● 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

● Resultados na IBM tem mostrado que os

softwares possuem bem menos erros,

● 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.

Avaliação do processo

Cleanroom

Pontos chave

● Verificação certifica a conformidade com a

especificação; Validação certifica que programa faz o que o usuário precisa.

● Planos de teste descrevem os itens a serem

testados.

● Inspeção de programas é o processo de

analisar o código fonte, sem executá-lo.

• O código do programa é sistematicamente checado por uma pequena equipe, para localizar defeitos.

Pontos chave.

● Ferramentas de análise estática pode revelar

anomalias no programa (possíveis defeitos).

● Processo de desenvolvimento cleanroom é

uma abordagem de desenvolvimento de

software que se apóia em desenvolvimento desenvolvimento incremental

incremental, verificação estática e verificação estática teste teste estatístico