AutoRestTest: A Tool for Automated REST API Testing Using LLMs and MARL

Alessandro Orso; Myeongsoo Kim; Saurabh Sinha; Tyler Stennett

REVIEW 4 major objections 4 minor 1 cited by

AutoRestTest: A Tool for Automated REST API Testing Using LLMs and MARL

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

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

Pith's one-line read AutoRestTest claims that combining a semantic dependency graph, five specialized Q-learning agents, and LLM-generated inputs covers more REST API operations in one hour than four state-of-the-art testing tools.

desk verdict A real, coherent tool with a public artifact; the headline outperformance claim is plausible but under-supported, and the OhSome gap may be an auth confound. read the letter →

arxiv 2501.08600 v2 pith:GWXE2PX7 submitted 2025-01-15 cs.SE cs.AI

Tyler Stennett , Myeongsoo Kim , Saurabh Sinha , Alessandro Orso This is my paper · ORCID

classification cs.SEcs.AI

keywords RESTAPItestingmulti-agentreinforcementlearninglargelanguagemodelssemanticpropertydependencygraphQ-learningOpenSpecificationautomatedtestgeneration

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 introduces AutoRestTest, a tool for automated REST API testing. It claims that AutoRestTest outperforms four state-of-the-art tools by integrating three mechanisms: a Semantic Property Dependency Graph, five specialized reinforcement-learning agents, and an LLM that generates realistic parameter and header values. In a one-hour evaluation on four real-world services, AutoRestTest covered 26 operations that returned 2xx responses, compared with 10 to 12 for the baselines, was the only tool to exercise the OhSome service successfully, and was the only one to detect a 5xx error on Spotify. The results are preliminary, but the claim is that combining dependency modeling, multi-agent learning, and LLM input generation is a more effective strategy than the individual approaches used by prior tools.

What carries the argument

The central object is the Semantic Property Dependency Graph (SPDG), a graph whose vertices are API operations and whose edges connect operations whose parameters, request bodies, or responses are semantically similar, measured with GloVe word embeddings above a threshold of 0.7 (or the top three matches when nothing exceeds the threshold). The dependency agent uses stored successful values to satisfy cross-operation dependencies. Five agents (operation, parameter, value, dependency, and header) each maintain Q-tables updated by Q-learning with epsilon-greedy action selection and a reward split: the operation agent is rewarded for 4xx and 5xx errors, while the other agents are rewarded for 2xx successes. The LLM supplies realistic values and headers. This machinery reduces the search space through semantic dependency edges and coordinates request-generation decisions across the five agents.

What would settle it

Run all five tools on the same four services on identical hardware and network, with the same time budget and comparable configuration effort, repeating each run several times and reporting variance; if any baseline reaches or exceeds 26 successfully processed operations, or matches AutoRestTest's 12 on OhSome when given the same LLM-based value generation, the central coverage claim fails.

Watch

Extended reading notes

Core claim

The paper's central claim is that AutoRestTest achieves substantially higher operation coverage than four existing REST API testing tools by treating operation selection, parameter selection, value generation, dependency exploitation, and header construction as five separate learning problems coordinated through a shared Q-learning framework. The paper reports 26 unique successfully processed operations across FDIC, OMDb, OhSome, and Spotify in one-hour runs, versus 12 for ARAT-RL, 11 each for EvoMaster and MoRest, and 10 for RESTler. AutoRestTest returns 2xx responses for 12 operations on OhSome, where all baselines return only 4xx, and it is the only tool to produce a 5xx server error on Spotify. The authors interpret this as evidence that the SPDG's semantic edges let the dependency agent reuse outputs of one operation as inputs to another, while the LLM supplies realistic values that make otherwise unreachable operations succeed.

Load-bearing premise

The evaluation assumes that the four baseline tools were set up and run under conditions as favorable as AutoRestTest's, so that the one-hour count of 2xx operations measures tool quality rather than setup quality.

Editorial extensions

If this is right

