Book 10 · Testing & QualityPage 11 of 36

Fuzz Testing

In Turkish: Fuzz Testi

Updated September 30, 20262 min read

In short

Fuzz testing is an automated technique that feeds a program huge numbers of unexpected or malformed inputs to find crashes, hangs, and security vulnerabilities.

What is fuzz testing?

Fuzz testing, or fuzzing, bombards a program with large numbers of random, unexpected, or malformed inputs and watches for crashes, hangs, memory errors, and other misbehavior. The idea goes back to a 1988 experiment by Barton Miller at the University of Wisconsin, where random input crashed many standard Unix utilities. Fuzzing is especially good at finding bugs that nobody thought to write a test for.

A fuzzer repeatedly generates an input, passes it to a fuzz target, usually a single function such as a file parser, and checks the result. Modern coverage-guided fuzzers start from a few sample inputs, called the seed corpus, mutate them by flipping bits, inserting bytes, or splicing files together, and keep the mutations that reach new code paths, so they explore deeper over time. They are often combined with sanitizers, tools that detect memory errors such as buffer overflows the moment they happen, and every crashing input is saved so developers can reproduce it and add it as a regression test.

Fuzzing is like handing a remote control to a toddler who presses every button in random order: sooner or later they find a combination the designers never considered. It is widely used for security-sensitive code such as file format and image parsers, network protocol handlers, compilers, browsers, and operating system kernels. Many large open-source projects run fuzzers continuously, and fuzzing has uncovered thousands of CVEs.

Fuzz testing is often confused with property-based testing. Both generate inputs automatically, but fuzzing usually runs for hours or days on raw bytes and mainly asks whether the program crashes or misbehaves, while property-based testing runs quickly in the normal test suite, generates structured values, and checks specific correctness rules. Fuzzing is also narrower than penetration testing, which is a broader, human-led attempt to break into a system.

Key takeaways

Fuzzing feeds a program massive amounts of unexpected or malformed input.
It looks for crashes, hangs, memory errors, and security vulnerabilities.
Coverage-guided fuzzers evolve inputs that reach new code paths.
Every crashing input should become a regression test.
It targets code that parses untrusted data, such as files and network messages.

Example

A fuzz test with Go's built-in fuzzinggo

package parser

import "testing"

// Run with: go test -fuzz=FuzzParseConfig
func FuzzParseConfig(f *testing.F) {
    f.Add([]byte("name=app\nport=8080")) // seed input the fuzzer mutates
    f.Fuzz(func(t *testing.T, data []byte) {
        // Any input may be rejected with an error, but it must never crash
        cfg, err := ParseConfig(data)
        if err == nil && cfg == nil {
            t.Errorf("no error and no config for input %q", data)
        }
    })
}

Readers ask

What is the difference between fuzzing and property-based testing?

Fuzzing usually runs for a long time on raw or malformed data and looks mainly for crashes and security bugs. Property-based testing runs as part of the normal test suite with structured inputs and checks that specific rules about the output hold.

What is coverage-guided fuzzing?

It is a fuzzing strategy that measures which code each input reaches and keeps the inputs that reach new paths, then mutates those further. This lets the fuzzer work its way deep into complex code instead of guessing blindly.

Is fuzzing only for security testing?

No. It is best known for finding vulnerabilities, but it also finds ordinary bugs such as crashes on empty input, infinite loops, and differences between two implementations that should behave the same.