Pith. sign in

REVIEW 4 major objections 5 minor 2 cited by

System Test Case Design from Requirements Specifications: Insights and Challenges of Using ChatGPT

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

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

Pith's one-line read Using a two-stage prompt chain, ChatGPT-4o Turbo generated test case designs from five SRS documents, and the developers who wrote those documents judged 87.7% of the designs valid.

desk verdict A decent small empirical study showing ChatGPT can generate mostly valid system test cases from SRS documents, with a plausible novelty claim; the main numbers are preliminary due to the small sample and subjective ratings, but the paper is worth a serious referee. read the letter →

arxiv 2412.03693 v1 pith:TG4SAWMC submitted 2024-12-04 cs.SE cs.AI

Shreya Bhatia , Tarushi Gandhi , Dhruv Kumar , Pankaj Jalote This is my paper · ORCID
classification cs.SEcs.AI
keywords LargeLanguageModelsSystemTestingTestCaseDesignSoftwareRequirementsSpecificationPromptChainingChatGPTRedundancyDetectionGenerativeAI
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 tries to establish that a large language model can produce usable system test case designs directly from a Software Requirements Specification (SRS) document, and that it can catch cases human testers miss. Using five student-built, real-client projects and a two-stage prompt-chaining setup on ChatGPT-4o Turbo, the authors report that developer teams judged 87.7% of the generated test cases valid. 15.2% of those valid tests covered scenarios the developers had not considered during their own testing, mainly accessibility, security, and user-experience edge cases. The paper also argues that the same model can help find redundant test cases, although about 30% of its redundancy flags are false positives. If these numbers hold, LLM-assisted test design could cut the effort of going from requirements to a first test suite while improving coverage.

What carries the argument

The load-bearing mechanism is prompt chaining, a two-stage prompting technique in which the model is first asked to read and internalize the SRS, then separately prompted for each use case to generate all possible test case designs using a specification-based technique and a fixed four-column format covering condition, input, expected output, and comments. This chaining lifts output volume from an average of 3.6 test cases per use case with a single whole-SRS prompt to 10-11 per use case. To tame randomness, the authors run the prompt several times and take the cumulative union of distinct test cases until no new tests appear, effectively saturating the model's output for a given SRS. The evaluation mechanism is a five-category developer feedback scheme, classifying each generated test as valid, redundant, not implemented but valid, not applicable, or missed, and it converts the raw generated designs into the reported percentages.

What would settle it

Show a sample of the ChatGPT-generated test case designs to a fresh team of testers who only see the SRS, and compare their valid and redundant labels with the original developers' labels; if agreement is low or the independent valid rate falls well below 87.7%, the reported quality is a property of the judging team, not of the generated tests.

Watch

Extended reading notes

Core claim

The paper's central claim is that a two-stage prompt-chaining approach, first familiarizing ChatGPT-4o Turbo with the full SRS and then prompting it once per use case to generate test case designs in a four-column tabular format, produces a high-quality system test suite from requirements alone. Across five projects, roughly 87.7% of the generated designs were classified as valid by the same developers who authored the SRS and delivered the software: 72.5% valid and implemented and 15.2% valid but not previously considered. The remaining cases split into 9.7% not applicable, 2.6% redundant, and a small number of missed tests, averaging 2-3 per SRS. For redundancy detection, ChatGPT's flags overlapped with developers' in 47.19% of cases, added another 22.65% that developers later accepted as redundant, and produced 30.16% false positives. The authors' conclusion is that LLMs are not yet a standalone replacement for testers but can assist developers in generating and pruning test suites.

Load-bearing premise

The whole study rests on the assumption that the developers' own ratings are an unbiased ground truth for whether a test case is valid, redundant, or missed, even though they are the same people who wrote the requirements and built the system.

Editorial extensions

