Engenharia de Software

Transcrição

1 Engenharia de Software Testes de Software Departamento de Matemática Universidade dos Açores Hélia Guerra Causas de faltas e falhas de software Requisitos errados: não é o que o cliente pretende Requisitos em falta Requisitos impossível de implementar Desenho com faltas Escrita de programa com faltas Desenho implementado incorrectamente 2

2 testes Objectivo dos testes: encontrar faltas Um teste diz-se bem sucedido se encontrar alguma falta Identificação de faltas é o processo de determinação das possíveis faltas que causaram a falha Correcção de faltas é o processo de modificação do sistema para remover as faltas (depuração) 3 Tipos de faltas Algorítmicas Computação e precisão Documentação Overloading Capacidade ou limite Timing ou coordenação Desempenho Recuperação Normas e procedimentos 4

3 Faltas algoritmicas Ocorrem quando o algoritmo de um componente não produz o output adequado Poucas/demasiadas alternativas testa a condição errada Não inicializa variáveis ou define os invariantes do ciclo Não testa condição particular Compara variáveis de tipos incompatíveis Faltas sintácticas 5 organização dos testes Testes de unidade Testes de integração Testes de funcionalidade Testes de desempenho Testes de aceitação Testes de instalação 6

4 organização dos testes 7 Atitude perante os testes Egoless programming: programas são componentes de um grande sistema programas não são propriedade de quem os escreve 8

5 Quem executa os testes? Equipa de testes independente evita conflitos melhora a objectividade permite testar e escrever código ao mesmo tempo 9 Estratégias de teste Caixa fechada (closed box ou black box): testes feitos à funcionalidade dos objectos, ignorando a sua estrutura interna Caixa aberta (clear box ou white box): testes feitos tendo em conta a estrutura interna dos objectos Nem sempre é possível testar todas as possibilidades 10

6 caixa aberta 11 factores que influenciam a escolha da estratégia de testes Número de possibilidades Natureza dos dados Quantidade de computação envolvida Complexidade dos algoritmos 12

7 Testes de unidade Revisão do código walkthrough Inspecção Prova da correcção do código Métodos formais Execução simbólica ferramentas automáticas 13 escolha dos casos de teste Determinar os objectivos do teste Seleccionar os casos de teste Definir um teste 14

8 profundidade dos testes Instrução (statement): toda a instrução é executada pelo menos uma vez Alternativa (branch): para cada ponto de decisão, toda a alternativa é executada pelo menos uma vez Caminho (path): todos os possíveis caminhos distintos de instruções são executados pelo menos uma vez Testes de integração Bottom-up Top-down Big-bang... 16

9 Testes de integração Terminologia Component Driver: rotina que chama determinado componente e passa-lhe um caso de teste Stub: programa especial para simular a actividade de um componente que ainda não foi testado 17 Testes de integração Exemplo de um sistema 18

10 Testes de integração Integração bottom-up Sequência de testes e respectivas dependências 19 Testes de integração Integração Top-Down O componente A (de topo) é testado isoladamente 20

11 Testes de integração Integração Big-Bang Componentes testados isoladamente e depois integrados de uma só vez Necessita de stubs e de drivers para testar os componentes 21 comparação de estratégias de integração Bottom-up Topdown Modified topdown Big-bang Sandwich Modified sandwich Integration Early Early Early Late Early Early Time to basic working program Component drivers needed Late Early Early Late Early Early Yes No Yes Yes Yes Yes Stubs needed No Yes Yes Yes Yes Yes Work parallelism at beginning Ability to test particular paths Ability to plan and control sequence Medium Low Medium High Medium High Easy Hard Easy Easy Medium Easy Easy Hard Hard Easy Hard hard 22

12 Testes ao sistema Testes de funcionalidade: verificam se o sistema faz o que foi especificado nos requisitos funcionais Testes de desempenho: verificam os requisitos não funcionais Testes de aceitação: verificam se o sistema funciona de acordo com as espectativas do cliente Testes de instalação: verificam se o sistema funciona correctamente no seu ambiente de instalação 23 Testes ao sistema 24