On the four evaluated services, AutoRestTest is the only one of the five tools that exercises OhSome operations successfully, suggesting the approach can handle services with heavy inter-operation dependencies.
The Spotify 5xx finding implies AutoRestTest can surface real server faults, not merely increase coverage counts.
Because the SPDG is built from any OAS 3.0 specification, the approach can in principle be applied to new REST APIs without per-service customization.
The Q-table outputs and cached LLM values make repeat executions cheaper and provide a record of which parameter combinations and dependencies led to success.
The reported numbers establish a new baseline for the one-hour successfully-processed-operations metric on these four services.

Reading between the lines

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

The reported gap may narrow if baseline tools receive equal LLM assistance or configuration tuning; a fair comparison would need identical hardware, network conditions, seeds, and repeated runs.
Because the operation agent is rewarded for 4xx and 5xx errors while other agents are rewarded for 2xx successes, the tool could favor operations that are easy to succeed at, so coverage count may not directly track fault-finding difficulty.
The SPDG construction depends only on semantic similarity between inputs and outputs, so the approach likely transfers to other interface description formats such as GraphQL schemas or gRPC service definitions.
An ablation removing the LLM, the SPDG, or individual agents would reveal which component drives the coverage gain; the paper does not provide such an ablation.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Desk Editor's Note

read the letter

Two things you should know. First, AutoRestTest is a real implemented tool — the paper ships a public repo and a detailed report format, and the architecture (SPDG, five reinforcement-learning agents, LLM-driven value/header generation) is coherent. Second, the headline empirical result ('26 unique operations vs 12/11/11/10') is not yet trustworthy as stated. The evaluation in Section IV is a one-hour, single-shot comparison with no run counts, no variance, and no baseline configuration details. That alone would merit a request for revision, not a rejection.

What's genuinely new: the integration of the Semantic Property Dependency Graph with multi-agent RL and LLM input generation in one tool, plus the header agent that learns to supply auth tokens from account-related operations in the spec. The header agent matters: it's a recent addition, not in the companion paper [11], and it's likely why AutoRestTest gets 2xx on OhSome while all four baselines get 0.

That last point is the soft spot that worries me. The paper never says whether OhSome's endpoints require authentication. If they do, and the baselines were run without equivalent credentials or header-generation support, the 26-vs-12 difference is an artifact of setup, not evidence that the SPDG+MARL+LLM architecture is better. The paper even calls the result 'initial, yet clear evidence' — that's overclaiming when the auth question is unaddressed. The same goes for the Spotify 5xx finding: it's a single observation, not a measured detection rate.

Other soft spots are more minor. The Q-learning details (learning rate 0.1, discount 0.9) come from the authors' own ARAT-RL paper, which is fine, but there's no sensitivity analysis. The tool supports only OAS 3.0. The report examples are helpful. The paper is honest that the detailed approach lives in [11], so it reads as a tool demo with preliminary results, not a full research paper — and that's okay.

My bottom line: this is a solid artifact paper. The architecture is sensible, the repo is public, and the empirical question is concrete and testable. The right fix is to (a) state explicitly whether OhSome requires auth, (b) provide credentials/header logic to all baselines or justify why not, and (c) add multi-run stats with mean and variance. If those are in, the 26-vs-12 claim can be evaluated fairly. I'd send it to peer review — it deserves a serious referee — but I'd push for major revision on the evaluation before accepting the outperformance claim.

Referee Report

4 major / 4 minor

Summary. The paper presents AutoRestTest, a tool for automated REST API testing that combines a Semantic Property Dependency Graph (SPDG), five specialized agents (operation, parameter, value, dependency, header), Q-learning, and LLM-based value and header generation. The authors evaluate AutoRestTest against RESTler, EvoMaster, ARAT-RL, and MoRest on four real-world services (FDIC, OMDb, OhSome, Spotify) and report that AutoRestTest successfully processed 26 unique operations versus 12, 11, 11, and 10 for the baselines, and that it was the only tool to obtain 2xx responses on OhSome and the only one to detect a 5xx error on Spotify. The paper also describes the tool's configuration options, CLI, and report generation. The reported results are described as preliminary.

