| Diretriz: Dados de Teste |
 |
 |
|
| Elementos Relacionados |
|---|
ExplicaçãoNa tarefa de design de teste, dois artefatos significativos foram identificados e descritos: Scripts de Teste e Casos de Teste. Sem os Dados de Teste, não é possível implementar e executar esses dois artefatos. Eles são meramente descrições de condições, cenários e caminhos sem valores concretos para identificá-los de forma sucinta. Os Dados de Teste, ainda que não sejam propriamente um artefato, têm um grande impacto no sucesso (ou na falha) do teste. Não é possível implementar nem executar os testes sem os Dados de Teste, visto que são necessários nas seguintes situações:
Portanto, a identificação dos valores é um esforço importante que é feito quando Casos de Teste são identificados (consulte Produto de Trabalho: Caso de Teste e Diretriz: Caso de Teste). Há quatro atributos dos Dados de Teste que devem ser considerados durante a identificação dos Dados de Teste reais:
Cada uma dessas características é abordada com mais detalhes nas seções abaixo: ProfundidadeA profundidade representa o volume ou a quantidade de dados usados no teste. A profundidade é uma consideração importante, pois um volume muito pequeno de dados talvez não reflita as condições reais, ao passo que pode ser difícil gerenciar e manter um volume excessivo de dados. O ideal é iniciar o teste com um pequeno conjunto de dados que suporte os Casos de Teste críticos (geralmente os Casos de Teste positivos). À medida que se adquire confiança no decorrer do teste, deve-se aumentar os Dados de Teste até que a profundidade dos dados seja representativa do ambiente implementado (ou o que for apropriado e viável). AmplitudeA amplitude se refere ao grau de variação dos valores dos Dados de Teste. É possível aumentar a profundidade dos Dados de Teste com a simples criação de mais registros. Ainda que normalmente essa seja uma boa solução, ela não considera as variações efetivas que se espera em dados reais. Sem essas variações nos Dados de Teste, talvez não consigamos identificar defeitos (afinal, nem todos os saques feitos em um Caixa Eletrônico são de R$50,00). Portanto, os valores dos Dados de Teste devem refletir os valores dos dados encontrados no ambiente implementado, como saques de R$10,00 ou R$120,00. Além disso, os Dados de Teste devem refletir informações reais como, por exemplo:
Os valores dos Dados de Teste podem ser uma representação física ou estatística dos dados reais para obter uma amplitude suficiente. Ambos os métodos são válidos e recomendados. Para criar Dados de Teste com base em uma representação física dos dados implementados, identifique os valores (ou faixas de valores) permitidos para cada elemento de dados no banco de dados implementado e verifique se, para cada elemento de dados, pelo menos um registro dos Dados de Teste contém cada valor permitido. Por exemplo:
A matriz acima contém o número mínimo de registros que representariam fisicamente os valores de dados aceitáveis. Para o Número da Conta, há um registro para cada uma das três faixas, todos os números PIN estão dentro da faixa especificada, há diversos Saldos de Conta - inclusive um negativo, e há registros para cada um dos diferentes Tipos de Conta. A matriz acima consiste nos dados mínimos, e o melhor seria manter os valores de dados nos limites de cada intervalo, bem como dentro do intervalo (consulte Diretriz: Caso de Teste). A vantagem da representação física é que os Dados de Teste têm tamanho limitado, podem ser gerenciados, concentram-se nos valores aceitáveis e são direcionados para esses valores aceitáveis. A desvantagem, entretanto, é que os dados reais não são totalmente aleatórios. Os dados reais tendem a possuir perfis estatísticos que podem afetar o desempenho, o que na utilização da representação física não seria observado. A representação estatística dos Dados de Teste são Dados de Teste que refletem a amostragem estatística (das mesmas porcentagens) dos dados de produção. Por exemplo, usando os mesmos elementos de dados acima, se analisássemos o banco de dados de produção e descobríssemos o seguinte:
nossos Dados de Teste, baseados na amostragem estatística, teriam 294 registros (em comparação com os quatro observados acima):
A matriz acima considera somente os tipos de conta. Ao desenvolver os melhores Dados de Teste com base na representação estatística, você incluiria os elementos de dados significativos. No exemplo acima, isso incluiria refletir os saldos reais das contas. Uma desvantagem da representação estatística é que ela pode não refletir a faixa total de valores aceitáveis. Geralmente, os dois métodos de identificação dos Dados de Teste são usados para garantir que esses dados considerem todos os valores e questões de desempenho/população. A amplitude dos Dados de Teste é relevante para os Dados de Teste usados como entrada, assim como para aqueles que dão suporte aos testes (nos dados preexistentes). EscopoO escopo é a relevância dos Dados de Teste para o objetivo do teste, e está relacionado à profundidade e à amplitude. Um grande volume de dados não significa que eles sejam apropriados. Da mesma forma que com a amplitude dos Dados de Teste, devemos garantir a relevância desses dados para o objetivo do teste, ou seja, é necessário haver Dados de Teste para suportar o objetivo do teste específico. Por exemplo, na matriz abaixo, os quatro primeiros registros de Dados de Teste consideram os valores aceitáveis para cada elemento de dados. No entanto, não há registros que avaliem saldos negativos dos tipos de conta C e T. Portanto, ainda que esses Dados de Teste incluam corretamente saldos negativos (amplitude válida), o escopo dos dados abaixo seria insuficiente para suportar qualquer teste usando saldos negativos para cada tipo de conta. A expansão desses dados para incluir novos registros, contendo saldos negativos para cada tipo de conta, seria necessária para suprir essa omissão.
O escopo dos Dados de Teste é relevante para os Dados de Teste usados como entrada, assim como para aqueles que dão suporte aos testes (nos dados preexistentes). ArquiteturaA estrutura física dos Dados de Teste é relevante somente para os dados preexistentes usados pelo objetivo do teste para dar suporte ao teste, como a tabela de regras ou o banco de dados de um aplicativo. O teste não é executado nenhuma vez e é encerrado. O teste é repetido dentro de iterações e entre elas. Para executar o teste de forma consistente, confiável e eficaz, os Dados de Teste devem ser retornados ao seu estado inicial antes da execução do teste. Isso deve ocorrer especialmente quando o teste for automatizado. Portanto, para garantir a integridade, confiança e eficácia do teste, é fundamental que os Dados de Teste não incluam influências externas, e seu estado deve ser conhecido no início, durante e no fim da execução do teste. Há duas questões que devem ser consideradas para alcançar esse objetivo do teste:
Cada uma dessas questões afetará o modo como você gerencia o banco de dados de testes, cria o modelo de teste e interage com outros papéis. Instabilidade / SegregaçãoOs Dados de Teste podem se tornar instáveis pelos seguintes motivos:
Para manter a confiança e a integridade do teste, os Dados de Teste devem ter um controle rígido e devem ser isolados dessas influências. As estratégias para garantir o isolamento dos Dados de Teste contêm:
Estado InicialA outra questão relativa à arquitetura dos Dados de Teste que deve ser considerada se refere ao estado inicial dos Dados de Teste no início da execução do teste. Isso deve ocorrer principalmente quando o teste for automatizado. Da mesma forma que o objetivo do teste deve iniciar a execução do teste em um estado desejado conhecido, os Dados de Teste também devem. Isso contribui para a capacidade de repetição e para a segurança de que cada execução de teste será idêntica à anterior. Quatro estratégias são freqüentemente usadas para abordar essa questão:
Cada estratégia é descrita com mais detalhes a seguir. O método usado dependerá de vários fatores, incluindo as características físicas do banco de dados, a competência técnica dos testadores, a disponibilidade de papéis externos (que não sejam papéis de teste) e o objetivo do teste. Atualização de DadosA Atualização dos Dados é o método mais conveniente de retornar os Dados de Teste ao seu estado inicial. Esse método envolve a criação de uma cópia do banco de dados em seu estado inicial e seu armazenamento. Depois (ou antes) da conclusão da execução do teste, a cópia arquivada do banco de dados de testes é transferida para o ambiente de teste para uso. Isso garante que o estado inicial dos Dados de Teste será o mesmo no início de cada execução de teste. Uma vantagem desse método é que os dados podem ser arquivados em estados iniciais distintos. Por exemplo, é possível arquivar os Dados de Teste no estado do fim do dia, do fim da semana, do fim do mês, etc. Com isso, o testador terá um método de atualizar rapidamente os Dados de Teste para um determinado estado, de forma a suportar um teste, como o teste dos casos de uso do fim do mês. Reinicialização de DadosSe não for possível atualizar os dados, o método mais aconselhável será restaurá-los ao estado inicial através de alguns meios programáticos. A reinicialização dos dados depende de ferramentas e casos de uso especiais para retornar os Dados de Teste a seus valores iniciais. É necessário ter cuidado para garantir que todos os dados, relacionamentos e valores-chave retornem a seu valor inicial apropriado, para assegurar a integridade dos dados. Uma vantagem desse método é que ele pode suportar o teste dos valores inválidos contidos no banco de dados. Sob condições normais, valores de dados inválidos seriam interceptados e não seria permitida a entrada de dados (por exemplo, por uma regra de validação no cliente). No entanto, outro agente pode afetar os dados (por exemplo, uma atualização eletrônica de outro sistema). O teste precisa verificar se os dados inválidos foram identificados e tratados de forma adequada, independentemente de como ocorreram. Reconfiguração de DadosUm método simples de retornar os dados ao estado inicial consiste em reverter as mudanças feitas nos dados durante o teste. Esse método depende do uso do objetivo do teste para inserir entradas de reversão, ou seja, adicionar registros/valores que foram excluídos, cancelar a modificação de registros/valores modificados e excluir dados adicionados. No entanto, há riscos associados a esse método, que incluem:
Se esse for o único método disponível no ambiente de teste, evite o uso de ponteiros, índices e chaves de banco de dados como os objetivos principais para verificação. Ou seja, use, por exemplo, o campo Nome do Paciente para determinar se o paciente foi adicionado ao banco de dados, em vez de usar um ID do Paciente gerado pelo sistema. Redirecionamento de DadosA rolagem progressiva dos dados é o método menos aconselhável de abordar o estado inicial dos Dados de Teste. Na verdade, isso não considera realmente a questão. Em vez disso, o estado dos dados ao término da execução do teste se torna o novo estado inicial dos Dados de Teste. Geralmente, isso requer modificar os Dados de Teste usados para entrada e/ou os Casos de Teste e Dados de Teste usados na avaliação dos resultados. Em algumas situações isso será necessário como, por exemplo, no fim do mês. Se não houver archive dos dados, antes do fim do mês, os Dados de Teste e os Scripts de Teste referentes a cada dia e a cada semana deverão ser executados a fim de fazer o "redirecionamento" dos dados para o estado necessário para o teste de processamento do fim do mês. Os riscos associados a esse método são:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
© Copyright IBM Corp. 1987, 2006. Todos os Direitos Reservados. |