Teste de Software Técnicas para a validação de sistemas de software Ana de Alencar Price Instituto de Informática - UFRGS

Tópicos a serem Abordados Certificação de Software Príncipios do Teste Estratégias de Teste Teste Funcional Teste Estrutural Teste Simbólico Teste de Software Orientado a Objetos Ferramentas de apoio ao Teste

Bibliografia G. Myers. The Art of Software Testing R. Pressman. Software Engineering R. Fairley: Software Engineering Concepts W. Hetzel. The Complete Guide to Software Testing Artigos de periódicos: Transactions on Software Engineering IEEE Software Comm. Of The ACM

Avaliação de Qualidade de Software Fatores de qualidade correto, confiável completo, consistente, preciso eficiente, factível Técnicas de Certificação Análise Estática Análise Dinâmica = Teste Teste Simbólico Verificação Formal => Software Correto

Análise Estática análise do código fonte sem executá-lo Inspeções entender o programa para descobrir erros Walkthroughs execução simulada do programa

Teste de Software “Teste consiste em executar o programa com a intenção de encontrar erros” [Myers] verificação incompleta não garante a inexistência de erros no programa pode ser usado para mostrar a presença de erros, mas nunca sua ausência [Dijkstra]

Teste Simbólico consiste em executar o programa com dados simbólicos ao invés de dados reais valores de variáveis resultam em fórmulas predicados de caminho = conjunção de condições do caminho executado predicados de caminho => deteminar dados que exercitam os caminhos lógicos do programa

Verificação Formal especificação formal do programa provador de teoremas: demonstrar matematicamente que o programa satisfaz as especificações aplicações restritas, programas pequenos provas formais são difíceis programadores não treinados possibilita a inserção de erros na demonstração cara e demorada vantagem: quando usada corretamente garante a correção ou não do programa

Custo do Teste

Custo do Teste 30-50% do custo de desenvolvimento causas: falta planejamento, tempo escasso falta metodologia inserção de novos erros ponto crucial: seleção de dados dados de teste óbvios, randômicos, viciados seleção adhoc ou randômica: segmentos de programas não testados casos de teste rigorosamente selecionados

Teste Exaustivo nodos = blocos de comandos sequenciais 1 a 20 arcos = fluxo de controle número de caminhos: 5 +(5x5)+...=1.0E14

PROBLEMA Determinar casos de teste (dados+resultados esperados) para o seguinte programa: O programa lê três valores inteiros que devem corresponder aos lados de um triângulo. Caso não sejam, o programa deve emitir a mensagem: “não é triângulo”. Caso contrário, o programa emitirá mensagem identificando o tipo de triângulo (“equilátero”, “isósceles”, ou “escaleno”). Assumir que os três valores são digitados e são inteiros.

Casos de testes para o programa do Triângulo 1) 1 caso válido para triângulo equilátero “equilátero” 2) 1 caso válido para triângulo escaleno “escaleno” 3) 3 casos válidos para triângulo isósceles “isósceles” 4) 3 casos para testar Li + Lj < Lk “não é triângulo” 5) 3 casos para testar Li + Lj = Lk “não é triângulo” 6) 3 casos para testar um dos lados = 0 “não é triângulo” 7) 3 casos para testar um dos lados < 0 “não é triângulo”

Princípios do Teste [Myers] não planeje o teste assumindo que o programa está correto um bom caso de teste é aquele que tem alta probabilidade de encontrar erro ainda não descoberto caso de teste bem sucedido é aquele que detecta erro ainda não descoberto a probabilidade de existência de mais erros numa parte do programa é proporcional ao número de erros já descoberto na mesma

Princípios do Teste [Myers] teste deve ser feito por outra pessoa que não o autor do programa dados de teste devem ser definidos para dados inválidos e não-esperados determinar SEMPRE os resultados esperados verificar cuidadosamente os resultados de cada teste nunca jogue fora casos de teste, a não ser que esteja jogando fora também seu programa

Teste de Software Objetivo: Suposição incorreta: Depuração: “Executar o programa com a intenção de descobrir erros” [Myers] Suposição incorreta: “Mostrar que o programa funciona corretamente” Depuração: “Processo para identificar, localizar e corrigir erros” custo/esforço de difícil previsão tempo para identificar um erro: minutos, horas, dias

Fluxo de informações na Fase de Teste Configuração do Sistema programa fonte correções Depuração Teste resultados erros Avaliação Teste plano/casos de teste resultados esperados análise dos erros Avaliação Qualidade Configuração de Teste modificações aceitação do sistema

Atividades do Processo de Teste determinar casos de teste escolher estratégia, critério (conclusão dos testes) selecionar dados e determinar resultados esperados executar os testes montar cenários (drivers e stubs) instrumentar programa (asserções, sinalizadores) avaliar os resultados comparar resultados computados c/esperados avaliar a satisfação do critério

Seleção de Dados de Teste atividade mais crítica do processo dados devem ser selecionados para encontrar erros teste de sucesso {Myers] => aquele que encontra erro seleção depende da estratégia de teste funcional (black-box) estrutrural (white-box) mutação

