Pith. sign in

REVIEW 5 major objections 6 minor 29 references

Simulink Mutation Testing using CodeBERT

T0 review · 5 major / 6 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A CodeBERT-based mask-and-predict pipeline generates Simulink mutants that, under requirements-aware mutation testing, outperform a state-of-the-art tool.

desk verdict Genuine adaptation of MLM mutation to Simulink, but the requirements-aware superiority claim is undercut by an unverified oracle and sparse requirement sets. read the letter →

arxiv 2501.07553 v1 pith:O2IHJSB2 submitted 2025-01-13 cs.SE

Jingfan Zhang , Delaram Ghobari , Mehrdad Sabetzadeh , Shiva Nejati This is my paper · ORCID
classification cs.SE
keywords SimulinkmutationtestingCodeBERTmaskedlanguagemodelingrequirements-awaremutantgenerationfaultinjectionLLM-basedmodel-based
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

BERTiMuS generates mutants for Simulink models by converting the model to a simplified JSON text, masking individual block-property tokens, and replacing them with predictions from CodeBERT, a transformer model fine-tuned on 2,611 third-party Simulink models. The paper claims that this single mechanism covers every block-based Simulink mutation pattern catalogued in the literature, producing mutants such as swapped GotoTag labels and renamed Stateflow variables that rule-based operators would need bespoke logic to generate. Compared against FIM, a state-of-the-art Simulink mutation tool, the two approaches select complementary test sets; under the classical output-based notion of killing they are fairly similar, with FIM slightly ahead in mutant count and difficulty. Under the requirements-aware notion, where a mutant is killed only by a test that exposes a violation of a system requirement, BERTiMuS is claimed to outperform FIM: tests selected using FIM mutants fail to kill 128 BERTiMuS mutants, while tests selected using BERTiMuS mutants fail to kill only 61 FIM mutants. If correct, this indicates that a general-purpose language model, without hand-coded fault patterns, can generate mutants that are more representative of requirements-relevant faults and harder to detect.

What carries the argument

The load-bearing mechanism is the mask-and-predict pipeline. BERTiMuS converts a Simulink model's XML serialization into a simplified JSON text, masks a block property token, and asks CodeBERT to predict the masked token; the top k predictions that differ from the original value and produce compilable models become mutants. CodeBERT is fine-tuned on a corpus of 2,611 third-party Simulink models so that its predictions respect Simulink structure and naming conventions. This context-aware prediction is what lets BERTiMuS generate mutants like swapping a GotoTag label between safety-level signals or renaming a Stateflow variable to another variable of the same type already in the model.

What would settle it

A replication study on a broader set of Simulink models with independently validated requirement specifications and reference test suites constructed by a different method (for example, search-based generation) could falsify the claim: if, under requirements-aware mutation testing, the number of FIM mutants left unkilled by BERTiMuS-selected tests equals or exceeds the number of BERTiMuS mutants left unkilled by FIM-selected tests, the claimed outperformance would not hold up.

Watch

Extended reading notes

Core claim

The central claim is that a mask-and-predict strategy with CodeBERT is a viable and, under one important criterion, superior way to generate mutants for graphical Simulink models. BERTiMuS first serializes the model into a JSON representation, masks each block property, and lets a fine-tuned CodeBERT propose alternatives; the top k compilable predictions become mutants. The paper shows these mutants instantiate all ten block-based mutation pattern families reported in the Simulink testing literature. When compared with FIM on five industrial-benchmark models, BERTiMuS selects a smaller but partially non-overlapping set of test cases, and under requirements-aware mutation killing the asymmetry in Table III is the paper's headline result: the test cases selected via FIM mutants fail to kill 128 BERTiMuS mutants, whereas the test cases selected via BERTiMuS mutants fail to kill only 61 FIM mutants. The authors interpret this as evidence that BERTiMuS mutants represent requirements-relevant faults that are harder to detect than FIM mutants under the same test-selection procedure.

Load-bearing premise

The comparison rests on the assumption that the five reference test suites (built by adaptive random testing) and the listed requirement sets for the five models give a fair, equally demanding yardstick for both BERTiMuS and FIM; if the requirements are incomplete or the test suites are biased, the 128-versus-61 asymmetry may be an artifact of the benchmark rather than of the approach.

Editorial extensions

