Teste de Software Técnicas para a validação de sistemas de software

Apresentação em tema: "Teste de Software Técnicas para a validação de sistemas de software"— Transcrição da apresentação:

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

2 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

3 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

4 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

5 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

6 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]

7 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

8 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

9 Custo do Teste

10 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

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

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

13 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”

14 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

15 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

16 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

17 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

18

19 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

20 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

21 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

22 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

23 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

24 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

25 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

26 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

27 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

28 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

29 Ambiente para Teste de Unidade
driver módulo stub stub

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 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

39 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

40 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

41 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

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