¿Qué es la cobertura del código y cómo la mides?
¿Qué es la cobertura del código y cómo la mides?
Me hicieron esta pregunta sobre nuestra cobertura de código de prueba de automatización. Parece ser que, fuera de las herramientas automatizadas, es más un arte que una ciencia. ¿Existen ejemplos del mundo real de cómo utilizar la cobertura de código?
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 seguimiento y ejecutar un conjunto completo de pruebas automatizadas en el producto instrumentado. Una buena herramienta le brindará 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ódigo. Si tiene una tienda .NET, Visual Studio tiene herramientas integradas para recopilar cobertura de código. También puede utilizar algunas herramientas personalizadas, como se describe en este artículo .
Si tiene una tienda de C++, Intel tiene algunas herramientas que se ejecutan para Windows y Linux, aunque yo no las 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 escenarios (del equipo de pruebas) y cobertura combinada.
Por cierto, si bien la cobertura del código es una buena métrica de cuántas pruebas estás realizando, no es necesariamente una buena métrica de qué tan bien estás probando tu producto. Hay otras métricas que debes utilizar junto con la cobertura del código para garantizar la calidad.
La cobertura del código básicamente le indica qué parte de su código está cubierto bajo las pruebas. Por ejemplo, si tiene una cobertura de código del 90 %, significa que el 10 % del código no está cubierto en las pruebas.
Sé que podrías estar pensando que si se cubre el 90% del código, es suficiente, pero hay que mirar desde un ángulo diferente. ¿Qué le impide obtener una cobertura de código del 100%?
Un buen ejemplo sería este:
if(customer.IsOldCustomer())
{
}
else
{
}
Ahora, en el código anterior, hay dos rutas/ramas. Si siempre presiona la rama "SÍ", no está cubriendo la parte "otra cosa" y se mostrará en los resultados de Cobertura del código. Esto es bueno porque ahora sabes qué es lo que no está cubierto y puedes escribir una prueba para cubrir la parte "más". Si no hubiera cobertura de código, simplemente estaría sentado sobre una bomba de tiempo, esperando a explotar.
NCover es una buena herramienta para medir la cobertura del código.
Solo recuerde, tener una "cobertura de código del 100%" no significa que todo se pruebe por completo; si bien significa que se prueba cada línea de código, no significa que se prueben en todas las situaciones (comunes).
Usaría cobertura de código para resaltar fragmentos de código para los que probablemente debería escribir pruebas. Por ejemplo, si cualquier herramienta de cobertura de código que muestra myImportantFunction() no se ejecuta mientras ejecuto 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 (unitarias) más completas.
Complementando algunos puntos a muchas de las respuestas anteriores:
Cobertura de código significa qué tan bien su conjunto de pruebas cubre su código fuente. es decir, hasta qué punto 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 rutas, condiciones, funciones, declaraciones, etc. Pero los criterios adicionales que deben cubrirse son
- Cobertura de condiciones: todas las expresiones booleanas se evaluarán para determinar si son verdaderas o falsas.
- Cobertura de decisión: no solo las expresiones booleanas se evaluarán para determinar si son verdaderas o falsas una vez, sino que también cubrirán todos los cuerpos if-elseif-else posteriores.
- Cobertura de bucle: significa que todos los bucles posibles se han ejecutado una vez, más de una vez y cero veces. Además, si tenemos una suposición sobre el límite máximo, entonces, si es posible, pruebe los tiempos límite máximos y uno más que los tiempos límite máximos.
- Cobertura de entrada y salida: prueba de todas las llamadas posibles y su valor de retorno.
- Cobertura del valor del parámetro (PVC). Para comprobar si se prueban todos los valores posibles para un parámetro. Por ejemplo, una cadena podría ser cualquiera de estos comúnmente: a) nulo, b) vacío, c) espacio 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. No probar cada valor de parámetro posible puede provocar un error. Probar solo una de estas podría dar como resultado una cobertura de código del 100 % ya que se cubre cada línea, pero como solo se prueba una de siete opciones, significa solo una cobertura del 14,2 % del valor del parámetro.
- Cobertura de herencia: en el caso de una fuente orientada a objetos, al devolver un objeto derivado referido por la clase base, se debe probar la cobertura para evaluar, si se devuelve un objeto hermano.
Nota: El análisis de 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 de función. Y también otras coberturas estáticas. Incluso si el análisis de código estático informa que se cubre el 100 % del código, no proporciona informes sobre su conjunto de pruebas si se prueba toda la cobertura de código posible.