If this is right

  • BERTiMuS generates mutants that cover all ten block-based Simulink mutation pattern families catalogued in the literature, so it could substitute for hand-coded pattern libraries at the block level.
  • BERTiMuS and FIM select different test cases and kill different mutants, making the two approaches complementary rather than one subsuming the other.
  • Under classical mutation testing, FIM produces more and harder-to-kill mutants; under requirements-aware mutation testing, the asymmetry reverses, with BERTiMuS mutants being twice as hard to kill by FIM-selected tests.
  • Requirements-aware mutation testing is a stricter and more meaningful criterion than classical output-based killing, and it changes the rank order of the two tools.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper: if the requirements-aware advantage generalizes beyond the five studied models, LLM-based mutant generation could serve as a low-cost requirements oracle amplifier, suggesting which model behaviors deserve requirement-level scrutiny without an explicit fault model.
  • Beyond the paper: the approach's quality is likely bounded by the diversity of the fine-tuning corpus of Simulink models; a larger or more domain-specific corpus might produce even more requirement-relevant mutants, a testable prediction.
  • Beyond the paper: the mask-and-predict mechanism might transfer to other graphical modeling notations with XML serializations, although the paper does not evaluate that extension.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 6 minor

Summary. The paper proposes BERTiMuS, a mutation testing approach for Simulink models that converts models into JSON textual representations, masks block-property tokens, and replaces them with the top-k predictions of a CodeBERT model fine-tuned on Simulink models from SLNET. The approach is evaluated on five industrial models from two benchmarks, comparing with the FIM tool. The paper reports that BERTiMuS covers all documented block-based Simulink mutation patterns, that BERTiMuS and FIM are complementary in terms of selected test cases, and that under a requirements-aware notion of mutation testing, BERTiMuS outperforms FIM (Table III).

Significance. The paper addresses an interesting and timely problem: applying masked-language-model-based mutation generation to Simulink models. Its strengths include the use of an external baseline tool (FIM) for comparison, a fine-tuning corpus (SLNET) that is independent of the subject models, a replication package, and a clear statement of novel claims (complementarity and requirements-aware superiority). If the central claims hold after addressing the measurement issues, the work would be a useful contribution to mutation testing for model-based development.