13 Testes de funcionalidade Comparam a execução do sistema com os requisitos Casos de teste são desenvolvidos baseados no documento dos requisitos 25 testes de desempenho Examinam os cálculos a velocidade de resposta a precisão do resultado a acessibilidade aos dados São desenhados e geridos pela equipa de testes 26

14 Tipos de testes de desempenho Carga Volume Configuração Compatibilidade Operacionais Segurança Ambientais Qualidade Recuperação Manutenção Documentação Usabilidade Timing 27 testes de aceitação Servem para os clientes e utilizadores verificarem se o sistema satisfaz os objectivos e as expectativas Concebidos, geridos e realizados pelos clientes/ utilizadores 28

15 tipos de testes de aceitação Benchmark: cliente prepara conjunto de casos de teste que representam situações típicas de utilização Piloto: sistema instalado numa base experimental para ser utilizado diariamente (sem casos de teste) Alfa: realizado no local onde foi desenvolvido Beta: realizado no local do cliente Paralelo : novo sistema é executado em paralelo com o antigo 29 testes de instalação Podem não ser necessários, caso os testes de aceitação tenham sido realizados no local de funcionamento do sistema Antes de testar Configurar o sistema Ligar todos os dispositivos Estabelecer as comunicações com os outros sistemas Testar operacionalidade: verificar se o sistema foi bem instalado e se funciona correctamente 30

16 Planeamento de testes Estabelecer os objectivos do teste Desenhar os casos de teste Escrever os casos de teste Testar os casos de teste Executar os testes Avaliar os resultados dos testes 31 causas das faltas de software 32

17 documentação de testes Plano: descrição do sistema e plano para exercitar todas as funções e características Especificação e avaliação: detalhes de cada testes e critérios de avaliação Descrição: dados de teste e procedimentos para cada teste Relatório: resultados de cada teste 33 Documentação de testes 34

18 Plano de testes 35 Exemplo Test Requirement 2.4.1: Generate and Maintain Database 1. Add new record X 2. Add field X 3. Change field X 4. Delete record X 5. Delete field X Requirement 2.4.2: Selectively Retrieve Data Requirement 2.4.3: Produced Specialized Reports 6. Create index X Retrieve record with a requested 7. Cell number X 8. Water height X 9. Canopy height X 10. Ground cover X 11, Percolation rate X 12. Print full database X 13. Print directory X 14. Print keywords X 15. Print simulation summary 36 X

19 Exemplo descrição de teste INPUT DATA: Input data are to be provided by the LIST program. The program generates randomly a list of N words of alphanumeric characters; each word is of length M. The program is invoked by calling! RUN LIST(N,M) in your test driver. The output is placed in global data area LISTBUF. The test datasets to be used for this test are as follows: Case 1: Use LIST with N=5, M=5 Case 2: Use LIST with N=10, M=5 Case 3: Use LIST with N=15, M=5 Case 4: Use LIST with N=50, M=10 Case 5: Use LIST with N=100, M=10 Case 6: Use LIST with N=150, M=10 INPUT COMMANDS: The SORT routine is invoked by using the command! RUN SORT (INBUF,OUTBUF) or! RUN SORT (INBUF) OUTPUT DATA: If two parameters are used, the sorted list is placed in OUTBUF. Otherwise, it is placed in INBUF. SYSTEM MESSAGES: During the sorting process, the following message is displayed:! Sorting... please wait... Upon completion, SORT displays the following message on the screen:! Sorting completed To halt or terminate the test before the completion message is displayed, press CONTROL-C on the keyboard. 37 Relatório de testes Documentam o resultado dos testes Fornece informação necessária para duplicar a falha e localizar e corrigir as respectivas causas Fornece informação para se inferir se o projecto está completo Garante a confiança no desempenho do sistema 38

20 COmo relatar uma falha Localização: onde ocorreu? Timing: quando ocorreu? Sintoma: o que foi observado? Resultado: quais foram as consequências? Mecanismo: como ocorreu? Causa: porque ocorreu? Gravidade: qual a intensidade dos danos? Custo: quanto custou? 39 Resumo Faltas versus falhas O objectivo dos testes é encontrar faltas e não provar a correcção Os testes devem iniciar-se o mais cedo possível Os testes baseiam-se no documento dos requisitos Considerar todos os possíveis casos de teste 40