Significance. If the reported results are reproducible and the differences are not due to configuration or stochastic variation, AutoRestTest would be a useful contribution to REST API testing, particularly in combining dependency modeling, multi-agent RL, and LLM-driven input generation. The artifact is publicly available, the tool addresses a practically relevant problem, and the evaluation uses four existing baseline tools and real-world services. However, the empirical evidence as presented is not yet sufficient to support the central claim of superiority: the comparison lacks run counts and variance, baseline configuration details are absent, and the OhSome result introduces a plausible authentication confound that is not addressed.

major comments (4)

[Section IV, Table I] The headline superiority claim relies heavily on the OhSome service, where AutoRestTest reports 12 successful operations and all four baselines report 0. The manuscript does not state whether OhSome's endpoints require authentication, nor whether RESTler, EvoMaster, ARAT-RL, and MoRest were provided with equivalent credentials or header-generation facilities. Since Section II-B describes a Header Agent that supplies token authentication headers and a footnote states that this agent is a recent addition not described in the companion paper, the comparison is confounded unless authentication handling is demonstrated to be equal across tools. Please report the authentication requirements of each service and the exact authentication-related configuration supplied to each baseline.
[Section IV] All effectiveness values appear to come from a single run per tool and service. No run counts, variance, confidence intervals, or statistical tests are reported. Given the use of epsilon-greedy Q-learning, random request mutation, and LLM sampling at temperature 0.7, there is substantial stochasticity in AutoRestTest; a lucky run could plausibly explain the observed differences. The paper should report at least several runs per tool and service with means and spread, and should state whether the one-hour window is wall-clock time and how LLM latency is accounted for.
[Sections II-A and II-C] The components of AutoRestTest are not validated independently. The SPDG construction depends on a similarity threshold of 0.7 and a top-three fallback; the Q-learning parameters are set to 0.1 and 0.9 based on prior work; and the LLM engine is not specified for the experiments. No ablation is provided to isolate the contribution of the SPDG, the MARL agents, the LLM, or the header agent. As a result, even if the comparison against the baselines were sound, the paper would not support the claim that the proposed architecture as a whole is responsible for the observed effectiveness. Please add an ablation or at least controlled variants that disable individual components.
[Section II-B, Footnote 1] The header agent is described only as leveraging 'account-related operations from the specification to supply basic token authentication headers,' and the footnote explicitly states that this agent is not described in the companion research paper. Because the header agent may be responsible for the OhSome successes and for the only detected Spotify 5xx error, its behavior is load-bearing for the evaluation. The paper should specify how account-related operations are identified, how tokens are obtained, and how the resulting headers are attached to requests, or it should point to a precise code location so that the evaluation is reproducible.

minor comments (4)

[Abstract and Section II-B] The abstract and introduction describe 'five specialized agents,' but Section II-B says the REST agents 'consist of four specialized components' and does not count the dependency agent in that list. Please clarify the agent count and the placement of the dependency agent in the architecture.
[Section III-A-2] The configuration section describes LLM temperature and engine selection but the experimental evaluation in Section IV does not state which LLM engine, model version, and temperature were used. This information is needed for reproducibility.
[Listing 1] The example report in Listing 1 appears to contain keys with extra spacing, such as 'T i t l e' and 'D u r a t i o n'; if the actual tool output is valid JSON, please ensure the listing reproduces it faithfully.
[References] Reference [6] is cited in the introduction as an example of reinforcement learning for REST API testing, but the text does not state its publication venue or year; please complete the bibliographic details in the citation if possible.

Circularity Check

0 steps flagged · score 2.0 of 10

No circular derivation: the paper's claims are empirical measurements against external services; the minor self-referential elements (benchmark sources, companion-paper citation) are not load-bearing.

full rationale

