Papers for

software testing teams

Papers whose findings have a practical use for this group, as judged from the abstract. Open a paper to read what it means in practice.

Machine referee changes code agent work by raising verification cost

SaltBench: A Referee-Gated Protocol for Measuring Method Effects in Machine-Checked Software Work

Abstract: SaltBench is a benchmark protocol for one question: How does a machine referee change the way a coding agent works? A machine referee --- a proof kernel, a program verifier, or a withheld test suite --- decides what an agent's work is worth, and the agent cannot argue with it. Here we report a protocol that makes the referee's effect measurable and whose answers cannot be narrated afterwards: every outcome is decided outside the agent's own toolchain; the agent is walled off from the network, the reference solutions and the harness itself, and the wall is tested by probes that try to breach it before any scored run, so the isolation is observed rather than assumed; every run is authorized by a dated freeze with its predictions registered; and a budget stop is a halt, never a failure. In this study, the subject of the benchmark is a ``seat'', meaning an agent session in its standard harness. We tested five systems components, all authored in Rust under a pinned Verus toolchain, with a withheld test suite as the referee for each. Four arms are tested: a plain agent; an agent that is also instructed to create a specification and verify the code against it, in a reduced rendering of the method, as registered; and two arms where the specification is provided a priori, extended under a dated amendment to $k=4$, where the registered sign test reached no verdict (3 of 4, $p = 0.3125$, every premium below the resolvable floor). We found that the arm instructed to specify and verify cost more on all five components, and by a practical margin: across these five components no premium exceeded $2.8879\times$ under either reading of the declared set, and the three cheapest sat below $1.4\times$. That bound is a property of this population and not a promise about larger ones: the premium runs near $1$ on the smallest components and rises with size. We publish the complete record.

Thu 10 SeptSoftware EngineeringLogic in Computer Science
The gist
This paper studies how having a machine judge, or referee, influences the way a computer program writes code. The referee can be a proof checker or a test set that decides if the program's work is correct, with no argument possible. The authors created a strict test protocol to measure exactly how much extra effort is needed when an agent must prove its code correct as judged by this referee. They found verifying the code adds a measurable cost in time or effort, but it varies by component size. This helps understand the trade-offs when requiring machine verification in software.
Open 2609.11076v1

Retrofitting code with large language models to add exception handling

Retrofitting Code Using LLMs to Support Exceptional Behavior

Abstract: Exception Related Code (ERC), which includes throw statements, conditions (if statements) that guard those throw statements, and try/catch blocks, is an essential component of software systems, allowing developers to detect and handle exceptional states that deviate from the expected program behavior. However, manually writing ERC across large codebases is tedious. We propose a novel task: retrofitting existing code with ERC. Namely, given code (without ERC) and Exceptional Behavior Tests (EBTs) (e.g., check if method throws InvalidArgumentException if null is given as the value to the argument) we aim to automatically generate missing ERC, such that the given tests pass. We design and implement Exception Coder (EXCODER) that performs context engineering to help Large Language Models (LLMs) tackle this task. EXCODER integrates static and dynamic program analysis with LLMs by providing the extracted contextual information to the LLMs. To evaluate EXCODER, we build a benchmark constructed from GitHub Java repositories, where we systematically remove ERC in 304 methods from 75 projects. Our results demonstrate that EXCODER provides an effective, though imperfect, solution to this problem in automated code generation, offering developers the first way to implement ERC following test-driven development. When combined with Qwen 2.5 Coder 32b, EXCODER achieves pass@1, 5, and 10 rates of 85.92% (12.56 percentage points over baseline), 86.18% (12.82 p.p. over baseline), and 86.51% (13.15 p.p. over baseline), respectively, on developer-written test suites. Our manual inspection of the generated code further reveals limitations of EXCODER, pointing to directions for future work.

Wed 9 SeptSoftware EngineeringComputation and Language
The gist
Software often needs special code to handle unusual or error situations, but writing this code can be boring and time-consuming. The authors created a method called EXCODER that helps large language models add this special exception-handling code automatically to existing programs when given tests that expect errors. EXCODER works by combining static analysis (looking at the code structure) and dynamic analysis (running code) with language models to better understand where and how to add these corrections. Their tests show EXCODER does a good job, though not perfect, of generating this code to pass developer-written tests.
Open 2609.10397v1

