La cobertura de código, Criterios de cobertura, En la práctica



La cobertura de código es una medida utilizada en las pruebas de software. En él se describe el grado en que ha sido probado el código fuente de un programa.

Cobertura de código fue uno de los primeros métodos inventados para las pruebas de software sistemática. La primera referencia fue publicado por Miller y Maloney en Comunicaciones de la ACM en 1963.

La cobertura de código es una consideración en la certificación de la seguridad de los equipos de aviónica. Las pautas mediante las cuales aviónica equipo está certificado por la Administración Federal de Aviación está documentado en DO-178B y el recientemente lanzado DO-178C.

Criterios de cobertura

Para medir qué tan bien el programa es ejercido por un conjunto de pruebas, se utilizan uno o más criterios de cobertura.

Criterios de cobertura básica

Hay una serie de criterios de cobertura, siendo las principales:

  • Cobertura de la función - ¿Se ha llamado a cada función en el programa?
  • Declaración de la cobertura - ¿Se ha ejecutado cada nodo en el programa?
  • Decisión de la cobertura - ¿Se ha ejecutado todas las aristas en el programa? Por ejemplo, contar con los requisitos de cada rama de cada estructura de control han cumplido, así como no conocemos?
  • Cobertura de condición - cada uno ha booleano sub-expresión que se evalúa tanto a la verdadera y la falsa? Esto no implica necesariamente la cobertura de decisión.
  • Condición/cobertura de decisión - Tanto la decisión y la cobertura de condiciones deben ser satisfechas.
  • Cobertura estatal - ¿Se ha llegado a cada estado en una máquina de estados finitos y explorado?
  • Parámetro Valor Cobertura - En un procedimiento con parámetros, se han considerado todos los valores comunes de estos parámetros?

Por ejemplo, considere la siguiente función C :

 int foo {int z = 0, si \u0026\u0026) {z = x, z} return;}

Asumir esta función es una parte de un programa más grande y este programa se llevó a cabo con un poco de pruebas.

  • Si durante la ejecución de esta función "foo" se llama al menos una vez, entonces se cumple la cobertura de la función para esta función.
  • Declaración de la cobertura de esta función se cumplirá si se llama por ejemplo, como foo, como en este caso, todas las líneas de la función se ejecuta como z = x;.
  • Pruebas de llamada foo y foo satisfarán cobertura de decisión, como en el primer caso el 2 si se cumplen las condiciones y z = x; se ejecuta, mientras que en el segundo caso, la primera condición no se cumple, lo que hace el código z = x; no ejecutado.
  • Cobertura de condición puede ser satisfecha con las pruebas que llaman foo, foo y foo. Estas son necesarias como en los dos primeros casos se evalúa como verdadera, mientras que en el tercero se evalúa falsa. Al mismo tiempo, el primer caso hace verdadera mientras que la segunda y tercera hacen que sea falsa.
  • Cobertura de valor de parámetro es la idea de que todos los valores comunes posibles de un parámetro se ponen a prueba. Por ejemplo, una cadena podría ser cualquiera de ellos comúnmente: 1) null, 2) vacía, 3) espacio en blanco, 4) de cadena válida, 5) cadena no válida, 6) cadena de un solo byte, 7) palabra de doble byte. Si no se prueba cada valor de parámetro posible puede dejar un bug. Prueba de sólo uno de ellos puede resultar en la cobertura de código 100%, ya que cada línea está cubierto, pero como sólo uno de siete opciones son examinados, sólo hay 14,2% de PVC.

Cobertura Condición no implica necesariamente la cobertura decisión. Por ejemplo, considere el siguiente fragmento de código:

 Si A y B a continuación,

Cobertura de condición puede ser satisfecha por dos pruebas:

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

Sin embargo, este conjunto de pruebas no satisface la cobertura de decisión en ningún caso será el si se cumple la condición de.

Inyección de fallos puede ser necesario para asegurar que todas las condiciones y las ramas de código de control de excepciones tienen una cobertura adecuada durante la prueba.

Condiciones/decisiones de modificación de cobertura

Para aplicaciones de seguridad crítica que a menudo se requiere que se cumplan condiciones/decisiones modificada cobertura. Este criterio se extiende criterios Estado/decisión de los requisitos que cada condición debe afectar el resultado de decisiones de forma independiente. Por ejemplo, considere el siguiente código:

 y si a continuación, c

Los criterios condición/decisión serán satisfechos por el siguiente conjunto de pruebas:

  • a = true, b = true, c = true
  • a = falso, b = false, c = false

Sin embargo, el análisis conjunto anterior no satisface la condición/decisión modificado la cobertura, ya que en la primera prueba, el valor de "b" y en la segunda prueba del valor de «c» no influiría en el resultado. Por lo tanto, se necesita el siguiente equipo de prueba para satisfacer MC/DC:

  • a = falso, b = false, c = true
  • a = true, b = false, c = true
  • a = falso, b = true, c = true
  • a = true, b = true, c = false

Los valores en negrita influyen en la salida, cada variable debe estar presente como un valor influir al menos una vez con falso y una vez con verdadera.

