En publicaciones anteriores del blog, hablamos sobre cómo desglosar un aspecto del desafío de las pruebas, que consiste en trabajar con múltiples entradas como un experimento diseñado en el que podemos comenzar centrándonos en una entrada a la vez. En una publicación posterior del blog, repasamos los principios fundamentales de los efectos factoriales en los experimentos diseñados. Ahora, combinaremos estas ideas y analizaremos lo que podríamos querer al diseñar un experimento que se utilizará para las pruebas.
Regresemos a la Distribución Beta y consideremos ahora si queremos probar variando las entradas de la Distribución Beta, centrándonos en q, alfa y beta.
Supongamos que elegimos tres valores para cada una de esas entradas (una baja/media/alta). Uno podría imaginar probar las 27 combinaciones posibles (3x3x3). Pero, ¿funcionaría esto si tuviéramos 10 entradas? ¿20? ¿100? En algún momento, se hace evidente que necesitamos una estrategia diferente. Si bien tenemos una forma de manejar esto en problemas típicos de diseño de experimentos, ¿este mismo enfoque funciona para las pruebas de software? Recordando que queremos encontrar errores y que se esconden en los rincones y los límites , reformulemos esto para decir que nuestro objetivo es encontrar combinaciones de entradas que induzcan una falla (es decir, no observamos nuestro resultado esperado).
¿Qué pasa con los límites?
Es posible que haya notado que parezco ignorar los límites. Aquí es donde el enfoque OFAT puede resultar útil. Lo ideal es que ya hayamos comprobado nuestros límites para cada una de nuestras entradas (y hayamos solucionado los problemas) antes de llegar a este punto de la prueba. Sin embargo, como descubriremos más adelante, podemos tener en cuenta los límites a medida que variamos nuestras entradas.
Más allá de la OFAT
En un diseño factorial, los principios fundamentales de los efectos factoriales se relacionan con los efectos importantes o significativos. Sin embargo, para las pruebas de software, reformulamos los principios fundamentales en términos de “combinaciones que inducen fallas”:
Jerarquía de combinaciones : i) Las combinaciones que involucran menos insumos tienen más probabilidades de provocar fallas que aquellas que involucran más insumos. ii) Las combinaciones del mismo orden tienen la misma probabilidad de ser importantes.
Escasez de combinaciones : el número de combinaciones que inducen fallos será pequeño.
Herencia combinada : es más probable que una combinación induzca fallas si se sabe que al menos uno de los factores parentales que involucran la interacción tiene más probabilidades de estar involucrado en la inducción de fallas.
¿Por qué necesitamos siquiera hacer una distinción?
Una de las diferencias clave en las pruebas es que nuestra respuesta es simplemente de aprobado/reprobado: ¿nos desviamos del resultado esperado o no? Además, normalmente asumimos un resultado determinista. Es decir, si utilizamos las mismas entradas, obtenemos los mismos resultados (sin errores). Si bien un evaluador quiere encontrar errores, esperamos que esos errores se solucionen con el tiempo. No buscamos ajustar un modelo, encontrar efectos u optimizar una respuesta. De hecho, la analogía más cercana a la idea de modelado es la tarea de rastrear una combinación que indujo un fallo. Esto se conoce como el problema de localización de fallas y tiene su propio conjunto de desafíos únicos.
Entonces, ¿tienen sentido estos principios para las pruebas?
Resulta que hay evidencia empírica de que la jerarquía de combinaciones se cumple (véase Kuhn et al., 2004). Por otro lado, la escasez de combinaciones puede no ser siempre una suposición razonable. Si un sistema no ha sido sometido a ningún tipo de prueba de interacciones, o incluso a pruebas de entradas individuales, puede haber muchas fallas en un conjunto de pruebas (especialmente antes de que se empiecen a corregir los errores). Esto también está relacionado con el principio de herencia de combinaciones: si una entrada individual induce una falla, entonces cualquier combinación que involucre esa entrada inducirá una falla.
Entonces, si estas suposiciones son razonables, ¿qué hace que un conjunto de pruebas sea bueno? Estén atentos a nuestras próximas entradas del blog.
Kuhn, DR, Wallace, DR y Gallo, AM, 2004. Interacciones de fallas de software e implicaciones para las pruebas de software.Transacciones IEEE sobre ingeniería de software, 30(6), págs.418-421.
