test software sentencias pruebas ejemplo coverage code testing computer-science code-coverage

testing - software - code coverage



¿Qué es la cobertura del código y cómo lo mide usted? (7)

¿Qué es la cobertura del código y cómo lo mide usted?

Me hicieron esta pregunta con respecto a nuestra cobertura de código de prueba automatizada. Parece ser que, fuera de las herramientas automatizadas, es más arte que ciencia. ¿Hay ejemplos reales de cómo usar la cobertura de código?


Complementando algunos puntos a muchas de las respuestas anteriores:

La cobertura de código significa, qué tan bien su conjunto de prueba cubre su código fuente. es decir, en qué medida el código fuente está cubierto por el conjunto de casos de prueba.

Como se mencionó en las respuestas anteriores, hay varios criterios de cobertura, como rutas, condiciones, funciones, declaraciones, etc. Pero los criterios adicionales a cubrir son:

  1. Condición de cobertura: todas las expresiones booleanas que se evaluarán son verdaderas y falsas.
  2. Cobertura de la decisión: no solo las expresiones booleanas deben evaluarse como verdaderas y falsas una vez, sino también para cubrir todo el cuerpo posterior de if-elseif-else.
  3. Cobertura de bucle: significa, se han ejecutado todos los bucles posibles una vez, más de una vez y cero. Además, si tenemos una suposición sobre el límite máximo, entonces, si es posible, probamos los tiempos límite máximos y, uno más que los tiempos límite máximos.
  4. Cobertura de entrada y salida: pruebe todas las llamadas posibles y su valor de retorno.
  5. Parámetro Valor Cobertura (PVC). Para comprobar si todos los valores posibles para un parámetro son probados. Por ejemplo, una cadena podría ser cualquiera de estos comúnmente: a) nulo, b) vacío, c) espacios en blanco (espacio, tabulaciones, nueva línea), d) cadena válida, e) cadena no válida, f) cadena de un solo byte, g ) cadena de doble byte. El hecho de no probar cada valor de parámetro posible puede dejar 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 probó una de las siete opciones, significa, solo un 14.2% de cobertura del valor del parámetro.
  6. Cobertura de herencia: en el caso de una fuente orientada a objetos, cuando se devuelve un objeto derivado referido por la clase base, se debe probar la cobertura para evaluar, si se devuelve un objeto de hermano.

Nota: El análisis de código estático buscará si hay algún código inalcanzable o código colgante, es decir, el código no está cubierto por ninguna otra función de llamada. Y también otra cobertura estática. Incluso si el análisis de código estático informa que el código al 100% está cubierto, no proporciona informes sobre su conjunto de pruebas si se prueba toda la cobertura de código posible.


La cobertura del código básicamente comprueba qué parte de su código está cubierto por las pruebas. Por lo tanto, si tiene una cobertura de código del 90% significa que hay un 10% de código que no está cubierto por las pruebas. Sé que podrías estar pensando que el 90% del código está cubierto, pero debes mirar desde un ángulo diferente. ¿Qué te detiene a obtener una cobertura de código del 100%?

Un buen ejemplo será este:

if(customer.IsOldCustomer()) { } else { }

Ahora, en el código anterior hay dos caminos / ramas. Si siempre está presionando la rama "SÍ", entonces no está cubriendo la otra parte y se mostrará en los resultados de la cobertura del código. Esto es bueno porque ahora sabe lo que no está cubierto y puede escribir una prueba para cubrir la otra parte. Si no hubo cobertura de código, entonces estás sentado en una bomba de tiempo para explotar.

NCover es una buena herramienta para medir la cobertura de código.


La cobertura del código es simplemente una medida del código que se prueba. Existe una variedad de criterios de cobertura que pueden medirse, pero generalmente son los diversos caminos, condiciones, funciones y declaraciones dentro de un programa los que conforman la cobertura total. La métrica de cobertura del código es solo un porcentaje de las pruebas que ejecutan cada uno de estos criterios de cobertura.