AutoRestTest's central claim is an observed experimental result: 26 successfully processed operations versus 12/11/11/10 for four baselines (Section IV, Table I). This is not a derivation from first principles, so there is no equation or fitted parameter whose output is, by construction, identical to its input. The Q-learning reward for other agents on 2xx responses (Section II-C.3) matches the evaluation metric of 2xx operation counts (Section IV), but that is an objective-function alignment, not a circular reduction; the tool's 2xx counts on external services (FDIC, OMDb, OhSome, Spotify) remain contingent empirical facts. The evaluation does rely on the authors' own prior work to select the services ('included in a recent study [8]') and the baseline lineup ('used in the ARAT-RL study [5]'), and the detailed method is deferred to the authors' companion paper [11]; these are self-references, but they do not carry the argument: the services are real public APIs and the baselines (RESTler, EvoMaster, MoRest, ARAT-RL) are independent implementations run for one hour. The footnote in Section II-B ('The header agent is a recent addition not described in our research paper') and the absence of baseline authentication configuration or variance data in Section IV are validity threats worth flagging, but they concern experimental fairness, not circularity of the claimed derivation. Accordingly the score reflects minor self-referential evaluation design, not a circular derivation chain.

Assumptions & free parameters 4 free parameters · 4 assumptions · 2 invented entities

The tool's results rest primarily on empirical configuration choices and unstated evaluation assumptions, not on a mathematical derivation. Listed items cover the main hand-chosen defaults and background assumptions.

free parameters (4)

SPDG edge similarity threshold = 0.7
Threshold for adding semantic dependency edges between operations; chosen in the current implementation without sensitivity analysis (Section II-A).
Q-learning learning rate = 0.1
Default learning rate for the Bellman update, cited from ARAT-RL [5]; may affect convergence and final results (Section III-A4).
Q-learning discount factor = 0.9
Default discount factor in value-decomposition Q-learning; may affect long-term reward weighting (Section III-A4).
LLM temperature = 0.7
Default temperature for LLM value and header generation, balancing diversity and determinism (Section III-A2).

assumptions (4)

domain assumption GloVe word embeddings provide semantically meaningful similarity between API parameter names, request bodies, and response fields.
The SPDG edge construction relies on this to infer operation dependencies (Section II-A).
domain assumption Q-learning with epsilon-greedy action selection converges to a useful policy for API request generation.
The agents' effectiveness depends on Q-table convergence in a large state-action space (Section II-C).
domain assumption The OpenAPI Specification is a complete and accurate description of the service under test.
The tool parses OAS to build the SPDG and guide requests; missing or inaccurate specs would limit coverage (Sections II-A, III-A1).
domain assumption OpenAI LLM APIs are available and generate realistic parameter values and headers.
The value and header agents depend on LLM outputs; costs and availability affect reproducibility (Section III-A2).

invented entities (2)

Semantic Property Dependency Graph (SPDG)
purpose: Graph representing operations as vertices and semantic similarity between operation inputs and outputs as edges, used to reduce search space and identify dependencies.
Introduced in the companion paper [11]; no external validation that the graph structure itself improves testing beyond the integrated tool.
Five REST agents (operation, parameter, value, dependency, header)
purpose: Decompose request generation into specialized decision agents trained with Q-learning.
Architectural decomposition of the tool; no isolated ablation shows each agent's independent contribution.

how reviews work

0 comments

Cite this review

Pith. "Pith review of AutoRestTest: A Tool for Automated REST API Testing Using LLMs and MARL." pith.science (2026). https://pith.science/paper/GWXE2PX7

@misc{pith2026250108600,
  author       = {Pith},
  title        = {Pith review of: AutoRestTest: A Tool for Automated REST API Testing Using LLMs and MARL},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GWXE2PX7}},
  note         = {Machine review of arXiv:2501.08600}
}

read the original abstract

As REST APIs have become widespread in modern web services, comprehensive testing of these APIs is increasingly crucial. Because of the vast search space of operations, parameters, and parameter values, along with their dependencies and constraints, current testing tools often achieve low code coverage, resulting in suboptimal fault detection. To address this limitation, we present AutoRestTest, a novel tool that integrates the Semantic Property Dependency Graph (SPDG) with Multi-Agent Reinforcement Learning (MARL) and large language models (LLMs) for effective REST API testing. AutoRestTest determines operation-dependent parameters using the SPDG and employs five specialized agents (operation, parameter, value, dependency, and header) to identify dependencies of operations and generate operation sequences, parameter combinations, and values. Through an intuitive command-line interface, users can easily configure and monitor tests with successful operation count, unique server errors detected, and time elapsed. Upon completion, AutoRestTest generates a detailed report highlighting errors detected and operations exercised. In this paper, we introduce our tool and present preliminary findings, with a demonstration video available at https://www.youtube.com/watch?v=VVus2W8rap8.

