Control de calidad del software: resolución de problemas con el diseño de pruebas combinatorias

En las pruebas de software , el diseño de casos de prueba es fundamental para garantizar la confiabilidad y solidez de las aplicaciones. Las técnicas de diseño de pruebas combinatorias, como las pruebas k-way y las pruebas por pares, tienen como objetivo probar las interacciones entre diferentes variables de entrada. Sin embargo, resulta evidente que los desafíos y dificultades pueden obstaculizar su eficacia a la hora de descubrir errores críticos.

Este breve artículo se centra en problemas específicos que podrían surgir durante el diseño de pruebas combinatorias, explorando los matices que exigen una cuidadosa consideración. Profundicemos en los casos de valores de entrada incorrectos, la importancia de los oráculos sólidos, la importancia de las combinaciones de variables que a menudo se pasan por alto y la comprensión crucial de cómo interactúan las variables.

Identificación incorrecta de los valores de entrada

Un conjunto de pruebas de k vías comprende todas las combinaciones posibles de valores para k variables. Por ejemplo, la aplicación del algoritmo Allpairs da como resultado un conjunto de pruebas bidireccional que abarca todas las combinaciones posibles de pares de valores variables. En consecuencia, una falla de k vías se refiere a un error resultante de la interacción de valores de k variables. El examen de dos sistemas, SYS1 y SYS2, reveló errores después de su lanzamiento en producción. Ambos sistemas se sometieron a pruebas de k-way con valores de k de 2, 3, 4 y 5+.

La tabla muestra los resultados de las pruebas de k-way para los dos sistemas.

Se realizaron comprobaciones secuenciales para cada conjunto de k-way. La Figura 2.1 indica que los errores que surgen de la interacción de dos o menos variables de entrada fueron 29 in SYS1 y 30 in SYS2 . Los errores de la interacción de tres variables fueron 4*(30+4) in SYS2 y 12*(29+12) in SYS1 . Para las interacciones que involucran cuatro variables, los errores fueron 7*(30+4+7) in SYS2 y 1*(29+12+1) in SYS1 . Los errores de interacciones con más de cuatro variables fueron 3*(29+12+1+3) in SYS1 y 7*(30+4+7+7) in SYS2 . En particular, no se encontraron 43 errores en SYS1 y 34 errores no se encontraron en SYS2.

En este ejemplo, los errores más importantes pertenecían a la categoría No encontrado . Investigaciones adicionales revelaron que la mayoría de los errores no detectados eran fallas unidireccionales, lo que significa que un valor específico de una variable conducía al error independientemente de los valores de otras variables. Las pruebas por pares deberían haber detectado estos errores, pero por alguna razón no se descubrieron. Estos errores de No encontrado son principalmente fallas unidireccionales que pasaron desapercibidas porque ciertos valores de entrada no se seleccionaron o se eligieron incorrectamente.

La esencia del problema radica en el hecho de que cualquier error cometido antes de la aplicación del algoritmo Allpairs persistirá. Esto implica que si las técnicas de diseño de pruebas anteriores se aplicaron incorrectamente o los valores de entrada fueron incorrectos, los errores en la aplicación persistirán independientemente de utilizar el algoritmo de todos los pares o la prueba de matriz ortogonal.

Debilidad en la definición de resultados esperados: incertidumbre en los últimos resultados

Como ejemplo, consideremos un módulo de aplicación con numerosas opciones (algo parecido a este formulario) y, en consecuencia, una gran cantidad de combinaciones de datos de entrada.

En el módulo, digamos que hay 2^12 * 3 combinaciones posibles. En este caso, el desafío no consiste en elegir valores de entrada incorrectos, ya que todos los valores de variables posibles se pueden probar exhaustivamente utilizando el algoritmo Allpairs. Sin embargo, ¿esto descubrirá todos los errores críticos? Probablemente no, debido a problemas con los resultados esperados. Después de manipular cada combinación de opciones en este tipo de módulo de software, sería necesario usar el sistema durante algún tiempo para verificar que las opciones funcionaran correctamente y que nada más se rompiera después de aplicar las opciones elegidas. En este caso, no hay garantía de que no haya ningún problema sutil y no obvio que se pase fácilmente por alto.

Después de cada prueba, es posible que sea necesario evaluar exhaustivamente las funciones principales del sistema. La cuestión aquí es que los defectos graves a menudo no son tan evidentes como uno quisiera, y tener en cuenta todo en los resultados esperados se vuelve prácticamente imposible.

Falta de atención a las combinaciones más probables

De las 2^12 * 3 combinaciones (como sugerimos en el ejemplo anterior), es probable que haya una combinación de opciones de módulo que ocurrirá con mucha más frecuencia que todas las demás: la configuración predeterminada . Si el 95% de las personas nunca cambiará las opciones de la configuración predeterminada para este módulo, debería haber una buena cobertura de las opciones casi o casi predeterminadas . Probar todas las variaciones con una desviación de la configuración predeterminada en una opción daría como resultado un número de pruebas de 2 dígitos. Si se probaran todas las combinaciones de opciones con una posible desviación en dos configuraciones del valor predeterminado, serían alrededor de cien casos de prueba. Realizar pruebas con estos casos de prueba y casos de prueba de todos los pares puede producir mejores resultados que ignorar la existencia de la opción predeterminada. Sin embargo, el algoritmo Allpairs obliga al evaluador a pasar por alto las combinaciones de variables más probables y más utilizadas.

Interacciones de variables desconocidas

El factor clave para el éxito o el fracaso de las pruebas por pares radica en comprender cómo la combinación de variables de entrada afecta los datos de salida. La aplicación de pruebas por pares a dos aplicaciones probadas diferentes puede producir resultados significativamente diferentes. Algunas aplicaciones utilizan menos datos de entrada para producir datos de salida, mientras que otras utilizan más.

Como ejemplo, considere el programa, que tiene tres variables de entrada (X, Y, Z) y tres posibles datos de salida (1, 2, 3). Las flechas indican qué variables deben interactuar para producir un resultado específico. Para obtener un resultado de 1, las variables Y y X deben interactuar; para obtener un resultado de 2, las variables Z y X deben interactuar. Para esta aplicación, aplicar pruebas por pares sería una opción adecuada y es probable que se obtengan resultados positivos. Sin embargo, en los casos en que existen escenarios en los que los datos de salida resultan de la interacción de más de dos variables de entrada, existe una alta probabilidad de que las pruebas por pares no logren identificar errores. La simple aplicación de pruebas por pares aumenta el riesgo de pasar por alto errores críticos en la aplicación probada.