Apêndice 1. Recomendações para testes de módulos

Transcrição

1 Recomendações para testes de módulos - 1 Apêndice 1. Recomendações para testes de módulos O presente conjunto de recomendações tem por objetivo definir um conjunto mínimo de critérios de seleção de casos de teste de aplicação simples, porém suficientemente eficaz para uma parcela significativa de aplicações. As recomendações visam o controle da qualidade de módulos de risco baixo a mediano, que operem em contexto mono-programado e que contenham cálculo numérico de baixa complexidade. Testes que visem o controle da qualidade de módulos com outras características requererão o uso de critérios de seleção de casos de teste adicionais. 1.1 Recomendações gerais Recom. 1. Recom. 2. Recom. 3. Recom. 4. Recom. 5. Recom. 6. Estabeleça o rigor dos testes em função da qualidade requerida para o artefato em teste. Assegure que o artefato a testar esteja suficientemente instrumentado para o rigor de teste estipulado. Somente inicie testes após ter realizado uma inspeção cuidadosa do artefato a testar. Somente inicie os testes após ter realizado uma inspeção cuidadosa do roteiro de teste, dos cenários de teste, e da massa de testes, conforme se aplique. Utilize depuradores somente em último recurso. Para cada artefato mantenha um Caderno de Acompanhamento de Problemas, contendo os itens da tabela abaixo. Registre neste caderno: todos os testes realizados; todos os casos de teste que tenham identificado algum problema (laudo). Data Id caso de teste Sintoma Data correção Artefatos alterados Classe da falta Correção realizada Apnd10-RecomTestes.doc 6/06/2016

2 2 - Programação Modular Recom. 7. Recom. 8. Recom. 9. Registre em um laudo todas as falhas e defeitos encontrados durante os testes. Utilize o Caderno de Acompanhamento de Problemas do artefato para manter o laudo. Mantenha uma lista de classes de faltas freqüentes comum a todos os projetos da organização. O grau de detalhe da lista deve ser compatível com o detalhe de controle sobre o processo de desenvolvimento. Após aceitar a nova versão do artefato, arquive o caderno de acompanhamento de problemas, os documentos descrevendo os o roteiro de teste, os cenários de teste, e o laudo do teste, arquive também a massa de teste utilizada, conforme o caso. Recom. 10. Reveja ou até refaça a especificação, o projeto e a implementação de módulos que apresentem um elevado número de problemas. Recom. 11. Somente execute um caso de teste depois que o correspondente resultado esperado estiver definido. Recom. 12. Assegure que o resultado esperado esteja consistente com a especificação do artefato em teste. Recom. 13. Assegure que a última execução de teste de um artefato novo tenha aplicado todo o roteiro de teste, envolvendo todos os cenários e toda a massa de testes prevista. Recom. 14. Assegure que o teste de um artefato alterado seja seguido de um teste de regressão, examinando todos os artefatos que interagem diretamente com o artefato em teste. Recom. 15. Realize o teste de regressão em uma plataforma semelhante à da produção. Em particular, realize o teste de regressão fora do contexto de ambientes integrados de desenvolvimento (IDE). Recom. 16. Procure realizar os testes de aceitação de um artefato utilizando uma equipe diferente da que o desenvolveu. 1.2 Cobertura de funções Recom. 17. Assegure que todas as funções e métodos tenham sido testadas no conjunto de todos os casos Recom. 18. Assegure que todas as mensagens previstas tenham sido emitidas pelo menos uma vez no conjunto de todos os casos

3 Recomendações para testes de módulos - 3 Recom. 19. Assegure que todas as exceções previstas por uma função tenham sido exercitadas pelo menos uma vez no conjunto de todos os casos Recom. 20. Assegure que todos os pontos de sinalização de exceções (throw) de uma função tenham sido executados pelo menos uma vez no conjunto de todos os casos Recom. 21. Assegure que todas as condições de retorno de uma função tenham sido exercitadas pelo menos uma vez no conjunto de todos os casos Recom. 22. Assegure que todos os pontos de retorno (return) de uma função tenham sido exercitadas pelo menos uma vez no conjunto de todos os casos Recom. 23. Sempre gere casos de teste examinando o comportamento do elemento (ex.: função, classe, diálogo, menu) para valores de entrada válidos e para valores de entrada não válidos. Exceção 24. Caso a especificação estabeleça explicitamente que os dados de entrada devem ser assumidos estarem corretos, não será necessário testar o componente com dados de entrada não válidos. 1.3 Valoração dos dados Recom. 25. Ao testar uma condição a <= b escolha sempre os valores a == b -, a == b e a == b +. O valor de é o menor valor possível que torne verdadeira a relação a < b enquanto for verdadeira a relação a + >= b. Recom. 26. Ao testar valores que sejam sujeitos a vários domínios de validade, realize os testes segundo Recom. 25 para cada um dos domínios. Recom. 27. Ao testar valores de tamanho variável, gere um caso de teste para cada um de tamanho zero, tamanho mínimo-1, tamanho mínimo, tamanho médio, tamanho máximo e tamanho máximo+1. Exceção 28. No caso da especificação estabelecer explicitamente o fato dos dados de entrada serem assumidos estarem corretos, não será necessário testar o componente com dados de entrada possuindo tamanhos não válidos.

