Pith. sign in

REVIEW 3 major objections 5 minor 71 references

KQFuzz: Knowledge-Guided Fuzzing for Quantum Libraries via Large Language Models

T0 review · 3 major / 5 minor · reviewed 2026-08-01 · deepseek-v4-flash

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

Pith's one-line read By extracting an API knowledge corpus from the library source, KQFuzz grounds LLM-generated tests and reports 13 confirmed bugs in three quantum libraries.

desk verdict Solid engineering with real confirmed bugs, but the coverage/crash superiority claim rests on single-run data and needs repetition before it holds. read the letter →

arxiv 2607.25647 v1 pith:4GFYFK6U submitted 2026-07-28 cs.SE cs.AIcs.MAquant-ph

Fuyuan Xia , Qixin Zhang , Chenhao Ying , Haojin Zhu , Shuai Wang , Yuan Luo , Pingchuan Ma , Yuxuan Du This is my paper · ORCID
classification cs.SEcs.AIcs.MAquant-ph
keywords quantumlibraryfuzzinglargelanguagemodelsAPIknowledgecorpuscodecoveragebugdetectionQiskitPennyLaneCirq
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

This paper claims that the biggest obstacle to LLM-based fuzzing of quantum libraries is the model's outdated or hallucinated knowledge of fast-changing APIs, and that this can be fixed by grounding generation in an explicit knowledge corpus distilled from the library's own source code. The proposed fuzzer, KQFuzz, builds this corpus with static API metadata, pairwise associations (proximity, type overlap, calls), LLM-written semantic summaries, and per-version evolution metrics, then uses it to guide a cheaper LLM to write valid seed programs. Those seeds are prioritized by a fitness function (gate diversity, entanglement, API diversity, call depth) and mutated at parameter and gate level. On Qiskit, PennyLane, and Cirq, the paper reports validity and line-coverage gains over existing baselines, up to 18.44 percentage points of coverage, and 13 discovered bugs, all confirmed and 12 fixed. A sympathetic reader would care because automated testing of quantum software currently either stays at circuit level or produces mostly invalid LLM code; if true, this gives a practical route to keeping up with volatile quantum APIs.

What carries the argument

The API corpus is the load-bearing object: a structured knowledge base built from the target library's source code, with four parts — static metadata (signature, location), association scores over three dimensions (proximity, type overlap, call relationships), LLM-generated semantic models (input constraints, output description, fuzzing test points), and evolution weights derived from n-gram differences between successive versions. This corpus drives a probabilistic API-selection rule that biases seed generation toward semantically related, actively changing APIs, and it is what distinguishes the approach from generic retrieval-augmented generation, which retrieves text chunks by semantic si

What would settle it

Repeat the head-to-head comparison between KQFuzz and the strongest baseline on the same pinned library versions (e.g., Qiskit 2.3.0) three to five times each with a fresh 24-hour budget, and check whether KQFuzz's coverage edge (reported as exactly 18.44 percentage points on Qiskit) reproduces in every run and by a margin larger than typical run-to-run variance, and whether the 13 reported bugs can be re-triggered by the published test cases.

Watch

Extended reading notes

Core claim

The central claim is that a large language model can fuzz quantum libraries effectively if its generation is anchored to the exact library version it is testing. KQFuzz first reads the library source to assemble an API corpus: signatures and locations, association scores between APIs, semantic summaries written by a strong LLM, and evolution metrics that flag frequently changed APIs. During fuzzing, a smaller LLM extends seed programs by adding APIs that are sampled with probability proportional to association strength and evolution weight, so the induced tests are version-aligned and target bug-prone paths. The generated programs are then filtered by a fitness function and mutated with quan

Load-bearing premise

The quantitative superiority claim rests on a single 24-hour fuzzing run per configuration; because the paper itself acknowledges LLM nondeterminism, the reported coverage margin and crash counts could vary across runs, though the 13 confirmed bug reports would remain valid regardless.

Editorial extensions

If this is right

  • With the API corpus extracted once per library release, fuzzers can remain valid despite rapid API restructuring, since the knowledge is regenerated from current source rather than the LLM's training data.
  • Because the corpus captures associations and evolution, the fuzzer naturally targets high-risk APIs (recently changed, semantically coupled) rather than sampling uniformly.
  • The two-level mutation adds crash-triggering exploration on top of generation: the ablation reports mutation contributes little extra coverage but finds dozens of additional unique crashes.
  • The reported 13 confirmed bugs (categorized as boundary violations, state divergences, and semantic violations across the three libraries) demonstrate that the approach can catch both low-level edge cases and high-level orchestration logic.
  • The framework is model-agnostic: it outperforms existing baselines under multiple LLM backends and scales, and the advantage grows with model size.

