O "Guia de um praticante de design de teste de software" de Lee Copeland foi publicado em 2003.
Desde então, está firmemente enraizado na lista de livros que qualquer testador deve ler. Vale a pena ler no original. Ele lê muito bem: a linguagem não é complicada, o estilo é fácil. No decorrer do livro, o autor ironiza um pouco sobre si mesmo, seus alunos, leitores e, em geral, sobre a esfera de nossa atividade.
O seguinte não é uma tradução, mas um resumo detalhado da seção "Técnicas de teste da caixa preta", que descreve a aplicação das técnicas de design de teste.
O livro caiu em minhas mãos sob o conselho de um ex-colega, pelo qual agradeci especialmente a ele.
Para ser o caso de teste mais eficaz e eficiente, é preciso projetar, não apenas dar um tapa.
Teste de Classe de Equivalência
Teste de valor limite
Teste da tabela de decisão
Teste pareado
Teste de transição de estado
Teste de Caso de Uso
Teste de Classe de Equivalência
Técnica
- Defina classes de equivalência.
- Crie casos de teste para cada classe de equivalência.
Uma classe de equivalência é um conjunto de dados que executa os mesmos módulos e deve produzir os mesmos resultados.
Quaisquer dados dentro da classe são equivalentes, o que significa que, se um caso de teste na caixa de equivalência descobrir / não encontrar um defeito, todos os outros casos de teste nessa classe de equivalência detectarão / não encontrarão o mesmo defeito.
Uma abordagem alternativa é usar classes de equivalência não para entradas, mas para saídas. Divida as variantes de saída em classes de equivalência, determine quais valores de entrada podem acionar essas saídas. A vantagem é que todas as opções de saída possíveis são verificadas. A desvantagem é que, dentro da classe de equivalência de saída, várias classes de equivalência de entrada podem ser ocultadas.
Se houver várias variáveis:
- classes válidas de várias variáveis são combinadas em um caso de teste;
- classes inválidas são testadas separadamente.
Informe seus designers e programadores quando eles o ajudarem. Apreciarão o pensamento e poderão entrar novamente.
Teste de valor limite
Técnica
- Definir classes de equivalência
- Definir os limites de cada classe de equivalência
- Crie casos de teste para cada valor de limite, escolhendo um ponto diretamente na borda, acima e abaixo da borda.
Deve-se lembrar que um ponto acima ou abaixo do limite pode ser uma instância de outra classe de equivalência; nesse caso, a duplicação do teste não é necessária.
Os valores são determinados por tipo. Se o limite for 5, os pontos 4 e 6 são testados para o campo em que são inseridos números inteiros e os pontos 4.99 e 5.01 são testados para o campo em que são inseridas as quantidades em rublos e copecks.
Se houver várias variáveis:
- valores mínimos de limites válidos são combinados em um caso de teste;
- valores máximos de limites válidos são combinados em outro caso de teste;
- limites inválidos são testados separadamente, como é o caso de classes inválidas.
O teste do valor limite concentra-se nos limites, porque é aí que muitos defeitos se escondem.
Teste da tabela de decisão
Técnica
- Definir todas as condições
- Faça todas as combinações possíveis de condições
- Remova combinações desnecessárias. Aqueles em que a alteração dos valores não afetam o resultado (Não se preocupe - CD) são excluídos
- Definir ações
- Crie casos de teste para cada combinação
Tabela de decisão - representa o relacionamento das condições compostas e as ações resultantes.
Se a condição for um intervalo de valores, os testes serão criados adicionalmente para verificar os valores acima e abaixo do limite.
Observando atentamente a tabela, você pode ver que nas regras 1, 2, 3, 4, se o código de ações for inválido, a verificação das demais condições não faz sentido. As regras 5 e 6 podem ser combinadas, porque a condição de verificação de fundos não afeta o resultado. As condições que não afetam o resultado são marcadas como "DC". A tabela é convertida:
Porque sempre há a possibilidade de a tabela não ser convertida corretamente ou o código ser gravado incorretamente melhor, para que a tabela original ainda esteja disponível.
O famoso testador de software, Mick Jagger, oferece excelentes conselhos sobre isso: “Você nem sempre consegue o que deseja, mas, se tentar algumas vezes, pode achar que consegue o que precisa.”
Teste de pareamento
Técnica
- Definir parâmetros
- Determine o número de valores para cada parâmetro (opções para variável)
- Crie uma matriz contendo colunas para cada parâmetro e valores em colunas que contêm todas as combinações dos valores desses parâmetros entre si.
- Combine a matriz ortogonal resultante para fins de teste.
- Crie casos de teste.
Foi determinado experimentalmente que a maioria dos defeitos são defeitos de modo único ou defeitos de modo duplo, ou seja, manifestado quando um único parâmetro é combinado com apenas um outro parâmetro, enquanto o valor dos demais parâmetros não importa.
Se o número de combinações de valores de variáveis for grande, você não deve tentar testar todas as combinações possíveis; é melhor se concentrar em testar todos os pares de valores de variáveis.
Duas abordagens de teste em pares: o método de matrizes ortogonais e o algoritmo allpair.
Uma matriz ortogonal é uma matriz bidimensional que possui uma propriedade especial: se você selecionar duas colunas na matriz, todas as combinações possíveis de valores de parâmetros estarão presentes, todos os pares de colunas terão a mesma propriedade.
Todos os pares - para criar uma matriz, é usado um algoritmo que gera pares diretamente, sem o uso de balanceamento adicional. Se houver um grande número de parâmetros que levam um pequeno número de valores, esse método é melhor para o emparelhamento.
Não é necessário fazer combinações aos pares manualmente, pois existem muitas ferramentas .
Deve-se ter em mente que restrições podem surgir devido ao fato de que algumas combinações de parâmetros nunca ocorrerão.
Não existe uma “física de defeitos de software” subjacente que garanta que o teste aos pares seja benéfico. Só há uma maneira de saber - experimente.
Diagrama de transição de estado
Técnica
Estado - Uma condição na qual o sistema espera um ou mais eventos.O estado lembra o que foi recebido na entrada e determina a resposta que deve ocorrer. Este evento pode ser trazido para um novo estado e / ou iniciar uma nova ação. O estado geralmente reflete o valor de alguma variável no sistema. Representado na forma de um círculo.
Transição - Representa a transição do estado atual para um novo, como resultado de alguma ação. Representado como uma flecha.
Evento - O evento que causou a alteração do estado. Geralmente, um evento entra no sistema do mundo externo através de alguma interface. Às vezes, esse evento é acionado dentro do próprio sistema, por exemplo, como um cronômetro, uma queda abaixo de um determinado nível. Acredita-se que o evento ocorra instantaneamente. Um evento pode ser independente ou relacionado. Quando um evento ocorre, o sistema pode mudar de estado ou permanecer no mesmo estado e / ou iniciar uma ação. Eventos podem ter parâmetros associados (número do cartão, valor na conta). Descrito como uma legenda para a seta de transição.
Ação - Uma operação iniciada como resultado de uma alteração de estado. Isso geralmente é uma resposta do sistema. Lembre-se de que uma ação ocorre durante a transição entre estados. Os próprios estados são estáticos. É indicado por uma barra na assinatura da seta de transição após o evento.
Um diagrama de transição de estado é uma entidade específica (por exemplo, um processo de backup). Um erro comum é uma tentativa de misturar diferentes entidades em um diagrama (por exemplo, Reserva e Passageiro com eventos e ações associados a cada uma delas).
Pode ser usado quando o sistema precisa conhecer os antecedentes ou a ordem correta das operações.
Com base no diagrama de transição de estado, uma tabela de transição de estado é compilada. A tabela contém 4 colunas: estado atual, evento, ação, próximo estado.
A vantagem da tabela de transição de estado é que ela é uma lista de todas as combinações possíveis de transições de estado para estado, incluindo as inválidas. Ao analisar essa tabela, podem ser observadas lacunas nos requisitos. O uso de uma tabela de transição de estado pode ajudá-lo a rastrear transições de estado inválidas.
Você pode escolher uma das 4 opções para criar casos de teste:
- Crie conjuntos de casos de teste para que todos os estados sejam concluídos pelo menos uma vez. Em um caso de teste, uma transição através de vários estados pode ser descrita. Esse é um nível bastante fraco de cobertura de teste.
- Crie conjuntos de casos de teste para que todos os eventos sejam acionados pelo menos uma vez. Os casos de teste que cobrem todos os eventos ao mesmo tempo cobrem todas as condições. Novamente fraca cobertura de teste.
- Crie conjuntos de casos de teste para que todos os caminhos sejam concluídos pelo menos uma vez. Esse método é bom do ponto de vista da cobertura de teste, mas é praticamente inviável. Se o diagrama tiver ciclos, o número de caminhos possíveis poderá ser infinito.
- Crie conjuntos de casos de teste para que todas as transições sejam concluídas pelo menos uma vez. Este método fornece um bom nível de cobertura de teste, por isso é recomendável usá-lo.
A estratégia recomendada para criar casos de teste é testar todas as transições de estado pelo menos uma vez. Em sistemas de alto risco em que é necessária uma cobertura de teste mais confiável, é possível criar casos de teste para cada caminho (cadeia de transição) entre estados.
E agora para algo completamente diferente. Monty Python
Teste de Caso de Uso
Técnica
Caso de uso - são cenários que descrevem como um ator (geralmente uma pessoa, mas talvez outro sistema) usa o sistema para atingir um objetivo específico. Os casos de uso são descritos da perspectiva do usuário, não do sistema. O trabalho interno para manter a integridade do sistema não faz parte do caso de uso.
Pelo menos um caso de teste deve verificar o cenário principal e pelo menos um caso deve estar em cenários alternativos.
Recomendações de Caso de Teste de Caso de Uso
- Comece com dados válidos e os cenários mais comuns.
- Verifique os valores de limite e valores inválidos (usando técnicas discutidas anteriormente).
- Cenários raramente usados, críticos para o sistema (o chamado desligamento do reator nuclear)
- Testes para cada ramo de extensão de cada etapa
- Tente executar a operação de uma maneira incomum
- Perverter a pré-condição, se isso realmente pode acontecer
- Se uma transação tiver loops, execute-a em um loop e não uma ou duas vezes - seja mais difícil
- Encontre um caminho muito longo e sinuoso e siga-o
- Se for esperado que a transação seja executada em uma ordem lógica, tente executá-la na ordem inversa (por exemplo, preencha os campos não de cima para baixo, mas de baixo para cima)
- Crie testes à prova de idiotas
Modelo de Descrição de Caso de Uso
Se você não tentar coisas estranhas. você sabe que os usuários irão.