4 4 - Programação Modular Recom. 29. Ao testar o acesso a valores contidos em um conjunto dinamicamente criado (ex.: tabelas, listas, arquivos), gere um casos de teste para cada um de conjunto vazio, conjunto com exatamente um elemento e em conjuntos com 3 ou mais elementos. Os casos de teste devem contemplar acessos a valores pertencentes e não pertencentes a cada um desses conjuntos. Recom. 30. Ao testar o acesso ou a localização de um valor em um conjunto dinamicamente criado e que contenha três ou mais elementos, gere casos de teste para acessar o primeiro, um no meio do conjunto e o último. Recom. 31. Caso o valor seja um elemento de um conjunto enumerado, crie um caso de teste para cada uma dos itens da enumeração. Recom. 32. Caso os valores de um conjunto enumerado sejam discriminados em uma tabela, deve-se inspecionar a tabela, verificando se está efetivamente completa e correta, e deve-se gerar casos de teste para os valores inicial e final da tabela, algum valor no meio e valores menor (maior) do que o primeiro (último) valor da tabela, onde estes valores não devem figurar na tabela. Recom. 33. Caso um elemento A admita um outro elemento B com efeito inverso, realize o teste da seqüência A B. Recom. 34. Caso um determinado caso de teste não seja possível de ser formulado, registre a justificativa na correspondente massa de teste. A geração de casos de teste deve ser sempre completa. A massa de teste deve registrar todos eles. No entanto, é possível que determinado caso de teste semântico não possa ser valorado em virtude da especificação ou da implementação do programa. Este fato deve ser registrado, jamais simplesmente ignorado. 1.4 Teste de interfaces com o usuário Recom. 35. Assegure que todos os diálogos sejam testados no conjunto de todos os casos Recom. 36. Assegure que todos os itens contidos em um diálogo sejam exercitados pelo menos uma vez no conjunto de todos os casos

5 Recomendações para testes de módulos - 5 Recom. 37. Assegure que todos os itens condicionais (ex.: toggle, radio button) tenham assumido cada uma das diversas condições permitidas, considerando o conjunto de casos Recom. 38. Assegure que todos os menus sejam exercitados no conjunto de todos os casos Recom. 39. Assegure que cada um dos itens de cada um dos menus tenha sido escolhido pelo menos uma vez no conjunto de todos os casos Recom. 40. Assegure que cada um dos itens condicionais (ex.: toggle, radio button) dos diversos menus tenha estado pelo menos uma vez ativo e pelo menos uma vez inativo no conjunto de todos os casos Recom. 41. Assegure que todos os ícones sejam exercitados pelo menos uma vez no conjunto de todos os casos Recom. 42. Assegure que todas as teclas de atalho (hot-keys) sejam exercitadas pelo menos uma vez no conjunto de todos os casos Recom. 43. Assegure que todas as formas de rolagem previstas tenham sido exercitadas pelo menos uma vez no conjunto de todos os casos Recom. 44. Assegure que todos os itens de manipulação direta tenham sido selecionados e processados segundo as várias opções de processamento permitidas. Recom. 45. Assegure que todos os logos, ícones, mensagens para o usuário, sinais sonoros e similares tenham sido gerados pelo menos uma vez no conjunto de todos os casos Recom. 46. Assegure que todo o auxílio contextual tenha sido ativado pelo menos uma vez no conjunto de todos os casos Recom. 47. Assegure que o auxílio seja consistente com o programa, tanto na informação que contém, como no look and feel utilizado ou ilustrado. Recom. 48. Realize sempre testes de utilizabilidade da interface do usuário.

6 6 - Programação Modular 1.5 Teste de estruturas de dados Recom. 49. Assegure que, no conjunto de todos os casos de teste, sejam contempladas instâncias da estrutura de dados para cada uma das alternativas estabelecidas no respectivo modelo físico. Recom. 50. Para cada relação de repetição contida no modelo físico da estrutura de dados, assegure que sejam geradas instâncias de estruturas com zero, um, e três ou mais elementos, no conjunto de todos os casos Recom. 51. Para cada vetor de dimensão dinamicamente definida e implementado em vetor de dimensão constante (ex.: string), assegure que, no conjunto de todos os casos de teste, sejam geradas instâncias de estruturas com zero, um, e três ou mais, exatamente a dimensão do vetor base e exatamente um além da dimensão do vetor base. Recom. 52. Para cada referência direta ou indiretamente recursiva assegure que, no conjunto de todos os casos de teste, sejam geradas instâncias de estruturas de dados nas quais a recursão seja repetida zero, uma e três ou mais vezes. 1.6 Teste estrutural Recom. 53. Assegure que, no conjunto de todos os casos de teste, existam casos de teste para cada uma das relações que compõe expressões condicionais. Recom. 54. Assegure que, no conjunto de todos os casos de teste, cada if tenha sido testado para uma avaliação TRUE e outra FALSE. Recom. 55. Ao utilizar a construção switch, case e default, assegure que cada possível seleção seja exercitada pelo menos uma vez no conjunto de todos os casos Recom. 56. Ao utilizar construções tais como throw e catch, assegure que cada condição de exceção sinalizada (throw) seja exercitada pelo menos uma vez no conjunto de todos os casos Recom. 57. Para cada repetição assegure que sejam gerados casos de teste para zero, uma e arrasto + 1 iterações. Recom. 58. Para cada chamada recursiva assegure que sejam gerados casos de teste para zero, uma e arrasto + 1 chamadas recursivas.