Campaña de detección de errores
Elige un experimento que pueda exponer una nueva garantía violada, luego gasta cómputo según lo que el experimento realmente observa. Mantén visibles los costos de descubrimiento, reproducción y clasificación. La velocidad es un factor de rendimiento listado, junto con "La cobertura de código debería crecer con el tiempo" y la resolución de problemas bloqueantes, y un objetivo útil "debe tener buena cobertura en el código que está probando"; los recuentos de ejecución por sí solos no establecen un alcance útil (Integración OSS-Fuzz, Cobertura, Rendimiento de ClusterFuzz, Factores de rendimiento).
Establecer la capacidad actual
Lee la revisión real del objetivo, la compilación habilitada, los productores de harness y los cuerpos de aserción. Registra qué entradas, estados iniciales, operaciones, efectos, programaciones, fallos y configuraciones puede ejercitar y observar cada línea existente. Inspecciona las exclusiones y los casos rechazados. Utiliza herramientas de cobertura o accesibilidad solo donde su compilación/ejecución documentada sea aplicable; Fuzz Introspector documenta informes "Para proyectos escritos en C/C++, Python y Java", cada uno con su propia herramienta de compilación, por lo que no es un backend universal (Fuzz Introspector, visión general y Diferencias en las herramientas de compilación). Para un proyecto de JavaScript o TypeScript, lee el inventario de líneas JS.
Cuenta una capacidad como existente cuando la implementación inspeccionada la proporciona. Para un objetivo que ya usa generación de programas válidos, comparación de resultados entre motores e historiales de transacciones, agregar los mismos mecanismos bajo nuevos nombres no es el avance propuesto. Elige en su lugar una interacción u observación no cubierta: dbsqlfuzz de SQLite "muta tanto la entrada SQL como el archivo de base de datos al mismo tiempo" y encontró fallos "pasados por alto por fuzzers anteriores", un precedente concreto para buscar dimensiones juntas. Es "un fuzz tester propietario": toma prestado el mecanismo, no una herramienta pública asumida (Pruebas de SQLite, §2 y §4.1.3).
Hacer ejecutable un candidato
Describe el candidato en la nota de experimento existente del proyecto; no introduzcas un servicio o esquema obligatorio. Mantén estas decisiones juntas, con rutas de evidencia. OSS-Fuzz pide que un objetivo "haga al menos algún progreso" en una ejecución local corta, y la reproducción necesita la compilación que coincida con el informe (Integración OSS-Fuzz, Objetivo Fuzz, reproducción, Construir la imagen y los fuzzers):
- Productor y brecha: punto de entrada real más el espacio de fallos omitido por la línea base.
- Garantía y oráculo: contrato rector, observación ejecutable y resultados legales/no admitidos/no concluyentes.
- Búsqueda: valores/estados/operaciones generados y cualquier elección controlada de programación, fallo o configuración.
- Piloto: envoltura autorizada de tiempo transcurrido/trabajadores/recursos, material de reproducción y la evidencia que justificará la siguiente asignación.
Diseña las observaciones antes de multiplicar las cargas de trabajo. Los objetos trazables de Elle revelan dependencias que las sobrescrituras ordinarias ocultan, porque las escrituras ciegas en un registro "destruyen la historia". Su inferencia también tiene límites explícitos: el verificador es sólido y "se acerca a garantizar la completitud", y "Nuestro enfoque ignora los predicados y trata solo con objetos individuales". Un generador que produce más historias no informativas no repara esos límites (Elle, §§3, 4.3 y 9). Usa correctness-oracles para el contrato general y un especialista debajo para su modelo particular.
| Dimensión u observación faltante | Especialista relevante |
|---|---|
| Objetos API dependientes y secuencias de operaciones legales | stateful-property-testing |
| Estados de navegador o UI de React alcanzables sin un modelo de operaciones, con oráculos por estado y reproducción de ruta | ui-state-exploration |
| Programas válidos en tiempo de ejecución con estado/efectos requeridos | semantic-program-generation |
| Comparación de ejecuciones independientes o relación justificada entre ejecuciones | semantic-differential-testing, metamorphic-testing |
| Mecanismos de instrumentación/búsqueda o material de búsqueda retenido | coverage-guided-fuzzing, corpus-evolution |
| Diagnósticos de acceso a memoria o elecciones de programación controladas | native-memory-instrumentation, race-detection-campaigns, schedule-exploration |
| Garantías de objetos concurrentes o transacciones | linearizability-checking, transactional-history-testing |
| Fallos de despliegue, entorno controlado o límites de recuperación | distributed-fault-testing, deterministic-simulation, crash-consistency-testing |
| Restricciones de ruta difíciles o invariantes acotadas | symbolic-concolic-execution, bounded-model-checking |
| Crecimiento de recursos, progreso, interacciones de compilación o precisión numérica | resource-complexity-testing, liveness-testing, configuration-differential-testing, numerical-oracles |
La tabla dirige las responsabilidades de este paquete; no establece que una herramienta nombrada sea compatible con el objetivo. Lee solo el especialista seleccionado y sus referencias aplicables. Usa harness-sensitivity para obtener evidencia de que un nuevo oráculo alcanza y rechaza violaciones representativas, preferiblemente a través de regresiones o controles existentes; las pruebas de mutación de SQLite "verifican que el conjunto de pruebas detecta la mutación" (Pruebas de SQLite, §7.6). Mantén esto proporcional al experimento, no una ronda de aprobación recurrente.
Asignar a partir de la evidencia del piloto
Ejecuta dentro de la envoltura autorizada. Verifica si el código objetivo y la propiedad prevista son ejercitados; distingue las rutas no disponibles de las rutas alcanzables que la mutación no ha resuelto. Fuzz Introspector compara el "potencial de accesibilidad estática" de cada fuzzer con la cobertura dinámica para esta distinción. Cambia el experimento cuando un productor faltante, un prerrequisito semántico o una observación sean el factor limitante (Fuzz Introspector, visión general). Para diagnósticos, lee diagnóstico del piloto.
Extiende una línea informativa cuando su evidencia justifique más búsqueda. Compara líneas complementarias donde sus mecanismos de búsqueda difieran; AFL++ dice "Para cada fuzzer secundario debe haber una variación" (Profundidad de AFL++, §3.c Uso de múltiples núcleos). Usa tiempo real, trabajadores y límites de recursos, no una duración o recuento de núcleos universal. Mantén las banderas de tiempo de ejecución en el especialista; el tiempo de espera por entrada, la duración de la campaña y los límites de memoria son controles diferentes (Opciones de libFuzzer 23.1.0).
Mantén contadores sin procesar para evaluaciones de propiedades y alcance semántico/código, candidatos sin procesar y hallazgos reproducidos, duplicados y desconocidos, y costos de configuración/ejecución/reducción/clasificación. No los colapses en una puntuación de productividad inventada. Cuando las afirmaciones comparativas importen, usa condiciones emparejadas y ensayos repetidos con variabilidad; FuzzBench informa "el número de ensayos, la media, la mediana, la desviación estándar" y "la distribución de las coberturas alcanzadas" en lugar de una sola ejecución afortunada (Informe de FuzzBench, Resumen por benchmark).
Preserva las entradas originales, el estado inicial, la fuente/compilación/configuración, la instrumentación, las salidas sin procesar y las opciones de reproducción antes de resumir. Un caso de prueba de OSS-Fuzz "contiene los bytes que se introdujeron en" el objetivo, y algunos errores "son reproducibles solo en modo de 32 bits o solo en modo de 64 bits" bajo el sanitizador informado; una semilla por sí sola no es ese artefacto completo (Reproducción de OSS-Fuzz, Errores del objetivo Fuzz y Construir la imagen y los fuzzers). Enruta los candidatos a failure-reduction y evidence-based-triage; deja los hallazgos poco fiables o no resueltos visibles en lugar de contarlos o descartarlos silenciosamente. ClusterFuzz filtra según la fiabilidad de la reproducción y mantiene estadísticas "sobre la frecuencia con la que ocurren los problemas, y bajo qué condiciones" (Clasificación de ClusterFuzz, Filtrado de casos de prueba y Estadísticas de fallos).
Finalizar la decisión de asignación
Registra continuar, cambiar de dimensión, reproducir/reducir/clasificar, o detener, con la razón observada y el espacio restante. Una meseta motiva un diagnóstico; no prueba ni la corrección ni que otra herramienta ayudará. Preserva cero hallazgos como un resultado acotado. Una cola de candidatos no procesados puede justificar gastar el siguiente tramo en evidencia en lugar de generación. Para objetivos guiados por cobertura de libFuzzer o AFL, ClusterFuzz aconseja que cuando un objetivo encuentra muchos fallos nuevos, "arreglarlos es probablemente más importante que analizar el rendimiento" (Rendimiento de ClusterFuzz, Cuándo analizar el rendimiento del objetivo Fuzz).
Devuelve la garantía probada, el presupuesto real, el comportamiento alcanzado, las rutas de evidencia, los hallazgos clasificados y la siguiente decisión. Describe los efectos visibles para el usuario cuando estén establecidos; mantén una causa posible separada de una violación demostrada. Para un ejemplo de asignación y registro, lee ejemplo de campaña; para atajos engañosos, lee errores comunes.
La invocación preserva el alcance y las reglas de ejecución existentes del usuario. No autoriza por sí misma cambios en el objetivo, instalaciones, gastos en la nube, inyección de fallos en producción ni publicación externa.