Skip to content
STIMSMITH

mutation testing

Concept

Mutation testing is illustrated in the provided evidence as a way to evaluate generated test cases by changing an executable model to create a mutant model, running the same generated tests, and observing which tests fail. In the VAMP processor case study, changes to int_add, int_sub, and cell2data caused many generated test cases to fail, indicating that the tests detected the injected changes.

First seen 5/26/2026
Last seen 6/5/2026
Evidence 2 chunks
Wiki v1

WIKI

Overview

In the provided case study, mutation testing is represented by modifying an executable model to create a mutant model and then running generated test cases against that altered model. The purpose stated in the evidence was to evaluate the quality of generated test cases: after the authors introduced changes into the executable model, a majority of the tests detected the errors. [C1]

Case-study context

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

3 connections
The paper mentions mutation testing as potential future work.
The paper uses mutation testing to evaluate the quality of generated test cases.
The paper mentions mutation testing as a direction for better coverage criterion.

CITATIONS

6 sources
6 citations — click to expand
[1] Mutation testing in the case study evaluated generated test cases by introducing changes into an executable model to produce a mutant model, after which many tests detected the errors. Test Program Generation for a Microprocessor: A Case Study
[2] The VAMP processor executable model was generated as ML/SML code and included instruction and execution-related definitions such as instr, int_add, int_sub, cell2data, exec_instr, sigma_0, and execInstrs. Test Program Generation for a Microprocessor: A Case Study
[3] HOL-TestGen generated two test scripts for load/store and arithmetic operation sequences; each produced 585 test cases that were transformed into executable testers, and the original executable model revealed no errors because it was also used for test generation. Test Program Generation for a Microprocessor: A Case Study
[4] The mutant model was produced by introducing three changes into int_add, int_sub, and cell2data in the generated SML code. Test Program Generation for a Microprocessor: A Case Study
[5] For arithmetic-operation tests on the mutant model, 303 of 585 test cases succeeded and 282 of 585 failed, with no warnings, errors, or fatal errors. Test Program Generation for a Microprocessor: A Case Study
[6] For load/store-operation tests on the mutant model, 54 of 585 test cases succeeded and 531 of 585 failed, with no warnings, errors, or fatal errors. Test Program Generation for a Microprocessor: A Case Study