paint-brush
Controle de qualidade de software: resolvendo problemas com design de teste combinatóriopor@shad0wpuppet
26,166 leituras
26,166 leituras

Controle de qualidade de software: resolvendo problemas com design de teste combinatório

por Konstantin Sakhchinskiy5m2024/01/22
Read on Terminal Reader
Read this story w/o Javascript

Muito longo; Para ler

Desafios em testes de software, especificamente em projetos de testes combinatórios, como testes k-way e pares. Discuto questões como entradas incorretas, métodos de teste robustos e combinações de variáveis. Usando um estudo de caso, destaco a prevalência de falhas não detectadas e enfatizo a necessidade de uma abordagem de teste diferenciada, considerando configurações padrão e interações variáveis complexas. A principal conclusão é a importância de uma estratégia de teste abrangente para software robusto.
featured image - Controle de qualidade de software: resolvendo problemas com design de teste combinatório
Konstantin Sakhchinskiy HackerNoon profile picture


Em testes de software , o design dos casos de teste é fundamental para garantir a confiabilidade e robustez dos aplicativos. Técnicas de design de testes combinatórios, como testes k-way e testes pareados, visam testar as interações entre diferentes variáveis de entrada. No entanto, torna-se evidente que desafios e armadilhas podem prejudicar a sua eficácia na descoberta de erros críticos.


Este breve artigo enfoca questões específicas que podem ser encontradas durante o projeto de testes combinatórios, explorando as nuances que exigem consideração cuidadosa. Vamos nos aprofundar nos casos de valores de entrada incorretos, na importância de oráculos robustos, na importância de combinações de variáveis frequentemente negligenciadas e na compreensão crucial de como as variáveis interagem.


Identificação incorreta de valores de entrada

Um conjunto de testes k-way compreende todas as combinações possíveis de valores para k variáveis. Por exemplo, a aplicação do algoritmo Allpairs resulta em um conjunto de testes bidirecionais, abrangendo todas as combinações possíveis de pares de valores de variáveis. Consequentemente, uma falha k-way refere-se a um erro resultante da interação de valores de k variáveis. O exame de dois sistemas, SYS1 e SYS2, revelou erros após seus lançamentos de produção. Ambos os sistemas foram submetidos a testes k-way com valores k de 2, 3, 4 e 5+.


A tabela exibe os resultados dos testes k-way para os dois sistemas.

Tipo de falha

SYS1

SYS2

2 maneiras

30

29

3 vias

4

12

4 vias

7

1

> 4 vias

7

3

Não encontrado

34

43


Verificações sequenciais foram realizadas para cada conjunto k-way. A Figura 2.1 indica que os erros decorrentes da interação de duas ou menos variáveis de entrada foram 29 in SYS1 e 30 in SYS2 . Os erros da interação de três variáveis foram 4*(30+4) in SYS2 e 12*(29+12) in SYS1 . Para interações envolvendo quatro variáveis, os erros foram 7*(30+4+7) in SYS2 e 1*(29+12+1) in SYS1 . Os erros de interações com mais de quatro variáveis foram 3*(29+12+1+3) in SYS1 e 7*(30+4+7+7) in SYS2 . Notavelmente, 43 erros não foram encontrados no SYS1 e 34 erros não foram encontrados no SYS2.


Neste exemplo, os erros mais significativos pertenciam à categoria Não Encontrado . Investigações posteriores revelaram que a maioria dos erros não detectados eram falhas unidirecionais, o que significa que um valor específico de uma variável levou ao erro independentemente dos valores de outras variáveis. O teste em pares deveria ter detectado esses erros, mas por algum motivo eles permaneceram desconhecidos. Esses erros Not Found são principalmente falhas unidirecionais que passaram despercebidas porque determinados valores de entrada não foram selecionados ou foram escolhidos incorretamente.