If this is right

  • For a new project with a use-case-structured SRS, a developer could obtain a first-draft system test suite in hours rather than days, then spend effort reviewing instead of authoring test cases.
  • The roughly 15% of valid tests that developers had not considered marks a concrete coverage gain, concentrated in accessibility, security, and user-experience edge cases.
  • LLM-generated suites still need human pruning: initial generations contained about 2.6% redundant tests, and targeted redundancy prompts, while helpful, carry a 30% false-positive rate that would hurt the suite if applied automatically.
  • Prompt chaining is the practical takeaway: feeding the whole SRS in one prompt yields far fewer tests than first familiarizing the model and then requesting tests use case by use case.
  • The model misses only a handful of test conditions per SRS, averaging 2-3 missed tests, suggesting that a developer's review of LLM output can be short and targeted.

Reading between the lines

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

  • A natural next experiment is to give the same SRSs to independent testers who did not write the requirements and compare their validity labels with the original developers'; without such a check, the 87.7% figure mixes model quality with the judging team's perspective.
  • The 15% yield of previously unconsidered tests is the economically strongest result: even if absolute validity varies across organizations, surfacing edge cases in accessibility and security is where an LLM assistant adds value beyond saving keystrokes.
  • Feeding the architecture design document alongside the SRS, as the authors suggest, could attack both the 9.7% not-applicable rate and the cross-use-case redundancy problem, because the model currently lacks system-level context needed to see that the same steps serve two actors.
  • The 30% false-positive redundancy rate implies a safe workflow: treat LLM redundancy flags as a triage list for human confirmation, never as automatic deletions.
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.

Referee Report

4 major / 5 minor

Summary. The paper reports an empirical study in which ChatGPT-4o Turbo is prompted, via a two-stage prompt-chaining approach, to generate system-level test case designs from the Software Requirements Specification (SRS) documents of five student software engineering projects. The generated test cases were classified by the projects' own developer teams into five categories: valid and implemented, not implemented but valid, not applicable, redundant, and missed. The headline results are that 87.7% of generated test cases were valid (72.5% valid and implemented plus 15.2% not implemented but valid), that 15.2% of valid tests were previously not considered by developers, and that ChatGPT can assist in identifying redundant test cases, although with a 30.16% false-positive rate. The paper also compares a single-prompt approach with a prompt-chaining approach and argues that prompt chaining yields more test cases per use case. The authors conclude that LLMs can assist but not replace human testers.

Significance. If the results hold, the study provides useful evidence that LLMs can generate a substantial fraction of valid system test designs directly from SRS documents and can surface test conditions that developers miss, while also quantifying current limitations in redundancy detection. The study has clear strengths: it uses real SRS documents from projects that were actually implemented and delivered, it obtains feedback from the developers who know the systems, it uses a reproducible prompt-chaining protocol with a saturation-based stopping rule, and it attempts to separate validity, redundancy, and missed tests. These design choices make the study more credible than a purely synthetic benchmark. However, the central quantitative claims currently depend on an ambiguous and possibly inconsistent classification of 'not implemented but valid' tests, on subjective single-source developer ratings with no reported agreement, and on aggregate percentages without raw counts. The contribution is therefore real but needs substantial clarification and re-reporting before the claims can be accepted as stated.

