arXiv subjects

Jiwei Yan

Publications and source records attributed to Jiwei Yan.

9 recordsLinked to original sources

arXiv2026

FuncDroid: Towards Inter-Functional Flows for Comprehensive Mobile App GUI Testing

As mobile application (app) functionalities grow increasingly complex and their iterations accelerate, ensuring high reliability presents significant challenges. While functionality-oriented GUI testing has attracted growing research attention, existing approaches largely overlook interactions across functionalities, making them ineffective at uncovering deep bugs hidden in inter-functional behaviors. To fill this gap, we first design a Functional Flow Graph (FFG), a behavioral model that explicitly captures an app's functional units and their inter-functional interactions. Based on the FFG, we further introduce an inter-functional-flow-oriented GUI testing approach with the dual goals of precise model construction and deep bug detection. This approach is realized through a long-short-term-view-guided testing process. By combining two complementary test-generation views, it can adaptively refine functional boundaries and systematically explore inter-functional flows under diverse triggering conditions. We implement our approach in a tool called FuncDroid, and evaluate it on two benchmarks: (1) a widely-used open-source benchmark with 50 reproducible crash bugs and (2) a diverse set of 52 popular commercial apps. Experimental results demonstrate that FuncDroid significantly outperforms state-of-the-art baselines in both coverage (+28%) and bug detection number (+107%). Moreover, FuncDroid successfully uncovers 18 previously unknown non-crash functional bugs in commercial apps, confirming its practical effectiveness.

cs.SE↗

arXiv2025

Co-Evolution of Types and Dependencies: Towards Repository-Level Type Inference for Python Code

Python's dynamic typing mechanism, while promoting flexibility, is a significant source of runtime type errors that plague large-scale software, which inspires the automatic type inference techniques. Existing type inference tools have achieved advances in type inference within isolated code snippets. However, repository-level type inference remains a significant challenge, primarily due to the complex inter-procedural dependencies that are difficult to model and resolve. To fill this gap, we present \methodName, a novel approach based on LLMs that achieves repository-level type inference through the co-evolution of types and dependencies. \methodName~constructs an Entity Dependency Graph (EDG) to model the objects and type dependencies across the repository. During the inference process, it iteratively refines types and dependencies in EDG for accurate type inference. Our key innovations are: (1) an EDG model designed to capture repository-level type dependencies; (2) an iterative type inference approach where types and dependencies co-evolve in each iteration; and (3) a type-checker-in-the-loop strategy that validates and corrects inferences on-the-fly, thereby reducing error propagation. When evaluated on 12 complex Python repositories, \methodName~significantly outperformed prior works, achieving a \textit{TypeSim} score of 0.89 and a \textit{TypeExact} score of 0.84, representing a 27\% and 40\% relative improvement over the strongest baseline. More importantly, \methodName~removed new type errors introduced by the tool by 92.7\%. This demonstrates a significant leap towards automated, reliable type annotation for real-world Python development.

cs.SE↗

arXiv2025

HACMony: Automatically Detecting Hopping-related Audio-stream Conflict Issues on HarmonyOS

HarmonyOS is emerging as a popular distributed operating system for diverse mobile devices. One of its standout features is app-hopping, which allows users to seamlessly transition apps across different HarmonyOS devices. However, when apps playing audio streams hop between devices, they can easily trigger Hopping-related Audio-stream Conflict (HAC) scenarios. Improper resolution of HAC will lead to significant HAC issues, which are harder to detect compared to single-device audio-stream conflicts, due to the unclear semantics of HarmonyOS's app-hopping mechanism and the lack of effective multi-app hopping testing methods. To fill the gap, this paper introduces an automated and efficient approach to detecting HAC issues. We formalized the operational semantics of HarmonyOS's app-hopping mechanism for audio streams for the first time. Leveraging this formalization, we designed an Audio Service Transition Graph (ASTG) to model the behaviors of audio-API-related services and proposed a model-based approach to detect HAC issues automatically. Our techniques were implemented in a tool, HACMony, and evaluated on 20 real-world HarmonyOS apps. Experimental results reveal that 11 of the 20 apps exhibit HAC issues. Additionally, we summarized the detected issues into two typical types, namely MoD and MoR, and analyzed their characteristics to assist and guide both app and OS developers.

cs.SE↗

arXiv2024

