Abordagem Estratégica ao Teste de Software

1. Abordagem Estratégica ao Teste de Software • A atividade de teste inicia-se no nível de módulos e prossegue “para fora” na direção da integração de todo o sistema baseado em computador • diferentes técnicas de teste são apropriadas e diferentes pontos do tempo • a atividade de teste é realizada pela equipe de desenvolvimento ou por um grupo de teste independente • atividades de teste e de depuração são diferentes, a depuração deve ser acompanhada de uma estratégia de teste

2. Uma Estratégia de Teste de Software • Uma estratégia de teste de software pode ser vista como uma espiral • o teste unitário inicia-se no vértice da espiral e concentra-se em cada unidade do software de acordo com o que é implementado no código fonte • teste de integração - a atenção concentra-se no projeto e na construção da arquitetura do software

3. Estratégia de Teste Engenharia de Sistema S Requisitos R D A Projeto U Código I V ST Teste de Unidade Teste de Integração Teste de Sistema Teste de Validação

4. Uma Estratégia de Teste de Software • Teste de validação - os requisitos estabelecidos como parte da análise de requisitos de software são validados em relação ao software que foi construído • Teste de sistema - o software e outros elementos do sistema são testados como um todo

5. Verificação e Validação • Verificação - conjunto de atividades que garante que o software implemente corretamente uma função específica Estamos construindo certo o produto? • Validação refere-se a um conjunto de atividades que garante que o software foi construído de acordo com as exigências do cliente Estamos construindo o produto certo?

6. Teste de Unidade • A interface com o módulo é testada para ter a garantia de que as informações fluem para dentro e para fora da unidade de programa que se encontra sob teste (testes de caixa branca) • estrutura de dados local é examinada • condições limites são testadas • caminhos independentes são exercitados • caminhos de tratamento de erros são testados

7. Erros mais comuns • Precedência aritmética incorreta • inicialização incorreta • erro de precisão • representação simbólica incorreta de uma expressão • variáveis de laço impropriamente modificadas

8. Erros mais comuns Casos de teste devem descobrir erros de fluxo de controle e comparações: • comparação de diferentes tipos de dados • operadores lógicos ou precedência incorreta • expectativa de igualdade quando um erro de precisão torna a igualdade improvável • comparação ou variável incorreta • término de laço impróprio ou inexistente • variáveis de laço impropriamente modificadas

9. Erros mais comuns Um bom projeto determina que as condições de erro sejam antecipadas e que caminhos de tratamento de erros sejam estabelecidos para re-orientar ou terminar o processamento de forma clara quando um erro ocorrer.

10. No tratamento de erros deve ser testado: • a descrição do erro é inteligível • o erro apontado não corresponde ao erro encontrado • a condição de erro provoca intervenção no sistema antes do tratamento do erro • o processamento das condições de exceção é incorreto • a descrição do erro não oferece nenhuma informação que ajude na localização da causa do erro

11. Teste de Unidade Interface Condições de limite Estrutura de dados locais Caminhos independentes Caminhos de manipulação de erros Driver Módulo a ser testado Casos de teste Stub Stub Resultados

12. Teste de Integração Se todos os módulos funcionam individualmente porque se tem dúvida de que eles funcionarão quando colocados juntos? • Dados podem ser perdidos ao longo da interface • um módulo pode ter um efeito inesperado • funções quando combinadas podem não produzir a função principal esperada

13. Teste de Integração • imprecisão individualmente aceitável pode ser ampliada até níveis inaceitáveis • estruturas de dados globais podem apresentar problemas • são usados testes de caixa preta

14. Teste de Integração O objetivo do teste de integração é a partir dos módulos testados no nível de unidade construir a estrutura de programa que foi determinada pelo projeto. • Integração big-bang o programa completo é testado como um todo • Integração incremental o programa é construído e testado em pequenos segmentos, os erros são mais fáceis de serem encontrados e corrigidos

15. Estratégias de Integração Top-down M1 M2 M3 M4 M7 M5 M6 • Os módulos são integrados movimentando-se de cima para baixo • módulos subordinados podem ser incorporados de uma maneira depth-first ou breadth-first M8

16. Estratégias de Integração Top-down • O módulo controle principal é usado como driver de testes • stubs subordinados são substituídos um de cada vez por módulos reais • testes são realizados a cada módulo integrado • testes de regressão

17. Integração Bottom-up • os módulos são integrados movimentando-se de baixo para cima M1 M2 M3 D2 D1 Cluster

18. Teste de Integração Quando o teste de integração é feito o analista deve identificar os módulos críticos. O módulo crítico se caracteriza por: • abordar diversos requisitos do software • tem elevados níveis de controle • é complexo ou propenso a erros • tem requisitos de desempenho definidos concentre testes de regressão em módulos críticos

19. Estratégia de Teste • Depois da integração os critérios de validação especificados na análise de requisitos devem ser testados, ele garante exigências funcionais, comportamentais e de desempenho. São usadas técnicas de caixa preta. Após a realização do teste: • as características de função ou desempenho conformam-se as especificações e são aceitas • um desvio é descoberto e uma lista de deficiências é criada

20. Testes de Aceitação • Capacitam o cliente a validar todos os requisitos. Realizado pelo usuário final e não pelo desenvolvedor do sistema. • Teste alfa - é levado a efeito por um cliente nas instalações do desenvolvedor. Erros e problemas serão registrados durante a interação. • Teste beta - é realizado nas instalações do cliente pelo usuário final. A interação não é controlada pelo desenvolvedor, problemas encontrados são relatados posteriormente ao desenvolvedor.

21. Estratégia de Teste - teste de sistema O teste de sistema procura verificar se elementos como hardware, pessoas, bancos de dados, etc estão adequados em função do desempenho global do sistema. • Projete casos de teste que simulem todas as entradas de dados de outros sistemas • realize testes simulando dados ruins ou erros em potencial para a interface • registre e documente o caso de testes • participe do planejamento para garantir que o teste seja adequado

22. Estratégia de Teste - teste de recuperação Força o software a falhar de diversas maneiras verificando se a recuperação é adequadamente executada.

23. Estratégia de Teste - teste de segurança Tenta verificar se todos os mecanismos de proteção embutidos em um sistema protegerão, de fato, acessos indevidos. O papel do projetista do sistema é fazer com que o acesso custe mais do que o valor da informação que será obtida

24. Estratégia de Teste - teste de estresse Executa o sistema de forma a exigir recursos em quantidade, freqüência e volume anormais. Exemplo: Casos de teste que exigem máxima memória

25. Estratégia de Teste - teste de desempenho É realizado para testar o desempenho de run-time do software dentro do contexto de um sistema integrado. Ocorre ao longo de todos os processos de teste, porém só quando todos os módulos estão interligados é que o desempenho real pode ser verificado.

26. Estratégia de Teste Engenharia de Sistema S Requisitos R D A Projeto U Código I V ST Teste de Unidade Teste de Integração Teste de Sistema Teste de Validação

27. 1. Descreva a diferença entre validação e verificação 2. Liste alguns problemas que poderiam estar associados a criação de um grupo de testes independente. 3. Se voc ê pudesse escolher 3 métodos de projeto de caso de teste para aplicar durante os testes de unidade quais seriam eles? 4. Quem deve realizar o teste de validação do software o desenvolvedor ou o usuário do software?