major comments (4)
  1. [Section 2.4, Section 3, Table 4] The definition of category (3), 'Not implemented but Valid,' is internally inconsistent with the definition of a valid test case and with category (4), 'Not Applicable.' Section 2.4 says these are 'test cases that were not implemented in the actual project but are valid and non-redundant.' In Section 3 and Table 4, these tests are added to the 72.5% share of 'valid and implemented' tests to obtain the headline 87.7% valid rate, and RQ2 treats the 15.2% share as the main novelty claim of tests 'previously not considered' by developers. If 'not implemented in the actual project' means the functionality under test is absent from the delivered system, then the test cannot be executed and cannot verify any behavior, so it should be classified as 'Not Applicable' rather than 'Valid.' Under that reading, the valid rate drops to about 72.5% and the 15.2% novelty contribution disappears. The examples given in RQ2 (screen reader compatibility, voice-to-text support, multi-factor authentication) are consistent with unimplemented features in student projects, which reinforces this concern. If the authors instead mean 'not implemented in the developers' test suite but executable against the delivered system,' the text must say so explicitly and provide evidence that the tests are executable and that the features are present. As written, the classification is ambiguous and the central quantitative claim depends on the reading chosen.
  2. [Section 2.4, Table 4] All validity and redundancy labels come from the same developer teams who authored the SRS and implemented the systems, but the paper reports no information about the rating procedure: how many developers rated each project, whether ratings were independent, whether any test case was double-coded, or what inter-rater agreement was. Since every percentage in Table 4 and in the RQ3 redundancy analysis is derived from these subjective labels, the absence of any reliability evidence is a load-bearing gap. The paper should either report inter-rater agreement and a clear coding protocol, or justify and explicitly discuss the limitations of a single-rater, non-independent design.
  3. [Table 4, Section 3 (RQ3)] The paper reports percentages and small averages without giving the raw counts that would let a reader assess the claims. Table 4 gives per-SRS percentages for the four categories and a count of missed tests per SRS, but it never states the total number of generated test cases per project, so the percentages cannot be converted to counts. Similarly, RQ3 reports that 47.19% of ChatGPT-flagged redundancies overlapped with developer flags, 22.65% were new, and 30.16% were false positives, but it gives no raw counts for ChatGPT-flagged, developer-flagged, overlapping, new, or false-positive sets. Without these counts, the reader cannot determine whether the aggregate percentages are stable or whether a single project dominates the result. Please include a data table with raw counts and denominators for all reported percentages.
  4. [Section 3 (RQ3)] The redundancy comparison is under-specified. It is not clear whether redundancy was judged with respect to the full set of ChatGPT-generated tests, the developers' original test suite, or both, nor is it defined how the 'overlap' between ChatGPT-flagged and developer-flagged redundancies was computed. The three reported percentages (47.19%, 22.65%, 30.16%) sum to 100% of ChatGPT-flagged redundancies, but the text also reports that 8.3% of developer-flagged tests were redundant; the relationship between these two sets is not explained. A confusion-matrix-style breakdown (true positives, false positives, false negatives, true negatives, with raw counts) is needed to make the RQ3 findings interpretable and reproducible.
minor comments (5)
  1. [Section 3, Table 4] The text states that missed tests were 'rare, only 2-3 per SRS,' but Table 4 reports 7 missed tests for the Medical Leave Portal. This inconsistency should be corrected, and the outlier should be discussed or explained.
  2. [Section 2.2, Table 2] The claim that prompt chaining 'generates better test-case designs' is not supported by the reported comparison, which only measures the average number of generated test cases and not their quality, validity, or comprehensiveness. The wording should be limited to what the data show, or a quality comparison should be added.
  3. [Section 2.3] The model is referred to as 'ChatGPT-4o Turbo' in the abstract and introduction but as 'GPT-4 Turbo' in Section 2.3. Please use a single, consistent model name, and report the exact model version and configuration used.
  4. [Section 5] The sentence beginning 'One limitation of the generated test cases is the presence of redundant test conditions. Perhaps more targeted prompting may be able to reduce these. [6, 8, 12, 30, 31]; Additionally, ...' is malformed: the citation appears mid-sentence and the semicolon after the bracket is incorrect. This passage should be rewritten.
  5. [General] There are several typographical issues, including 'by by' in Section 1 and 'Aditonally' in Section 2.3. The reference list also contains a duplicate entry (references [23] and [24] are the same paper) and placeholder conference/DOI fields. These should be cleaned up before publication.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the study is an empirical evaluation in which LLM-generated test cases are judged against external developer feedback, with no fitted parameter, predicted quantity, or load-bearing self-citation.

full rationale