GraphDroid improves mobile app testing by exploring apps more effectively

GraphDroid: Asynchronous LLM-Based Mobile App GUI Testing via History-Aware Exploration and Hybrid Intent Fulfillment

Abstract: Automated GUI testing is a widely adopted technique for ensuring mobile application quality by simulating user interactions to exercise functionalities. Despite the research breakthroughs in the past decades, covering complex functionalities that require multi-step action sequences still remains challenging. Traditional tools lack semantic understanding capability and can rarely synthesize such action sequences. Recent LLM-based tools can generate test intents describing target functionalities and leverage the LLM to fulfill the intents, but suffer from three key limitations: 1) loss of historical context for identifying uncovered functionalities, 2) synchronous intent generation that blocks exploration, and 3) per-step LLM-driven fulfillment incurring high cost and latency. To address these limitations, we propose GraphDroid, an intent-driven GUI testing framework that integrates a cluster-based memory mechanism to effectively identify uncovered functionalities from historically visited states for comprehensive application testing. For improving testing efficiency, GraphDroid adopts an asynchronous intent generation paradigm that eliminates the latency bottleneck and a hybrid intent fulfillment strategy that reserves the LLM for fulfilling complex intents while delegating simple intents to a lightweight heuristic algorithm. We evaluate GraphDroid on 41 real-world Android apps against six state-of-the-art baselines. Results show that GraphDroid outperforms all baselines, achieving up to 36.4% higher code coverage while incurring less than one eighth of the cost of the best pure LLM-based baseline. GraphDroid also exposes 19 bugs in the 41 apps and detects 13 of 52 crashes in the Themis bug benchmark, surpassing all the six baselines. Seven of the 19 bugs were previously unknown and we reported them to the developers. So far, four bugs have been confirmed and fixed.

Wed 9 SeptSoftware Engineering
The gist
Testing mobile apps automatically is hard when you need to try complicated sequences of actions to find all the important features and bugs. The authors created GraphDroid, a system that remembers what parts of the app it has explored, plans new actions without waiting too long, and uses both fast rules and AI to carry out tests efficiently. This approach lets GraphDroid cover more of the app’s code and find more bugs than other recent tools, while using fewer expensive AI calls. The authors tested it on many real Android apps and found new bugs that developers fixed.
Open 2609.10031v1

Cross repository knowledge graph improves code generation accuracy

Beyond Repository Boundaries: Cross-Repository Graph Retrieval for Code Generation

Abstract: Repository-level code generation requires generated code to be compatible not only with the target repository but also with its dependency environment. Existing retrieval-based methods mainly retrieve context from the local repository, leaving external API usage dependent on the model's pretrained knowledge, which can be insufficient for unseen or version-specific APIs. Moreover, current retrieval strategies largely focus on one-hop evidence and overlook the structural relationships among code components. We propose CrossCoder, a cross-repository code generation framework that explicitly incorporates external libraries into the retrieval context through a unified knowledge graph over repository and library entities. CrossCoder identifies important nodes via planning and semantic retrieval, then selectively expands neighboring nodes to retrieve richer multi-hop contextual evidence for generation. To further evaluate dependency-version compatibility, we introduce VersionExec, an execution-based benchmark derived from BigCodeBench that evaluates generation under different dependency versions. Experimental results on RepoExec, DevEval, and VersionExec demonstrate that CrossCoder consistently improves both functional correctness (up to 6.3% on pass@1) and robustness to dependency-version changes.

Wed 9 SeptSoftware Engineering
The gist
Generating code that works well with other software libraries can be tricky because code often depends on things outside its own project. The authors created CrossCoder, a tool that looks beyond one project to include relevant parts from other libraries using a knowledge graph. This helps the system find important connections in the code and dependencies, making the generated code more accurate and compatible with different versions. They also made a new test called VersionExec to check how well the generated code works with various library versions. Their experiments show better code correctness and robustness with their approach.
Open 2609.09987v1

