Extended Taxonomy Definitions

← Back to Home

← Extended Background

This page provides expanded definitions for the concepts used throughout the survey Fuzzing AI Systems: Foundations, Techniques, and Open Challenges.

The main paper presents these concepts in compact form. This companion page adds interpretation, boundary cases, and examples to clarify how the taxonomy was applied during study annotation and analysis.

Taxonomy at a Glance

Concept Question answered by the concept
Testing Target What concrete artifact does the fuzzer directly exercise?
System Level At what layer is the behavior or failure observed?
AI Paradigm What kind of AI system or learning setting is under test?
Target Framework/Platform Which software ecosystem, runtime, compiler, simulator, or execution platform is tested?
Technique Family What high-level mechanism guides test generation or exploration?
Input-Generation Strategy How are initial tests or seeds created or selected?
Mutation Strategy How are existing tests transformed into new candidates?
Oracle Type and Construction How is a failure recognized, and how is that oracle implemented?
Failure Type What kind of abnormal behavior is ultimately exposed?

Testing Target

The Testing Target identifies the concrete artifact directly exercised by the fuzzer.

The four target categories used in the survey are:

  1. Model
  2. Framework/Library
  3. Compiler/Backend
  4. System-level AI application

This dimension is central because the target strongly influences:

Model

The trained or deployed model is the primary artifact under test.

Typical test inputs include:

Typical observations include:

Representative examples include DeepHunter, DLFuzz, GradFuzz, and DeepCNP.

Framework/Library

The target is software infrastructure that implements AI computation, such as:

Generated tests may need to satisfy constraints over:

Representative examples include FreeFuzz, DocTer, TensorJSFuzz, and ACETest.

Compiler/Backend

The target is the transformation or execution pipeline that converts AI computations into optimized executable code.

Relevant components may include:

Representative examples include TzER, NNsmith, HIRGEN, MLIR-Smith, and NeuRI.

System-Level AI Application

The target is an integrated AI-enabled application rather than an isolated model, API, or compiler component.

The fuzzer evaluates interactions among:

Representative examples include DriveFuzz, AV-FUZZER, MDPFuzz, and MalFuzz.

System Level

The System Level records the layer at which behavior or failure is observed.

The survey distinguishes:

Model-Level Observation

The observed behavior is centered on the trained model.

Examples include:

Component-Level Observation

The observed behavior occurs in an AI software component, such as:

Typical failures include:

System-Level Observation

The observed behavior emerges from an integrated AI-enabled system.

Examples include:

Testing Target and System Level are related but not interchangeable. The Testing Target records the artifact directly exercised by the fuzzer, whereas System Level records where the behavior or failure is observed. A test can exercise one layer while exposing a defect whose consequences become visible at another layer.

AI Paradigm

The AI Paradigm records the type of AI system or learning setting addressed by the study.

Common paradigms include:

The paradigm affects both the test representation and the meaning of failure.

Deep Learning and Computer Vision

Many early studies focus on deep neural networks, especially image classification.

Typical test artifacts include:

Typical failures include:

Autonomous and Cyber-Physical Systems

The input may be a complete scenario rather than a single data instance.

Examples include:

Representative studies include DeepRoad, AV-FUZZER, and DriveFuzz.

Reinforcement Learning

Fuzzing explores sequential decision-making behavior by modifying:

Representative examples include MDPFuzz, ReinSeed, and the RL testing and repair framework.

LLM and Agent-Based Systems

The test input may include:

These settings introduce failure modes such as:

Target Framework or Platform

The Target Framework/Platform records the concrete software ecosystem in which fuzzing is performed.

Examples include:

Frameworks and Libraries

Compilers, Backends, and Runtimes

Simulators and System Platforms

Representative studies include:

Datasets and model architectures are not classified as frameworks or platforms. For example, MNIST, ImageNet, ResNet, and BERT may describe experimental subjects, but they do not identify the software platform being fuzzed.

Technique Family

The Technique Family captures the high-level mechanism or guidance principle used to explore the test space.

The normalized technique families used in the survey are:

  1. Mutation-based
  2. Coverage-guided
  3. Learning-based
  4. Constraint-guided
  5. Search/Heuristic-guided
  6. Differential testing
  7. LLM/Prompt-guided
  8. Generation-based
  9. Metamorphic testing
  10. Debugging/Fault-localization

Mutation-Based

New tests are created by modifying existing:

Representative examples include DeepHunter, FreeFuzz, and DriveFuzz.

Coverage-Guided

The fuzzer retains or prioritizes tests using feedback such as:

Representative examples include DeepHunter and TzER.

Constraint-Guided

Generation or mutation is restricted by explicit or inferred validity constraints.

Representative examples include NNsmith, DocTer, TensorJSFuzz, and ACETest.

