Calcula la cobertura de sentencias, decisiones, funciones, condiciones y MC/DC, compárala con requisitos publicados y detecta informes imposibles.
Las tres cifras que dan jest, pytest-cov, JaCoCo, lcov y SonarQube. Introduce las que tengas: con una basta.
Las informan las herramientas creadas para trabajo de certificación (VectorCAST, LDRA, Rapita, BullseyeCoverage). Déjalo vacío si tu herramienta no las mide.
Las definiciones de cobertura de decisiones y de MC/DC están citadas del Manual de Ingeniería de Software de la NASA, sección 7.21.
| Criterio | Qué exige | Lo informan |
|---|---|---|
| Cobertura de sentencias | Cada sentencia ejecutable se ejecuta al menos una vez. | Todas las herramientas habituales |
| Cobertura de decisiones | «Cada punto de entrada y de salida del programa se ha invocado al menos una vez, y cada decisión del programa ha tomado todos los resultados posibles al menos una vez.» También se llama cobertura de ramas. | Todas las herramientas habituales |
| Cobertura de funciones | Cada función o método se llama al menos una vez. No dice nada de lo que ocurre dentro. | La mayoría de las habituales |
| Cobertura de condiciones | Cada subexpresión booleana toma ambos valores, sin exigir que ninguna de ellas cambie el resultado. Es el criterio que más se confunde con MC/DC. | Algunas herramientas; a menudo mal etiquetada |
| MC/DC | «Cada punto de entrada y de salida del programa se ha invocado al menos una vez. Cada condición de una decisión del programa ha tomado todos los resultados posibles al menos una vez, y se ha demostrado que cada condición afecta al resultado de esa decisión de forma independiente.» | Solo herramientas de certificación |
Cada uno vincula la cobertura estructural a un nivel de criticidad, y cada uno se vende en lugar de publicarse. No vamos a imprimir un porcentaje cuya fuente no podemos mostrarte: consulta el estándar o pregunta a tu autoridad de certificación.
| Estándar | Ámbito | A qué vincula la cobertura |
|---|---|---|
| DO-178C / ED-12C | Software aeronáutico | Vincula las obligaciones de cobertura estructural al nivel de software (A–E). Lo vende RTCA; el nivel determina qué criterio se aplica, y MC/DC entra en el nivel A. |
| ISO 26262 | Vehículos de carretera | Vincula las recomendaciones de cobertura estructural al ASIL (A–D), a nivel de unidad y de integración. Lo vende ISO. |
| IEC 62304 | Software de dispositivos médicos | Vincula el rigor de la verificación a la clase de seguridad del software (A–C). Lo vende IEC. |
Los porcentajes de cobertura describen la ejecución de las pruebas, no la corrección ni la seguridad. Los umbrales que se muestran aquí están citados de las fuentes indicadas; no son asesoramiento de certificación, y el estándar o la autoridad que rige tu proyecto es la única referencia vinculante.
También podrías encontrar útiles estas calculadoras
Pega tu código y obtén su complejidad ciclomática por función
Cuenta SLOC, comentarios y líneas en blanco y estima el esfuerzo
Mide el rendimiento DevOps con cuatro métricas clave
Pega tu código y obtén su Big-O de tiempo y espacio
Introduce los elementos cubiertos y el total de cualquiera de los criterios: sentencias, decisiones, funciones, condiciones o MC/DC. Obtienes cada porcentaje, una comparación con los requisitos cuyos umbrales están realmente publicados y una comprobación de si tus cifras pueden ser todas ciertas a la vez. Los estándares que regulan la cobertura sin publicar una cifra se nombran en lugar de suponerse.
La cobertura de código es la proporción de algo contable de tu programa (sentencias, decisiones, condiciones) que tus pruebas ejecutaron al menos una vez. Es una familia de criterios, no una sola cifra, y los criterios están ordenados por fuerza: cumplir MC/DC por completo implica cumplir por completo la cobertura de decisiones, que a su vez implica la de sentencias. Ese orden es lo útil, porque significa que un informe que declara el 100 % de un criterio fuerte junto a menos del 100 % de uno más débil es imposible por dentro.
Cobertura de un criterio cualquiera
Comprobar si tienes el criterio que realmente pide el estándar, en lugar del que imprime tu integración continua.
Cuando dos cifras no pueden ser ciertas a la vez, la causa casi siempre es una diferencia de ámbito o de filtro entre ejecuciones. La comprobación de imposibilidad la señala.
Decidir qué criterio mide tu puerta de calidad y si se aplica al código nuevo o a todo, usando el valor predeterminado publicado de SonarQube como referencia y no un rumor.
Un conjunto de pruebas sin aserciones puede llegar al 100 % de cobertura de sentencias. Ver los criterios uno al lado del otro hace concreta la diferencia entre ejecutar y verificar.
«87 % de cobertura» no es un dato hasta que sabes 87 % de qué. La cobertura de sentencias y la MC/DC del mismo conjunto de pruebas pueden diferir en decenas de puntos, y solo una es la que pide un estándar de seguridad.
El manual de la NASA fija el 100 % de MC/DC para los componentes críticos para la seguridad. No hay nada equivalente publicado para la cobertura de sentencias, así que una cifra de sentencias no responde a esa pregunta por alta que sea.
Los criterios de cobertura se subsumen unos en otros, así que algunas combinaciones de cifras son imposibles. Un informe con 100 % de MC/DC y 92 % de decisiones significa que las dos cifras salen de ejecuciones, ámbitos o filtros distintos.
El 80 % predeterminado de SonarQube se aplica solo al código nuevo, y se omite por debajo de 20 líneas nuevas. Aplicado a todo un código es un objetivo mucho más duro que la puerta de la que salió.
Divide los elementos cubiertos entre los elementos totales de un criterio y multiplica por 100. La aritmética es trivial; lo importante es qué criterio has contado. Sentencias, decisiones, funciones, condiciones y MC/DC cuentan cosas distintas, así que cada uno da un porcentaje distinto para el mismo conjunto de pruebas.
No hay ninguna cifra universal publicada, y esta página no va a inventarla. Los dos umbrales que podemos citar son la puerta predeterminada de SonarQube (80 % en código nuevo, omitida por debajo de 20 líneas nuevas por cubrir) y el 100 % de MC/DC de NASA SWE-219 para componentes críticos para la seguridad. Cualquier objetivo del 70 % u 80 % global presentado como estándar del sector es convención, no un requisito publicado.
MC/DC exige que cada condición de una decisión tome ambos valores y que se demuestre que cada condición afecta al resultado de la decisión de forma independiente. La cobertura de condiciones solo exige la primera mitad. Esa exigencia de independencia es toda la diferencia, y por eso la cobertura de condiciones no sustituye a MC/DC cuando un estándar lo pide. El manual de la NASA lo dice sin rodeos: el criterio MC/DC es mucho más fuerte que la cobertura de condiciones y decisiones.
DO-178C vincula las obligaciones de cobertura estructural al nivel de software, y el criterio que se aplica depende de ese nivel: MC/DC entra en el nivel A. Aquí no publicamos porcentajes por nivel porque DO-178C lo vende RTCA en lugar de publicarlo, así que no podemos mostrarte el texto del que saldría una cifra. Consulta el estándar o pregunta a tu autoridad de certificación. Lo mismo vale para ISO 26262 e IEC 62304.
Con cobertura parcial es posible, porque los denominadores son distintos: MC/DC cuenta obligaciones de condición y decisión, mientras que la cobertura de decisiones cuenta resultados de decisiones. Un conjunto de pruebas que cubre por completo una decisión compleja y nunca llega a una simple puede puntuar más alto en MC/DC. Solo el caso del 100 % es una contradicción: un MC/DC completo implica una cobertura de decisiones completa.
Fuera del trabajo crítico para la seguridad, normalmente no. La cobertura mide ejecución, no verificación: un conjunto de pruebas sin aserciones puede ejecutar todas las líneas. Los últimos puntos porcentuales suelen ser gestión de errores costosa de alcanzar y donde rara vez se esconden los defectos. Cuando un estándar exige el 100 % de un criterio concreto, eso es una obligación de cumplimiento y no un argumento de calidad.
Sí, si las pruebas nuevas incorporan al ámbito archivos que antes no se medían, o si añades código junto a ellas. Es también el motivo más habitual de que dos cifras de un mismo informe discrepen de forma imposible: se midieron sobre conjuntos de archivos distintos.
Las orientadas a trabajo de certificación: VectorCAST, LDRA, Rapita y BullseyeCoverage, entre otras. Las habituales como jest, pytest-cov, JaCoCo y lcov informan cobertura de sentencias, ramas y funciones, pero no MC/DC, y por eso un proyecto que lo necesita suele necesitar una segunda herramienta en lugar de un cambio de configuración.