Bloco de português com artigo de opinião 8º A, B 3.docx
Engenharia Software I Testes
1. Engenharia do Software I Manuel Menezes de Sequeira DCTI, ISCTE-IUL Manuel.Sequeira@iscte.pt, D6.02 As apresentações desta série baseiam-se nas apresentações disponibilizadas por IanSommerville, tendo sido alteradas e adaptadas primeiro por Anders Lyhne Christensen e finalmente por Manuel Menezes de Sequeira.
2. Na aula anterior Verificação e validação Planeamento da verificação e validação Inspecções de software Análise estática automática Desenvolvimento de software em sala limpa 2009/2010 2 Engenharia do Software I
4. Sumário Testes de software Teste de sistemas Teste de componentes Desenho de casos de teste Automatização de testes 2009/2010 4 Engenharia do Software I
5. Objectivos Discutir diferença entre testes de validação e de defeitos Descrever princípios de testes de sistema e de componentes Descrever estratégias para gerar casos de teste para sistemas Compreender características essenciais das ferramentas de automatização de testes 2009/2010 5 Engenharia do Software I
6. Processo de testes Testes de componentes Teste de componentes individuais do programa Usualmente responsabilidade de desenvolvedor do componente (excepto por vezes em sistemas críticos) Testes derivados da experiência do desenvolvedor Testes de sistema Teste sistemas ou um subsistemas (compostos de componentes) Responsabilidade de equipa de testes independente Testes baseados em especificação do sistema 2009/2010 Engenharia do Software I 6
7. Fases de teste 2009/2010 7 Engenharia do Software I Testes de componentes Testes de sistemas Desenvolvedor do software Equipa de testes independente
8. Testes de defeitos Objectivo é descobrir defeitos em programas Teste com sucesso leva programa a comportamento anómalo Mostram presença e não ausência de defeitos 2009/2010 Engenharia do Software I 8
9. Objectivos do processo de testes Testes de validação Demonstra a desenvolvedor e cliente do sistema que software cumpre requisitos Teste com sucesso mostra que sistema se comporta como pretendido Testes de defeitos Descobre erros ou defeitos no software levando a comportamento incorrecto ou que não corresponde à especificação Teste com sucesso leva sistema a comportar-se incorrectamente, assim expondo um defeito no sistema 2009/2010 Engenharia do Software I 9 Um teste que não descubra erros ou defeitos é inconclusivo.
10. Processo de testes de software 2009/2010 10 Engenharia do Software I Casos de teste Dados de teste Resultados dos testes Relatórios dos testes Desenhar casos de teste Preparar dados de teste Executar programa com dados de teste Comparar resultado com casos de teste
11. Políticas de testes Testes exaustivos podem mostrar ausência de defeitos Testes exaustivos geralmente impossíveis Políticas de testes definem abordagem a usar na escolha de testes de sistema Testar todas funcionalidades acessíveis em menus Testar combinações de funcionalidades acedidas no mesmo menu Quando for necessário introduzir dados do utilizador, testar todas funcionalidades com entradas correctas e incorrectas 2009/2010 Engenharia do Software I 11
12. Testes de sistemas Envolvem integrar componentes de modo a formarem sistema ou subsistema Podem envolver testar incremento a fornecer a cliente 2009/2010 Engenharia do Software I 12
13. Fases dos testes de sistemas 2009/2010 Engenharia do Software I 13
14. Testes de integração Envolve Construir sistema a partir de componentes Ir testando para revelar problemas gerados por interacção entre componentes Integração deve ser incremental para simplificar localização de erros 2009/2010 Engenharia do Software I 14
16. Testes de integração incrementais 2009/2010 16 Engenharia do Software I T1 T1 T1 A A A T2 T2 T2 B B B T3 T3 T3 C C T4 T4 D T5 Sequência de testes 3 Sequência de testes 2 Sequência de testes 1
17. Abordagens aos testes 2009/2010 Engenharia do Software I 17 Descendente Facilita validação arquitectónica, i.e., descoberta de erros na arquitectura do sistema Permite demonstração limitada do sistema mesmo em fases iniciais do desenvolvimento Observação dos testes pode exigir código extra Ascendente Facilita muitas vezes implementação dos testes Observação dos testes pode exigir código extra
18. Testes de lançamento Processo de teste do lançamento do sistema a fornecer a clientes Objectivo principal: aumentar confiança de fornecedor no cumprimento de requisitos Normalmente de caixa preta ou funcionais Baseados só na especificação do sistema Testadores não conhecem implementação 2009/2010 Engenharia do Software I 18
19. Testes de caixa preta 2009/2010 19 Engenharia do Software I Dados de entrada do teste Entradas causadoras de anomalias Sistema Resultados de saída do teste Resultados reveladores de defeitos
20. Linhas de orientação para testes Escolher entradas Gerando todas as mensagens de erro Levando a transbordamentos de memória Repetir várias vezes mesma entrada ou sequência de entradas Forçar geração de saídas inválidas Forçar cálculo de valores além dos limites 2009/2010 Engenharia do Software I 20 Dicas para equipa escolher testes que revelem defeitos no sistema.
21. Cenário de teste Na Escócia, uma estudante está a estudar a história americana e foi convidada a escrever um artigo sobre a “mentalidade de fronteira no oeste americano de 1840 a 1880”. Para o fazer, precisa de encontrar fontes bibliográficas numa série de bibliotecas. Assim, autentica-se no sistema LIBSYS e usa o mecanismo de pesquisa para descobrir se pode aceder a documentos originais da época. Descobre fontes bibliográficas em várias bibliotecas universitárias dos EUA e descarrega cópias de algumas dessas fontes. No entanto, para um dos documentos é necessário que a sua universidade confirme que ela é realmente estudante e que a fonte será utilizada para fins não comerciais. A estudante usa o mecanismo do LIBSYS que permite solicitar essa autorização e regista o seu pedido. Se o pedido for concedido, o documento será transferido para o servidor da biblioteca e impresso. Ela receberá então uma mensagem do LIBSYS dizendo que irá receber uma mensagem de correio electrónico assim que o documento impresso estiver disponível para recolha. 2009/2010 Engenharia do Software I 21
22. Testes de sistema Testar mecanismo de autenticação usando credenciais válidas e inválidas para verificar se utilizadores com credenciais válidas são aceites e se utilizadores com credenciais inválidas são rejeitados. Testar mecanismo de pesquisa usando diferentes interrogações a diferentes fontes de informação para verificar se mecanismo de facto encontra documentos. Testar mecanismo de apresentação para verificar se informação é apresentada correctamente. Testar mecanismo de pedido de autorização para descarregamento. Testar resposta via correio electrónico que indica que documento descarregado está disponível. 2009/2010 Engenharia do Software I 22
23. Casos de uso Podem ser base para obtenção de testes de sistema Ajudam a identificar operações a testar e ajudam a conceber os casos de teste necessários A partir de diagrama de sequência associado, indentificar entradas e saídas a usar nos testes 2009/2010 Engenharia do Software I 23
24. Diagrama de sequência da recolha de dados meteorológicos 2009/2010 24 Engenharia do Software I sd data collection : CommunicationsController : WeatherStation : WeatherData getReport() acknowledge() getReport() getSummary() acknowledge()
25. Testes de desempenho Testes de lançamento podem envolver teste a propriedades emergentes Testes de desempenho Testes de fiabilidade Planear série de testes com carga crescente até desempenho ficar inaceitável 2009/2010 Engenharia do Software I 25
26. Testes de estresse Sujeitam sistema a cargas superiores a máximo previsto tentando revelar defeitos Aferem comportamento em caso de falha Sistema não pode falhar catastroficamente Falhas não podem levar a perdas inaceitáveis de serviço ou dados Muito relevantes para sistemas distribuídos que podem sofre degradação séria perante rede sobrecarregada 2009/2010 Engenharia do Software I 26
27. Testes de componentes ou testes unitários Processo de testar isoladamente componentes individuais É processo de teste de defeitos 2009/2010 Engenharia do Software I 27
28. Componentes ou unidades (de modularização) Rotinas Funções e procedimentos isolados Operações de classes e seus objectos Classes e respectivas propriedades e operações Componentes compósitos com interface definida para aceder à sua funcionalidade 2009/2010 Engenharia do Software I 28
29. Testes de classes (de objectos) Cobertura completa de classe por testes implica Testar todas as operações Alterar e inspeccionar todas as propriedades Fazer objectos passar por todos os estados representativos Fazer objectos passar por todos os possíveis fluxos de controlo Herança dificulta desenho de testes para classes, pois informação está disseminada 2009/2010 Engenharia do Software I 29
30. Interface de estação meteorológica 2009/2010 30 Engenharia do Software I WeatherStation + reportWeather() + calibrate(instruments) + test() + startup(instruments) + shutdown(instruments)
31. Teste da estação meteorológica Necessário definir casos de teste para reportWeather() calibrate() test() startup() shutdown() 2009/2010 Engenharia do Software I 31
32. Teste da estação meteorológica Usando modelo de transição de estados Identificar sequências de transição a testar Identificar sequências de eventos que as causem Exemplo Esperando Calibrando Testando Transmitindo Esperando 2009/2010 Engenharia do Software I 32
33. Testes de interfaces Detectar anomalias devidas a Erros de interface Suposições inválidas acerca das interfaces Especialmente importantes em desenvolvimento orientado para objectos (classes de objectos definidas pela interface) 2009/2010 Engenharia do Software I 33
37. Linhas de orientação para testes de interface Invocar rotinas com valores extremos dos argumentos Invocar rotinas com argumentos nulos onde parâmetros forem ponteiros ou referências Tentar fazer os componentes falhar Fazer testes de estresse em sistemas com passagem de mensagens Variar ordem de activação de componentes em sistemas com memória partilhada 2009/2010 Engenharia do Software I 37
38. Desenho de casos de teste Desenho de casos de teste (entradas e saídas) usados para testar sistema Objectivo: criar conjunto de testes eficazes na validação e nos testes de defeitos Abordagens Testes baseados em requisitos Testes de partição Testes estruturais 2009/2010 Engenharia do Software I 38
39. Testes baseados em requisitos Requisitos têm de ser testáveis Técnica de testes de validação Conjunto de testes derivado para cada requisito 2009/2010 Engenharia do Software I 39 Princípio geral da engenharia de requisitos
42. Testes de partições Entradas e saídas muitas vezes em diferentes classes cujos membros estão relacionados Cada classe é partição ou domínio de equivalência para cujos membros comportamento do programa é equivalente Devem escolher-se casos de teste em cada partição 2009/2010 Engenharia do Software I 42
43. Partições de equivalência 2009/2010 43 Engenharia do Software I entradas válidas entradas inválidas Sistema saídas
44. Partições de equivalência 2009/2010 44 Engenharia do Software I 3 11 4 10 7 Número de entradas Menos de 4 Entre 4 e 10 Mais de 10 9 999 100 000 10 000 99 999 50 000 Valores da entrada Menos de 10 000 Entre 10 000 e 99 999 Mais de 99 999
45. Especificação de rotina de pesquisa procedure Search(element : inElement_T; sequence : inarray (Integer range <>) ofElement_T; elementFound : inout Boolean; index : inout Integer) is with Pre => -- the sequence has at least one element sequence'FIRST <= sequence'LAST, Post => -- the element is found and is referenced by index (elementFoundand sequence(index) = element) or -- the element is not in the sequence (notelementFoundand not (exists i, sequence'FIRST <= i <= sequence'LAST, sequence(i) = element)); 2009/2010 Engenharia do Software I 45 Artificial…
46. Partição das entradas Entradas Que não cumprem a pré-condição Que cumprem a pré-condição Em que o elemento ocorre na sequência Em que o elemento não ocorre na sequência 2009/2010 Engenharia do Software I 46
47. Linhas de orientação para testes (sequências) Usar sequências vazias Usar sequências com um único elemento Usar sequências com diferentes comprimentos em diferentes testes Forçar acesso a primeiro elemento, último elemento e elemento central 2009/2010 Engenharia do Software I 47
50. Testes estruturais Também conhecidos por testes de caixa branca Derivação de casos de teste de acordo com estrutura do programa Conhecimento do programa usado para identificar casos de teste adicionais Objectivo é exercitar todas instruções do programa e não todos possíveis caminhos 2009/2010 Engenharia do Software I 50
51. Testes estruturais 2009/2010 51 Engenharia do Software I Dados de teste derivar testar Código do componente Resultados do teste
52. Especificação de rotina de pesquisa binária procedureSearchIncreasing(element : inElement_T; sequence : inarray (Integer range <>) ofElement_T; elementFound : inout Boolean; index : inout Integer) is with Pre => -- the sequence is increasing (foralli, sequence'FIRST <= i < sequence'LAST, sequence(i) <= sequence(i + 1)), Post => -- the element is found and is referenced by index (elementFoundand sequence(index) = element) or -- the element is not in the sequence (notelementFoundand not (exists i, sequence'FIRST <= i <= sequence'LAST, sequence(i) = element)); 2009/2010 Engenharia do Software I 52
53. Partição das entradas Entradas Que não cumprem a pré-condição Que cumprem a pré-condição Em que o elemento ocorre na sequência Em que o elemento não ocorre na sequência Sequência vazia Sequência com um único elemento Sequência com um número par de elementos Sequência com um número ímpar de elementos 2009/2010 Engenharia do Software I 53
54. Partições de equivalência 2009/2010 54 Engenharia do Software I Centro Primeiro Último Centro + 1 Centro - 1 Inferiores Superiores Classes de equivalência
56. Teste de caminhos Objectivo: assegurar que conjunto de casos de teste garante que cada caminho é executado pelo menos uma vez Começar por obter grafo de fluxo do programa mostrando nós representando decisões do programa e arcos representando o fluxo de controlo Instruções com condições são por isso nós do grafo de fluxo de controlo 2009/2010 Engenharia do Software I 56
57. Implementação da pesquisa binária public <T extends Comparable<T>> void search(final T element, final List<T> sequence) { 1 indexOfFoundElement = -1; 2 found = false; 3 int left = 0; 4 int right = sequence.size() - 1; 5 while(left <= right) { 6 final int middle = (left + right) / 2; 7 int comparison = sequence.get(middle).compareTo(element); 8 if(comparison == 0) { 9 found = true; 10 indexOfFoundElement = middle; 11 return; 12 } else if(comparison < 0) 13 left = middle + 1; else 14 right = middle - 1; } 15 } 2009/2010 Engenharia do Software I 57
58. Grafo de fluxo da pesquisa binária 2009/2010 58 Engenharia do Software I 1 2 3 4 left > right 5 left <= right 6 comparison < 0 7 13 comparison == 0 comparison != 0 8 9 12 14 10 comparison > 0 11 15
60. Caminhos independentes Desenvolver casos de teste que levem a execução de cada um dos caminhos Um analisador dinâmico de programas pode ser usado para verificar que todos os caminhos foram executados 2009/2010 Engenharia do Software I 60
61. Automatização de testes Testar é caro Bancadas de trabalho para testes ajudam a automatizar o processo Bancadas de trabalho para testes Ferramentas para poupar tempo e custo dos testes Sistemas como JUnit suportam execução automática de testes Maioria são sistemas abertos, assim suportando especificidades das organizações Por vezes difíceis de integrar com bancadas de trabalho fechadas para desenho e análise 2009/2010 Engenharia do Software I 61
62. Uma bancada de trabalho para testes 2009/2010 62 Engenharia do Software I Gerador de dados de teste Especificação Oráculo Dados de teste Gestor de testes Código fonte Programa em teste Resultados dos testes Previsões dos testes Analisador dinâmico Relatório de execução Simulador Comparador de ficheiros Relatório dos resultados dos testes Gerador de relatórios
63. Adaptação da bancada de trabalho para testes Scripts para simuladores de interfaces com o utilizador e padrões para geradores de dados Preparação manual de saídas dos testes para posterior comparação Desenvolvimento de comparadores de ficheiros especializados 2009/2010 Engenharia do Software I 63
64. A reter Testes Revelam erros em sistema Não demonstram ausência de erros De componentes: desenvolvedores De sistema: outra equipa De integração: incrementos a sistema De lançamento: sistema a fornecer Desenhados recorrendo a experiência e linhas de orientação 2009/2010 Engenharia do Software I 64
65. A reter Testes de interface revelam defeitos em interfaces de componentes compósitos Partições de equivalência para descobrir casos de teste – casos em partição têm comportamento equivalente Análise estrutural analisa programa e deriva casos de teste Automatização de testes reduz custos através de múltiplas ferramentas software 2009/2010 Engenharia do Software I 65
66. A ler IanSommerville, Software Engineering, 8.ª edição, Addison-Wesley, 2006 Capítulo 23 2009/2010 Engenharia do Software I 66