En cuanto a cómo hago para rastrear la cobertura de pruebas unitarias en mis proyectos, utilizo herramientas de análisis de código estático para realizar un seguimiento.


La cobertura del código es una medida de cuántas líneas / bloques / arcos de su código se ejecutan mientras se ejecutan las pruebas automatizadas.

La cobertura del código se recopila mediante el uso de una herramienta especializada para instrumentar los binarios para agregar llamadas de rastreo y ejecutar un conjunto completo de pruebas automatizadas contra el producto instrumentado. Una buena herramienta le dará no solo el porcentaje del código que se ejecuta, sino que también le permitirá profundizar en los datos y ver exactamente qué líneas de código se ejecutaron durante una prueba en particular.

Nuestro equipo utiliza Magellan , un conjunto interno de herramientas de cobertura de códigos. Si usted es una tienda .NET, Visual Studio tiene herramientas integradas para recopilar cobertura de código. También puede rodar algunas herramientas personalizadas, como se describe en este artículo .

Si eres una tienda de C ++, Intel tiene algunas tools que se ejecutan para Windows y Linux, aunque no las he usado. También escuché que existe la herramienta gcov para GCC, pero no sé nada al respecto y no puedo darle un enlace.

En cuanto a cómo lo usamos, la cobertura del código es uno de nuestros criterios de salida para cada hito. En realidad, tenemos tres métricas de cobertura de código: cobertura de pruebas de unidad (del equipo de desarrollo), pruebas de escenario (del equipo de prueba) y cobertura combinada.

Por cierto, aunque la cobertura del código es una buena medida de la cantidad de pruebas que está realizando, no es necesariamente una buena medida de qué tan bien está probando su producto. Hay otras métricas que debe usar junto con la cobertura del código para garantizar la calidad.


La cobertura del código se ha explicado bien en las respuestas anteriores. Así que esto es más una respuesta a la segunda parte de la pregunta.

Hemos utilizado tres herramientas para determinar la cobertura del código.

  1. JTest - una herramienta patentada construida sobre JUnit. (Genera pruebas unitarias también).
  2. Cobertura : una herramienta de cobertura de código fuente abierto que se puede combinar fácilmente con las pruebas de JUnit para generar informes.
  3. Emma - otra - esta es la que hemos usado para un propósito ligeramente diferente al de las pruebas unitarias. Se ha utilizado para generar informes de cobertura cuando los usuarios finales acceden a la aplicación web. Esto, junto con las herramientas de prueba web (ejemplo: Canoo) puede proporcionarle informes de cobertura muy útiles que le indican la cantidad de código que se cubre durante el uso típico del usuario final.

Utilizamos estas herramientas para

  • Revisar que los desarrolladores han escrito buenas pruebas unitarias.
  • Asegúrese de que todo el código se recorre durante las pruebas de caja negra

Para Perl está el excelente módulo Devel::Cover que uso regularmente en mis módulos.

Si la compilación y la instalación son administradas por Module :: Build, simplemente puede ejecutar ./Build testcover para obtener un sitio HTML agradable que le indique la cobertura por sub, línea y condición, con colores agradables que le permitan ver fácilmente qué ruta de código tiene no ha sido cubierto.


Simplemente recuerde que tener "cobertura de código al 100%" no significa que todo se haya probado completamente, mientras que significa que cada línea de código se ha probado, no significa que se hayan probado en todas las situaciones (comunes).

Usaría la cobertura de código para resaltar los bits de código para los que probablemente debería escribir pruebas. Por ejemplo, si cualquier herramienta de cobertura de código muestra que myImportantFunction () no se ejecuta mientras se ejecutan mis pruebas de unidad actuales, probablemente deberían mejorarse.

Básicamente, la cobertura de código al 100% no significa que su código sea perfecto. Úselo como una guía para escribir pruebas más completas (de unidad).