Em   , 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. testes de software  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   de valores de entrada incorreta  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   e   . Os erros da interação de três variáveis foram   e   . Para interações envolvendo quatro variáveis, os erros foram   e   . Os erros de interações com mais de quatro variáveis foram   e   . Notavelmente,   erros não foram encontrados no SYS1 e   erros não foram encontrados no SYS2. 29 in SYS1 30 in SYS2 4*(30+4) in SYS2 12*(29+12) in SYS1 7*(30+4+7) in SYS2 1*(29+12+1) in SYS1 3*(29+12+1+3) in SYS1 7*(30+4+7+7) in SYS2 43 34  Neste exemplo, os erros mais significativos pertenciam à categoria   . 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   são principalmente falhas unidirecionais que passaram despercebidas porque determinados valores de entrada não foram selecionados ou foram escolhidos incorretamente. Não Encontrado Not Found    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. A essência do problema   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   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. 2^12 * 3  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   (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   . 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   . 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. 2^12 * 3 padrão quase/quase padrão  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.

About Me

Read My Articles

Hire Me

Este áudio é produzido no idioma original da história!

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

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Crescimento de Criptomoedas: Criando Personas de Usuários Eficazes

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Guia do arquiteto para construir arquitetura de referência para um Datalake de IA/ML

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Crescimento de Criptomoedas: Criando Personas de Usuários Eficazes

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Guia do arquiteto para construir arquitetura de referência para um Datalake de IA/ML

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps