Cobertura de código

Existen varios criterios de cobertura, pero los principales son: ^{[ 5 ]}

• Cobertura de funciones : ¿se ha llamado a cada función (o subrutina ) del programa? 
• Cobertura de instrucciones : ¿se ha ejecutado cada instrucción del programa? 
• Cobertura de aristas : ¿ se han ejecutado todas las aristas del grafo de flujo de control ? 
  • Cobertura de ramas : ¿ se ha ejecutado cada rama (también llamada ruta DD ) de cada estructura de control (como en las sentencias if y case )? Por ejemplo, dada una sentencia if , ¿se han ejecutado tanto la rama verdadera como la falsa ? (Esto es un subconjunto de la cobertura de aristas ) . 
• Cobertura de condiciones : ¿ cada subexpresión booleana se ha evaluado como verdadera y falsa? (También llamada cobertura de predicados). 

Por ejemplo, considere la siguiente función en C :

int foo ( int x , int y ) { int z = 0 ; if (( x > 0 ) && ( y > 0 )) { z = x ; } return z ; }

Supongamos que esta función forma parte de un programa más grande y que este programa se ejecutó con un conjunto de pruebas.

• La cobertura de funciones se considerará satisfecha si, durante esta ejecución, la función foose llamó al menos una vez.
• La cobertura de sentencias para esta función se satisfará si se llama, por ejemplo, como foo(1,1), porque en este caso, se ejecutaría cada línea de la función, incluyendo z = x;.
• La cobertura de ramas se satisfará mediante pruebas que llamen a foo(1,1)y foo(0,1)porque, en el primer caso, ifse cumplen ambas condiciones y z = x;se ejecuta, mientras que en el segundo caso, (x>0)no se cumple la primera condición, , lo que impide la ejecución de z = x;.
• La cobertura de condiciones se satisfará con pruebas que llamen a foo(1,0), foo(0,1), y foo(1,1). Estas son necesarias porque en el primer caso, (x>0)se evalúa como true, mientras que en el segundo, se evalúa como false. Al mismo tiempo, el primer caso hace que (y>0)false, el segundo caso no se evalúa (y>0)(debido a la evaluación perezosa del operador booleano), el tercer caso hace que true.

En los lenguajes de programación que no realizan evaluación de cortocircuito , la cobertura de condiciones no implica necesariamente la cobertura de ramas. Por ejemplo, considere el siguiente fragmento de código Pascal :

si a y b entonces

La cobertura de la condición se puede comprobar mediante dos pruebas:

• a=true,b=false
• a=false,b=true

Sin embargo, este conjunto de pruebas no satisface la cobertura de ramas, ya que ninguno de los casos cumplirá la ifcondición.

Puede ser necesario inyectar fallos para garantizar que todas las condiciones y ramas del código de gestión de excepciones tengan una cobertura adecuada durante las pruebas.

La combinación de cobertura de funciones y cobertura de ramas también se denomina a veces cobertura de decisiones . Este criterio exige que cada punto de entrada y salida del programa se haya invocado al menos una vez, y que cada decisión del programa haya considerado todos los resultados posibles al menos una vez. En este contexto, la decisión es una expresión booleana que comprende condiciones y cero o más operadores booleanos. Esta definición no es la misma que la cobertura de ramas, ^{[ 6 ]} sin embargo, el término cobertura de decisiones se utiliza a veces como sinónimo. ^{[ 7 ]}

La cobertura de condiciones/decisiones exige que se cumplan tanto la cobertura de decisiones como la de condiciones. Sin embargo, para aplicaciones críticas para la seguridad (como el software de aviónica ), a menudo se requiere que se cumpla la cobertura de condiciones/decisiones modificada (MC/DC) . Este criterio amplía los criterios de condiciones/decisiones con el requisito de que cada condición afecte al resultado de la decisión de forma independiente.

Por ejemplo, considere el siguiente código:

si ( a o b ) y c entonces

Los criterios de condición/decisión se cumplirán mediante el siguiente conjunto de pruebas:

Sin embargo, el conjunto de pruebas anterior no satisface la cobertura de condición/decisión modificada, ya que en la primera prueba, el valor de 'b' y en la segunda prueba el valor de 'c' no influyen en el resultado. Por lo tanto, se necesita el siguiente conjunto de pruebas para satisfacer MC/DC:

