Cobertura de pruebas en pruebas de software: cómo medirla

⚡ Resumen inteligente

La cobertura de pruebas en las pruebas de software mide qué porcentaje de una aplicación se prueba realmente con un conjunto de pruebas. Revela requisitos, rutas de código y riesgos no probados, lo que permite a los equipos añadir casos específicos y lanzar versiones con una confianza medible.

  • 🎯 Definición: Los informes de cobertura de pruebas indican qué requisitos, características y rutas de código ya han sido evaluadas por las pruebas existentes.
  • 🧭 Tipos de Candidiasis: La declaración, la rama, la condición, la ruta, los requisitos y la cobertura de riesgos responden cada uno a una pregunta diferente.
  • 🇧🇷 Code vs Prueba: Code La cobertura mide las líneas de código fuente ejecutadas, mientras que la cobertura de pruebas mide el plan de pruebas general.
  • 🧮 Fórmula: Divide las líneas ejecutadas entre el total de líneas y luego multiplica por 100 para obtener el porcentaje.
  • 🛠️ técnicas: El análisis de valores límite, las tablas de decisión y las pruebas de transición de estados amplían la cobertura sin aumentar el tamaño del conjunto de herramientas.
  • 📈 Mejoramiento: Clasifique los módulos por riesgo, automatice el conjunto de pruebas de regresión y revise la tendencia de cobertura en cada sprint.
  • 🤖 Asistencia de IA: Las herramientas de IA generan pruebas unitarias faltantes y clasifican las rutas no probadas según el riesgo de producción.

¿Qué es la cobertura de prueba?

La cobertura de prueba se define como una métrica en Pruebas de software que mide la cantidad de pruebas realizadas por un conjunto de pruebas. Incluirá la recopilación de información sobre qué partes de un programa se ejecutan al ejecutar el conjunto de pruebas para determinar qué ramas de declaraciones condicionales se han tomado.

En términos simples, es una técnica para garantizar que sus pruebas prueben su código o qué parte de su código ejerció al ejecutar la prueba.

¿Qué hace la cobertura de pruebas?

En un proyecto real, la cobertura de pruebas respalda cuatro actividades prácticas:

  • Encontrar el área de un requisito no implementado por un conjunto de casos de prueba
  • Ayuda a crear casos de prueba adicionales para aumentar la cobertura.
  • Identificar una medida cuantitativa de la cobertura de la prueba, que es un método indirecto para el control de calidad.
  • Identificar casos de prueba sin sentido que no aumentan la cobertura

Beneficios de la cobertura de pruebas en ingeniería de software

Esas actividades se traducen en beneficios concretos para la ingeniería.

  • Puede asegurar la calidad de la prueba.
  • Puede ayudar a identificar qué partes del código se modificaron realmente para el lanzamiento o la corrección.
  • Puede determinar todos los puntos de decisión y rutas en su aplicación que no fueron probados, lo que le permite aumentar la cobertura de las pruebas.
  • Prevenir precisa fuga
  • El tiempo, el alcance y el coste se pueden mantener bajo control
  • Prevención de defectos en una etapa temprana del ciclo de vida del proyecto
  • Las lagunas en los requisitos, casos de prueba y defectos a nivel de unidad y de código se pueden encontrar de forma sencilla

Tipos de cobertura de pruebas

La cobertura nunca es un solo número. Equipos track varios tipos a la vez, porque cada uno responde a una pregunta diferente sobre el mismo conjunto. La tabla a continuación agrupa los tipos que encontrará con más frecuencia.

Tipo de cobertura Qué mide Mejores usados ​​para
Cobertura de la declaración (línea) Las líneas ejecutables se ejecutan al menos una vez. Pruebas unitarias y auditorías de código heredado
Cobertura de sucursales o decisiones Resultado verdadero y falso de cada decisión Lógica condicional y de validación
Cobertura de condiciones Cada subexpresión booleana como verdadera y como falsa. Expresiones compuestas AND u OR
Cobertura de ruta Rutas únicas recorridas a través de un módulo flujos financieros y de seguridad crítica
Cobertura de funciones Funciones o métodos invocados por las pruebas Capas de API y de servicio
Cobertura de requisitos Requisitos asignados a al menos una prueba Aceptación y contracfirma doble
Cobertura de riesgos Se identificaron zonas de alto riesgo que se ejercitaron. Ciclos de liberación cortos