The paper contains no derivation chain that reduces to its inputs. Its central claims are empirical percentages: ChatGPT generated test cases from SRS documents, and the same developer teams who authored and implemented the SRS classified those test cases as valid, redundant, not applicable, or not implemented but valid. There is no parameter fitting, no regression, no model trained on the evaluation labels, and no quantity that is predicted from a fitted value. The 87.7% valid figure is a direct tabulation of developer-provided categories, and the 15.2% 'not implemented but valid' figure is likewise a count of a category defined in Section 2.4. The only self-citations, such as reference [4] on unit test generation, appear in related work and are not load-bearing for the experimental results. The fact that the raters are the same developers who wrote the SRS is a potential validity concern about subjectivity, but it is not circularity: the evaluation target is external human judgment, not a quantity derived from the LLM's own output by construction. A reviewer might question whether 'Not implemented but Valid' test cases should count toward the 'valid' total, since they cannot be executed against the delivered system, but that is an internal-consistency issue in the evaluation metric, not a circular-reasoning issue. No step exhibits self-definitional reduction, fitted-input-as-prediction, imported uniqueness, or ansatz-smuggling via citation. Therefore the appropriate circularity score is 0.

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

This empirical study makes no mathematical derivation and fits no numerical constants. Its conclusions rest on the dataset and the developer judgments, which are captured as domain assumptions below. No invented entities are introduced.

assumptions (4)
  • domain assumption Developer feedback is a reliable and unbiased ground truth for test case validity and redundancy.
    The evaluation in Section 2.4 uses the same developer teams who wrote the SRS to classify each test case, without independent raters or agreement metrics.
  • domain assumption The five student SRS documents are representative of software requirements in general.
    The authors acknowledge in Section 5 that the dataset is small and may not generalize, yet use it to draw conclusions about LLM effectiveness.
  • domain assumption The union-until-saturation procedure fully captures the set of test cases the LLM can generate for a given SRS.
    Section 2.3 assumes that stopping when the union stops growing yields a complete set, but the number of attempts needed is not reported and earlier runs showed variance (e.g., 5 vs 7 distinct tests).
  • domain assumption The SRS documents used for generation match the final implemented systems.
    The paper reports in Section 3 that some tests were 'not applicable' due to 'changes in system requirements', indicating that the SRS and the delivered system diverged for at least some projects.

how reviews work

0 comments
Cite this review

Pith. "Pith review of System Test Case Design from Requirements Specifications: Insights and Challenges of Using ChatGPT." pith.science (2026). https://pith.science/paper/TG4SAWMC

@misc{pith2026241203693,
  author       = {Pith},
  title        = {Pith review of: System Test Case Design from Requirements Specifications: Insights and Challenges of Using ChatGPT},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/TG4SAWMC}},
  note         = {Machine review of arXiv:2412.03693}
}
read the original abstract

System testing is essential in any software development project to ensure that the final products meet the requirements. Creating comprehensive test cases for system testing from requirements is often challenging and time-consuming. This paper explores the effectiveness of using Large Language Models (LLMs) to generate test case designs from Software Requirements Specification (SRS) documents. In this study, we collected the SRS documents of five software engineering projects containing functional and non-functional requirements, which were implemented, tested, and delivered by respective developer teams. For generating test case designs, we used ChatGPT-4o Turbo model. We employed prompt-chaining, starting with an initial context-setting prompt, followed by prompts to generate test cases for each use case. We assessed the quality of the generated test case designs through feedback from the same developer teams as mentioned above. Our experiments show that about 87 percent of the generated test cases were valid, with the remaining 13 percent either not applicable or redundant. Notably, 15 percent of the valid test cases were previously not considered by developers in their testing. We also tasked ChatGPT with identifying redundant test cases, which were subsequently validated by the respective developers to identify false positives and to uncover any redundant test cases that may have been missed by the developers themselves. This study highlights the potential of leveraging LLMs for test generation from the Requirements Specification document and also for assisting developers in quickly identifying and addressing redundancies, ultimately improving test suite quality and efficiency of the testing procedure.

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

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

  1. Uncovering Business Logic Bugs via Semantics-Driven Unit Test Generation

    cs.SE 2026-04 conditional novelty 7.0 of 10

    SeGa extracts business semantics from requirements to generate unit tests that detect 22-25 more real-world business logic bugs than prior LLM-based methods in industrial Go projects.

  2. LLMCFG-TGen: Using LLM-Generated Control Flow Graphs to Automatically Create Test Cases from Use Cases

    cs.SE 2025-12 conditional novelty 6.0 of 10

    An LLM-generated control-flow graph intermediate representation improves completeness and reduces redundancy in test cases generated from natural-language use cases.