Code generation leakage detection improved with new membership inference method

Keep Evaluation Fair: Detecting Data Leakage in Code Generation Benchmarks via Membership Inference Attacks

Abstract: Code generation benchmarks are widely used to evaluate Large Language Models (LLMs), but benchmark data leakage into training sets can inflate performance and undermine evaluation validity. DetectLeak, a method specifically designed for code generation benchmark leakage detection, relies on perplexity scores to identify likely leaked samples. However, perplexity mainly reflects general familiarity with code patterns and may perform poorly on complex or rare samples. It also overlooks other useful signals, such as code similarity, functional correctness, and semantic representations. To address these limitations, we propose CGMIA (Code-Generation-specific Membership Inference Attack), a method for detecting leakage in code generation benchmarks. CGMIA fine-tunes a shadow model on a subset of benchmark samples to construct labeled member and non-member data. For each sample, it collects the input prompt, generated code, and reference solution, and extracts expert features, including CodeBLEU, edit distance, test pass rate, and perplexity, together with semantic features from CodeBERT embeddings. An integrated learning module combines these features to capture both surface-level memorization signals and deeper behavioral patterns, enabling a classifier to predict whether a sample was included in the target model's training set. Experiments on eight code generation benchmarks show that CGMIA outperforms eight existing membership inference methods in most cases. It also effectively detects known leaked APPS samples in StarCoder-7B's training data.

Wed 9 SeptSoftware Engineering
The gist
Evaluating AI models that generate code can be tricky when test examples accidentally appear in training data, making results seem better than they really are. The authors created a method called CGMIA that uses many clues—like how similar codes are, how well the code works, and language model scores—to spot leaked test examples. This new approach works better than previous methods and found leaked samples in a popular AI model’s training data. Detecting such leakage helps make AI code evaluations fair and trustworthy.
Open 2609.09865v1

Traditional test criteria struggle to find bugs in AI generated code

How effective are traditional test criteria at detecting bugs in large language models generated code?

Abstract: Test adequacy criteria are widely used to evaluate and guide software testing. Although prior research has extensively examined these criteria using human-written programs, faults, and tests, the increasing adoption of Large Language Models (LLMs) for code generation raises important questions about their effectiveness in detecting LLM-induced faults. To investigate this, we conduct an empirical study involving 5 LLMs and 4 benchmarks, simulating end-to-end workflows in which both code and tests are automatically generated. We collect 6,000+ faulty program instances and evaluate the effectiveness and efficiency of 3 widely used adequacy criteria: statement coverage, branch coverage, and mutation testing. Our findings reveal several key insights. First, most faults introduced by LLMs are relatively trivial to catch. Second, the challenging faults are difficult to trigger using either traditional coverage-based or mutation-based criteria. Third, actual fault detection rates remain extremely low, often near zero, because test oracles fail to capture faulty behavior triggered by the generated test prefixes, exposing a critical limitation of automated test generation. Fourth, prompt-aware oracles can improve fault detection, but their overall effectiveness remains limited, highlighting the need for users to manually reason about test assertions. We further observe that mutation testing only marginally outperforms traditional coverage criteria in both triggering and detecting faults, raising questions about whether its significantly higher application cost is justified in this context.

Tue 8 SeptSoftware Engineering
The gist
The paper looks at how well common software testing rules catch bugs in code written by AI models. They found that many bugs are actually easy to detect, but harder problems slip through unnoticed because tests can't always spot them. Even stronger testing methods only do slightly better and may not be worth their extra effort. The authors say people still need to carefully check test results manually to find tricky mistakes.
Open 2609.09315v1

DJPlus reduces redundant test steps for faster system testing

DJPlus: Generating minimal test suites for strong coverage criteria in graph models