Los primeros cinco tipos son medidas a nivel de código y pertenecen a pruebas de caja blanca, mientras que los requisitos y la cobertura de riesgos se sitúan en el nivel del plan de pruebas.

¿Cuáles son las principales diferencias entre Code ¿Cobertura y cobertura de pruebas?

Code cobertura y la cobertura de prueba son técnicas de medición que le permiten evaluar la calidad del código de su aplicación.

A continuación, se muestran algunas diferencias fundamentales entre las cabinas de estos métodos de cobertura:

Parámetros Code Global Cobertura de prueba
Definición Code El término "cobertura" se utiliza cuando se evalúa el código de una aplicación mientras esta se está ejecutando. Cobertura de prueba significa plan de prueba general.
Objetivo Code Las métricas de cobertura pueden ayudar al equipo a supervisar sus pruebas automatizadas. La cobertura de la prueba proporciona detalles sobre el nivel en el que se ha probado la codificación escrita de una aplicación.
Subtipos Code cobertura dividida con subtipos como cobertura de sentencia, cobertura de condición, cobertura de rama, Togglcobertura electrónica, cobertura de los Estados Federados de Micronesia. Ningún subtipo de método de cobertura de prueba.

Fórmula de cobertura de prueba

Para calcular la cobertura de la prueba, debe seguir los pasos que se indican a continuación:

Paso 1) Contar Y, el total de líneas de código en la pieza de software que estás las pruebas

Paso 2) Contar X, el número de líneas de código que se ejecutan actualmente en todos los casos de prueba

Ahora, necesita encontrar (X dividido por Y) multiplicado por 100. El resultado de este cálculo es el porcentaje de cobertura de su prueba.

Por ejemplo:

Si el número de líneas de código en un componente del sistema es 500 y el número de líneas ejecutadas en todos los casos de prueba existentes es 50, entonces su cobertura de prueba es:

(50 / 500) * 100 = 10%   // executed lines divided by total lines

Ejemplos de cobertura de pruebas

El porcentaje por sí solo nunca lo dice todo, como demuestran los ejemplos que aparecen a continuación.

Ejemplo 1:

Por ejemplo, si el cuchillo es un objeto que desea probar, debe centrarse en comprobar si corta las verduras o frutas con precisión. Sin embargo, existen otros aspectos a considerar, como que el usuario pueda manejarlo cómodamente.

Ejemplo 2:

Por ejemplo, si quieres comprobar la aplicación Bloc de notas, es imprescindible verificar sus funciones esenciales. Sin embargo, también debes considerar otros aspectos, como que la aplicación responda correctamente al usar otras aplicaciones, que el usuario comprenda su funcionamiento, que no se bloquee al intentar realizar alguna acción inusual, etc.

Técnicas de cobertura de pruebas

Ambos ejemplos apuntan a la misma conclusión: alcanzar un objetivo de cobertura depende menos de escribir más pruebas y más de elegir la técnica de diseño de pruebas adecuada. Las técnicas que se describen a continuación amplían la cobertura mientras mantienenping La suite es pequeña.

  • Análisis de valores límite: Selecciona entradas en los extremos de cada rango válido, donde los defectos se agrupan con mayor frecuencia. Ver análisis de valor límite para casos resueltos.
  • Particionamiento de equivalencia: Agrupa las entradas que la aplicación trata de forma idéntica, de modo que un solo caso puede representar con seguridad toda una clase de valores.
  • Prueba de tablas de decisión: Cubre combinaciones de condiciones y sus resultados esperados dentro de una única cuadrícula.
  • Pruebas de transición de estado: Realiza todos los movimientos válidos e inválidos entre los estados de la aplicación.
  • Pruebas de ruta base: Deriva el conjunto mínimo de rutas independientes a partir del grafo de flujo de control.
  • Pruebas basadas en riesgos: Clasifica las funcionalidades según su impacto en el negocio y aborda primero las de mayor riesgo.
  • Prueba exploratoria: Descubre lagunas que los casos guionizados y los informes de cobertura nunca exponen.

¿Cómo se puede lograr la cobertura de pruebas?

Una vez seleccionadas las técnicas, cuatro rutas establecidas proporcionan la cobertura.

  • La cobertura de la prueba se puede realizar ejercitando técnicas de revisión estática, como revisiones por pares, inspecciones y recorridos.
  • Transformando los defectos ad-hoc en casos de prueba ejecutables
  • A nivel de código o de prueba unitaria, la cobertura de la prueba se puede lograr aprovechando la cobertura de código automatizada o las herramientas de cobertura de prueba unitaria.
  • La cobertura de pruebas funcionales se puede realizar con la ayuda de herramientas de gestión de pruebas adecuadas.