Reference graph

Works this paper leans on

33 extracted references · 16 canonical work pages · cited by 2 Pith papers

  1. [1]

    [n. d.]. Model-based test case generation and prioritiz ation: a systematic literature review | Software and Systems Modeli ng. https://link.springer.com/article/10.1007/s10270-021-00924-8

    work page doi:10.1007/s10270-021-00924-8

  2. [2]

    IEEE Standard for Software and System Test Documen tation - Redline

    2008. IEEE Standard for Software and System Test Documen tation - Redline. IEEE Std 829-2008 (Revision of IEEE Std 829-1998) - Redline (2008), 1–161

    work page 2008

  3. [3]

    Waleed Abdeen, Xingru Chen, and Michael Unterkalmstein er. 2023. An approach for performance requirements verification and tes t environ- ments generation. Requirements Eng 28, 1 (March 2023), 117–144. https://doi.org/10.1007/s00766-022-00379-3

    work page doi:10.1007/s00766-022-00379-3 2023

  4. [4]

    Shreya Bhatia, Dhruv Kumar, Tarushi Gandhi, and Pankaj J alote. 2024. Unit Test Generation using Generative AI : A Comparative Perform ance Analysis of Autogeneration Tools. (2024)

    work page 2024

  5. [5]

    Tom B. Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah , Jared Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Giri sh Sastry, Amanda Askell, Sandhini Agarwal, Ariel Herbert-Voss, Gretchen Krueger, Tom Henighan, Rewon Child, Aditya Ramesh, Daniel M. Ziegler, Jeffrey Wu, Cl emens Winter, Christopher Hesse, Mark Chen, Eric Sigler, Mateusz Litw...

    work page 2020

  6. [6]

    Banghao Chen, Zhaofeng Zhang, Nicolas Langrené, and She ngxin Zhu. 2024. Unleashing the potential of prompt engineering: a comprehe nsive review. https://doi.org/10.48550/arXiv.2310.14735 arXiv:2310 .14735 [cs]

    arXiv doi:10.48550/arxiv.2310.14735 2024

  7. [7]

    Dias-Neto and Guilherme H

    Arilo C. Dias-Neto and Guilherme H. Travassos. 2010. A Pi cture from the Model- Based Testing Area: Concepts, Techniques, and Challenges. In Advances in Computers, Marvin V. Zelkowitz (Ed.). Advances in Computers, Vol. 80. Elsevier, 45–120. https://doi.org/10.1016/S0065-2458(10)80002- 6

    work page doi:10.1016/s0065-2458(10)80002- 2010

  8. [8]

    Jindong Gu, Zhen Han, Shuo Chen, Ahmad Beirami, Bailan He , Gengyuan Zhang, Ruotong Liao, Yao Qin, Volker Tresp, and Philip Torr. 2023. A Sys- tematic Survey of Prompt Engineering on Vision-Language Fo undation Models. http://arxiv.org/abs/2307.12980 arXiv:2307.12980 [cs]

    arXiv 2023