Cobertura de condiciones múltiple

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

  • a = falso, b = false, c = false
  • a = falso, b = false, c = true
  • a = falso, b = true, c = false
  • a = falso, b = true, c = true
  • a = true, b = false, c = false
  • a = true, b = false, c = true
  • a = true, b = true, c = false
  • a = true, b = true, c = true

Otros criterios de cobertura

Hay otros criterios de cobertura, que se utilizan con menos frecuencia:

  • Secuencia de código lineal y la cobertura Jump - se ha ejecutado cada LCSAJ?
  • Cobertura de JJ-Camino - todos han saltado a los caminos han ejecutado?
  • Cobertura Ruta - tiene todo el recorrido posible a través de una determinada parte del código ha ejecutado?
  • Entrada/salida de cobertura - Tiene todo lo posible llamada y retorno de la función se ejecuta?
  • Cobertura Loop - tiene todo el bucle posible ha ejecutado cero veces, una vez, y más de una vez?
  • Parámetro Valor Cobertura - Para cada parámetro en un método, tiene el parámetro más común posible valores ha probado?

Aplicaciones de seguridad crítica a menudo se requieren para demostrar que la prueba alcanza el 100% de algún tipo de cobertura de código.

Algunos de los criterios de cobertura anterior están conectados. Por ejemplo, la cobertura de caminos implica decisión, la declaración y la entrada/salida de la cobertura. Decisión de cobertura implica la cobertura de sentencias, porque cada declaración es parte de una rama.

Cobertura de ruta completa, del tipo descrito anteriormente, por lo general es poco práctico o imposible. Cualquier módulo con una sucesión de decisiones que puede tener un máximo de rutas dentro de ella, construcciones de bucle pueden dar lugar a un número infinito de caminos. Muchos caminos también pueden ser inviable, ya que no hay entrada al programa se está probando que puede causar ese camino particular que se ejecuta. Sin embargo, un algoritmo de uso general para la identificación de caminos no factibles se ha demostrado ser imposible. Los métodos de prueba de la cobertura camino práctico lugar tratan de identificar las clases de las rutas de código que se diferencian sólo en el número de ejecuciones del bucle, y para lograr la "ruta base" cobertura el probador debe cubrir todas las clases de caminos.

En la práctica

El software de destino se construye con opciones o bibliotecas especiales y/o ejecutar en un entorno especial, que cada función que se ejerce en el programa se asigna de nuevo a los puntos de función en el código fuente. Este proceso permite a los desarrolladores y el personal de control de calidad para buscar las partes de un sistema que se accede rara vez o nunca en condiciones normales y ayuda a tranquilizar a los ingenieros de pruebas que han sido probados en las condiciones más importantes. La salida resultante se analiza para ver qué áreas de código no se han ejercido y las pruebas se actualizó para incluir estas áreas, según sea necesario. En combinación con otros métodos de cobertura de código, el objetivo es desarrollar un riguroso, pero manejable, un conjunto de pruebas de regresión.

En la aplicación de las políticas de cobertura de código dentro de un entorno de desarrollo de software se debe considerar lo siguiente:

  • ¿Cuáles son los requisitos de cobertura para la certificación del producto final y en ese caso se requiere el nivel de cobertura de código? El nivel típico de progresión de rigor es la siguiente: Norma, Sucursal/Decisión modificada Estado/decisión de cobertura, LCSAJ
  • ¿Será la cobertura de código medirse pruebas que verifiquen los requisitos gravan el sistema bajo prueba?
  • ¿El código objeto generado directamente atribuible a instrucciones de código fuente? Algunas certificaciones, requieren la cobertura en el nivel de ensamblado si este no es el caso: "Entonces, verificación adicional se debe realizar en el código objeto de establecer la veracidad de tales secuencias de códigos generadas" para-6.4.4.2.

Los ingenieros de prueba pueden ver los resultados de pruebas de cobertura de código para ayudarles a diseñar casos de prueba y la entrada o la configuración de sistemas que incrementen la cobertura de código a través de las funciones vitales. Dos formas comunes de cobertura de código utilizadas por los probadores son la cobertura de sentencias y la cobertura de sucursales. Informes de cobertura de línea en la huella de la ejecución de las pruebas en términos de líneas de código que se ejecutan para completar la prueba. Informes sobre la cobertura de borde que las sucursales o puntos de decisión códigos fueron ejecutados para completar la prueba. Ambos reportan una cobertura métrica, medida como porcentaje. El significado de esto depende de qué tipo de cobertura de código se han utilizado, como cobertura de sucursales 67% es más completa que la cobertura de sentencias 67%.

En general, las herramientas y bibliotecas exigir un rendimiento y/o memoria u otro costo de los recursos, que es inaceptable para las operaciones normales del programa de cobertura de código. Por lo tanto, sólo se utilizan en el laboratorio. Como era de esperar, hay clases de software que no puede ser factible sometidos a estas pruebas de cobertura, aunque un grado de mapeo de cobertura puede ser aproximado a través del análisis en lugar de pruebas directas.

También hay algunos tipos de defectos que se ven afectados por este tipo de herramientas. En particular, algunas condiciones de carrera u operaciones sensibles al tiempo reales similares se pueden enmascarar cuando se ejecuta en entornos de cobertura de código, y a la inversa, algunos de estos defectos pueden llegar a ser más fácil de encontrar, como resultado de la sobrecarga adicional del código de prueba.