Teste de Software. Profa. Cátia dos Reis Machado

Transcrição

1 Teste de Software Profa. Cátia dos Reis Machado

2 Qualidade Garantia de Qualidade Qualidade do processo Qualidade do produto Testes Estáticos Testes Dinâmicos

3 Teste de software Teste de software é o processo de executar um programa com o objetivo de encontrar erros. Fonte: (Myer, 1979) Teste de software é o processo formal de avaliar um sistema ou comportamento de um sistema por meios manuais ou automáticos para verificar se ele satisfaz os requisitos especificados ou identificar diferenças entre os resultados esperados e os obtidos. Fonte: (IEEE 729, 1983)

4 Testes podem mostrar a presença de erros, não a sua ausência (Dijkstra)

5 Testes são tentativas sistemáticas de encontrar erros em programa que você acha que está funcionando.

6 Analisa os artefatos estaticamente (revisões) Podem ser utilizados em todas as fases do desenvolvimento de software Esta técnica não demonstra que o software é útil operacionalmente, já que não podemos testar algumas características do software como: eficiência, confiabilidade, usabilidade. Revisões (inconsistência, ambiguidade, etc...)

7 Teste dinâmico Consiste em executar o programa usando dados reais de entrada e avaliar se as saídas obtidas estão de acordo com as saídas esperadas.

8 Quem já utilizou teste estático no desenvolvimento de software?

9 Propagação de defeitos entre as fases do ciclo de vida de desenvolvimento Informação perdida durante a transformação Informação transformada incorretamente Transformações inconsistentes a partir de uma mesma fonte de informação Abstração

10 Custo relativo para corrigir um defeito Teste estático Custo relativo para a correção de um defeito Tempo

11 A revisão tem o objetivo de assegurar que: O artefato satisfaz as especificações funcionais e atributos de qualidade O artefato atende às necessidades do cliente O artefato cumpre com as regulamentações, regras, políticas, planejamentos e procedimentos, identificando os possíveis desvios

12 O que pode ser revisado? Especificações de requisitos Modelos de processos Regras de negócio Casos de teste Código Arquitetura

13 Tipos de defeitos encontrados nos artefatos Defeito Descrição Fato incorreto Omissão Inconsistência Ambiguidade Informações no artefato de software contradizem as informações presentes na especificação de requisitos ou o conhecimento geral de domínio As informações necessárias sobre o sistema foram omitidas do artefato de software Informações em parte do artefato encontra-se inconsistente com outras partes do artefato Possibilita ao desenvolvedor interpretar as informações de diferentes maneiras, podendo não levar a uma implementação correta Informação estranha Informações que não são necessárias ou não são usadas Fonte: adaptado de IEEE 830, 1999)

14 Classificação por tipo de revisões Dependendo da formalidade da revisão podemos classificar as principais técnicas de revisão em: Mais formal Menos formal Inspeção Walkthrough Pair programming Deskcheck Revisão Ad hoc

15 Inspeção O processo de inspeção compreende várias etapas: Coleta dos artefatos a serem utilizados (analisados) Inspeção propriamente dita Acompanhamento da correção de defeitos Os participantes desempenham diferentes papéis, dependendo da etapa de desenvolvimento e grau de conhecimento e envolvimento com o projeto

16 Inspeção

17 Inspeção No Planejamento os inspetores são selecionados e os materiais a serem revisados são preparados; Na Apresentação, o grupo recebe instruções essenciais sobre o material a ser inspecionado, especialmente sobre o que deve ser inspecionado; Na Preparação, integrantes do time de inspeção se preparam para desempenhar o papel designado a cada um; Na Reunião de Inspeção os defeitos são encontrados, discutidos e categorizados;

18 Inspeção No Retrabalho o autor do documento corrige os defeitos encontrados pelo time de inspeção; Na etapa de Acompanhamento, o time de inspeção é responsável por assegurar que todos os defeitos encontrados foram corrigidos e nenhum outro tipo de defeito foi introduzido na fase de retrabalho. O acompanhamento também pode ser realizado somente pelo moderador.

19 Walkthrough (revisão de apresentação) O autor apresenta o artefato em ordem lógica passo a passo, justifica porque tomou determinadas decisões. O grupo verifica o material a medida que vai sendo apresentado. Os revisores analisam a proposta e procuram apontar falhas e apresentar sugestões.

20 Programação em pares Dois desenvolvedores trabalham simultaneamente no mesmo programa. Esta abordagem facilita a comunicação, revisão das ideias O programa é revisto por duas pessoas

21 Deskcheck É um processo onde procura-se erros em um artefato ou produto de software É realizado pela própria pessoa que desenvolveu o material Peer-Deskcheck É usado quando o autor distribui o artefato para outra pessoa e solicita uma revisão (informal) presencial Passaroud É usado quando o autor distribui o artefato para outra pessoa e solicita uma revisão (informal) não presencial

22 Revisão Ad Hoc É uma revisão informal realizada nas atividades do dia a dia dos membros da equipe na hora do café, no almoço, durante uma conversa. Desenvolvedores utilizam este tipo de revisão frequntemente.

23 Testes estáticos Checklists Objetivos genéricos dos checklists usados nas reuniões Serve de guia para realização da revisão Encontrar os tipos de defeitos mais freqüentes Encontrar problemas de falta de aderência ao padrões estabelecidos e templates Etc.

24 Checklist de requisito: Qualidade geral do documento O documento está de acordo com o modelo padrão? O documento está livre de erros de layout? Os números das páginas do documento estão impressos para facilitar a referência de localização específica durante a inspeção?

25 Checklist de requisito: Qualidade de requisitos Os requisitos foram escritos em linguagem não-técnica permitindo um bom grau de entendimento? Foi elaborado um glossário de temas para auxiliar no entendimento? Os requisitos definem todos os usuários/atores do sistema? As precondições, exceções e saídas esperadas para cada requisito estão claros e definidos? Todas as restrições foram definidas? As mensagens de erros especificadas são únicas e significativas?

26 Checklist Característica s de qualidade Consistência Critério Consistência interna Checklist Os requisitos são consistentes entre si? Consistência externa Os requisitos do cliente são consistentes com os requisitos de documentos relacionados (licitações, cotratos, pedidos de proposta,...)? Clareza clareza O significado de cada requisito é compreensível? Os requisitos estão descritos com um nível de detalhe suficientes para o entendimento?

27 Checklist Característica s de qualidade Completeza Testabilidade Critério Completeza Viabilidade de testes Checklist Todas as necessidades do cliente (inclusive as implícitas) estão identificadas? Todas as restrições e suposições do cliente estão identificadas? Todas os requisitos estão priorizadas? Cada requisito é testável?

28 Exercícios Aponte as principais premissas sobre teste de software