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

Question

¿Qué es la cobertura de código y cómo la MIDE? Me hicieron esta pregunta sobre nuestra cobertura de códigos de prueba automatizados. Parece ser que, fuera de las herramientas automatizadas, es más arte que ciencia. ¿Alguien tiene algún ejemplo del mundo real de cómo usan la cobertura de código?

Answer 1

Cobertura de 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 seguimiento 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 usa Magellan - un conjunto interno de herramientas de cobertura de código. Si usted es una tienda .Net, VS tiene herramientas integradas para recopilar la cobertura de código. También puede rodar algunas herramientas personalizadas, como se describe en this article.

Si usted es una tienda de C++, Intel tiene algunos tools que se ejecutan para Windows y Linux, aunque no los he usado. También escuché que existe la herramienta gcov para gcc, pero no sé nada al respecto y no puedo darte 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 unitarias (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á haciendo, no es necesariamente una buena medida de lo bien que está probando su producto. Hay otras métricas que debe usar junto con la cobertura del código para garantizar la calidad.

Answer 2

Cobertura de código es simplemente una medida del código que se prueba. Hay una variedad de criterios de cobertura que se pueden medir, pero generalmente son los diversos caminos, condiciones, funciones y declaraciones dentro de un programa los que componen la cobertura total. La métrica de cobertura del código es solo el porcentaje de pruebas que ejecuta cada uno de estos criterios de cobertura.

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

Answer 3

La cobertura de código básicamente prueba qué parte de su código está cubierto por las pruebas. Entonces, 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 mirarlo desde un ángulo diferente. ¿Qué le impide obtener una cobertura de código del 100%?

Un buen ejemplo será la siguiente:

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 parte else y se mostrará en los resultados de la Cobertura del código. Esto es bueno porque ahora sabes que lo que no está cubierto y puedes escribir una prueba para cubrir la parte else. Si no había cobertura de código, entonces simplemente estás sentado en una bomba de tiempo para explotar.

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

Answer 4

Sólo recuerde, que tiene "100% de cobertura de código" no significa que todo se prueba por completo -, mientras que significa que cada línea de código se prueba, no significa que se prueban en cada situación (común) ..

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

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

Answer 5

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

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

1. JTest - una herramienta propietaria construida sobre JUnit. (Se genera pruebas unitarias también)
2. Cobertura - una herramienta de cobertura de código fuente abierto que puede acoplarse fácilmente con las pruebas JUnit para generar informes.

3. Emma - otro - éste que hemos utilizado para un propósito ligeramente diferente de la unidad de pruebas. 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 (por ejemplo, Canoo), puede proporcionarle informes de cobertura muy útiles que le informan la cantidad de código que se cubre durante el uso típico del usuario final.

   usamos estas herramientas para

   1. . Revise que los desarrolladores hayan escrito buenas pruebas de unidades
   2. . Asegúrese de que todo el código es atravesada durante las pruebas de recuadro negro

Answer 6

para Perl está el excelente módulo de Devel::Cover que utilizo regularmente en mis módulos.

Si la compilación y la instalación están gestionadas por Module :: Build, simplemente ejecute ./Build testcover para obtener un buen sitio HTML que indique la cobertura por sub, línea y condición, con colores agradables que facilitan ver qué ruta de código no ha sido cubierto.

Answer 7

Complementando algunos puntos con muchas de las respuestas anteriores.

Cobertura de código significa qué tan bien su conjunto de pruebas 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, existen varios criterios de cobertura, como caminos, condiciones, funciones, declaraciones, etc., pero los criterios adicionales para cubrir son

1. cobertura Condición: Todas expresión booleana a ser evaluado para verdadero y falso.
2. Cobertura de decisión: no solo la expresión booleana se debe evaluar como verdadera y falsa una vez, sino para cubrir todo el cuerpo if-elseif-else posterior.
3. Cobertura de bucle: significa: ¿Se han ejecutado todos los bucles posibles una vez, más de una vez y el tiempo cero.Además, si tenemos una suposición sobre el límite máximo, entonces, si es factible, pruebe los tiempos límite máximos y, una vez más, los tiempos límites máximos.
4. Cobertura de entrada y salida: prueba para todas las llamadas posibles y su valor de retorno.
5. Cobertura del valor del parámetro (PVC). Para verificar si se prueban todos los valores posibles para un parámetro. Por ejemplo, una cadena podría ser cualquiera de estas comúnmente: a) nula, b) vacía, c) espacio en blanco (espacio, pestañas, nueva línea), d) cadena válida, e) cadena inválida, f) cadena de un solo byte, g) cadena de doble byte. Si no se prueba cada valor de parámetro posible, puede dejar un error. Probar solo uno de estos podría dar como resultado una cobertura de código del 100% ya que cada línea está cubierta, pero como solo se prueba una de las siete opciones, significa que solo tiene una cobertura del 14.2% del valor del parámetro.
6. Cobertura de herencia: en caso de fuente orientada a objetos, al devolver un objeto derivado referido por clase base, se debe probar la cobertura para evaluar, si se devuelve un objeto hermano.

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