major comments (5)
  1. [Section IV, Table III and Finding 3] In Table III, the row 'Average # of killed mutants that could not be killed by the test cases selected by the other approach' reports 128 for BERTiMuS and 61 for FIM under requirements-aware mutation testing. These raw counts are used in Finding 3 and the abstract to claim that 'test cases selected using FIM mutants failed to kill twice as many BERTiMuS mutants as the number of FIM mutants not killed by test cases selected using BERTiMuS mutants.' However, the denominators differ: BERTiMuS has 311 killable mutants and FIM has 402. The paper should report these counts as proportions (e.g., 128/311 ≈ 41% vs 61/402 ≈ 15%) and discuss whether the absolute-count framing is appropriate. As written, the claim conflates the size of the mutant sets with the difficulty of killing them.
  2. [Section IV, RQ2 experiments] The paper defines requirements-aware mutation testing as killing a mutant when it violates a requirement satisfied by the original model, citing Bartocci et al. [4]. However, it never states how the requirements for the five models (Table I) are represented or checked. No property language, assertion mechanism, or monitor tool is described. This is a load-bearing omission because Finding 3 depends entirely on a reliable oracle for requirement violations. Without this specification, the results are not reproducible, and the sparse requirement counts for ATCS (1) and AECS (2) raise the possibility that the comparison is an artifact of the particular requirement sets rather than of mutant quality.
  3. [Section IV, RQ2 experiments] The sentence 'For both FIM and BERTiMuS, we select a minimal subset T ⊆ TS of test cases that can kill as many mutants generated by each approach as possible' is the entire description of the test-set selection procedure. The paper does not specify how minimality is achieved (e.g., greedy, optimal, or heuristic), how ties are broken, or what randomness is involved in the five repetitions. This makes the complementarity findings (Figure 3) impossible to reproduce and weakens the comparison between the selected test cases of the two approaches.
  4. [Section IV, RQ2 experiments] The reference test suites are generated by 'adaptive random testing, as used in earlier studies,' but no details are given about the size of the suites, the input value ranges, or the stopping criteria. The adequacy of these suites directly determines which mutants are considered 'killable' (Table III reports only 311/387 BERTiMuS and 402/594 FIM mutants as killable). The paper should provide the suite sizes and a justification that the suites are sufficiently powerful to expose requirements violations, particularly for the models with very few requirements.
  5. [Table III and Table I] Table III reports only aggregate averages across the five models, without per-model breakdown. Given the heterogeneity of the models (57 to 825 blocks; 1 to 32 requirements; and two models from the baseline's own benchmark), the authors should show per-model results to demonstrate that Finding 3 is not driven by a single model or by the models with extremely sparse requirement sets.
minor comments (6)
  1. [Section II, Figure 2] There appears to be a duplicate/overlapping figure: the text under 'Figure 2' contains two sets of (a)-(d) subfigures, with a caption appearing in the middle of the description. This should be cleaned up so that the figure and caption show a single coherent illustration.
  2. [Section IV, RQ1] The analysis claiming that all BERTiMuS mutants can be generated using the patterns in Table II is not described. The paper should specify the classification procedure and provide a mapping of mutants to patterns to substantiate the coverage claim.
  3. [Section IV, RQ1] The statement that BERTiMuS generates 'mutant instances that are unlikely to be generated based on syntactic and manual mutation rules' seems to conflict with the earlier claim that all mutants can be generated using the 10 patterns in Table II; this tension should be clarified.
  4. [Section III and IV] The hyperparameter choices (top_k=3, fine-tuning for 15 epochs, masking 15%) are given without sensitivity analysis; the paper should at least acknowledge the influence of these choices on the reported results.
  5. [Section IV, Table III] The table reports averages as integers because 'there were almost no differences across the five runs'; the paper should provide the actual spread (e.g., min/max or standard deviation) to support this statement.
  6. [General] The paper lacks a threats-to-validity section, which would be important given the small number of subjects and the manual analysis in RQ1.

Circularity Check

0 steps flagged · score 1.0 of 10

No circular derivation: BERTiMuS mutants come from an independently fine-tuned CodeBERT and are benchmarked against an external tool; the requirements-aware gap is a validity concern, not a circular reduction.

full rationale

The paper's derivation chain is self-contained. BERTiMuS converts Simulink models to JSON text, masks block-property tokens, and replaces them with top-k predictions from CodeBERT that was fine-tuned on 2,611 third-party SLNET models (Section III), not on the subject models or on the requirements-aware outcome. No parameter is fitted to the target models; the fine-tuning corpus is external to the five benchmarks. The comparison baseline FIM is an independently developed tool [3], and the requirements-aware killing notion is taken from Bartocci et al. [4], not from the present authors. The RQ1 claim that BERTiMuS mutants fall within the documented block-based patterns is an empirical classification, and the paper explicitly concedes that BERTiMuS produces no pattern outside Table II, so there is no renaming of a known result. The central Finding 3 (128 BERTiMuS mutants not killed by FIM-selected tests vs 61 FIM mutants not killed by BERTiMuS-selected tests) is a statistical comparison that could be sensitive to the adequacy of the reference test suites and the completeness of the requirement sets (e.g., ATCS has 1 requirement, AECS has 2), but such benchmark-validity threats are not circularity under the definitions used here. The self-citations (e.g., [21], [24], [22] for adaptive random testing) are methodological support, not load-bearing premises that reduce the result to its own inputs. No equation or construction in the paper forces the claimed outperformance by definition.

Assumptions & free parameters 3 free parameters · 5 assumptions · 1 invented entities

The central claim rests on a small set of hyperparameters and several domain assumptions about textual representation, model corpus representativeness, and requirement adequacy. There are no fitted parameters in a derivation sense, because the work is an empirical tool evaluation rather than a quantitative theory. The invented-entities ledger is empty in the scientific sense; only the software tool itself is introduced.

free parameters (3)
  • top_k_predictions = 3
    The number of CodeBERT predictions used to form mutants is a hand-chosen threshold; no sensitivity analysis is reported, and the mutant set size and quality likely depend on it.
  • fine_tuning_epochs = 15
    The CodeBERT fine-tuning duration is a hand-chosen hyperparameter; the paper does not explore how epoch count affects mutant quality.
  • masking_probability_during_fine_tuning = 15%
    The fraction of masked tokens during fine-tuning follows common MLM practice but is still a configuration choice that affects the model's ability to predict block property values.
assumptions (5)
  • domain assumption CodeBERT, after fine-tuning, can predict plausible and compilable Simulink block property values from surrounding textual context.
    Invoked in Steps 2 and 3 of Section II; the whole approach depends on this capability.
  • domain assumption The simplified JSON textual representation preserves enough semantic information for meaningful mutant generation.
    Step 1 of Section II creates a reduced representation; if semantic content is lost, the generated mutants may not reflect real model changes.
  • domain assumption The SLNET corpus of 2,611 third-party Simulink models is representative enough to fine-tune CodeBERT for industrial Simulink models.
    Stated in Section III; the fine-tuning corpus must align with the subject models' style for predictions to be relevant.
  • domain assumption The assigned requirements for the five subject models are correct and complete enough to determine requirements-aware mutant killing.
    Section IV uses the requirement counts from Table I and property-based killing; inaccurate or incomplete requirements would invalidate the requirements-aware comparison.
  • domain assumption Adaptive random testing generates reference test suites that are adequate for comparing mutant-killing ability across tools.
    Section IV states the reference suites were generated using adaptive random testing; the paper does not assess suite adequacy or sensitivity to this choice.
invented entities (1)
  • BERTiMuS (the tool)
    purpose: A software pipeline for Simulink mutant generation using CodeBERT; it is a proposed tool, not a physical or theoretical entity.
    No new particle, force, dimension, or conserved quantity is postulated. BERTiMuS is evaluated only through the paper's own experiments and replication package.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Simulink Mutation Testing using CodeBERT." pith.science (2026). https://pith.science/paper/O2IHJSB2

@misc{pith2026250107553,
  author       = {Pith},
  title        = {Pith review of: Simulink Mutation Testing using CodeBERT},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/O2IHJSB2}},
  note         = {Machine review of arXiv:2501.07553}
}
read the original abstract