Figures

Figures reproduced from arXiv: 2501.08600 by the authors.

**Figure 1.** Overview of AutoRestTest. for generating realistic requests for each endpoint. In this section, we provide a brief overview of each component; a detailed discussion of our approach is available in our research paper [11]. A. Semantic Property Dependency Graph The SPDG is constructed by parsing the input OAS and assigning each API operation as a vertex. AutoRestTest then iterates through each pair of vertices, using … view at source ↗

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

SAINT: Service-level Integration Test Generation with Program Analysis and LLM-based Agents
cs.SE 2025-11 conditional novelty 6.0 of 10

SAINT automatically generates both endpoint-level and scenario-based REST API tests for enterprise Java apps using static analysis and LLM agents, outperforming EvoMaster on code coverage in several benchmarks.

Reference graph

Works this paper leans on

17 extracted references · 10 canonical work pages · cited by 1 Pith paper

[11]

A multi-agent approach for rest api testing with semantic graphs and llm-driven inputs,

M. Kim, T. Stennett, S. Sinha, and A. Orso, “A multi-agent approach for rest api testing with semantic graphs and llm-driven inputs,” arXiv preprint arXiv:2411.07098, 2024

arXiv 2024
[1]

Richardson, M

L. Richardson, M. Amundsen, and S. Ruby, RESTful Web APIs: Services for a Changing World . O’Reilly Media, Inc., 2013

work page 2013
[2]

Automated test generation for rest apis: No time to rest yet,

M. Kim, Q. Xin, S. Sinha, and A. Orso, “Automated test generation for rest apis: No time to rest yet,” in Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis , ser. ISSTA

work page
[3]

Restful api automated test case generation with evomaster,

A. Arcuri, “Restful api automated test case generation with evomaster,” ACM Transactions on Software Engineering and Methodology (TOSEM), vol. 28, no. 1, jan 2019

work page 2019
[4]

Morest: Model-based restful api testing with execution feedback,

Y . Liu, Y . Li, G. Deng, Y . Liu, R. Wan, R. Wu, D. Ji, S. Xu, and M. Bao, “Morest: Model-based restful api testing with execution feedback,” in Proceedings of the 44th International Conference on Software Engineering, ser. ICSE ’22. New York, NY , USA: Association for Computing Machinery, 2022, p. 1406–1417

work page 2022
[5]

Adaptive rest api testing with rein- forcement learning,

M. Kim, S. Sinha, and A. Orso, “Adaptive rest api testing with rein- forcement learning,” in 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE) . Los Alamitos, CA, USA: IEEE Computer Society, sep 2023, pp. 446–458

work page 2023
[6]

Deeprest: Automated test case generation for rest apis exploiting deep reinforcement learning,

D. Corradini, Z. Montolli, M. Pasqua, and M. Ceccato, “Deeprest: Automated test case generation for rest apis exploiting deep reinforcement learning,” 2024. [Online]. Available: https://arxiv.org/abs/ 2408.08594

arXiv 2024
[7]

Llamaresttest: Effective rest api testing with small language models,

M. Kim, S. Sinha, and A. Orso, “Llamaresttest: Effective rest api testing with small language models,” 2025. [Online]. Available: https://arxiv.org/abs/2501.08598

arXiv 2025

Show all 17 references

[8]

Enhancing rest api testing with nlp techniques,

M. Kim, D. Corradini, S. Sinha, A. Orso, M. Pasqua, R. Tzoref-Brill, and M. Ceccato, “Enhancing rest api testing with nlp techniques,” in Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis, ser. ISSTA 2023. New York, NY , USA: Associat...

2023
[9]

Leveraging large language models to improve rest api testing,

M. Kim, T. Stennett, D. Shah, S. Sinha, and A. Orso, “Leveraging large language models to improve rest api testing,” in Proceedings of the 2024 ACM/IEEE 44th International Conference on Software Engineering: New Ideas and Emerging Results , ser. ICSE-NIER’24. New York, NY , US...

2024
[10]