Differential Testing

The same or equivalent test is executed across multiple:

Disagreement is treated as a potential failure signal.

Representative examples include NNsmith, Muffin, and DeepDiffer.

Learning-Based and LLM/Prompt-Guided

Learning-based methods use learned policies or models to support:

LLM/prompt-guided methods specifically use LLMs or prompts for:

Representative examples include TitanFuzz, DFUZZ, MirrorFuzz, and NÜWA.

Generation-Based

Tests are synthesized from a grammar, template, generative model, structural model, or other generator rather than only being mutated from existing seeds.

Representative examples include SYNTHFUZZ, MLIR-Smith, and HIRGEN.

Metamorphic Testing

The fuzzer generates related inputs and checks whether an expected relation between their outputs holds.

Representative examples include DeepRoad, QATest, and π-fuzz.

Technique-family labels are multi-label. A study may combine several central mechanisms, such as:

The complete distribution and study mapping are available on the Technique-Family Analysis and Technique-to-Study Mapping pages.

Input-Generation Strategy

The Input-Generation Strategy describes how initial tests or seeds are created or selected before execution or mutation.

Common strategies include:

Seed-Based Generation

The fuzzer starts from existing:

Representative examples include DeepHunter and FreeFuzz.

Constraint-Based Generation

Generated tests must satisfy conditions such as:

Representative examples include NNsmith, ACETest, and DocTer.

Generative or Model-Guided Generation

Tests are synthesized using:

Representative examples include DeepRoad, CtrlFuzz, and MDPFuzz.

LLM-Based Generation

LLMs may create:

Representative examples include TitanFuzz, DFUZZ, and FD-FACTORY.

Input generation is therefore strongly shaped by the validity requirements and representation of the target layer.

Mutation Strategy

The Mutation Strategy describes how an existing test is transformed into a new candidate.

Common mutation categories include:

Semantic or Robustness-Oriented Mutation

The transformation attempts to preserve relevant high-level meaning while changing low-level characteristics.

Examples include:

Representative studies include DeepRoad, DeepHunter, and DEEPWALK.

Gradient-Based Mutation

Model gradients or gradient-related signals guide the search toward error-inducing inputs.

Representative examples include DLFuzz and GradFuzz.

Structure-Aware Mutation

The fuzzer modifies structured artifacts while preserving syntactic or semantic validity.

Examples include:

Representative examples include FreeFuzz, DocTer, TzER, HIRGEN, and MLIR-Smith.

Scenario and Interaction Mutation

System-level fuzzers may mutate:

Representative examples include DriveFuzz, MDPFuzz, and ScenarioFuzz-LLM.

Input generation and mutation are recorded separately because the mechanism used to create initial tests may differ from the mechanism used to transform them during iterative exploration.

Test Oracle and Oracle Construction

The Test Oracle determines how the fuzzer recognizes a failure.

The survey distinguishes four oracle types:

  1. Specification-based
  2. Differential
  3. Crash/Exception
  4. Inconsistency-based

Specification-Based Oracle

The system is checked against:

Representative examples include MDPFuzz and DriveFuzz.

Differential Oracle

Behavior is compared across:

Representative examples include NNsmith, TensorJSFuzz, and DeepDiffer.

Crash/Exception Oracle

Failures are identified through:

Representative examples include DocTer, TzER, and NNsmith.

Inconsistency-Based Oracle

The oracle detects:

Representative examples include DeepHunter and DLRegion.

Oracle Construction

Oracle Construction records how the oracle is implemented or approximated in practice.

Construction mechanisms include:

Oracle type and construction are separate because the same high-level oracle can be realized in different ways.

For example, a differential oracle may compare:

The complete oracle analysis is available on the Oracle Analysis and Study Mapping page.

Failure Type

The Failure Type records the abnormal behavior ultimately exposed by the fuzzer.

The main categories include:

Model-Level Failures

Common examples include:

Representative studies include DeepHunter, DLFuzz, and DeepCNP.

Framework/Library Failures

Common examples include:

Representative studies include FreeFuzz, DocTer, and ACETest.

Compiler/Backend Failures

Common examples include:

Representative examples include TzER, NNsmith, and HIRGEN.

System-Level Failures

Common examples include:

Representative examples include DriveFuzz, AV-FUZZER, MalFuzz, SimsV, and FuzzScene.

AI fuzzing therefore does not rely on one universal failure signal. The appropriate failure definition depends on the target, system layer, domain, and available oracle.

The complete failure analysis is available on the Failure Analysis and Study Mapping page.

Multi-Label Interpretation

Several taxonomy dimensions are intentionally non-mutually exclusive.

A study may:

Multi-label annotation preserves the hybrid and cross-layer nature of AI-system fuzzing rather than forcing each study into one category.