We present BERTiMuS, an approach that uses CodeBERT to generate mutants for Simulink models. BERTiMuS converts Simulink models into textual representations, masks tokens from the derived text, and uses CodeBERT to predict the masked tokens. Simulink mutants are obtained by replacing the masked tokens with predictions from CodeBERT. We evaluate BERTiMuS using Simulink models from an industrial benchmark, and compare it with FIM -- a state-of-the-art mutation tool for Simulink. We show that, relying exclusively on CodeBERT, BERTiMuS can generate the block-based Simulink mutation patterns documented in the literature. Further, our results indicate that: (a) BERTiMuS is complementary to FIM, and (b) when one considers a requirements-aware notion of mutation testing, BERTiMuS outperforms FIM.

Figures

Figures reproduced from arXiv: 2501.07553 by the authors.

Figure 1
Figure 1. Overview of BERTiMuS (a) Example Simulink model: (b) Textual representat ion of the Relat ion block highlighted in (a) . . . ,{ "BlockType" : "GotoTag" , "Name" : " Input5" , "Property " :{ "GotoTag" : "SL_ Input " }}, . . . ,{ "BlockType" : "GotoTag" , "Name" : " Input7" , "Property " :{ "GotoTag" : "SH_ Input " }}. . . (c) Masking a block proper ty value of the Relat ional block . . . ,{ "BlockType" : "GotoTag" , … view at source ↗
Figure 2
Figure 2. Illustration of token masking by BERTiMuS [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Comparing BERTiMuS and FIM based on the average [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

29 extracted references · 25 canonical work pages

  1. [4]

    Property-based mutation testing

    Ezio Bartocci, Leonardo Mariani, Dejan Ni ˇckovi´c, and Drishti Yadav. Property-based mutation testing. In 2023 IEEE Conference on Software Testing, Verification and Validation (ICST), pages 222–233. IEEE, 2023

    work page 2023

  2. [1]

    https://bit.ly/BERTiMuS-Anonym, 2024

    Github repo for the paper. https://bit.ly/BERTiMuS-Anonym, 2024

    work page 2024

  3. [2]

    Gpt-4 technical report

    Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. Gpt-4 technical report. arXiv preprint arXiv:2303.08774, 2023

    arXiv 2023

  4. [3]

    Fim: fault injection and mutation for simulink

    Ezio Bartocci, Leonardo Mariani, Dejan Ni ˇckovi´c, and Drishti Yadav. Fim: fault injection and mutation for simulink. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering , pages 1716– 1720, 2022

    work page 2022

  5. [5]

    Mutation operators for simulink models

    Nguyen Thanh Binh et al. Mutation operators for simulink models. In 2012 Fourth International Conference on Knowledge and Systems Engineering, pages 54–59. IEEE, 2012

    work page 2012

  6. [6]

    Enhancing genetic improvement mutations using large lan- guage models

    Alexander EI Brownlee, James Callan, Karine Even-Mendoza, Alina Geiger, Carol Hanna, Justyna Petke, Federica Sarro, and Dominik Sobania. Enhancing genetic improvement mutations using large lan- guage models. In International Symposium on Search Based Software Engineering, pages 153–159. Springer, 2023

    work page 2023

  7. [7]

    Effective test generation using pre- trained large language models and mutation testing

    Arghavan Moradi Dakhel, Amin Nikanjam, Vahid Majdinasab, Foutse Khomh, and Michel C Desmarais. Effective test generation using pre- trained large language models and mutation testing. Information and Software Technology, page 107468, 2024

    work page 2024

  8. [8]

    µbert: Mutation testing using pre-trained language models

    Renzo Degiovanni and Mike Papadakis. µbert: Mutation testing using pre-trained language models. In 2022 IEEE International Conference on Software Testing, Verification and Validation Workshops (ICSTW), pages 160–169. IEEE, 2022

    work page 2022

Show all 29 references
  1. [9]

    Bert: Pre-training of deep bidirectional transformers for language un- derstanding

    Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. Bert: Pre-training of deep bidirectional transformers for language un- derstanding. arXiv preprint arXiv:1810.04805 , 2018

    2018 arXiv

  2. [10]

    Codebert: A pre-trained model for programming and natural languages

    Zhangyin Feng, Daya Guo, Duyu Tang, Nan Duan, Xiaocheng Feng, Ming Gong, Linjun Shou, Bing Qin, Ting Liu, Daxin Jiang, et al. Codebert: A pre-trained model for programming and natural languages. arXiv preprint arXiv:2002.08155 , 2020

    2002 arXiv

  3. [11]

    Whalen, and Mats Per Erik Heimdahl

    Gregory Gay, Ajitha Rajan, Matt Staats, Michael W. Whalen, and Mats Per Erik Heimdahl. The effect of program and model structure on the effectiveness of MC/DC test adequacy coverage. ACM Trans. Softw. Eng. Methodol., 25(3):25:1–25:34, 2016

    2016

  4. [12]

    On the applicability of language models to block-based programs

    Elisabeth Griebl, Benedikt Fein, Florian Oberm ¨uller, Gordon Fraser, and Ren´e Just. On the applicability of language models to block-based programs. In 45th IEEE/ACM International Conference on Software Engineering, ICSE 2023, Melbourne, Australia, May 14-20, 2023 , pages 23...

    2023

  5. [13]

    Test-case generation for embedded simulink via formal concept analysis

    Nannan He, Philipp R ¨ummer, and Daniel Kroening. Test-case generation for embedded simulink via formal concept analysis. In Proceedings of the 48th Design Automation Conference , pages 224–229, 2011

    2011

  6. [14]

    An analysis and survey of the development of mutation testing

    Yue Jia and Mark Harman. An analysis and survey of the development of mutation testing. IEEE transactions on software engineering, 37(5):649– 678, 2010

    2010

  7. [15]

    Defects4j: A database of existing faults to enable controlled testing studies for java programs

    Ren ´e Just, Darioush Jalali, and Michael D Ernst. Defects4j: A database of existing faults to enable controlled testing studies for java programs. In Proceedings of the 2014 international symposium on software testing and analysis, pages 437–440, 2014

    2014

  8. [16]

    Efficient mutation testing via pre-trained language models

    Ahmed Khanfir, Renzo Degiovanni, Mike Papadakis, and Yves Le Traon. Efficient mutation testing via pre-trained language models. arXiv preprint arXiv:2301.03543, 2023

    2023 arXiv

  9. [17]

    Mutation- based test data generation for simulink models using genetic algorithm and simulated annealing

    Khuat Thanh Le Thi My Hanh and Nguyen Thanh Binh Tung. Mutation- based test data generation for simulink models using genetic algorithm and simulated annealing. International Journal of Computer and Information Technology, 3(04):763–771, 2014

    2014

  10. [18]

    Briand, and Thomas Bruck- mann

    Bing Liu, Lucia, Shiva Nejati, Lionel C. Briand, and Thomas Bruck- mann. Localizing multiple faults in simulink models. In IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering, SANER 2016, Suita, Osaka, Japan, March 14-18, 2016 - Volume 1, page...

    2016

  11. [19]

    Bing Liu, Shiva Nejati, Lucia, and Lionel C. Briand. Effective fault localization of automotive simulink models: achieving the trade-off between test oracle effort and fault localization accuracy. Empir. Softw. Eng., 24(1):444–490, 2019

    2019

  12. [20]

    Requirements- driven slicing of simulink models using llms

    Dipeeka Luitel, Shiva Nejati, and Mehrdad Sabetzadeh. Requirements- driven slicing of simulink models using llms. In 32nd IEEE International Requirements Engineering Conference, RE 2024 - Workshops, Reykjavik, Iceland, June 24-25, 2024 , pages 72–82. IEEE, 2024

    2024

  13. [21]

    Test generation and test prioritization for simulink models with dynamic behavior

    Reza Matinnejad, Shiva Nejati, Lionel C Briand, and Thomas Bruck- mann. Test generation and test prioritization for simulink models with dynamic behavior. IEEE Transactions on Software Engineering , 45(9):919–944, 2018

    2018

  14. [22]

    Briand, Thomas Bruckmann, and Claude Poull

    Reza Matinnejad, Shiva Nejati, Lionel C. Briand, Thomas Bruckmann, and Claude Poull. Automated model-in-the-loop testing of continuous controllers using search. In G ¨unther Ruhe and Yuanyuan Zhang, editors, Search Based Software Engineering - 5th International Symposium, SSBS...

    2013

  15. [23]

    Mavridou, H

    A. Mavridou, H. Bourbouh, D. Giannakopoulou, T. Pressburger, M. He- jase, P. L. Garoche, and J. Schumann. The Ten Lockheed Martin Cyber-Physical Challenges: Formalized, Analyzed, and Explained. In International Requirements Engineering Conference (RE) , pages 300–

  16. [24]

    Briand, Stephen Foster, and David Wolfe

    Shiva Nejati, Khouloud Gaaloul, Claudio Menghi, Lionel C. Briand, Stephen Foster, and David Wolfe. Evaluating model testing and model checking for finding requirements violations in simulink models. In Marlon Dumas, Dietmar Pfahl, Sven Apel, and Alessandra Russo, editors, Proc...

    2019

  17. [25]

    Mutation testing advances: an analysis and survey

    Mike Papadakis, Marinos Kintis, Jie Zhang, Yue Jia, Yves Le Traon, and Mark Harman. Mutation testing advances: an analysis and survey. In Advances in Computers, volume 112, pages 275–378. Elsevier, 2019

    2019

  18. [26]

    SIMULTATE: A toolset for fault injection and mutation testing of simulink models

    Ingo Pill, Ivan Rubil, Franz Wotawa, and Mihai Nica. SIMULTATE: A toolset for fault injection and mutation testing of simulink models. In Ninth IEEE International Conference on Software Testing, Verification and Validation Workshops, ICST Workshops 2016, Chicago, IL, USA, Apri...

    2016

  19. [27]

    Requirements coverage as an adequacy measure for conformance testing

    Ajitha Rajan, Michael Whalen, Matt Staats, and Mats PE Heimdahl. Requirements coverage as an adequacy measure for conformance testing. In International Conference on Formal Engineering Methods, pages 86–

  20. [28]

    SLNET: A redistributable corpus of 3rd-party simulink models

    Sohil Lal Shrestha, Shafiul Azam Chowdhury, and Christoph Csallner. SLNET: A redistributable corpus of 3rd-party simulink models. In 19th IEEE/ACM International Conference on Mining Software Repositories, MSR 2022, Pittsburgh, PA, USA, May 23-24, 2022 , pages 1–5. ACM, 2022

    2022

  21. [29]

    Simulink, 2023

    The MathWorks Inc. Simulink, 2023. Version R2021b

    2023

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.