R. S. Sutton and A. G. Barto, Reinforcement Learning: An Introduction. Cambridge, MA, USA: A Bradford Book, 2018

2018
[12]

Glove: Global vectors for word representation,

J. Pennington, R. Socher, and C. D. Manning, “Glove: Global vectors for word representation,” in Proceedings of the 2014 conference on empirical methods in natural language processing (EMNLP) , 2014, pp. 1532–1543

2014
[13]

Value-decomposition networks for cooperative multi-agent learning,

P. Sunehag, G. Lever, A. Gruslys, W. M. Czarnecki, V . Zambaldi, M. Jaderberg, M. Lanctot, N. Sonnerat, J. Z. Leibo, K. Tuyls, and T. Graepel, “Value-decomposition networks for cooperative multi-agent learning,” arXiv preprint arXiv:1706.05296 , 2017

2017 arXiv
[14]

Restler: Stateful rest api fuzzing,

V . Atlidakis, P. Godefroid, and M. Polishchuk, “Restler: Stateful rest api fuzzing,” in Proceedings of the 41st International Conference on Software Engineering , ser. ICSE ’19. Piscataway, NJ, USA: IEEE Press, 2019, p. 748–758

2019
[15]

Testing restful apis: A survey,

A. Golmohammadi, M. Zhang, and A. Arcuri, “Testing restful apis: A survey,” ACM Trans. Softw. Eng. Methodol. , aug 2023

2023
[16]

Experiment infrastructure, data, and results for autoresttest,

SE@GT, “Experiment infrastructure, data, and results for autoresttest,” https://github.com/selab-gatech/AutoRestTest, 2024

2024
[2022]

New York, NY , USA: Association for Computing Machinery, 2022, p. 289–301

2022

Pith tools

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

[1] [11]

A multi-agent approach for rest api testing with semantic graphs and llm-driven inputs,

M. Kim, T. Stennett, S. Sinha, and A. Orso, “A multi-agent approach for rest api testing with semantic graphs and llm-driven inputs,” arXiv preprint arXiv:2411.07098, 2024

arXiv 2024

[2] [1]

Richardson, M

L. Richardson, M. Amundsen, and S. Ruby, RESTful Web APIs: Services for a Changing World . O’Reilly Media, Inc., 2013

work page 2013

[3] [2]

Automated test generation for rest apis: No time to rest yet,

M. Kim, Q. Xin, S. Sinha, and A. Orso, “Automated test generation for rest apis: No time to rest yet,” in Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis , ser. ISSTA

work page

[4] [3]

Restful api automated test case generation with evomaster,

A. Arcuri, “Restful api automated test case generation with evomaster,” ACM Transactions on Software Engineering and Methodology (TOSEM), vol. 28, no. 1, jan 2019

work page 2019

[5] [4]

Morest: Model-based restful api testing with execution feedback,

Y . Liu, Y . Li, G. Deng, Y . Liu, R. Wan, R. Wu, D. Ji, S. Xu, and M. Bao, “Morest: Model-based restful api testing with execution feedback,” in Proceedings of the 44th International Conference on Software Engineering, ser. ICSE ’22. New York, NY , USA: Association for Computing Machinery, 2022, p. 1406–1417

work page 2022

[6] [5]

Adaptive rest api testing with rein- forcement learning,

M. Kim, S. Sinha, and A. Orso, “Adaptive rest api testing with rein- forcement learning,” in 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE) . Los Alamitos, CA, USA: IEEE Computer Society, sep 2023, pp. 446–458

work page 2023

[7] [6]

Deeprest: Automated test case generation for rest apis exploiting deep reinforcement learning,

D. Corradini, Z. Montolli, M. Pasqua, and M. Ceccato, “Deeprest: Automated test case generation for rest apis exploiting deep reinforcement learning,” 2024. [Online]. Available: https://arxiv.org/abs/ 2408.08594

arXiv 2024

[8] [7]

Llamaresttest: Effective rest api testing with small language models,

M. Kim, S. Sinha, and A. Orso, “Llamaresttest: Effective rest api testing with small language models,” 2025. [Online]. Available: https://arxiv.org/abs/2501.08598

arXiv 2025