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.

¿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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Eliminar casos redundantes. Elimine las pruebas duplicadas que añaden minutos de ejecución sin añadir una sola línea sin cubrir.
- 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.