Reading between the lines

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

  • Editorial: The paper's approach suggests a general recipe for fuzzing any library with high API churn — treat the library source itself as the ground truth, use a strong model only for one-time semantic summarization, and a cheap model for iterative generation.
  • Editorial: The same knowledge-grounding idea could be tested on classical libraries with similarly fast-evolving interfaces (e.g., deep-learning frameworks) to see whether the validity gap closes there too; the paper's own pilot study shows a smaller but analogous gap for stable classical libraries.
  • Editorial: Because the crash oracle relies on heuristic exception filtering, it may silently miss bugs that share error signatures with benign failures; a complementary oracle based on output-distribution comparison or metamorphic relations could increase recall, a directly testable 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

3 major / 5 minor

Summary. KQFuzz is a knowledge-guided fuzzing framework for quantum Python libraries (Qiskit, PennyLane, Cirq). It extracts an API corpus from the target library's source code — static metadata, association scores across proximity/type/call dimensions, LLM-generated semantic models, and version-evolution metrics — and uses this corpus to prompt an LLM to iteratively extend seed programs. Generated seeds are scored by a fitness function (gate diversity, entangled qubits, API diversity, call depth) and mutated with parameter-level and gate-level operators. The paper evaluates KQFuzz against MorphQ, FuzzQ, and Fuzz4All on three libraries, reporting higher line coverage (up to 18.44 percentage-point improvement over Fuzz4All on Cirq), more unique crashes, and 13 developer-confirmed bugs. Ablations attribute most of the gain to the codebase-knowledge component, and the framework is shown to outperform Fuzz4All across multiple LLM families and scales.

Significance. If the quantitative margins are reproducible, KQFuzz makes a solid contribution to LLM-based software testing for quantum libraries. The core idea — grounding generation in a structured API corpus mined from the target library itself — is pragmatic, cheap, and directly addresses the low validity of LLM-generated quantum code. The paper also ships a public artifact and reports 13 externally confirmed bugs, including several with clear root-cause discussions; this is real external evidence of utility. The ablation study is informative, and the per-sample token/time accounting in the supplementary material is a useful addition. The main weakness is that the headline superiority claims rest on a single 24-hour run per configuration, which is insufficient given the acknowledged nondeterminism of LLM-based fuzzing. The bug-finding result is more robust than the coverage/crash margins, but the latter are central to the paper's stated contribution.

major comments (3)
  1. [§6.1, Table 2; §7] The central quantitative claim — 'significantly outperforms' and '2.1× more unique crashes' — is supported only by a single continuous 24-hour run for each fuzzer on each library. No repeated runs, random-seed variation, confidence intervals, or statistical tests are reported. §7 explicitly acknowledges LLM nondeterminism and claims it is mitigated by the 24-hour budget, but one long run is still a single sample from a stochastic generation process, not an average over samples. This matters for both coverage (Table 2) and crash counts (685/1027/706), which can be highly sensitive to the particular seed programs sampled. The ablation in Table 3 uses fixed 6,000-seed budgets and is internally consistent, but it does not quantify variance either. Please add repeated runs (e.g., at least 3–5 per configuration) and report medians with IQR or confidence intervals, or provide direct variance ev
  2. [§6.3, Table 5, Abstract, §6.3 'Answer to RQ3'] The reported number of fixed bugs is internally inconsistent. The Abstract and the 'Answer to RQ3' state that 13 bugs were confirmed and 12 are fixed; the body of §6.3 states '13 bugs, with 13 confirmed and 10 already fixed'; Table 5 lists 13 bugs, of which 12 are marked Fixed and 1 Confirmed. The table agrees with the Abstract (12 fixed), so the '10 already fixed' sentence in §6.3 is an error, but this is a headline result and the inconsistency must be resolved before publication.
  3. [§6.1, Table 2 vs. §6.3, Table 5] The paper uses 'unique crashes' as a primary effectiveness metric, but it does not establish a relationship between these crashes and genuine bugs. KQFuzz reports 685, 1027, and 706 unique crashes, yet only 13 bugs were confirmed across all libraries. Because the baselines' crashes are not triaged with the same heuristic/manual process, it is possible that a large fraction of KQFuzz's crash advantage is due to different false-positive rates, exception types, or deduplication behavior rather than to more real defects. Please report crash precision (e.g., the number/ratio of crashes that were manually confirmed as bugs) for KQFuzz and, ideally, for a sample of baseline crashes, or explicitly state that 'unique crashes' is only a proxy for exploration and not for bug-finding effectiveness.
