Teste de Software Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br
Qualidade Garantia de Qualidade Qualidade do processo Qualidade do produto Testes Estáticos Testes Dinâmicos
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)
Testes podem mostrar a presença de erros, não a sua ausência (Dijkstra)
Testes são tentativas sistemáticas de encontrar erros em programa que você acha que está funcionando.
Teste estático 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...)
Quem já utilizou teste estático no desenvolvimento de software?
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.
A única forma de garantir que um sistema NÃO POSSUI DEFEITOS seria por meio da execução de todos os testes possíveis, ou seja, testar todas as combinações de valores de entrada possíveis. Será que isso é possível?????
Para que os testes projetados ofereçam maior potencial de encontrar erros com uma quantidade mínima de tempo e esforço, algumas técnicas podem ser utilizadas. O uso de técnicas apoiam na definição de uma condição de teste que é um item ou evento de um componente ou sistema que pode ser verificado por um ou mais casos de teste, ou, simplesmente, o que pode ser testado, também denominado possibilidades do teste.
Técnicas para projeto de casos de teste As técnicas são agrupadas em categorias: Funcional: também conhecida como Teste de Caixa Preta, são usados critérios para geração de casos de teste com o objetivo de avaliar a aderência, ou conformidade do software implementado em relação ao comportamento descrito nos requisitos. Estrutural: também conhecida como Teste de Caixa Branca, são usados critérios para a geração de casos de teste com o objetivo de identificar defeitos nas estruturas internas do software
Classe de equivalência É uma técnica proposta por Myers em 1979, usada para reduzir o número de casos de teste a um nível controlável, mas mantendo uma cobertura razoável de teste. Já que não podemos testar todos os casos existentes, podemos dividi-los em classes, de modo que os casos dentro de cada classe sejam equivalentes.
Classe de equivalência As classes de equivalência devem ser construídas de modo a agrupar os casos de teste para os quais o comportamento do sistema seja o mesmo. Elas podem ser determinadas para os inputs do sistema (classe de entrada) e saída do sistema (classes de saída). Quando possível, também é necessário testar partições não válidas.
Classe de equivalência (data de partida e data de retorno)
Classe de equivalência
Classe de equivalência
Classe de equivalência
Hoje 09/10/12 Ok IDA Data futuras 01/06/13 Ok Datas passadas 01/08/12 Err Datas inválidas 31/02/13 Err Ida e volta no mesmo dia 16/10/12 e 16/10/12 Ok Datas futuras 19/10/12 e 23/10/12 Ok IDA e VOLTA Datas passadas 01/01/11 e 03/01/11 Err Ida inválida e volta válida 31/02/12 e 06/10/13 Err Ida válida e volta inválida 10/12/12 e 31/02/13 Err Volta menor que a ida 20/11/12 e 18/11/12 Err
Valores limítrofes A análise de valor limítrofes é complementar ao particionamento de equivalência O enfoque desta abordagem são os valores que se encontram nos limites ou fronteiras das classes de equivalência Muitos erros tendem a ocorrer nos limites ou fronteiras do domínio de entrada
Tabela de decisão Esta técnica oferece uma representação concisa das condições de entrada e das ações/efeitos correspondentes. A técnica segue quatro passos: São relacionadas causas (condições de entrada) e efeitos (ação) para um módulo, e um identificador é atribuído a cada causa e efeito Uma situação de causa/efeito é desenvolvida Essa situação é convertida numa tabela de decisão As regras da tabela são convertidas em casos de teste
Tabela de decisão Regras de decisão Regra 1 Regra 2 Regra 3 Regra 4 Condi ções resulta dos Estado civil (solteiro) S S N N Estado civil (casado) N N S N Estado civil (casado com comunhão de bens) Vive maritalmente com alguém? (Sim/Não)? Cópia da certidão de nascimento Cópia da certidão de casamento Cópia da certidão de registro do pacto antenupcial Certidão de convivência N N N S N S S S X X X X
Exercício Monte uma tabela de decisão