Abstract: Automated test generation from graph models is essential to model-based testing. In this type of testing, graph coverage ensures test suite strength but also results in long test cases that take time to execute on the system under test. We propose a novel optimization-driven method, DJPlus, which generates reduced test suites while satisfying given graph-based test requirements. We implement DJPlus and show the feasibility of edge-pair criterion, a stronger coverage criterion than vertex or edge criteria, on four realistic systems, while prime path criterion poses scalability issues. Our evaluation reveals that the alternative methods generate 2 to 26 times more redundant test steps than DJPlus and DJPlus decreases test execution times by reducing the number of test steps. These results show that DJPlus is a positive step towards tackling the challenges of model-based testing at an industrial scale.

Tue 8 SeptSoftware Engineering
The gist
Testing software systems can take a long time when tests cover all possible paths, which leads to very long test scenarios. The authors created DJPlus, a method that reduces the number of test steps while still meeting strict testing goals based on graphs that model software behavior. DJPlus produces much shorter test suites that run faster than other methods, enabling more efficient testing without losing important coverage. This helps companies test complicated systems quicker and with fewer redundant steps.
Open 2609.08953v1

Code driven framework improves handling of evolving information in conversations

EvolveScaler: Synthesizing Information-Evolution Contexts via Executable State Machines and Natural-Language Rendering

Abstract: In persistent interactions, long contexts may encode an evolving process rather than a fixed record: later events can revise or revoke earlier information, changing what remains valid and what conclusions follow. We call this setting information evolution (IE). Solving IE requires identifying valid records, applying updates in order, and reconstructing the query-relevant state from the event history. Existing text-first synthesis pipelines make such data difficult to verify because state transitions and answer logic remain implicit. We introduce EvolveScaler, a code-driven framework that defines information evolution before rendering it as natural language. Human-authored operational specifications define state transitions, record validity, difficulty controls, and executable answer logic; a strong LLM then synthesizes a self-contained simulator from each specification. Executing validated simulators produces natural-language multi-turn event histories, while deterministic replay computes reference answers and atomic checklists. We instantiate EvolveScaler with 117 task prototypes and 159 final-question operators across five difficulty levels spanning approximately 7 to 1,200 events per instance, yielding about 35,100 training examples and 585 validated evaluation instances. On the very_long tier, the strongest model reaches 59.3% avg@5, while six models score below 10%. Training an internal A3B model on 6,000 EvolveScaler examples improves performance over its base checkpoint on all eight independently constructed out-of-distribution benchmarks, with a 5.25-point average gain. These results show that code-driven IE synthesis provides both challenging evaluation and transferable training supervision.

Tue 8 SeptArtificial IntelligenceSoftware Engineering
The gist
Sometimes, when information changes over time, earlier facts get updated or erased, making understanding the full story harder. The authors created EvolveScaler, a method that first defines these changing facts using clear, computer-readable rules before turning them into natural language stories. This approach helps test and train computer models better by simulating events and checking answers precisely. Their tests show this method creates challenging examples and helps improve model performance on new situations.
Open 2609.08435v1

FPScan finds critical errors in floating-point programs automatically

FPScan: An Automated Constraint-Based Analyzer for Floating-Point Anomaly Detection

Abstract: Writing error-free floating-point programs is a challenging task, especially for programmers who lack a strong background in numerical analysis and rounding-error propagation. State-of-the-art techniques typically aim to bound such errors using static or dynamic analysis. However, only a few tools explicitly address critical floating-point pitfalls such as absorption and catastrophic cancellation. These anomalies represent situations in which rounding errors are significantly amplified, causing the semantics of the finite-precision computation to deviate substantially from the real-number semantics. In this article, we present FPScan, a novel tool to formally define and detect both catastrophic cancellation and absorption in floating-point programs. Our approach starts with a custom static analyzer based on abstract interpretation to infer the order of magnitude of all program variables. This magnitude information is then used to build a set of first-order constraints that model error propagation and numerical precision within the program. Finally, we employ an off-the-shelf SMT solver to determine whether the program exhibits any of these critical numerical pitfalls. Experiments were conducted on FPBench, a well-known benchmark suite of floating-point programs, to evaluate the effectiveness of our tool. We also present a comparison with state-of-the-art tools regarding soundness and analysis time.