Tipos de Teste Funcional ou Caixa-preta Estrutural ou Caixa-aberta baseado na Especificação de Requisitos verifica se as funções do produto são realizadas adequadamente Estrutural ou Caixa-aberta baseado no código fonte verifica quais funções foram implementadas Mutação ou Teste baseado em erros introduzir modificações num programa P, suposto correto, criando-se mutantes, que se executados resultarem em erro, pode-se dizer que P está correto

Teste Randômico dados gerados randômicamente elevado número de dados de teste problema: determinar os resultados esperados certas condições podem não ser testadas trabalhos comprovam eficácia

Teste Funcional dependente da especificação de requisitos DADOS RESULTADOS dependente da especificação de requisitos seleção de dados baseada nas condições de entrada avaliação de cobertura das funcionalidades

Teste Estrutural teste de caminho dependente do código fonte DADOS RESULTADOS teste de caminho dependente do código fonte grafo de fluxo de controle critérios de cobertura de caminhos

Estágios de Teste Teste de Unidade Teste de Integração assegurar que cada módulo funciona apropriadademente Teste de Integração montagem do software e verificação das interfaces Teste de Aceitação assegurar que o software satisfaz os requisitos do usuário Teste de Sistema integração do software com outros sistemas

Teste de Unidade teste de caixa aberta (estrutural) conduzido em paralelo para vários módulos características avaliadas interface operações sobre variáveis caminhos de execução importantes caminhos de atendimento a erros condições de contorno

Teste de Unidade: características avaliadas interface dados entram e saem corretamente número e tipo de parâmetros - compatibilidade operações sobre variáveis cálculos incorretos over/underflow, índices, etc. caminhos de execução caminhos importantes caminhos de atendimento a erros

Teste de Unidade: características avaliadas atendimento a erros rotina de erro corresponde ao erro encontrado erro causa intervenção do sistema antes do atendimento mensagem elucida causa do erro? condições de contorno testes com valores máximo, mínimo, imediatamente abaixo e acima de itens de dados e de variáveis de controle de “loops” erros comuns precedência de operadores incorreta comparações de tipos de dados diferentes terminação inexistente de ciclos erros de precisão

Ambiente para Teste de Unidade driver módulo stub stub

Cenários de Teste driver stubs módulo que chama o módulo em teste contém inicializações das variáveis globais e dos parâmetros reais da chamada stubs módulos chamados pelo módulo testado contém comandos para recebimento de parâmetros de entrada e devolução de valores de saída

Planejamento do Teste de Unidade escolha de critério de cobertura lógica selecionar caminhos de teste determinar casos de teste caso de teste dado de teste resultado esperado

Teste de Integração montagem do software com módulos já testados verificação da interface entre módulos funções parciais e global do sistema estratégias de integração topdown bottom-up mista

Integração Topdown integração parte do módulo principal para os módulos que implementam funções primitivas tipos: vertical: segundo o fluxo principal de controle horizontal: incorpora todos os módulos diretamente subordinados a cada nível

Integração Top-down módulo principal usado como driver módulos diretamente subordinados substituídos por stubs stubs são substituídos um de cada vez testes de regressão asseguram que não houve introdução de novos erros

Integração Bottom-up módulos inferiores combinados em grupos drivers são escritos para testar grupos drivers são substituídos por módulos integradores de grupos

Topdown X Bottom-up top-down bottom-up programa principal + alguns módulos = protótipo erros de interface são descobertos cedo erros em módulos critícos de níveis inferiores são descobertos tarde no início requer pouca mão-de-obra bottom-up ajuste mais fácil das necessidades de mão-de-obra ao pessoal disponível erros de interface são descobertos tarde muitos módulos precisam ser integrados antes que se tenha uma idéia do programa

Teste de Integração seleção de estratégia Teste Misto características do software cronograma do projeto enfoque combinado Teste Misto Topdown modificado Sandwich Big-bang

Teste de Integração Misto Top-down Modificado módulos críticos são testados com drivers em paralelo à integração topdown Sandwich teste realizado a partir das extremidades drivers e stubs são necessários Big-bang integração de todos os módulos ao mesmo tempo dificuldade de descobrir origem dos erros

Plano de Integração fluxo de controle do sistema estratégia de integração ordem de acoplamento determinar casos de teste gerar drivers e stubs

Testes de Aceitação e de Sistema Teste de Aceitação demonstrar conformidade com a Especificação de Requisitos testes funcional e de desempenho Teste de Sistema teste de integração com outros sistemas (software e hardware) teste de aceitação conduzido pelo usuário final

Plano de Teste do Software Conteúdo Plano de Teste de cada unidade Plano de Integração Plano para o Teste de Aceitação e de Sistema Benefícios do Plano de Teste indução ao teste sistemático facilita testes de regressão facilita manutenção facilita teste de integração quando da evolução do sistema

Considerações Finais Teste: fase fundamental no desenvolvimento de software. Teste e manutenção consomem 60% dos recursos de desenvolvimento Escassez ferramentas CASE para suporte destas fases Desenvolvimento de métodos e ferramentas Avaliação de Qualidade - parte da rotina, ao invés de procedimento especial.