minor comments (5)
  1. [Abstract and §6.1] The phrase 'coverage improved by up to 18.44%' should state whether this is an absolute percentage-point improvement or a relative improvement. From Table 2, 73.79% vs. 55.35% is an 18.44 percentage-point absolute gain; please use this wording for precision.
  2. [Table 4] The column 'Total Coverage (Unique)' is ambiguous. It is unclear whether this is cumulative unique lines over the 6,000-seed budget, total line coverage, or something else. Please clarify the metric and label it consistently with Table 2.
  3. [SM B] In the call-association score S_c(a,b), the term 1/(2D(a,b)) is used, while D(a,b)=+∞ is allowed. Please explicitly define 1/∞=0 so the formula is well-defined.
  4. [§4.2, Figure 9] The two prompt variants (coverage-oriented and call-oriented) are central to the generation strategy, but they are only described in the supplementary material. A one-sentence description in the main text, with an explicit pointer to SM C, would make the method easier to follow.
  5. [Figure 6] The heatmap labels such as '0% 2.2% 0.1% 0.1%' are difficult to read. Consider reporting the values in a table or annotating the figure more clearly, since the pairwise unique-coverage numbers are important evidence of complementarity.

Circularity Check

0 steps flagged · score 1.0 of 10

No load-bearing circularity; API corpus mining is standard fuzzing input and confirmed bug reports are external evidence.

full rationale

KQFuzz's claimed derivation is an empirical evaluation rather than a mathematical reduction. The API corpus (Sec. 4.1) is constructed from the target library's source code and documentation and then used to prompt the fuzzing LLM; this is standard knowledge/coverage-guided fuzzing, not a fitted parameter being renamed as a prediction. The reported validity and line coverage (Sec. 6.1, Table 2) come from executing generated and mutated programs against pinned library versions; they are not equal by construction to Eqn. (4)'s fitness score (gate diversity + capped entanglement + call depth + weighted API diversity). The fitness score is a heuristic selection signal, not the evaluation metric, so the loop is not self-fulfilling. The 13 bugs (Table 5) were confirmed/fixed by the library developers, providing external ground truth independent of the authors' corpus choices. The paper contains no load-bearing self-citation chain: the cited baselines Fuzz4All [56] and MorphQ [43] are external works with no author overlap, and no uniqueness theorem is imported from prior work by the same authors. Sec. 7's note about LLM nondeterminism raises a statistical-robustness concern (single 24-hour runs), but that is a threat to validity rather than circularity. Overall, the central claims reduce to controlled measurement plus independently confirmed bugs; no circular step is identifiable.

Assumptions & free parameters 7 free parameters · 6 assumptions · 0 invented entities

All hyperparameters are hand-set; the paper does not report sensitivity analyses, so results could shift with different choices. The claims also rely on several domain assumptions about coverage metrics, the crash oracle, API association signals, and representativeness of the selected libraries.

free parameters (7)
  • Association weights w1, w2, w3 = 2, 1, 2
    Hand-set weights in Eq. 1 for proximity, type overlap, and call relationships; no sensitivity analysis.
  • Proximity scores α, β, λ = 1.0, 0.6, 0
    Same-file, same-module, otherwise proximity scores (SM C Table 7).
  • Evolution hyperparameters γ, δ = 4, 0.3
    Shape the API instability priority mapping in Eq. 2.
  • Fitness cap τ and API diversity weight η = 6, 3
    Fitness function Eq. 4: entanglement cap and API-diversity weight.
  • Selection and batch sizes κ, programs/iteration = 10, 30
    Seed-pool top-k selection and per-iteration generation count.
  • Execution time budget = 20 s
    Per-test-case timeout to avoid hangs; affects coverage and crash counts.
  • Mutation constant set = ±1, 0, π
    Parameter-level mutation values chosen as corner cases (Sec. 4.4).
assumptions (6)
  • domain assumption Line coverage via coverage.py is a valid proxy for fuzzing effectiveness.
    Primary RQ1 metric; no correlation with actual defect-finding except crash counts (Sec. 6.1).
  • domain assumption Crash-based oracle plus heuristic filtering and manual inspection identifies genuine library bugs.
    Message filtering and deduplication could drop real bugs or keep false positives; authors acknowledge this in Sec. 7.
  • ad hoc to paper API association scores from file locality, type overlap, and call reachability capture semantically compatible API usage.
    Eq. 1 and SM B; no external validation that these signals improve generation validity.
  • ad hoc to paper AST n-gram evolution metric M'(i) identifies bug-prone unstable APIs.
    Eq. 2 in Sec. 4.1; novelty of this proxy is not independently validated.
  • ad hoc to paper Fitness function (gate diversity, entangled qubits, API diversity, call depth) prioritizes seeds that trigger bugs.
    Eq. 4 in Sec. 4.3; weights chosen by hand.
  • domain assumption The three selected libraries/versions are representative of quantum library bugs.
    Sec. 5 uses Qiskit 2.3.0, PennyLane 0.44.0, and Cirq 1.6.1; generalization to other platforms is asserted in Sec. 7.

how reviews work

0 comments
Cite this review

