Verificação e validação

Transcrição

1 UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Verificação e validação Engenharia de Software 2o. Semestre de 2005 Slide 1

2 Verificação e validação Asseguram que o software cumpra com suas especificações e atenda às necessidades dos usuários Slide 2

3 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 software Cleanroom Slide 3

4 Verificação vs validação 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. Slide 4

5 O 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. Tem dois objetivos principais: a descoberta de defeitos no sistema Assegurar se o sistema é ou não utilizável em uma situação operacional. Slide 5

6 Verificação estática e dinâmica 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. Slide 6

7 Teste 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 Slide 7

8 Tipos de teste 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. Slide 8

9 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. Slide 9

10 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. Slide 10

11 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. Slide 11

12 O processo de depuração Resultados dos testes Especificação Casos de testes Localizar erros Projetar reparo de erros Reparar erros Refazer os testes de programa Slide 12

13 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. Slide 13

14 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 Slide 14

15 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.) Técnica muito eficaz para a descoberta de erros. Slide 15

16 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. Slide 16

17 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. Slide 17

18 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. Slide 18

19 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 aumentara os custos no começo do processo de software. Slide 19

20 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. Acompanhamento Uma nova inspeção pode ser ou não necessária. Slide 20

21 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. Slide 21

22 Classe de defeitos Defeitos nos dados Defeitos de controle Defeitos de entrada/saída Defeitos de interface Defeitos de Gerenciamento de armazenamento Defeitos de gerenciamento de exceções Checagem de inspeção 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 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? 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? 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? 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? Todas as possíveis condições de erros foram levadas em conta?

23 Taxa de inspeção (IBM) Cerca de 500 declarações/hora durante revisão geral 125 declarações/hora durante preparação individual 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. Slide 23

24 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. Slide 24

25 Checagem da análise estática Classe de defeitos Defeitos em dados Defeitos de controle Defeitos de entrada/saída Defeitos de interface Defeitos de gerenciamento De armazenamento Checagem da análise estática 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 Código inacessível Condições que nunca se tornam verdadeiras Análise de condições que afetam um valor de variável. 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 Ponteiros não designados Aritmética de ponteiro Slide 25

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

27 Desenvolvimento de software Cleanroon 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. Slide 27

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

29 Desenvolvimento Incremental Especificação congelada Estabelecer requisitos Especificação formal Desenvolver incremento de software Entregar o software Pedido de mudança de requisitos Slide 29

30 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. Slide 30

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

32 Avaliação do processo Cleanroom 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. Slide 32

33 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. Slide 33

34 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 incremental, verificação estática e teste estatístico. Slide 34