Cobertura de seguridad: qué está probado y qué no

La cobertura de líneas dice qué código se ejecutó mientras corrían las pruebas, no qué se comprobó. Una prueba que llama a la exportación con la administración de su propio conjunto recorre todas las líneas de la función y no comprueba nunca que la de otro conjunto reciba un no. La cobertura de seguridad se mide de otra forma: se parte de los requisitos (los que salieron del modelo de amenazas, de los hallazgos o de un estándar como el ASVS de OWASP) y para cada uno se pregunta qué prueba fallaría si se rompiera, y cuándo corre esa prueba.

Ese «cuándo» importa tanto como el «qué». Una prueba que corre en cada solicitud de cambio frena el fallo antes de que se una al código; una que corre de noche lo avisa al día siguiente; una semanal, cuando el cambio quizá ya está en producción; una omitida, nunca.

Abre el laboratorio y cruza requisitos-seguridad.txt con trazabilidad.txt. Uno de los doce no tiene ninguna prueba asociada, aunque el código donde vive aparece casi entero cubierto en cobertura-lineas.txt.

Ahora mira ejecuciones-ci.txt. Un requisito tiene su prueba escrita, pero la última corrida la omite, y es la única que tiene.

Cuenta los requisitos que tienen al menos una prueba que corre en cada solicitud de cambio y que no está omitida. Los que dependen solo de la corrida nocturna o de la semanal no cuentan para esta pregunta.

El cliente grande pide «el porcentaje de seguridad probado». Con lo que tienes, elige el informe honesto.