Pith. "Pith review of KQFuzz: Knowledge-Guided Fuzzing for Quantum Libraries via Large Language Models." pith.science (2026). https://pith.science/paper/4GFYFK6U

@misc{pith2026260725647,
  author       = {Pith},
  title        = {Pith review of: KQFuzz: Knowledge-Guided Fuzzing for Quantum Libraries via Large Language Models},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4GFYFK6U}},
  note         = {Machine review of arXiv:2607.25647}
}
read the original abstract

As quantum computing continually improves, ensuring the reliability and correctness of quantum libraries has become increasingly critical. To this end, many LLM-based fuzzing approaches towards quantum libraries have been proposed to uncover potential bugs. However, these methods still suffer from limitations such as insufficient flexibility and low efficiency, which hinder the progress of the quantum computing field. To address these challenges, we propose KQFuzz, a novel knowledge-guided fuzzer for quantum libraries. It leverages comprehensive codebase knowledge to ground LLM-based test generation, synergizing this with fitness-guided evaluation and two-level mutations to explore complex execution paths and trigger potential bugs. Firstly, KQFuzz introduces a novel prompting scheme tailored to quantum programs, which strategically incorporates knowledge of the codebase to efficiently generate high-quality quantum seed programs. Moreover, we develop evaluation and mutation strategies to handle the generated seed programs, facilitating efficient fuzzing execution while further enriching the diversity of the resulting test cases. We implement KQFuzz and conduct fuzzing on three popular quantum libraries, including Qiskit, PennyLane, and Cirq. Experimental results demonstrate that our approach significantly outperforms other state-of-the-art methods, with coverage improved by up to 18.44%. During the development of KQFuzz, we discovered 13 bugs, all of which have been confirmed and 12 have already been fixed by the developers.

Figures

Figures reproduced from arXiv: 2607.25647 by the authors.