Write Your Own CodeChecker: An Automated Test-Driven Checker Development Approach with LLMs

With the rising demand for code quality assurance, developers are not only utilizing existing static code checkers but also seeking custom checkers to satisfy their specific needs. Nowadays, various code-checking frameworks provide extensive checker customization interfaces to meet this need. However, both the abstract checking logic and the complex API usage of large-scale checker frameworks make this task challenging. To this end, automated code checker generation is anticipated to ease the burden of checker development. In this paper, we propose AutoChecker, an innovative LLM-powered approach that can write code checkers automatically based on only a rule description and a test suite. To achieve comprehensive checking logic, AutoChecker incrementally updates the checker's logic by focusing on solving one selected case each time. To obtain precise API knowledge, during each iteration, it leverages fine-grained logic-guided API-context retrieval, where it first decomposes the checking logic into a series of sub-operations and then retrieves checker-related API-contexts for each sub-operation. For evaluation, we apply AutoChecker, five baselines, and three ablation methods using multiple LLMs to generate checkers for 20 randomly selected PMD rules. Experimental results show that AutoChecker significantly outperforms others across all effectiveness metrics, with an average test pass rate of 82.28%. Additionally, the checkers generated by AutoChecker can be successfully applied to real-world projects, matching the performance of official checkers.

cs.SE↗

arXiv2024

Better Debugging: Combining Static Analysis and LLMs for Explainable Crashing Fault Localization

Nowadays, many applications do not exist independently but rely on various frameworks or libraries. The frequent evolution and the complex implementation of framework APIs induce many unexpected post-release crashes. Starting from the crash stack traces, existing approaches either perform direct call graph (CG) tracing or construct datasets with similar crash-fixing records to locate buggy methods. However, these approaches are limited by the completeness of CG or dependent on historical fixing records. Moreover, they fail to explain the buggy candidates by revealing their relationship with the crashing point. To fill the gap, we propose an explainable crashing fault localization approach by combining static analysis and LLM techniques. Our primary insight is that understanding the semantics of exception-throwing statements in the framework code can help find and apprehend the buggy methods in the app code. Based on this idea, first, we design the exception-thrown summary (ETS) that describes the key elements related to each framework-specific exception and extract ETSs by performing static analysis. Then we make data-tracking of its key elements to identify and sort buggy candidates for the given crash. After that, we introduce LLMs to improve the explainability of the localization results. To construct effective LLM prompts, we design the candidate information summary (CIS) that describes multiple types of explanation-related contexts and then extract CISs via static analysis. We apply our approach to one typical scenario, i.e., locating Android framework-specific crashing faults, and implement a tool CrashTracker. For fault localization, it exhibited an overall MRR value of 0.91 in precision. For fault explanation, compared to the naive one produced by static analysis only, the LLM-powered explanation achieved a 67.04% improvement in users' satisfaction score.

cs.SE↗

arXiv2024

Fix the Tests: Augmenting LLMs to Repair Test Cases with Static Collector and Neural Reranker

During software evolution, it is advocated that test code should co-evolve with production code. In real development scenarios, test updating may lag behind production code changing, which may cause compilation failure or bring other troubles. Existing techniques based on pre-trained language models can be directly adopted to repair obsolete tests caused by such unsynchronized code changes, especially syntactic-related ones. However, the lack of task-oriented contextual information affects the repair accuracy on large-scale projects. Starting from an obsolete test, the key challenging task is precisely identifying and constructing Test-Repair-Oriented Contexts (TROCtxs) from the whole repository within a limited token size. In this paper, we propose SYNTER (SYNtactic-breaking-changes-induced TEst Repair), a novel approach based on LLMs to automatically repair obsolete test cases via precise and concise TROCtxs construction. Inspired by developers' programming practices, we design three types of TROCtx: class context, usage context, and environment context. Given an obsolete test case to repair, SYNTER firstly collects the related code information for each type of TROCtx through static analysis techniques automatically. Then, it generates reranking queries to identify the most relevant TROCtxs, which will be taken as the repair-required key contexts and be input to the large language model for the final test repair. To evaluate the effectiveness of SYNTER, we construct a benchmark dataset that contains a set of obsolete tests caused by syntactic breaking changes. The experimental results show that SYNTER outperforms baseline approaches both on textual- and intent-matching metrics. With the augmentation of constructed TROCtxs, hallucinations are reduced by 57.1%.

cs.SE↗

arXiv2024

Exception-aware Lifecycle Model Construction for Framework APIs

The implementation of complex software systems usually depends on low-level frameworks or third-party libraries. During their evolution, the APIs adding and removing behaviors may cause unexpected compatibility problems. So, precisely analyzing and constructing the framework/ library's API lifecycle model is of great importance. Existing works have proposed the API existence-changing model for defect detection, while not considering the influence of semantic changes in APIs. In some cases, developers will not remove or deprecate APIs but modify their semantics by adding, removing, or modifying their exception-thrown code, which may bring potential defects to upper-level code. Therefore, besides the API existence model, it is also necessary for developers to be concerned with the exception-related code evolution in APIs, which requires the construction of exception-aware API lifecycle models for framework/library projects. To achieve automatic exception-aware API lifecycle model construction, this paper adopts a static analysis technique to extract exception summary information in the framework API code and adopts a multi-step matching strategy to obtain the changing process of exceptions. Then, it generates exception-aware API lifecycle models for the given framework/library project. With this approach, the API lifecycle extraction tool, JavaExP, is implemented, which is based on Java bytecode analysis. Compared to the state-of-the-art tool, JavaExP achieves both a higher F1 score (+60%) and efficiency (+7x), whose precision of exception matching and changing results is 98%. Compared to the exception-unaware API lifecycle modeling on 60 versions, JavaExp can identify 18% times more API changes. Among the 75,433 APIs under analysis, 20% of APIs have changed their exception-throwing behavior at least once after API introduction, which may bring many hidden compatibility issues.

cs.SE↗

arXiv2022

A Comprehensive Evaluation of Android ICC Resolution Techniques

Inter-component communication (ICC) is a widely used mechanism in mobile apps, which enables message-based control flow transferring and data passing between Android components. Effective ICC resolution requires precisely identifying entry points, analyzing data values of ICC fields, modeling related framework APIs, etc. Due to various control-flow- and data-flow-related characteristics involved and the lack of oracles for real-world apps, the comprehensive evaluation of ICC resolution techniques is challenging. To fill this gap, we collect multiple-type benchmark suites with 4,104 apps, covering hand-made apps, open-source, and commercial ones. Considering their differences, various evaluation metrics, e.g., number count, graph structure, and reliable oracle based metrics, are adopted on-demand. As the oracle for real-world apps is unavailable, we design a dynamic analysis approach to extract the real ICC links triggered during GUI exploration. By auditing the code implementations, we carefully check the extracted ICCs and confirm 1,680 ones to form a reliable oracle set, in which each ICC is labeled with 25 code characteristic tags. The evaluation performed on six state-of-the-art ICC resolution tools shows that 1) the completeness of static ICC resolution results on real-world apps is not satisfactory, as up to 38%-85% ICCs are missed by tools; 2) many wrongly reported ICCs are sent from or received by only a few components and the graph structure information can help the identification; 3) the efficiency of fundamental tools, like ICC resolution ones, should be optimized in both engineering and research aspects. By investigating both the missed and wrongly reported ICCs, we discuss the strengths of different tools for users and summarize eight common FN/FP patterns in ICC resolution for tool developers.

cs.SE↗

arXiv2017

Target Directed Event Sequence Generation for Android Applications

Testing is a commonly used approach to ensure the quality of software, of which model-based testing is a hot topic to test GUI programs such as Android applications (apps). Existing approaches mainly either dynamically construct a model that only contains the GUI information, or build a model in the view of code that may fail to describe the changes of GUI widgets during runtime. Besides, most of these models do not support back stack that is a particular mechanism of Android. Therefore, this paper proposes a model LATTE that is constructed dynamically with consideration of the view information in the widgets as well as the back stack, to describe the transition between GUI widgets. We also propose a label set to link the elements of the LATTE model to program snippets. The user can define a subset of the label set as a target for the testing requirements that need to cover some specific parts of the code. To avoid the state explosion problem during model construction, we introduce a definition "state similarity" to balance the model accuracy and analysis cost. Based on this model, a target directed test generation method is presented to generate event sequences to effectively cover the target. The experiments on several real-world apps indicate that the generated test cases based on LATTE can reach a high coverage, and with the model we can generate the event sequences to cover a given target with short event sequences.

cs.SE↗