A essência do problema reside no fato de que quaisquer erros cometidos antes da aplicação do Algoritmo Allpairs persistirão. Isso implica que se as técnicas de design de teste anteriores foram aplicadas incorretamente ou os valores de entrada estavam incorretos, os erros na aplicação persistirão independentemente do uso do Algoritmo de Todos os Pares ou do Teste de Matriz Ortogonal.


Fraqueza na definição dos resultados esperados: incerteza nos resultados finais

Como exemplo, vamos considerar um módulo de aplicação com inúmeras opções (algo parecido com este formulário) e, consequentemente, um grande número de combinações de dados de entrada.


No módulo, digamos que existam 2^12 * 3 combinações possíveis. Aqui, o desafio não está em escolher valores de entrada incorretos, pois todos os valores de variáveis possíveis podem ser testados exaustivamente usando o algoritmo Allpairs. No entanto, isso revelará todos os erros críticos? Provavelmente não, devido a problemas com os resultados esperados. Após manipular cada combinação de opções nesse tipo de módulo de software, seria necessário usar o sistema por algum tempo para verificar se as opções funcionaram corretamente e nada mais quebrou após a aplicação das opções escolhidas. Nesse caso, não há garantia de que não exista nenhum problema sutil e não óbvio facilmente ignorado.


Após cada teste, pode ser necessário avaliar minuciosamente as funções principais do sistema. A questão aqui é que defeitos graves muitas vezes não são tão aparentes quanto gostaríamos que fossem, e contabilizar tudo nos resultados esperados torna-se praticamente impossível.


Desatenção às combinações mais prováveis

Das combinações 2^12 * 3 (como sugerimos no exemplo acima), é provável que haja uma combinação de opções de módulo que ocorrerá com muito mais frequência do que todas as outras - a configuração padrão . Se 95% das pessoas nunca alterarem as opções das configurações padrão deste módulo, deverá haver uma boa cobertura de opções quase/quase padrão . Testar todas as variações com desvio da configuração padrão em uma opção resultaria em um número de testes de 2 dígitos. Se testarmos todas as combinações de opções com um possível desvio em duas configurações do padrão, seriam cerca de cem casos de teste. Testar com esses casos de teste e com todos os pares de casos de teste pode produzir resultados melhores do que ignorar a existência da opção padrão. No entanto, o algoritmo Allpairs força o testador a ignorar as combinações de variáveis mais prováveis e comumente usadas.


Interações de variáveis desconhecidas

O fator chave para o sucesso ou fracasso do teste pareado reside na compreensão de como a combinação de variáveis de entrada afeta os dados de saída. A aplicação de testes pareados a duas aplicações testadas diferentes pode produzir resultados significativamente diferentes. Alguns aplicativos usam menos dados de entrada para produzir dados de saída, enquanto outros usam mais.


Como exemplo, considere o programa, que possui três variáveis de entrada (X, Y, Z) e três possíveis dados de saída (1, 2, 3). As setas indicam quais variáveis devem interagir para produzir um resultado específico. Para obter um resultado 1, as variáveis Y e X devem interagir; para obter um resultado 2, as variáveis Z e X devem interagir. Para esta aplicação, a aplicação de testes pareados seria uma escolha adequada e resultados positivos são prováveis. No entanto, nos casos em que existem cenários em que os dados de saída resultam da interação de mais de duas variáveis de entrada, há uma grande probabilidade de que o teste pareado não consiga identificar erros. A simples aplicação de testes pareados aumenta o risco de ignorar erros críticos na aplicação testada.


Como profissional de controle de qualidade, é importante compreender essas nuances. Embora teóricos em alguns casos, esses insights ressaltam a necessidade de uma abordagem holística de testes que vá além da superfície, garantindo a confiabilidade e a robustez dos seus aplicativos. Compreender a complexidade do design de testes combinatórios permite que os profissionais de controle de qualidade testem com eficácia a complicada lógica de negócios dos aplicativos e forneçam software de alta qualidade aos seus usuários.