Figure 1
Figure 1. Comparison of Fuzzing Scopes. (ASE ’26). ACM, New York, NY, USA, 17 pages. https://doi.org/10.1145/ nnnnnnn.nnnnnnn 1 Introduction Diverse quantum libraries have been developed by academic in￾stitutions and technology companies to accelerate the design and implementation of quantum algorithms, motivated by the promise that quantum computing offers capabilities beyond classical com￾putation across diverse domains [18… view at source ↗
Figure 2
Figure 2. Comparison between circuit-level fuzzer-generated code [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Empirical evaluation of the validity and error patterns [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: Code example of typical errors in quantum computing [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]
Figure 5
Figure 5. Figure 5: The workflow of KQFuzz for detecting bugs in quantum libraries. Constraints and inefficiencies in quantum exploration. The subsequent exploration phase remains challenging even with valid seeds. Effective exploration of the program space typically relies on an iterativ…
Figure 6
Figure 6. Figure 6: Pairwise unique coverage comparison. using coverage.py while excluding the libraries’ internal test files, and we regard a generated program as valid only if it executes without runtime exceptions in a properly configured environment and invokes the target API at least…
Figure 7
Figure 7. Figure 7: Line coverage comparison [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: Prompt structure used by KQFuzz for API implementation semantic modeling. You are a code analysis assistant. Analyze the source code of the function in quantum library [<TARGET_LIB>] and provide the result ONLY in the following JSON format: { "Input Constraints": ["con…
Figure 9
Figure 9. Figure 9: A structured view of the prompt template used for LLM [PITH_FULL_IMAGE:figures/full_fig_p015_9.png]
Figure 10
Figure 10. Figure 10: Line coverage comparison using CodeLlama. [PITH_FULL_IMAGE:figures/full_fig_p016_10.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

71 extracted references · 1 canonical work pages

  1. [1]

    Amira Abbas, Andris Ambainis, Brandon Augustino, Andreas Bärtschi, Harry Buhrman, Carleton Coffrin, Giorgio Cortiana, Vedran Dunjko, Daniel J Egger, Bruce G Elmegreen, et al. 2024. Challenges and opportunities in quantum opti- mization.Nature Reviews Physics6, 12 (2024), 718–735

    2024

  2. [2]

    Shaukat Ali, Tao Yue, and Rui Abreu. 2022. When software engineering meets quantum computing.Commun. ACM65, 4 (2022), 84–88

    2022

  3. [3]

    Anonymous Authors. 2026. Replication package for anonymous submission. https://doi.org/10.5281/zenodo.19230459

    work page doi:10.5281/zenodo.19230459 2026

  4. [4]

    Paolo Arcaini, Andriy Miranskyy, and Hausi Müller. 2025. Introduction to the Special Section on software engineering for hybrid quantum computing systems. , 112362 pages

    2025

  5. [5]

    Nicola Assolini, Alessandra Di Pierro, and Isabella Mastroeni. 2024. Static analysis of quantum programs. InInternational Static Analysis Symposium. Springer, 1–25

    2024

  6. [6]

    Ville Bergholm, Josh Izaac, Maria Schuld, Christian Gogolin, Shahnawaz Ahmed, Vishnu Ajith, M Sohaib Alam, Guillermo Alonso-Linaje, Bharath Akash- Narayanan, Ali Asadi, et al. 2018. Pennylane: Automatic differentiation of hybrid quantum-classical computations.arXiv preprint arXiv:1811.04968(2018)

    arXiv 2018

  7. [7]

    Marcel Böhme, Valentin JM Manès, and Sang Kil Cha. 2020. Boosting fuzzer efficiency: An information theoretic perspective. InProceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 678–689

    2020

  8. [8]

    Marcel Böhme, Van-Thuan Pham, Manh-Dung Nguyen, and Abhik Roychoudhury

Show all 71 references
  1. [9]

    Marco Cerezo, Andrew Arrasmith, Ryan Babbush, Simon C Benjamin, Suguru Endo, Keisuke Fujii, Jarrod R McClean, Kosuke Mitarai, Xiao Yuan, Lukasz Cincio, et al. 2021. Variational quantum algorithms.Nature Reviews Physics3, 9 (2021), 625–644

    2021

  2. [10]

    2025.Cirq

    Cirq Developers. 2025.Cirq. https://doi.org/10.5281/zenodo.4062499

    2025 doi

  3. [11]

    Yinlin Deng, Chunqiu Steven Xia, Haoran Peng, Chenyuan Yang, and Lingming Zhang. 2023. Large language models are zero-shot fuzzers: Fuzzing deep-learning libraries via large language models. InProceedings of the 32nd ACM SIGSOFT international symposium on software testing and ...

    2023

  4. [12]

    Yinlin Deng, Chunqiu Steven Xia, Chenyuan Yang, Shizhuo Dylan Zhang, Shu- jing Yang, and Lingming Zhang. 2024. Large language models are edge-case generators: Crafting unusual programs for fuzzing deep learning libraries. In Proceedings of the 46th IEEE/ACM international confe...

    2024

  5. [13]

    Ruiqi Dong, Fanke Tong, He Huang, Xiaogang Zhu, Xi Xiao, Shaohua Wang, Sheng Wen, and Yang Xiang. 2025. One Mutation Fits All: Exploring Universal Library Fuzzing based on Exogenous Mutation.IEEE Transactions on Dependable and Secure Computing(2025)

    2025

  6. [14]

    Wang Fang and Mingsheng Ying. 2024. Symbolic execution for quantum error correction programs.Proceedings of the ACM on Programming Languages8, PLDI (2024), 1040–1065

    2024

  7. [15]

    2020.{AFL++}: Combining incremental steps of fuzzing research

    Andrea Fioraldi, Dominik Maier, Heiko Eißfeldt, and Marc Heuse. 2020.{AFL++}: Combining incremental steps of fuzzing research. In14th USENIX workshop on offensive technologies (WOOT 20)

    2020

  8. [16]

    Austin G Fowler, Matteo Mariantoni, John M Martinis, and Andrew N Cleland

  9. [17]

    Sukhpal Singh Gill, Oktay Cetinkaya, Stefano Marrone, Daniel Claudino, David Haunschild, Leon Schlote, Huaming Wu, Carlo Ottaviani, Xiaoyuan Liu, Sree Pragna Machupalli, et al. 2025. Quantum computing: Vision and challenges. InQuantum computing. Elsevier, 19–42

    2025

  10. [18]

    Sukhpal Singh Gill, Adarsh Kumar, Harvinder Singh, Manmeet Singh, Kamalpreet Kaur, Muhammad Usman, and Rajkumar Buyya. 2022. Quantum computing: A taxonomy, systematic review and future directions.Software: Practice and Experience52, 1 (2022), 66–114

    2022

  11. [19]

    Xiaoyu Guo, Shinobu Saito, and Jianjun Zhao. 2025. M2QCode: A Model-Driven Framework for Generating Multi-Platform Quantum Programs.arXiv preprint arXiv:2510.17110(2025)

    2025

  12. [20]

    Xiaoyu Guo, Minggu Wang, and Jianjun Zhao. 2025. QuanBench: Benchmark- ing Quantum Code Generation with Large Language Models.arXiv preprint arXiv:2510.16779(2025)

    2025

  13. [21]

    Xiaoyu Guo, Jianjun Zhao, and Pengzhan Zhao. 2024. On repairing quantum pro- grams using ChatGPT. InProceedings of the 5th ACM/IEEE International Workshop on Quantum Software Engineering. 9–16

    2024

  14. [22]

    Tianmin Hu, Guixin Ye, Zhanyong Tang, Shin Hwei Tan, Huanting Wang, Meng Li, and Zheng Wang. 2024. Upbeat: Test input checks of q# quantum libraries. ASE ’26, October 12–16, 2026, Munich, Germany Xia et al. InProceedings of the 33rd ACM SIGSOFT International Symposium on Softw...

    2024

  15. [23]

    Binyuan Hui, Jian Yang, Zeyu Cui, Jiaxi Yang, Dayiheng Liu, Lei Zhang, Tianyu Liu, Jiajun Zhang, Bowen Yu, Keming Lu, et al. 2024. Qwen2. 5-coder technical report.arXiv preprint arXiv:2409.12186(2024)

    2024 arXiv

  16. [24]

    Ali Javadi-Abhari, Matthew Treinish, Kevin Krsulich, Christopher J Wood, Jake Lishman, Julien Gacon, Simon Martiel, Paul D Nation, Lev S Bishop, An- drew W Cross, et al . 2024. Quantum computing with Qiskit.arXiv preprint arXiv:2405.08810(2024)

    2024 arXiv

  17. [25]

    Yu Jiang, Jie Liang, Fuchen Ma, Yuanliang Chen, Chijin Zhou, Yuheng Shen, Zhiyong Wu, Jingzhou Fu, Mingzhe Wang, Shanshan Li, et al . 2024. When fuzzing meets llms: Challenges and opportunities. InCompanion Proceedings of the 32nd ACM International Conference on the Foundation...

    2024

  18. [26]

    Tiancheng Jin, Shangzhou Xia, and Jianjun Zhao. 2025. NovaQ: Improving Quantum Program Testing through Diversity-Guided Test Case Generation.arXiv preprint arXiv:2509.04763(2025)

    2025 arXiv

  19. [27]

    Hyungseok Kim, Soomin Kim, Jungwoo Lee, and Sang Kil Cha. 2024. AsFuzzer: Differential testing of assemblers with error-driven grammar inference. InPro- ceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 1099–1111

    2024

  20. [28]

    Vasileios Klimis, Avner Bensoussan, Elena Chachkarova, Karine Even-Mendoza, Sophie Fortz, and Connor Lenihan. 2025. Shaking Up Quantum Simulators with Fuzzing and Rigour.Proceedings of the ACM on Programming Languages9, OOPSLA2 (2025), 1400–1428

    2025

  21. [29]

    Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, et al. 2020. Retrieval-augmented generation for knowledge-intensive nlp tasks. Advances in neural information processing s...

    2020

  22. [30]

    Yuechen Li, Minqi Shao, Jianjun Zhao, and Qichen Wang. 2026. A Methodological Analysis of Empirical Studies in Quantum Software Testing.arXiv preprint arXiv:2601.08367(2026)

    2026 arXiv

  23. [31]

    Xingshuang Lin, Qinge Xie, Binbin Zhao, Yuan Tian, Saman Zonouz, Na Ruan, Jiliang Li, Raheem Beyah, and Shouling Ji. 2025. PROMFUZZ: Leveraging LLM- Driven and Bug-Oriented Composite Analysis for Detecting Functional Bugs in Smart Contracts.arXiv preprint arXiv:2503.23718(2025)

    2025

  24. [32]

    Peixun Long and Jianjun Zhao. 2024. Equivalence, identity, and unitarity checking in black-box testing of quantum programs.Journal of Systems and Software211 (2024), 112000

    2024

  25. [33]

    Peixun Long and Jianjun Zhao. 2024. Testing multi-subroutine quantum pro- grams: From unit testing to integration testing.ACM Transactions on Software Engineering and Methodology33, 6 (2024), 1–61

    2024

  26. [34]

    Junjie Luo, Shangzhou Xia, Fuyuan Zhang, and Jianjun Zhao. 2026. QEMI: A Quantum Software Stacks Testing Framework via Equivalence Modulo Inputs. InInternational Conference on Fundamental Approaches to Software Engineering. Springer, 149–169

    2026

  27. [35]

    Valentin JM Manès, HyungSeok Han, Choongwoo Han, Sang Kil Cha, Manuel Egele, Edward J Schwartz, and Maverick Woo. 2019. The art, science, and engi- neering of fuzzing: A survey.IEEE Transactions on Software Engineering47, 11 (2019), 2312–2331

    2019

  28. [36]

    Eñaut Mendiluze, Shaukat Ali, Paolo Arcaini, and Tao Yue. 2021. Muskit: A mutation analysis tool for quantum software testing. In2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 1266– 1270

    2021

  29. [37]

    Eñaut Mendiluze Usandizaga, Shaukat Ali, Tao Yue, and Paolo Arcaini. 2025. Quantum circuit mutants: Empirical analysis and recommendations.Empirical Software Engineering30, 4 (2025), 100

    2025

  30. [38]

    Asmar Muqeet, Shaukat Ali, Tao Yue, and Paolo Arcaini. 2024. A machine learning-based error mitigation approach for reliable software development on IBM’s quantum computers. InCompanion Proceedings of the 32nd ACM Interna- tional Conference on the Foundations of Software Engin...

    2024

  31. [39]

    Asmar Muqeet, Tao Yue, Shaukat Ali, and Paolo Arcaini. 2024. Mitigating noise in quantum software testing using machine learning.IEEE Transactions on Software Engineering50, 11 (2024), 2947–2961

    2024

  32. [40]

    Juan Manuel Murillo, Jose Garcia-Alonso, Enrique Moguel, Johanna Barzen, Frank Leymann, Shaukat Ali, Tao Yue, Paolo Arcaini, Ricardo Pérez-Castillo, Ignacio García-Rodríguez de Guzmán, et al. 2025. Quantum software engineering: Roadmap and challenges ahead.ACM Transactions on ...

    2025

  33. [41]

    Noah H Oldfield, Christoph Laaber, Tao Yue, and Shaukat Ali. 2025. Faster and better quantum software testing through specification reduction and projective measurements.ACM Transactions on Software Engineering and Methodology34, 7 (2025), 1–39

    2025

  34. [42]

    Matteo Paltenghi and Michael Pradel. 2022. Bugs in quantum computing plat- forms: an empirical study.Proceedings of the ACM on Programming Languages6, OOPSLA1 (2022), 1–27

    2022

  35. [43]

    Matteo Paltenghi and Michael Pradel. 2023. MorphQ: Metamorphic testing of the Qiskit quantum computing platform. In2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 2413–2424

    2023

  36. [44]

    Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiao- qing Ellen Tan, Yossi Adi, Jingyu Liu, Romain Sauvestre, Tal Remez, et al. 2023. Code llama: Open foundation models for code.arXiv preprint arXiv:2308.12950 (2023)

    2023 arXiv

  37. [45]

    Md Shafiuzzaman, Achintya Desai, Laboni Sarker, and Tevfik Bultan. 2024. STASE: Static analysis guided symbolic execution for UEFI vulnerability signature gener- ation. InProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering. 1783–1794

    2024

  38. [46]

    Dongdong She, Adam Storek, Yuchong Xie, Seoyoung Kweon, Prashast Srivas- tava, and Suman Jana. 2024. Fox: Coverage-guided fuzzing as online stochastic control. InProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security. 765–779

    2024

  39. [47]

    Nick Stephens, John Grosen, Christopher Salls, Andrew Dutcher, Ruoyu Wang, Jacopo Corbetta, Yan Shoshitaishvili, Christopher Kruegel, and Giovanni Vigna

  40. [48]

    Gemini Team, Rohan Anil, Sebastian Borgeaud, Jean-Baptiste Alayrac, Jiahui Yu, Radu Soricut, Johan Schalkwyk, Andrew M Dai, Anja Hauth, Katie Millican, et al. 2023. Gemini: a family of highly capable multimodal models.arXiv preprint arXiv:2312.11805(2023)

    2023 arXiv

  41. [49]

    Krishna Upadhyay, Moshood Fakorede, and Umar Farooq. 2026. Understanding Bugs in Quantum Simulators: An Empirical Study. arXiv:2603.22789 [quant-ph] https://arxiv.org/abs/2603.22789

    2026

  42. [50]

    Hanrui Wang, Daniel Bochen Tan, Pengyu Liu, Yilian Liu, Jiaqi Gu, Jason Cong, and Song Han. 2024. Q-pilot: Field programmable qubit array compilation with flying ancillas. InProceedings of the 61st ACM/IEEE Design Automation Conference. 1–6

    2024

  43. [51]

    Jiyuan Wang, Fucheng Ma, and Yu Jiang. 2021. Poster: Fuzz testing of quan- tum program. In2021 14th IEEE Conference on Software Testing, Verification and Validation (ICST). IEEE, 466–469

    2021

  44. [52]

    Jiyuan Wang, Qian Zhang, Guoqing Harry Xu, and Miryung Kim. 2021. QDiff: Dif- ferential testing of quantum software stacks. In2021 36th IEEE/ACM international conference on automated software engineering (ASE). IEEE, 692–704

    2021

  45. [53]

    Xinyi Wang, Shaukat Ali, Tao Yue, and Paolo Arcaini. 2024. Quantum approximate optimization algorithm for test case optimization.IEEE Transactions on Software Engineering50, 12 (2024), 3249–3264

    2024

  46. [54]

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al. 2022. Chain-of-thought prompting elicits reasoning in large language models.Advances in neural information processing systems35 (2022), 24824–24837

    2022

  47. [55]

    Mingyuan Wu, Ling Jiang, Jiahong Xiang, Yanwei Huang, Heming Cui, Lingming Zhang, and Yuqun Zhang. 2022. One fuzzing strategy to rule them all. InPro- ceedings of the 44th International Conference on Software Engineering. 1634–1645

    2022

  48. [56]

    Chunqiu Steven Xia, Matteo Paltenghi, Jia Le Tian, Michael Pradel, and Lingming Zhang. 2024. Fuzz4all: Universal fuzzing with large language models. InPro- ceedings of the IEEE/ACM 46th International Conference on Software Engineering. 1–13

    2024

  49. [57]

    Shangzhou Xia, Jianjun Zhao, Fuyuan Zhang, and Xiaoyu Guo. 2025. Quantum concolic testing.Proceedings of the ACM on Software Engineering2, ISSTA (2025), 1146–1166

    2025

  50. [58]

    Yuchong Xie, Wenhui Zhang, and Dongdong She. 2025. ZTaint-Havoc: From Havoc mode to zero-execution fuzzing-driven taint inference.Proceedings of the ACM on Software Engineering2, ISSTA (2025), 917–939

    2025

  51. [59]

    Yupeng Yang, Yongheng Chen, Rui Zhong, Jizhou Chen, and Wenke Lee. 2024. Towards generic database management system fuzzing. In33rd USENIX Security Symposium (USENIX Security 24). 901–918

    2024

  52. [60]

    Jiaming Ye, Xiongfei Wu, Shangzhou Xia, Fuyuan Zhang, and Jianjun Zhao. 2025. Is Measurement Enough? Rethinking Output Validation in Quantum Program Testing.arXiv preprint arXiv:2509.16595(2025)

    2025

  53. [61]

    Mingsheng Ying, Li Zhou, and Gilles Barthe. 2025. Laws of Quantum Program- ming.ACM Transactions on Software Engineering and Methodology(2025)

    2025

  54. [62]

    Cen Zhang, Yaowen Zheng, Mingqiang Bai, Yeting Li, Wei Ma, Xiaofei Xie, Yuekang Li, Limin Sun, and Yang Liu. 2024. How effective are they? exploring large language model based fuzz driver generation. InProceedings of the 33rd ACM SIGSOFT International Symposium on Software Tes...

    2024

  55. [63]

    Lingming Zhang, Binbin Zhao, Jiacheng Xu, Peiyu Liu, Qinge Xie, Yuan Tian, Jianhai Chen, and Shouling Ji. 2025. Waltzz:{WebAssembly} Runtime Fuzzing with{Stack-Invariant} Transformation. In34th USENIX Security Symposium (USENIX Security 25). 6159–6178

    2025

  56. [64]

    Qifan Zhang, Xuesong Bai, Xiang Li, Haixin Duan, Qi Li, and Zhou Li. 2024. {ResolverFuzz}: Automated Discovery of{DNS} Resolver Vulnerabilities with {Query-Response} Fuzzing. In33rd USENIX Security Symposium (USENIX Secu- rity 24). 4729–4746

    2024

  57. [65]

    Jianjun Zhao. 2020. Quantum software engineering: Landscapes and horizons. arXiv preprint arXiv:2007.07047(2020)

    2020 arXiv

  58. [66]

    Pengzhan Zhao, Zhongtao Miao, Shuhan Lan, and Jianjun Zhao. 2023. Bugs4Q: A benchmark of existing bugs to enable controlled testing and debugging studies KQFuzz: Knowledge-Guided Fuzzing for Quantum Libraries via Large Language Models ASE ’26, October 12–16, 2026, Munich, Germ...

    2023

  59. [67]

    Pengzhan Zhao, Xiongfei Wu, Zhuo Li, and Jianjun Zhao. 2023. Qchecker: Detecting bugs in quantum programs via static analysis. In2023 IEEE/ACM 4th International Workshop on Quantum Software Engineering (Q-SE). IEEE, 50–57

    2023

  60. [68]

    Input Constraints

    Xiaogang Zhu, Sheng Wen, Seyit Camtepe, and Yang Xiang. 2022. Fuzzing: a survey for roadmap.ACM Computing Surveys (CSUR)54, 11s (2022), 1–36. ASE ’26, October 12–16, 2026, Munich, Germany Xia et al. This supplementary material (SM) provides necessary details omitted from the m...

    2022

  61. [2012]

    Surface codes: Towards practical large-scale quantum computation.Physical Review A—Atomic, Molecular, and Optical Physics86, 3 (2012), 032324

    2012

  62. [2016]

    In NDSS, Vol

    Driller: Augmenting fuzzing through selective symbolic execution.. In NDSS, Vol. 16. 1–16

  63. [2017]

    InProceedings of the 2017 ACM SIGSAC conference on computer and communications security

    Directed greybox fuzzing. InProceedings of the 2017 ACM SIGSAC conference on computer and communications security. 2329–2344

    2017

Pith tools

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