stuck-at-fault model

Concept

The stuck-at-fault model is presented in the evidence as an implementation-level testing technique for circuits, where a circuit design is modified by mutators that represent fabrication faults such as broken wires between gates. It is characterized as a white-box mutation technique that can be effective for medium-size circuits, but it may miss design-level flaws such as memory write-read errors influenced by byte alignment.

First seen 5/25/2026

Last seen 5/25/2026

Evidence 1 chunks

Wiki v1

WIKI

Overview

The stuck-at-fault model is described as a common circuit-analysis technique in which a given circuit design—treated as an implementation—is modified by mutators that capture a fabrication fault model. The evidence gives an example fault model in which one or more wires connecting gates in a circuit are broken.

Testing characterization

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

LINKED ENTITIES

1 links

conformance testing USED_IN Extracted graph relationship

CITATIONS

6 sources

6 citations — click to expand

[1] Stuck-at-faults are based on modifying a circuit implementation with mutators that capture a fabrication fault model, such as broken wires connecting gates. Test Program Generation for a Microprocessor: A Case Study

[2] Stuck-at-fault testing is characterized as a white-box mutation technique and as an implementation-based testing method when contrasted with specification-based approaches. Test Program Generation for a Microprocessor: A Case Study

[3] Stuck-at-faults are described as very effective for medium-size circuits and as using the structure of the design to construct equivalence-class tests incorporating a fault model. Test Program Generation for a Microprocessor: A Case Study

[4] A limitation noted for this testing technique is that it will not reveal design flaws such as a write-read error influenced by byte alignments in memory. Test Program Generation for a Microprocessor: A Case Study

[5] In the VAMP case study, the authors had a gate-level model available but chose to test at the design level, while noting that equivalence classes could be refined through byte-level or bit-level representations of registers and memory cells. Test Program Generation for a Microprocessor: A Case Study

[6] The source discusses conformance-style test specifications that compare the final execution state, or part of it, against a system under test. Test Program Generation for a Microprocessor: A Case Study