Este criterio exige que se prueben todas las combinaciones de condiciones dentro de cada decisión. Por ejemplo, el fragmento de código de la sección anterior requerirá ocho pruebas:

La cobertura de valores de parámetros (PVC) requiere que, en un método que recibe parámetros, se consideren todos los valores comunes para dichos parámetros. La idea es que se prueben todos los valores posibles comunes para un parámetro. ^{[ 8 ]} Por ejemplo, los valores comunes para una cadena son: 1) nulo , 2) vacío, 3) espacio en blanco (espacio, tabulaciones, salto de línea), 4) cadena válida, 5) cadena no válida, 6) cadena de un byte, 7) cadena de dos bytes. También puede ser apropiado usar cadenas muy largas. No probar cada valor posible de parámetro puede resultar en un error. Probar solo uno de estos podría resultar en una cobertura de código del 100%, ya que cada línea está cubierta, pero como solo se prueba una de las siete opciones, hay solo un 14,2% de PVC.

Existen otros criterios de cobertura que se utilizan con menos frecuencia:

• Cobertura de secuencias de código lineal y saltos (LCSAJ) , también conocida como cobertura de rutas JJ : ¿ se han ejecutado todas las rutas LCSAJ/JJ? ^{[ 9 ]} 
• Cobertura de ruta : ¿Se han ejecutado todas las rutas posibles a través de una parte determinada del código? 
• Cobertura de entrada/salida : ¿Se han ejecutado todas las posibles llamadas y retornos de la función? 
• Cobertura de bucles : ¿Se ha ejecutado cada bucle posible cero veces, una vez y más de una vez? 
• Cobertura de estados : ¿ Se ha alcanzado y explorado cada estado en una máquina de estados finitos ? 
• Cobertura del flujo de datos : ¿Se ha alcanzado y explorado cada definición de variable y su uso? ^{[ 10 ]} 

Las aplicaciones críticas para la seguridad o que requieren alta fiabilidad suelen exigir una cobertura de prueba del 100 %. Por ejemplo, la norma ECSS -E-ST-40C exige una cobertura del 100 % de las declaraciones y decisiones para dos de los cuatro niveles de criticidad; para los demás, los valores de cobertura objetivo se negocian entre el proveedor y el cliente. ^{[ 11 ]} Sin embargo, establecer valores objetivo específicos —y, en particular, el 100 %— ha sido criticado por los profesionales por diversas razones (véase ^{[ 12 ]} ). Martin Fowler escribe: «Desconfiaría de cualquier cosa como el 100 %; daría la impresión de que alguien está escribiendo pruebas para que las cifras de cobertura sean satisfactorias, pero sin pensar en lo que está haciendo». ^{[ 13 ]}

Algunos de los criterios de cobertura mencionados anteriormente están relacionados. Por ejemplo, la cobertura de rutas implica la cobertura de decisiones, sentencias y entradas/salidas. La cobertura de decisiones implica la cobertura de sentencias, ya que cada sentencia forma parte de una bifurcación.

La cobertura completa de la ruta, del tipo descrito anteriormente, suele ser poco práctica o imposible. Cualquier módulo con una sucesión de${\displaystyle n}$Las decisiones en él pueden tener hasta${\displaystyle 2^{n}}$rutas dentro de él; las construcciones de bucle pueden resultar en un número infinito de rutas. Muchas rutas también pueden ser inviables, ya que no hay ninguna entrada al programa bajo prueba que pueda hacer que se ejecute esa ruta en particular. Sin embargo, se ha demostrado que un algoritmo de propósito general para identificar rutas inviables es imposible (dicho algoritmo podría usarse para resolver el problema de la parada ). ^{[ 14 ]} La prueba de ruta base es, por ejemplo, un método para lograr una cobertura completa de ramas sin lograr una cobertura completa de rutas. ^{[ 15 ]}

Los métodos para las pruebas prácticas de cobertura de rutas intentan identificar clases de rutas de código que difieren únicamente en el número de ejecuciones de bucles, y para lograr una cobertura de "ruta base", el probador debe cubrir todas las clases de rutas. ^{[ 16 ]}