Qué es una prueba de fuzzing y qué cobertura da

Una prueba de ejemplos fija entradas y salidas esperadas: «con este archivo, la tabla tiene dos filas». Una prueba de fuzzing no espera una salida concreta; pregunta otra cosa: «¿existe alguna entrada con la que el programa falle de forma que nunca debería?». El motor parte de unas pocas entradas de ejemplo (el corpus semilla), las muta (cambia bytes, corta, repite, mezcla) y se queda con las que hacen pasar el código por caminos nuevos. Eso se llama fuzzing guiado por cobertura, y es lo que hacen motores de la familia libFuzzer o AFL++.

Lo que el motor detecta es un fallo observable: una excepción no prevista, una caída, un bloqueo que supera el tiempo límite, un consumo de memoria descontrolado. No sabe si el resultado era «correcto»; solo ve que algo reventó. Por eso se usa sobre código propio, con permiso, en el entorno de desarrollo o de CI.

Un arnés es el pedazo de código que conecta el motor con la función que se prueba: recibe los bytes que genera el motor y se los entrega a la función. Su decisión más importante es qué excepciones son normales. Si la biblioteca rechaza un archivo mal formado con su propia excepción (TablaInvalida), eso es la respuesta correcta y el arnés la deja pasar; cualquier otra excepción es un hallazgo.

El corpus semilla da al motor un punto de partida con entradas válidas de varias formas. Cuantas más formas válidas distintas, más rápido llega a código profundo.

Abre fuzz/fuzz_lector.py y la carpeta fuzz/corpus-semilla.

La cobertura mide qué líneas (o ramas) del código se ejecutaron durante la corrida. Es la única forma de saber qué parte del programa ha visto el motor: lo que nunca se ejecuta nunca se prueba. Un porcentaje bajo en un módulo no es un fallo, es una zona ciega: dice dónde no se ha mirado.

La causa más común de un cero es que ningún arnés llega hasta ese módulo: el motor solo explora lo que el arnés le deja alcanzar.

Abre informe/cobertura-por-modulo.csv.

La salida de la corrida termina con «ningún fallo encontrado». Lee con cuidado lo que cubrió: el lector alcanzó una cobertura alta, pero los módulos que el arnés no importa no se ejecutaron. Un resultado sin fallos describe lo que se ejecutó, con las entradas probadas, en el tiempo que corrió; no demuestra que no existan fallos. Y una cobertura de líneas alta tampoco: se puede pasar por una línea con una entrada que no la rompe y no pasar nunca con la que sí.

Revisa fuzz/corrida-10min.txt y el informe de cobertura antes de contestar.