Show all 33 references
  1. [9]

    Vitor Guilherme and Auri Vincenzi. 2023. An initial inve stigation of Chat- GPT unit test generation capability. In Proceedings of the 8th Brazilian Symposium on Systematic and Automated Software Testing (<conf-loc>, <city>Campo Grande, MS</city>, <country>Brazil</countr y>, <...

    2023

  2. [10]

    Khalid El Haji, Carolin Brandt, and Andy Zaidman. 2024. Using GitHub Copi- lot for Test Generation in Python: An Empirical Study. In 2024 IEEE/ACM International Conference on Automation of Software Test (AST) . 45–55

    2024

  3. [11]

    Pankaj Jalote. 1997. Software Requirements Analysis and Specification. Springer New York, New York, NY, 73–158. https://doi.org/10.1007/9 78-1-4684-9312-2_3

    1997 doi

  4. [12]

    Aobo Kong, Shiwan Zhao, Hao Chen, Qicheng Li, Yong Qin, Ruiqi Sun, Xin Zhou, Enzhi Wang, and Xiaohang Dong. 2024. Better Zero-Shot Reaso ning with Role- Play Prompting. In Proceedings of the 2024 Conference of the North American Chapter of the Association for Computational Lin...

    2024

  5. [13]

    Mohammed Lafi, Thamer Alrawashed, and Ahmad Munir Hamma d. 2021. Automated Test Cases Generation From Requirements Specific ation. In 2021 International Conference on Information Technology (ICIT) . 852–857. https://doi.org/10.1109/ICIT52682.2021.9491761

    2021

  6. [14]

    Feng Lin, Dong Jae Kim, Tse-Husn, and Chen. 2024. When LL M- based Code Generation Meets the Software Development Proce ss. https://doi.org/10.48550/arXiv.2403.15852 arXiv:2403 .15852 [cs]

    2024 doi arXiv

  7. [15]

    Quang Hung Luu, Huai Liu, and Tsong Yueh Chen. 2023. Can ChatGPT advance software testing intelligence? An experie nce report on metamorphic testing. ArXiv abs/2310.19204 (2023). https://api.semanticscholar.org/CorpusID:264828837

    2023 arXiv

  8. [16]

    Ggaliwango Marvin, Nakayiza Hellen, Daudi Jjingo, and Joyce Nakatumba- Nabende. 2024. Prompt Engineering in Large Language Models . In Data Intelligence and Cognitive Informatics, I. Jeena Jacob, Selwyn Piramuthu, and Przemyslaw Falkowski-Gilski (Eds.). Springer Nature Singapo...

    2024

  9. [17]

    Alok Mathur, Shreyaan Pradhan, Prasoon Soni, Dhruvil P atel, and Ra- jeshkannan Regunathan. 2023. Automated Test Case Generati on Us- ing T5 and GPT-3. In 2023 9th International Conference on Advanced Computing and Communication Systems (ICACCS), Vol. 1. 1986–1992. https://doi...

    2023

  10. [18]

    Gerard O’Regan. 2019. Test Case Analysis and Design. Springer International Publishing, Cham, 117–132. https://doi.org/10.1007/978 -3-030-28494-7_6 System Test Case Design from Requirements Specifications: I nsights and Challenges of Using ChatGPT Conference’17, July 2 017, Wa...

    2019 doi

  11. [19]

    Long Ouyang, Jeffrey Wu, Xu Jiang, Diogo Almeida, Carrol l Wainwright, Pamela Mishkin, Chong Zhang, Sandhini Agarwal, Katarina Sl ama, Alex Ray, John Schulman, Jacob Hilton, Fraser Kelton, Luke Mille r, Mad- die Simens, Amanda Askell, Peter Welinder, Paul F Christian o, Jan Lei...

    2022

  12. [20]

    Lilly Raamesh and G V Uma. 2010. Reliable Mining of Autom atically Generated Test Cases from Software Requirements Specification (SRS). 7, 1 (2010)

    2010

  13. [21]

    Tajmilur Rahman and Yuecai Zhu. 2024. Automated User St ory Gen- eration with Test Case Specification Using Large Language Mo del. https://doi.org/10.48550/arXiv.2404.01558 arXiv:2404 .01558 [cs]

    2024 doi arXiv

  14. [22]

    Arkadii Sapozhnikov, Mitchell Olsthoorn, Annibale Pa nichella, Vladimir Ko- valenko, and Pouria Derakhshanfar. 2024. TestSpark: Intel liJ IDEA’s Ulti- mate Test Generation Companion. In Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering: Com...

    2024

  15. [24]

    Max Schäfer, Sarah Nadi, Aryaz Eghbali, and Frank Tip. 2 024. An Empiri- cal Evaluation of Using Large Language Models for Automated Unit Test Gen- eration. IEEE Transactions on Software Engineering 50, 1 (2024), 85–105. https://doi.org/10.1109/TSE.2023.3334955

    2024

  16. [25]

    Yogesh Singh. 2011. Creating Test Cases from Requirements and Use Cases. Cambridge University Press, 285–334

    2011

  17. [26]

    Santosh Swain, Durga Mohapatra, and Rajib Mall. 2010. T est Case Generation Based on Use case and Sequence Diagram. International Journal of Software Engineering 3 (Jan. 2010)

    2010

  18. [27]

    Rizwan Beg

    Ravi Prakash Verma and Md. Rizwan Beg. 2013. Generation of Test Cases from Software Requirements Using Natural Language Process ing. In 2013 6th International Conference on Emerging Trends in Engineering and Technology . 140–147. https://doi.org/10.1109/ICETET.2013.45

    2013 doi

  19. [28]

    Chunhui Wang, Fabrizio Pastore, Arda Goknil, and Lione l C. Briand. 2020. Au- tomatic Generation of Acceptance Test Cases from Use Case Sp ecifications: an NLP-based Approach. http://arxiv.org/abs/1907.08490 ar Xiv:1907.08490 [cs]

    2020 arXiv

  20. [29]

    Junjie Wang, Yuchao Huang, Chunyang Chen, Zhe Liu, Song Wang, and Qing Wang. 2024. Software Testing With Large Language Model s: Survey, Landscape, and Vision. IEEE Trans. Softw. Eng. 50, 4 (Feb. 2024), 911–936. https://doi.org/10.1109/TSE.2024.3368208

    2024

  21. [30]

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma , brian ichter, Fei Xia, Ed Chi, Quoc V Le, and Denny Zhou. 2022. Chain-of-Tho ught Prompting Elicits Reasoning in Large Language Models. In Advances in Neural Information Processing Systems, S. Koyejo, S. Mohamed, A. Agar...

    2022

  22. [31]

    Jules White, Sam Hays, Quchen Fu, Jesse Spencer-Smith, and Dou- glas C. Schmidt. 2023. ChatGPT Prompt Patterns for Improvin g Code Quality, Refactoring, Requirements Elicitation, and Soft ware Design. https://doi.org/10.48550/arXiv.2303.07839 arXiv:2303 .07839 [cs]

    2023 doi arXiv

  23. [32]

    Shengcheng Yu, Chunrong Fang, Yuchen Ling, Chentian Wu , and Zhenyu Chen

  24. [33]

    frog.jpg

    Man Zhang, Tao Yue, Shaukat Ali, Huihui Zhang, and Ji Wu. 2014. A Systematic Approach to Automatically Derive Test Cases fr om Use Cases Specified in Restricted Natural Languages. In System Analysis and Modeling: Models and Reusability, Daniel Amyot, Pau Fonseca i Casas, and Gu...

    2014 arXiv

  25. [2023]

    In 23rd IEEE International Conference on Software Quality, Reliability, and Security, QRS 2023, Chiang Mai, Thailand, October 22-26, 2023

    LLM for Test Script Generation and Migration: Challen ges, Capabilities, and Opportunities. In 23rd IEEE International Conference on Software Quality, Reliability, and Security, QRS 2023, Chiang Mai, Thailand, October 22-26, 2023 . IEEE, 206–217. https://doi.org/10.1109/QRS609...

    2023

Pith tools

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