Mon 7 SeptSoftware Engineering
The gist
Floating-point programs, which use numbers with limited precision, are tricky to write correctly because tiny rounding mistakes can become large problems. FPScan is a new tool that helps find two types of serious errors where these small rounding issues get magnified. It works by analyzing the sizes of numbers in a program and setting up math constraints to check where errors could get very bad. The authors tested FPScan on standard benchmarks and compared it with other tools to show how well it detects these problems.
Open 2609.07492v1

Surrogate models speed up multi-objective software architecture optimization

A Surrogate-based Approach for Fast Multi-objective Architectural Refactoring Optimization

Abstract: Software model optimization is a process that generates architecture alternatives aimed at improving quantifiable non-functional properties of software systems, such as performance and reliability. Multi-objective evolutionary algorithms are commonly used to explore the search space and help designers identify trade-offs among competing non-functional properties (e.g., through a Pareto front). However, such algorithms face efficiency challenges in complex software models and large design spaces, since evaluating the fitness (i.e., the quality) of each architecture requires analysis tools that become computationally expensive when repeatedly invoked during the search process. In this paper, we explore the construction of surrogate models based on regression techniques to approximate the outputs of these analysis tools at significantly lower computational cost, while maintaining reasonable output accuracy. Our experimental results suggest that surrogate models provide savings of up to $30\%$ in computational time and maintain the Pareto front quality provided by evolutionary algorithms. Also, we observed some differences in the architectural models produced by our approach. Overall, surrogate models constitute a promising approach for scaling multi-objective architecture optimization to larger spaces and complex architectural models.

Mon 7 SeptSoftware Engineering
The gist
Optimizing software architecture to improve things like speed and reliability often requires testing many design options, which can be very slow. The authors tried using shortcut models that approximate the testing process to save time. These shortcut models can reduce computation time by about 30% while still finding good design trade-offs. This approach helps handle more complex designs more efficiently.
Open 2609.07389v1

Limits of single-run safety monitors for large language models revealed

The Oversight Gap: What LLM Safety Monitors Miss, and Why It Is Not Capability

Abstract: Several properties safety monitors are asked to certify, among them cross-tenant noninterference, sandbagging and evaluation awareness, are 2-safety hyperproperties, witnessed only by two executions. The standard consequence is a binary impossibility: one trace cannot decide them. We replace the binary with a measurement. A tight bound puts the balanced accuracy of any single-trace monitor at $\tfrac12+\tfrac12\,TV(P_0,P_1)$, turning undecidability into a graded detectability frontier and defining an oversight gap: a monitor's shortfall below it. On a leak family with closed-form $TV$, nine LLM monitors are optimal at $TV=0$ but capture little signal as $TV$ grows; at $TV=1$, where a 20-line membership check scores $100\%$, they average $60.9\%$. That shortfall is mostly not capability: naming what to check closes $61\%$ of it while leaving the $TV=0$ control at chance. The same split runs through a $2{\times}2$ factorial: an imagined second run leaves monitors at chance ($50.4\%$) while the same rule on an executed second run reaches $90.0\%$, and a stored oracle without a comparison procedure yields only $68.2\%$. Information and procedure are each necessary and neither is capability. Under nondeterminism, replay tracks a closed-form $k$-replay curve only under the right projection, and a projection frontier shows the resulting dilemma is forced: narrow misses $98.6\%$ of off-channel leaks, broad flags $75.7\%$ of clean traffic, and attainable accuracy decays like $1/(qm)$ in the benign-variation rate and the channel count. Finally, two frontier LLM judges certified an earlier version of our own benchmark as sound while a sign test found a directional bias ($p=2.7\times10^{-5}$) that invalidated three of our findings. Construction validity for hyperproperty benchmarks should be proved mechanically, not audited by models.

Mon 7 SeptMachine LearningCryptography and Security
The gist
Checking the safety of large language models (LLMs) by looking at just one run or interaction is often not enough. The authors show that certain safety properties can only be reliably detected by comparing multiple runs, not by examining a single run. They measured how well current safety monitors work and found that they miss many signals especially when leakage between runs grows. The missing signals are not because the models lack capability but because of what and how we check safety. The authors suggest safety tests should be mechanically verified instead of relying on human or model audits.
Open 2609.07162v1