En , 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. las pruebas de software 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 de los valores de entrada incorrecta 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. Tipo de falla SIS1 SIS2 2 vías 30 29 3 vías 4 12 4 maneras 7 1 > 4 vías 7 3 Extraviado 34 43 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 y . Los errores de la interacción de tres variables fueron y . Para las interacciones que involucran cuatro variables, los errores fueron y . Los errores de interacciones con más de cuatro variables fueron y . En particular, no se encontraron errores en SYS1 y errores no se encontraron en 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 En este ejemplo, los errores más importantes pertenecían a la categoría . 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 son principalmente fallas unidireccionales que pasaron desapercibidas porque ciertos valores de entrada no se seleccionaron o se eligieron incorrectamente. No encontrado de No encontrado 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. La esencia del problema 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 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. 2^12 * 3 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 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 . 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 . 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. 2^12 * 3 predeterminada casi o casi predeterminadas 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. Como profesional de control de calidad, es importante comprender estos matices. Si bien son teóricos en algunos casos, estos conocimientos subrayan la necesidad de un enfoque de prueba holístico que vaya más allá de la superficie y garantice la confiabilidad y solidez de sus aplicaciones. Comprender la complejidad del diseño de pruebas combinatorias permite a los profesionales de control de calidad probar de manera efectiva la complicada lógica empresarial de las aplicaciones y ofrecer software de alta calidad a sus usuarios.

Read My Stories

Lead Software QA Engineer

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Making security fun one episode at a time

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

Demasiado Largo; Para Leer

Constantine

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

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

Demasiado Largo; Para Leer

Constantine

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

HISTORIAS RELACIONADAS