Cómo mejorar la cobertura de las pruebas

Establecer la cobertura es el punto de partida; aumentarla es una rutina repetible. Siga esta secuencia al inicio de cada ciclo de lanzamiento.

  1. Establezca la cifra actual como referencia. Genere un informe de cobertura y registre la cobertura de declaraciones, ramas y requisitos por separado, de modo que las brechas permanezcan visibles por módulo en lugar de quedar ocultas dentro de un promedio general del proyecto.
  2. Asignar pruebas a requisitos. Construye una tracMatriz de aptitud que vincula cada requisito con al menos un caso de prueba. Cualquier fila vacía representa una deficiencia confirmada, no una sospecha.
  3. Clasifique los módulos por riesgo. La lógica de pago, autenticación y migración de datos merece una cobertura mucho más exhaustiva que una pantalla de ayuda estática, así que destine el presupuesto a donde un fallo tendría mayores consecuencias.
  4. Añade casos negativos y casos límite. Las entradas vacías, los valores sobredimensionados, los tiempos de espera de red y los errores de permisos llegan a ramas que las pruebas de la ruta normal nunca tocan.
  5. Superpón los niveles de prueba. Combinar examen de la unidad, pruebas de integracióny controles de extremo a extremo, porque cada nivel cubre lo que los demás no pueden cubrir estructuralmente.
  6. Automatice el conjunto de pruebas de regresión. Promolos casos estables en pruebas de automatización y ejecutarlos dentro del Canalización de CI / CD después de cada confirmación.
  7. Eliminar casos redundantes. Elimine las pruebas duplicadas que añaden minutos de ejecución sin añadir una sola línea sin cubrir.
  8. RevObserva la tendencia en cada sprint. Traccobertura k al lado de densidad de defectosEl aumento de las fugas frente a una cobertura uniforme es una señal de alerta temprana de un punto ciego.

⚠️ Advertencia: No considere el 100 por ciento como el objetivo. Un conjunto de pruebas al 85 por ciento con aserciones sólidas protege una versión mucho mejor que un 95 por ciento de comprobaciones superficiales que ejecutan código sin verificar ningún resultado.

Desventajas de la cobertura de pruebas

La cobertura sigue siendo valiosa, pero tiene limitaciones que conviene mencionar antes de informar cualquier porcentaje.

  • La mayoría de las tareas cubiertas por la prueba son manuales ya que no existen herramientas para automatizar. Por lo tanto, se necesita mucho esfuerzo para analizar los requisitos y crear casos de prueba.
  • La cobertura de prueba le permite contar características y luego compararlas con varias pruebas. Sin embargo, siempre hay espacio para errores de juicio.

Preguntas Frecuentes

La mayoría de los equipos consideran que entre el 70 y el 80 por ciento es un objetivo práctico, y el 90 por ciento o más para módulos críticos para la seguridad. Perseguir el 100 por ciento rara vez compensa el esfuerzo. Es preferible priorizar la profundidad en la lógica de alto riesgo en lugar de distribuir las pruebas uniformemente por todo el código.

No. La cobertura total demuestra que todos los elementos se ejecutaron correctamente, no que todos los valores, requisitos o recorridos del usuario se validaron. Requisitos faltantes, aserciones débiles y fallas no funcionales, como tiempos de respuesta lentos, aún pueden pasar desapercibidas incluso en una suite que reporta una cobertura del 100 %.

Un informe de cobertura enumera las líneas, ramas y funciones cubiertas y no cubiertas por archivo, con porcentajes resumidos por módulo y proyecto. Herramientas como JaCoCo También señale las ramas parcialmente cubiertas, que suelen ser las que se cierran más rápidamente.

La IA analiza el código fuente, el historial de ejecución y los datos de defectos para identificar rutas de alto riesgo no probadas y, a continuación, propone casos para solucionarlas. Además, prioriza las pruebas que deben ejecutarse, acortando el tiempo de retroalimentación en el proceso sin sacrificar la cobertura.

Sí. Herramientas como Diffazul Escribe automáticamente pruebas unitarias para la lógica no cubierta, y los modelos generativos convierten los requisitos en lenguaje natural en casos ejecutables. La revisión humana sigue siendo esencial, ya que las aserciones generadas pueden pasar sin comprobar el comportamiento significativo.

Resumir este post con: