Pith. sign in

REVIEW 3 major objections 5 minor 22 references

DragonCrawl: A Generative, Intent-Based Framework for Scalable Mobile End-to-End Testing

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

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

Pith's one-line read DragonCrawl rebuilds mobile end-to-end regression testing as an LLM decision loop that reads each screen, picks the next action, and judges screenshots, reporting 91.6%/92.2% pass rates across 1,013 production flows.

desk verdict A solid industrial experience report on a large-scale LLM-based regression testing system, but the headline pass rates and savings figures are self-reported and rest on an unvalidated, self-referential VQA oracle—treat them as operational claims, not verified results. read the letter →

arxiv 2607.28750 v2 pith:TNT3H3DZ submitted 2026-07-30 cs.SE cs.AI

Sowjanya Puligadda , Mengdie Zhang , Ali Zamani , Dhruva Dixith Kurra , Eric Chen , Juan Marcano This is my paper
classification cs.SEcs.AI
keywords mobiletestingend-to-endregressionlargelanguagemodelsmultimodalvisualassertionsintent-basedtestautomationCI/CDqualitygatesUIsoftwareassurance
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

DragonCrawl claims that mobile end-to-end regression testing can be rebuilt around a large language model that reads the current screen, the test's natural-language intent, and the action history, then chooses the next action and judges from a screenshot whether the flow reached its goal. The paper argues that this intent-based design removes the brittle element locators and hand-built reference datasets that made traditional UI tests expensive, while doing something prior LLM testing tools did not: running the same critical flows on every code change and blocking commits that break them. In production the system reports 91.6% pass rates on iOS and 92.2% on Android across 1,013 tests, cuts test onboarding from roughly four days to under four hours per flow, and estimates 27 developer-years of authoring and maintenance effort saved. If true, this makes continuous regression testing at large scale feasible with a small team and makes a failed test a signal of a real regression rather than a brittle script.

What carries the argument

The load-bearing object is the intent-based reasoning loop, a per-step decision cycle that sends the LLM a context package of four pieces: a canonized view hierarchy (noisy XML compressed into only interaction-relevant elements, for example 144 nodes reduced to 51 actions), the test's natural-language goal, the chronological action history, and the set of currently available actions. The same loop routes end-state detection through a separate multimodal assertion endpoint that judges a base64 screenshot against a natural-language question, and routes backend state changes through tool calling so tests can set up conditions such as driver document approval without waiting on real-world state. Prompt constraints enforce that the model selects only from available actions, returns valid JSON, and cannot fabricate elements, which is what turns an open-ended generator into a deterministic-enough regression gate.

What would settle it

Take a random sample of the 1,013 flows and collect the screenshots at the moment each test is declared passed; have independent human reviewers judge whether the end-state assertion is truly satisfied, and compare agreement with the model's verdicts, paying special attention to near-miss states like loading spinners or partially rendered screens. Alternatively, run DragonCrawl in shadow mode for a period, letting it classify commits as pass or block without actually blocking, and measure whether the commits it would have blocked introduce user-visible regressions more often than the ones it would have passed.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that the job of an end-to-end test can be restated as goal-directed reasoning instead of scripted interaction. DragonCrawl V2 takes a natural-language intent, a canonized list of currently actionable UI elements, and a running action history, and asks a multimodal LLM (GPT-4o) to pick the next action, with constraint-based prompts guaranteeing the action comes from the visible set. End-state and mid-state verification are likewise turned into visual questions: a screenshot is sent with an assertion such as "is the ride successfully requested?" and the model answers. Backend setup steps that are impractical through the UI are reached through dynamically generated tool calls to controlled test environments. The paper reports that this architecture raised end-to-end pass rates from 80-82% to 91.6%/92.2%, took complex flows from 0% to 89%, achieved 95.9% success in a controlled ablation with all components intact, and reduced maintenance effort to about 5% of engineering time.

Load-bearing premise

The load-bearing premise is stated in Section 5.2: every pass/fail verdict comes from the multimodal model judging screenshots against natural-language assertions, and the paper assumes that judging is near-perfect on the strength of prior work; if the model over-accepts, the reported pass rates and the attribution of remaining failures to genuine regressions are unsupported.

Editorial extensions

If this is right

  • If the pass rates hold, a team can run thousands of flow-level regression checks on every commit with only the cost of LLM inference, rather than writing and maintaining locator-based scripts per platform.
  • The 30-40x onboarding reduction means coverage can scale to the combinatorial space of markets, languages, and device configurations without per-variant test code.
  • A failed build becomes a credible regression signal rather than a flaky test, so CI/CD gates can actually stop broken releases.
  • The tool-calling layer extends the same reasoning loop beyond UI assertions to system state, letting regression tests cover flows that require backend preconditions.
  • The cost model depends on caching and selective execution; the paper's $200K annual inference estimate is achievable only with that engineering.

Reading between the lines

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

  • A testable extension the paper does not run is shadow-mode gating: let DragonCrawl classify commits without blocking them, then compare its would-be blocks and passes against human triage to quantify over-acceptance and under-blocking.
  • If the screenshot-assertion verdicts are as reliable as assumed, the same visual question-answering loop is a general-purpose QA primitive that could be pointed at web, desktop, or embedded UIs, not just mobile.
  • The economics are the least portable part: the 27 developer-years saved is measured against manually scripted tests, and a smaller team or app suite may not cross the inference-cost threshold, as the paper itself notes.
  • Because the verdicts come from a model that can be updated, the measurement baseline has drift risk; a continuously human-audited sample of assertions would be needed to keep the reported rates meaningful over time.
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. DragonCrawl is an industrial LLM-based mobile end-to-end regression testing system deployed at Uber. The paper describes the evolution from an MPNet embedding-based matcher (V1) to a GPT-4o intent-based agent (V2) that combines generative action selection, multimodal screenshot assertions, tool calling for backend state transitions, CI/CD integration, and cost optimization. It reports 91.6% iOS and 92.2% Android pass rates across 1,013 automated tests, a reduction in onboarding time from 96-120 hours to under 4 hours per flow, and an estimated 27 developer-years of maintenance and authoring effort saved. The paper also reports precision@k action-prediction results, latency comparisons, an ablation study with 5,065 runs per configuration, and an external comparison with other LLM-based mobile testing tools.

Significance. If the headline measurements were supported by an independent oracle, this would be a significant industrial case study: per-commit regression gating with an LLM-driven agent at the scale of 1,013 production flows is not common in the published literature, and the design choices (canonized view hierarchy, prompt constraints, tool-call templates, prompt caching, selective execution) are useful to practitioners. The paper's strengths include a concrete ablation study, a candid limitations section, and detailed operational cost engineering. The main weakness is that the system's own verdict generator is also the oracle for every success/failure metric; no independent ground truth is reported for any of the 1,013 tests. This gap must be closed before the pass-rate, regression-attribution, and savings claims can be accepted.

major comments (3)
  1. [§5.2, §3.2, §8] The central pass/fail metric is self-referential. Every test verdict is produced by GPT-4o answering end-state and mid-state visual assertions, and §5.2 justifies the reliability of these verdicts by citing near-perfect VQA accuracy in prior work [11] rather than measuring assertion accuracy on this deployment. Since §8 concedes that transient states can produce false verdicts and that low-priority assertion mismatches are non-blocking, the reported 91.6%/92.2% pass rates and the classification of non-passing runs as 'genuine regressions' are not supported by evidence in this paper. Please add an independent evaluation on a sample of production runs: have human oracles label end-state and mid-state screenshots, report per-assertion precision and recall, and especially report the false-pass rate; without this, an over-accepting model could inflate pass rates and misclassify model error as product health.
  2. [§6.4] The 27 developer-years estimate is an assumption-driven arithmetic exercise rather than a measured result. The computation uses 16 developer-hours per test for authoring and 20 hours per test for maintenance, with H_year=1,380, but no source, measurement, or sensitivity analysis is given for these baselines; the numbers also mix one-time authoring effort with recurring maintenance over an unspecified deployment period. Please provide the empirical basis for the per-test baselines and the deployment period, and add a sensitivity analysis, or downgrade the claim to an explicitly illustrative estimate.
  3. [§5.2, Table 2] The V1-versus-V2 comparison is not apples-to-apples. V1 was evaluated on 48 low-complexity flows with hardcoded resource-ID end-state detection, while V2 is evaluated on 1,013 flows whose end states are judged by GPT-4o visual assertions; the pass criteria themselves changed, so part of the reported improvement from 80-82% to 91.6-92.2% could be due to a more permissive oracle rather than better navigation. Please report V1 and V2 on a common held-out set of flows with a common, independently verified success criterion, and state the per-complexity test counts behind the 95%/94%/89% breakdown.
minor comments (5)
  1. [§5.2] The statement that the 61 core flows sustain a near 99% pass rate should be reconciled with Table 2 and with the aggregate 91.6%/92.2% rates; please add core-flow pass rates and sample sizes.
  2. [§5.5] The paper should state explicitly that the ablation's Full System row (95.9%) was computed with the same self-judged assertion oracle as the deployment numbers, and therefore measures relative component contributions rather than absolute success; the comparability note gestures at this but should be stated in the metric definition.
  3. [§4.2] The claim that the daily evaluation pipeline alerts when accuracy drops below a 95% threshold is not accompanied by a definition of the accuracy metric or by any reported values; please define the metric and report recent measured values.
  4. [§5.3, Table 3] The external comparison is clearly labeled as context rather than a like-for-like benchmark, which is appropriate; consider moving the table to the related-work section or adding columns for task definitions and app domains to reduce the risk of misreading.
  5. [§6.5] The approximate 15% feature-velocity increase and the bug-escape-rate improvement are reported without measurement methodology; if these are qualitative observations, please say so explicitly.

Circularity Check

1 steps flagged · score 4.0 of 10

One load-bearing self-citation: the assertion oracle that produces every pass/fail verdict is validated only by the authors' prior work, so the headline pass rates and 'genuine regressions' claims are partially self-referential; the pass-rate numbers themselves remain observed, not derived.

  1. self citation load bearing [Section 5.2 (Pass Rate Analysis); supported by Sections 3.2 and 4.2; qualified in Section 8]
    "The underlying visual question answering is highly reliable, with near-perfect accuracy reported in our prior work [11], so blocking is governed by policy rather than model error: a commit is blocked when the end state is not reached or a high-priority assertion fails, while low-priority assertion mismatches (e.g. the text in a button changing from 'confirm' to 'ok') are tracked but non-blocking"

    Every test verdict is produced by GPT-4o visual assertions: Section 3.2 sends screenshots to /assert_flow_end and /verify_mid_state, and Section 5.2 defines a pass as satisfying those GPT-4o judgments. The only support for treating these verdicts as trustworthy is the self-cited 'near-perfect accuracy' of [11], whose author list overlaps with this paper. No assertion-level accuracy, false-positive rate, or independent oracle is reported for the 1,013 production flows; transfer of [11] to these flows is asserted, not demonstrated. The 91.6%/92.2% pass rates, V1-to-V2 improvement, and the 'genuine regressions' classification all pass through this oracle, so the central quantitative interpretation rests on a load-bearing self-citation.

full rationale

The paper's central numbers (91.6%/92.2% pass rates over 1,013 tests) are operational measurements: a test is counted as passing exactly when GPT-4o's end-state and mid-state visual assertions return true. Taken alone, that is a normal test-oracle definition and not circular. The circularity risk enters when the paper interprets those numbers as evidence of correctness and regression detection: Section 5.2 imports 'near-perfect accuracy' for the visual question answering from the authors' own prior work [11], without presenting assertion-level accuracy or an independent oracle for this deployment. The ablation study (Section 5.5) uses the same self-judged success criterion, so it cannot validate the oracle; however, because it compares configurations under a consistent oracle, it is not itself circular. The developer-year savings (Section 6.4) are arithmetic from stated per-test assumptions and are not circular. The paper also honestly lists assertion-reliability limits in Section 8, which tempers the self-citation but does not replace it. On balance, the self-citation is load-bearing for interpreting the pass rates as genuine quality signals, but the engineering contributions (coverage growth, onboarding reduction, latency, bug examples) have independent content. Score 4 reflects one significant load-bearing self-citation with independent content elsewhere, not full reduction-by-construction.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The paper's headline quantitative claims (pass rates, onboarding times, 27 developer-years saved) depend on self-measured metrics and hand-picked baselines that are not independently verified. The main assumptions are listed above.

free parameters (3)
  • manual authoring baseline per test = 16 developer-hours
    Used in Section 6.4 to compute 12 developer-years of authoring savings; no empirical basis is given for the 16-hour figure.
  • manual maintenance baseline per test = 20 developer-hours
    Used in Section 6.4 to compute 15 developer-years of maintenance savings; stated as an estimate with no supporting data.
  • productive developer-hours per year = 1,380
    Assumed in Section 6.4 to convert hours to developer-years; not justified.
assumptions (4)
  • domain assumption The visual question-answering used for end-state and mid-state assertions is highly reliable, with near-perfect accuracy.
    Invoked in Section 5.2, relying on the authors' prior work [11] rather than an independent evaluation in this paper.
  • domain assumption The Golden Dataset of approximately 10,000 validated interaction sequences is accurate and representative for evaluating action correctness.
    Assumed in Section 4.2; no details on how the dataset was validated or its coverage.
  • ad hoc to paper LLM token costs will decline by roughly 10x every 6-12 months, making the investment in vendor LLMs economically sound.
    Used in Sections 2.2 and 5.6 to justify moving from free MPNet inference to paid GPT-4o; this is a trend projection, not a measured fact.
  • ad hoc to paper The V1 and V2 pass rates are comparable despite using different test sets and time periods.
    Table 2 compares V1 (80-82%) with V2 (91.6-92.2%) without noting that V1 ran on 48 simple flows while V2 ran on 1,013 flows including complex ones; the comparison is not controlled.

how reviews work

0 comments
Cite this review

Pith. "Pith review of DragonCrawl: A Generative, Intent-Based Framework for Scalable Mobile End-to-End Testing." pith.science (2026). https://pith.science/paper/TNT3H3DZ

@misc{pith2026260728750,
  author       = {Pith},
  title        = {Pith review of: DragonCrawl: A Generative, Intent-Based Framework for Scalable Mobile End-to-End Testing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/TNT3H3DZ}},
  note         = {Machine review of arXiv:2607.28750}
}
read the original abstract

As mobile applications grow in complexity, traditional End-to-End (E2E) testing frameworks struggle with UI volatility, maintenance overhead, and cross-platform scalability. This paper presents DragonCrawl, an AI-driven mobile testing system for continuous regression testing that has evolved from embedding-based similarity matching to generative intent-based reasoning using large language models. Unlike prior LLM-based testing research focused on exploratory testing and crash detection, DragonCrawl validates specific user flows on every code change, blocking commits that break critical functionality. By leveraging GPT-4o's multimodal capabilities, DragonCrawl achieves 91.6% pass rate on iOS and 92.2% on Android across 1,013 automated tests running continuously in CI/CD pipelines. The system reduces test onboarding time from 96-120 hours to under 4 hours and has saved an estimated 27 developer years in test maintenance effort. We present the architectural evolution from V1 (semantic embedding matching) to V2 (generative intent-based reasoning), discuss implementation challenges including token explosion and memory constraints, and report operational experience from production deployment. The integration of multimodal vision for end-state detection and tool calling for backend state transitions enables comprehensive regression testing that bridges UI interactions with system state. Our results demonstrate that AI-driven testing can maintain stability while eliminating the brittleness of traditional automated tests, enabling continuous quality assurance at scale.

Figures

Figures reproduced from arXiv: 2607.28750 by the authors.

Figure 1
Figure 1. Architecture of DragonCrawl. The core of DragonCrawl V2 is an intent-based reasoning engine that generates next actions based on rich context. For each decision point during test execution, the system constructs a context package containing: • Current UI Snapshot: A textual representation of the XML view hierarchy of the screen, including all interactive ele￾ments, their properties, and their relationships • Overall… view at source ↗
Figure 2
Figure 2. Dataflow of Visual Assertions. when layouts change. DragonCrawl V2 uses multimodal vision to detect test completion. At each step, the system captures a screenshot and encodes it as base64. When the model believes the test goal may be achieved, it triggers an end-state detection query. The system sends both the screenshot and a natural language question to GPT-4o: "Based on this image, has the user successfully reac… view at source ↗
Figure 3
Figure 3. Context enhancement from view hierarchy. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Context-Conditioned Backend Orchestration in [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: Coverage growth over time [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: Distribution of high priority bug resolutions. [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]

Review history (2 revisions) →

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

22 extracted references · 2 canonical work pages

  1. [11]

    Juan Marcano, Ashish Samant, Kai Song, Lingchao Chen, Kaelan Mikowicz, Tim Smyth, Mengdie Zhang, Ali Zamani, Arturo Bravo Rovirosa, Sowjanya Puligadda, Srikanth Prodduturi, and Mayank Bansal. 2026. Scaling Mobile Chaos Testing with AI-Driven Test Execution. InProceedings of the 48th International Conference on Software Engineering: Software Engineering in...

    work page arXiv 2026

  2. [1]

    Nadia Alshahwan, Xinbo Gao, Mark Harman, Yue Jia, Ke Mao, Alexander Mols, Taijin Tei, and Ilya Zorin. 2018. Deploying Search Based Software Engineering with Sapienz at Facebook. InProceedings of the 10th International Symposium on Search Based Software Engineering (SSBSE). Springer, Cham, Switzerland, 3–45. doi:10.1007/978-3-319-99241-9_1

    doi:10.1007/978-3-319-99241-9_1 2018

  3. [2]

    Riccardo Coppola, Luca Ardito, Maurizio Morisio, and Marco Torchiano. 2020. Mobile Testing: New Challenges and Perceived Difficulties from Developers of the Italian Industry.IT Professional22, 5 (2020), 32–39. doi:10.1109/MITP.2019. 2942810

    doi:10.1109/mitp.2019 2020

  4. [3]

    Google. 2012. UI/Application Exerciser Monkey. Android Developers. https: //developer.android.com/studio/test/monkey

    work page 2012

  5. [4]

    Nguyen, and Vu Nguyen

    Hieu Huynh, Hai Phung, Hung Pham, Tien N. Nguyen, and Vu Nguyen. 2025. Towards Test Generation from Task Description for Mobile Testing with Multi- Modal Reasoning. arXiv:2504.15917. doi:10.48550/arXiv.2504.15917

    arXiv doi:10.48550/arxiv.2504.15917 2025

  6. [5]

    Yuanchun Li, Ziyue Yang, Yao Guo, and Xiangqun Chen. 2017. DroidBot: A Lightweight UI-Guided Test Input Generator for Android. InProceedings of the 39th International Conference on Software Engineering Companion (ICSE-C). IEEE, Buenos Aires, Argentina, 23–26. doi:10.1109/ICSE-C.2017.8

    doi:10.1109/icse-c.2017.8 2017

  7. [6]

    Yuanchun Li, Ziyue Yang, Yao Guo, and Xiangqun Chen. 2019. Humanoid: A Deep Learning-Based Approach to Automated Black-box Android App Testing. In Proceedings of the 34th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, San Diego, CA, USA, 1070–1073. doi:10.1109/ASE.2019. 00104

    doi:10.1109/ase.2019 2019

  8. [7]

    Zhe Liu, Chunyang Chen, Junjie Wang, Xing Che, Yuekai Huang, Jun Hu, and Qing Wang. 2022. Fill in the Blank: Context-Aware Automated Text Input Gener- ation for Mobile GUI Testing. arXiv:2212.04732. doi:10.48550/arXiv.2212.04732

    arXiv doi:10.48550/arxiv.2212.04732 2022

Show all 22 references
  1. [8]

    Zhe Liu, Chunyang Chen, Junjie Wang, Mengzhuo Chen, Boyu Wu, Xing Che, Dandan Wang, and Qing Wang. 2023. Chatting with GPT-3 for Zero-Shot Human- Like Mobile Automated GUI Testing. arXiv:2305.09434. doi:10.48550/arXiv.2305. 09434

    2023 doi arXiv

  2. [9]

    Zhe Liu, Chunyang Chen, Junjie Wang, Yuekai Huang, Jun Hu, and Qing Wang

  3. [10]

    Ke Mao, Mark Harman, and Yue Jia. 2016. Sapienz: Multi-objective Automated Testing for Android Applications. InProceedings of the 25th International Sympo- sium on Software Testing and Analysis (ISSTA). ACM, New York, NY, USA, 94–105. doi:10.1145/2931037.2931054

    2016

  4. [12]

    Goucher, Adam Perelman, Aditya Ramesh, Aidan Clark, AJ Ostrow, Akila Welihinda, Alan Hayes, Alec Radford, et al

    OpenAI, Aaron Hurst, Adam Lerer, Adam P. Goucher, Adam Perelman, Aditya Ramesh, Aidan Clark, AJ Ostrow, Akila Welihinda, Alan Hayes, Alec Radford, et al. 2024. GPT-4o System Card. arXiv:2410.21276. doi:10.48550/arXiv.2410.21276

    2024 doi arXiv

  5. [13]

    Minxue Pan, An Huang, Guoxin Wang, Tian Zhang, and Xuandong Li. 2020. Reinforcement Learning Based Curiosity-Driven Testing of Android Applications. InProceedings of the 29th ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). ACM, New York, NY, USA, ...

    2020

  6. [14]

    Chao Peng, Zhengwei Lv, Jiarong Fu, Jiayuan Liang, Zhao Zhang, Ajitha Rajan, and Ping Yang. 2023. Hawkeye: Change-Targeted Testing for Android Apps Based on Deep Reinforcement Learning. arXiv:2309.01519. doi:10.48550/arXiv. 2309.01519

    2023 doi arXiv

  7. [15]

    Dezhi Ran, Zongyang Li, Chenxu Liu, Wenyu Wang, Weizhi Meng, Xionglin Wu, Hui Jin, Jing Cui, Xing Tang, and Tao Xie. 2022. Automated Visual Testing for Mobile Apps in an Industrial Setting. InProceedings of the 44th International Conference on Software Engineering: Software En...

    2022

  8. [16]

    Dezhi Ran, Hao Wang, Zihe Song, Mengzhou Wu, Yuan Cao, Ying Zhang, Wei Yang, and Tao Xie. 2024. Guardian: A Runtime Framework for LLM-Based UI Exploration. InProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). ACM, New York, NY...

    2024

  9. [17]

    Kaitao Song, Xu Tan, Tao Qin, Jianfeng Lu, and Tie-Yan Liu. 2020. MPNet: Masked and Permuted Pre-Training for Language Understanding. arXiv:2004.09297. doi:10.48550/arXiv.2004.09297

    2020 doi arXiv

  10. [18]

    Ting Su, Guozhu Meng, Yuting Chen, Ke Wu, Weiming Yang, Yao Yao, Geguang Pu, Yang Liu, and Zhendong Su. 2017. Guided, Stochastic Model-Based GUI Testing of Android Apps. InProceedings of the 11th Joint Meeting on Foundations of Software Engineering (ESEC/FSE). ACM, New York, N...

    2017

  11. [19]

    Hao Wen, Yuanchun Li, Guohong Liu, Shanhui Zhao, Tao Yu, Toby Jia-Jun Li, Shiqi Jiang, Yunhao Liu, Yaqin Zhang, and Yunxin Liu. 2024. AutoDroid: LLM-Powered Task Automation in Android. InProceedings of the 30th Annual International Conference on Mobile Computing and Networking...

    2024

  12. [20]

    Hao Wen, Hongming Wang, Jiaxuan Liu, and Yuanchun Li. 2023. DroidBot-GPT: GPT-Powered UI Automation for Android. arXiv:2304.07061. doi:10.48550/arXiv. 2304.07061

    2023 doi arXiv

  13. [21]

    Juyeon Yoon, Robert Feldt, and Shin Yoo. 2023. Autonomous Large Language Model Agents Enabling Intent-Driven Mobile GUI Testing. arXiv:2311.08649. doi:10.48550/arXiv.2311.08649 Received 2026-04-21; accepted 2026-07-01

    2023 doi arXiv

  14. [2020]

    InProceed- ings of the 35th IEEE/ACM International Conference on Automated Software Engi- neering (ASE)

    Owl Eyes: Spotting UI Display Issues via Visual Understanding. InProceed- ings of the 35th IEEE/ACM International Conference on Automated Software Engi- neering (ASE). ACM, New York, NY, USA, 398–409. doi:10.1145/3324884.3416547

Pith tools

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