Automated Test Generation

Concept

Automated Test Generation is a verification technique that programmatically produces test cases for software and hardware systems, reducing manual effort and enabling coverage at scale. It is applied in domains such as RISC-V processor and SoC verification (e.g., Breker's Test Suite Synthesis) and in software testing for non-traditional artifacts such as Dockerfiles and Python code.

First seen 7/6/2026

Last seen 7/6/2026

Evidence 1 chunks

Wiki v1

WIKI

Automated Test Generation

Overview

Automated Test Generation refers to techniques that programmatically create test cases for validating software or hardware systems, replacing or augmenting manually authored tests. It is used where manual test creation is impractical due to the scale, complexity, or sheer volume of configurations that must be exercised. Approaches range from coverage-guided search-based methods, to result/layer-based analysis for declarative artifacts, to constraint-driven and AI-planning synthesis for hardware.

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

1 connections

Breker Verification Systems ← implements 95% 1e

Breker provides automated test generation as a key approach to meeting RISC-V verification quality expectations.

LINKED ENTITIES

3 links

Breker Verification Systems IMPLEMENTS Extracted graph relationship

RISC-V APPLIED_TO The Breker presentation explicitly frames automated test generation as key to addressing RISC-V core and SoC verification challenges, including custom instruction verification and architectural compliance.

Test Suite Synthesis RELATED_TO Test Suite Synthesis is the product category under which Breker delivers automated test generation for x86, Arm, and RISC-V processors and SoCs.

CITATIONS

7 sources

7 citations — click to expand

[1] Automated test generation is identified as a key technique to meet RISC-V verification quality expectations, given the scale at which established ISAs (e.g., Arm, ~$150M/year on 10^15 verification cycles per core) are verified. RISC-V Core & SoC Verification: A New Normal in Verification Techniques (Breker, Verification Futures Reading 2024)

[2] RISC-V verification challenges include custom instruction verification, compliance assurance via RISC-V International certification, and a broad range of target architectures (embedded cores, processor clusters, application processors). RISC-V Core & SoC Verification: A New Normal in Verification Techniques (Breker, Verification Futures Reading 2024)

[3] Breker Verification Systems delivers Test Suite Synthesis for RISC-V cores and SoCs, with a SystemVIP Library that includes Core Integrity FastApps, RISC-V System Integrity TrekApp, ARM System Integrity TrekApp, Cache Coherency TrekApp 2.0, Firmware-First TrekApp, Power Management TrekApp, Security TrekApp, and Networking TrekApp. RISC-V Core & SoC Verification: A New Normal in Verification Techniques (Breker, Verification Futures Reading 2024)

[4] Two principal automated test generation paradigms used in hardware verification are Constrained Random and AI Planning Algorithm Synthesis, applied to crossing RISC-V core verification components and concurrent test execution. RISC-V Core & SoC Verification: A New Normal in Verification Techniques (Breker, Verification Futures Reading 2024)

[5] Core-level automated test generation scenarios for RV64 include instruction generation, instruction coverage analysis (e.g., 27/103 reachable opcodes exercised in a register-only test, with atomics/loads/stores unreachable), load/store (with locality of writes), exception testing, and page-based virtual memory/MMU tests (e.g., swapping MMU PTEs and checking memory access). RISC-V Core & SoC Verification: A New Normal in Verification Techniques (Breker, Verification Futures Reading 2024)

[6] Because Dockerfiles contain no branches, conventional branch-coverage objective functions used in search-based automated test generation are meaningless for them; a result-based method that analyzes Dockerfile instructions and Docker image layers reproduced over 80% of developer-authored tests. Toward Automated Test Generation for Dockerfiles Based on Analysis of Docker Image Layers (arXiv:2504.18150v1, 2025)

[7] A relative Lines-of-Code (LOC) heuristic for property-based Python testing with TSTL improved branch and statement coverage by often >20% (up to 40%+), and improved fault detection by usually >75% (up to 400%+), and is comparable to or better than two established random-testing guidance approaches. Using Relative Lines of Code to Guide Automated Test Generation for Python (arXiv:2103.07006v1, 2021)