Software test document generation method based on large model and placeholder and related equipment

Abstract

The application discloses a software test document generation method based on a large model and a placeholder and related equipment, which pre-processes and converts software requirement documents into pure text, extracts full-amount structured elements based on a placeholder rule base and performs term standardization mapping, uses a large language model constrained by test field data to generate requirement elements in parallel, combines the test generation input set after verification to generate a test item set, blocks and disassembles the test item set according to test types, business modules and requirement entries, and performs consistency, coverage and standardization verification, and fills the test content block that passes the verification into a preset template, thereby solving the problems of low efficiency and easy errors in manual preparation and static template generation, lack of intelligent content creation in automatic tools and difficulty in automatically generating test content according to complex standards, and missing placeholder management leading to scattered and non-uniform data sources, improving the automation degree and intelligent level of software test document generation, and improving the document standardization degree and generation efficiency.

Description

Technical Field

[0001] This invention relates to the fields of text generation and artificial intelligence technology, and in particular to a method and related equipment for generating software test documents based on large models and placeholders. Background Technology

[0002] Currently, the generation of software test documentation mainly relies on the following two methods: First, there's the difference between manual compilation and static template generation. Most companies still rely on manual compilation or semi-automatic filling using fixed templates when writing test outlines, test cases, and test reports. This method is inefficient, error-prone, and cannot quickly respond to changes in software requirements. It also makes it difficult to meet the stringent testing standards such as GJB141 and GB / T25000.

[0003] Secondly, there is the application of some automation tools. Some automation tools have emerged in the market, which use rule engines or template engines to automatically fill in documents to a certain extent. However, these tools are mostly limited to static rules and fixed formats, lack intelligent content creation, and have an insufficient degree of automation. They cannot intelligently extract key requirements from unstructured data, nor can they automatically generate test items, test cases, and other content based on complex industry standards and dynamic requirements.

[0004] Furthermore, existing technologies often neglect the systematic management of placeholders, resulting in fragmented and inconsistent data sources during document generation, which in turn affects the standardization and integrity of documents.

[0005] In summary, existing technologies for generating software test documentation suffer from low efficiency, insufficient intelligence, and a lack of placeholder management. Therefore, there is an urgent need to provide a technical solution to address these issues. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides a method and related equipment for generating software test documents based on large models and placeholders.

[0007] Firstly, this invention provides a method for generating software test documents based on large models and placeholders. The technical solution of this method is as follows: The obtained software requirements document is preprocessed to extract the text content, and the text content is converted into plain text format to obtain the text to be parsed; Based on a preset placeholder rule base, all structured elements are extracted from the text to be parsed, and terminology standardization mapping is performed on the all structured elements to obtain a standardized element set. The standardized element set is input into a large language model constrained by test domain data, and the requirement elements are generated in parallel through the large language model. Perform consistency and standardization checks on the required elements, and combine the checked required elements with the test item method elements and test case writing idea elements in the full set of structured elements to form a test generation input set; The test-generated input set is input into the large language model, and the large language model generates a set of test items. The test item set is divided into blocks according to test type, business module, and requirement item. The decomposed test content blocks are subjected to requirement consistency verification, coverage verification, and standardization verification. The verified test content blocks are filled into a pre-set software test document template to generate software test documents.

[0008] The beneficial effects of the software test document generation method based on large models and placeholders of the present invention are as follows: The method of this invention preprocesses the software requirements document and converts it into plain text. It extracts all structured elements based on a placeholder rule base and performs terminology standardization mapping. It uses a large language model constrained by test domain data to generate requirement elements in parallel. After verification, these elements are combined into a test generation input set to generate a test item set. The test items are then broken down into blocks according to test type, business module, and requirement item, and consistency, coverage, and standardization checks are performed. The verified test content blocks are filled into a preset template. This method solves the problems of low efficiency and error-proneness of manual compilation and static template generation, lack of intelligent content creation in automated tools and difficulty in automatically generating test content according to complex standards, and scattered and inconsistent data sources due to the lack of placeholder management. It improves the automation and intelligence level of software test document generation, and enhances the standardization and generation efficiency of the documents.

[0009] Based on the above scheme, the software test document generation method based on large models and placeholders of the present invention can be further improved as follows.

[0010] In one alternative approach, the steps of preprocessing the acquired software requirements document, extracting text content, and converting the text content into plain text format to obtain the text to be parsed include: Identify the input format of the software requirements document; When the software requirements document is a scanned copy, optical character recognition is performed on the software requirements document. The text content of the software requirements document after optical character recognition is extracted, and the text content is converted into plain text format to obtain the text to be parsed.

[0011] The advantages of adopting the above optional methods are: further identifying the input format of software requirement documents, performing optical character recognition on scanned documents and extracting text content to convert it into plain text, expanding document preprocessing methods, enabling non-electronic documents to obtain structured parsing capabilities, and improving the compatibility range of document sources.

[0012] In one alternative approach, the step of extracting all structured elements from the text to be parsed based on a preset placeholder rule base includes: Using the preset placeholder rule library, test type technical requirements, role prompts, test type, test item methods, and test case writing ideas are obtained from the text to be parsed, resulting in the full set of structured elements. The preset placeholder rule library includes placeholders for basic information, date and time, content creation, data statistics, program logic, and graphics / images.

[0013] The advantages of adopting the above optional approach are: further utilizing the placeholder rule base to extract test type technical requirements, role prompts, test types, test item methods, and test case writing ideas from the text to be parsed, and relying on multiple types of placeholders to achieve element classification and collection, providing a complete data foundation for subsequent terminology mapping.

[0014] In one alternative approach, the step of performing terminology normalization mapping on the full set of structured features to obtain a normalized feature set includes: The non-standardized terms in the full set of structured elements are uniformly mapped to preset test domain standard terms. The mapped full set of structured elements is then deduplicated and completed to obtain the standardized element set.

[0015] The beneficial effects of adopting the above optional method are: to further map the non-standardized terms in the full set of structured elements into standard terms in the test domain, and to perform deduplication and completion on the mapping results, thereby eliminating terminological ambiguity and data redundancy, so that the standardized element set can meet the input requirements of the parallel generation of large language model elements.

[0016] In one alternative approach, the step of generating requirement elements in parallel using the large language model includes: The standardized element set is input into the large language model constrained by the test domain data, and the large language model generates requirement names, requirement descriptions, and test type labels corresponding to the requirement names in parallel. The requirement names follow a unified naming convention that combines test objects, test scenarios, and test types, and the requirement descriptions cover normal scenarios, boundary scenarios, and abnormal scenarios.

[0017] The advantages of adopting the above optional approach are as follows: the standardized element set is further input into the large language model constrained by the test domain data, and the requirement names that follow the unified naming convention and the requirement descriptions that cover normal, boundary and abnormal scenarios are generated in parallel. Test type labels are output synchronously, so that the requirement elements meet the test generation requirements in terms of standardization and scenario coverage.

[0018] In one alternative approach, the step of combining the validated requirement elements with the test item method elements and test case writing idea elements from the full set of structured elements to form a test generation input set includes: Perform consistency and standardization checks on the requirement elements, check whether the terminology, format and logical consistency of the requirement elements conform to the preset check rules, correct requirement elements that do not conform to the preset check rules, and combine the requirement elements that pass the checks with the test item method elements and the test case writing idea elements in the full set of structured elements to form the test generation input set.

[0019] The advantages of adopting the above optional methods are as follows: further perform consistency and standardization checks on the requirement elements, verify whether the terminology, format and logical consistency conform to the preset rules, correct requirement elements that do not conform to the rules, and combine the requirement elements that have passed the checks with the test item method elements and test case writing idea elements into a test generation input set to ensure the quality of input data.

[0020] In one alternative approach, the steps of filling the validated test content blocks into a pre-set software test document template to generate the software test document include: Load the pre-set software test document template, which contains pre-set placeholder markers; The verified test content block is matched and replaced with the placeholder mark in the software test document template to generate a first draft of the software test document; The initial draft of the software test document is scanned for placeholders to determine information completeness. For the initial draft of the software test document with incomplete information, the information gap type is marked. The initial draft of the software test document is then filled in according to the marked information gap type. The initial draft of the software test document with the filled information is then output as the software test document.

[0021] The beneficial effects of adopting the above optional method are as follows: further loading the preset software test document template, matching and replacing the verified test content blocks with the placeholder marks in the template to generate a draft, performing placeholder scanning on the draft to determine the information completeness, marking the information gap type and performing completion, so that the final output software test document meets the delivery standards.

[0022] Secondly, this invention provides a software test document generation system based on large models and placeholders. The technical solution of this system is as follows: The processing module is used to preprocess the acquired software requirements document, extract the text content, and convert the text content into plain text format to obtain the text to be parsed. The mapping module is used to extract all structured elements from the text to be parsed based on a preset placeholder rule library, and to perform terminology standardization mapping on the all structured elements to obtain a standardized element set. The parallel module is used to input the standardized element set into a large language model constrained by the test domain data, and generate the requirement elements in parallel through the large language model; The verification module is used to perform consistency and standardization verification on the requirement elements, and combine the verification-passed requirement elements with the test item method elements and test case writing idea elements in the full set of structured elements to form a test generation input set; The generation module is used to input the test generation input set into the large language model and generate a test item set through the large language model; The output module is used to break down the test item set into blocks according to test type, business module and requirement item, perform requirement consistency verification, coverage verification and standardization verification on the decomposed test content blocks, and fill the verified test content blocks into a pre-set software test document template to generate software test documents.

[0023] The beneficial effects of the software test document generation system based on large models and placeholders of the present invention are as follows: The system of this invention preprocesses software requirement documents and converts them into plain text. It extracts all structured elements based on a placeholder rule base and performs terminology standardization mapping. It generates requirement elements in parallel using a large language model constrained by test domain data. After verification, these elements are combined into a test generation input set to generate a set of test items. The system is then broken down into blocks according to test type, business module, and requirement item, and consistency, coverage, and standardization checks are performed. The verified test content blocks are filled into a preset template. This system solves the problems of low efficiency and error-proneness of manual compilation and static template generation, lack of intelligent content creation in automated tools and difficulty in automatically generating test content according to complex standards, and scattered and inconsistent data sources due to the lack of placeholder management. It improves the automation and intelligence level of software test document generation, and enhances the standardization and generation efficiency of the documents.

[0024] Thirdly, the technical solution of an electronic device according to the present invention is as follows: It includes a memory, a processor, and a program stored in the memory and running on the processor, wherein the processor executes the program to implement the steps of the software test document generation method based on large models and placeholders as described in this invention.

[0025] Fourthly, the technical solution of a computer-readable storage medium provided by the present invention is as follows: The computer-readable storage medium stores instructions that, when read, cause the computer-readable storage medium to perform the steps of the software test document generation method based on large models and placeholders of the present invention.

[0026] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0027] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a flowchart illustrating an embodiment of a software test document generation method based on a large model and placeholders according to the present invention. Figure 2 This is a diagram illustrating the five-step document generation process. Figure 3 A schematic diagram of the three-process template adaptation mechanism; Figure 4 This is a schematic diagram of the overall framework structure; Figure 5 This is a schematic diagram of the case process; Figure 6 This is a schematic diagram of the S103 structural framework in the case process; Figure 7 This is a schematic diagram of the S103 algorithm flow in the case study process; Figure 8 This is a schematic diagram of an embodiment of a software test document generation system based on a large model and placeholders according to the present invention. Figure 9 This is a schematic diagram of an embodiment of an electronic device according to the present invention. Detailed Implementation

[0028] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0029] Figure 1 This diagram illustrates a flowchart of an embodiment of a software test document generation method based on large models and placeholders provided by the present invention. This method can be executed by electronic devices such as terminal devices or servers. The terminal device can be any fixed or mobile terminal, such as user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, or wearable device. The server can be a single server or a server cluster consisting of multiple servers. Any electronic device can implement the software test document generation method based on large models and placeholders by having its processor call computer-readable instructions stored in its memory. Figure 1 As shown, it includes the following steps: S10. Preprocess the obtained software requirements document, extract the text content, and convert the text content into plain text format to obtain the text to be parsed.

[0030] Among them, the software requirements document refers to an unstructured or semi-structured document that records the functional requirements and technical solutions of the software to be tested; for example, the tester uploads a Word document named "Software Requirements Specification for Software A", which describes the user login function requirements of Software A, including business rules such as performing identity verification after the user enters an account and password, redirecting to the main interface after successful verification, and locking the account for 30 minutes after three consecutive incorrect password entries.

[0031] The text content refers to the original text information identified and extracted from the software requirements document, including text data such as requirements description and technical requirements; for example, the text content extracted from the "Software Requirements Specification" document is "User login function: After receiving the user's entered account and password, it is compared with the user information stored in the database. If the comparison is consistent, login is allowed and the user is redirected to the main interface. If the comparison is inconsistent, the system will prompt 'Account or password error' and automatically lock the account for 30 minutes after three consecutive incorrect password entries."

[0032] Plain text format refers to a single-character encoded text format that does not contain formatting information such as layout styles and table structures. For example, after removing the font and font size information of Word format from the text content extracted from the "Software Requirements Specification" document, a plain text string containing only character encoding is obtained. The text to be parsed refers to the requirement text data that has been preprocessed and converted to plain text format. For example, after the Software Requirements Specification is identified as a non-scanned document, the text content is extracted and converted to plain text format; the resulting plain text string is the text to be parsed, and subsequent steps will perform structured element extraction based on this text.

[0033] S20. Based on a preset placeholder rule base, extract all structured elements from the text to be parsed, and perform terminology standardization mapping on the all structured elements to obtain a standardized element set.

[0034] The placeholder rule base refers to a pre-built set of rules that includes a placeholder classification system and element extraction rules. For example, based on the test type placeholder corresponding rules in the pre-set placeholder rule base, "functional test" is matched from the text to be parsed as the test type element value, and "login user" is matched as the role prompt word element value based on the role prompt word placeholder corresponding rules.

[0035] Among them, the full set of structured elements refers to the structured data set that covers all preset element types, which is extracted from the text to be parsed at one time using a placeholder rule base. For example, the full set of structured elements extracted from the text to be parsed corresponding to the software requirements specification document A includes: the test type technical requirement element is "user login identity verification and account lockout mechanism", the role prompt word element is "login user", the test type element is "functional test", the test item method element is "equivalence class partitioning and boundary value analysis", and the test case writing idea element is "covering three scenarios: normal login, password error, and account lockout".

[0036] Terminology standardization mapping refers to the process of standardizing non-uniform expressions in all structured elements according to a pre-defined standard terminology table for the testing domain. For example, the expressions "login verification" and "authentication" appearing in all structured elements are uniformly mapped to the standard terminology "identity authentication" in the testing domain, and "incorrect password" is mapped to "password verification failed." The standardized element set refers to the set of elements with unified terminology obtained after terminology standardization mapping and deduplication and completion processing. For example, after uniformly mapping "login verification" and "authentication" in all structured elements to "identity authentication," redundant element items are removed, and missing priority elements are completed. The resulting standardized element set includes elements with unified terminology descriptions such as identity authentication, functional testing, equivalence class partitioning, and login scenario coverage.

[0037] S30. Input the standardized element set into a large language model constrained by the test domain data, and generate the requirement elements in parallel through the large language model.

[0038] The "large language model" refers to a deep learning model with natural language understanding and generation capabilities, pre-trained on a large-scale text corpus and constrained by test domain data. The test domain data constraint employs the LoRA (Locally Arithmetic Restriction) method, ensuring the training dataset contains at least 5000 labeled samples. Each sample consists of a standardized set of elements and corresponding requirement names, descriptions, and test type labels. During training, the original parameters of the base model are frozen, and only the low-rank adaptation matrix is ​​updated. This allows the model to maintain general semantic capabilities while enhancing the accuracy of generating test domain terminology and naming conventions. For example, after receiving the standardized set of elements, the large language model constrained by test domain data can understand the user login business logic described in Software Requirements Specification A and generate requirement names and descriptions that conform to the test specifications. Requirement elements refer to structured information units generated in parallel by the large language model based on a standardized set of elements. For example, the three requirement elements generated in parallel by the large language model are: requirement name "Software A - User Login - Functional Test", requirement description "Verify that the user can log in normally after entering a valid username and password on the login interface, and receive an error message when entering invalid credentials, and the account will be locked for 30 minutes after three consecutive incorrect entries", and test type label "Functional Test".

[0039] S40. Perform consistency and standardization checks on the requirement elements, and combine the requirement elements that pass the checks with the test item method elements and test case writing idea elements in the full set of structured elements to form a test generation input set.

[0040] Among them, consistency and standardization verification refers to the process of verifying whether the requirement elements are consistent with the original requirement document in terms of business logic and whether the terminology and format conform to the verification rules. For example, for the requirement element "Software A - User Login - Functional Test", verify whether the naming of the requirement name conforms to the naming specification of "Test Object - Test Scenario - Test Type", verify whether the use of the terms "Account Name" and "Account Number" in the requirement description is consistent, and verify whether the logic of the requirement description is consistent with the original description in the Software A requirement specification.

[0041] Among them, the test item method element refers to the element extracted from the text to be parsed that indicates the test method and test strategy; for example, the test item method element extracted from the software requirements specification document A is "equivalence class partitioning and boundary value analysis", indicating that the login function uses the equivalence class partitioning method to divide the input into valid equivalence classes and invalid equivalence classes, and uses the boundary value analysis method to test the upper and lower limits of password length. The test case writing idea element refers to the strategic element extracted from the text to be parsed that guides the design and writing of test cases; for example, the test case writing idea element extracted from the software requirements specification document A is "covering three scenarios: normal login, password error, and account lockout", providing a scenario coverage direction for the subsequent writing of test cases.

[0042] The test generation input set refers to a structured input data set formed by combining validated requirement elements with test item method elements and test case writing idea elements. For example, the test generation input set is obtained by combining the validated requirement name "Software A - User Login - Functional Test", requirement description and test type label "Functional Test", test item method element "Equivalence Class Partitioning and Boundary Value Analysis", and test case writing idea element "Covering three scenarios: normal login, password error, and account lockout".

[0043] S50. Input the test-generated input set into the large language model, and generate a test item set through the large language model.

[0044] The test item set refers to a set of multiple test items generated by the large language model based on the test generation input set. For example, the test item set generated by the large language model based on the test generation input set contains three test items: "User login - normal scenario verification", "User login - password error exception verification", and "User login - continuous failure account lockout boundary verification".

[0045] S60. The test item set is divided into blocks according to test type, business module and requirement item. The test content blocks obtained by the block are subjected to requirement consistency verification, coverage verification and standardization verification. The test content blocks that pass the verification are filled into the pre-set software test document template to generate software test document.

[0046] Among these, "test type" refers to a category label that classifies test activities according to different test objectives and test objects; for example, the test activity performed on the user login function of software A belongs to the functional test type. "Business module" refers to a functional unit with independent functional boundaries, divided according to the software's business functions; for example, software A includes a user management module, an order management module, and a report management module, where the user management module is a business module. "Requirement item" refers to a description of a single functional point in the requirements document, and is the smallest traceable unit of requirement decomposition; for example, a requirement item in the requirements specification of software A is "automatically lock the account for 30 minutes after the user enters the wrong password three times consecutively," describing the account locking rule. "Block decomposition" refers to the operation of dividing the test item set into independent processing units according to three dimensions: test type, business module, and requirement item; for example, the test item set generated from the functional testing of software A is decomposed into blocks according to the user management business module and the login verification requirement item, with the three test items belonging to the user login function being assigned to the same processing block.

[0047] The test content block refers to a set of test items corresponding to the same requirement item after being broken down into blocks. For example, the three test items "User Login - Normal Scenario Verification", "User Login - Password Error Anomaly Verification", and "User Login - Continuous Failure Account Lockout Boundary Verification" corresponding to the login verification requirement item under the user management module are grouped into one test content block. A test content block that passes the verification is a test content block that meets the requirements after requirement consistency verification, coverage verification, and standardization verification. Requirement consistency verification adopts a combination of semantic similarity calculation and keyword matching: the test steps and expected results in the test content block are semantically vectorized with the requirement description in the original requirement document (using the BERT model), and the cosine similarity is calculated. If the similarity is lower than a preset threshold (0.75), it is judged as inconsistent; at the same time, fuzzy matching is performed using keyword sets (such as "login", "verification", "lockout"). Coverage verification constructs a coverage matrix based on the business scenario classification (normal, boundary, anomaly) in the requirement item, marks the covered scenarios item by item, identifies missing scenarios, and triggers the supplementary generation process. The standardization verification is based on the terminology and format requirements in standards such as GJB141 and GB / T25000. It verifies whether the terminology in the test cases is in the standard terminology list, and whether the format of step numbers, punctuation, etc., conforms to the specifications. For example, the requirement consistency verification for the user login test content block confirms that the three test items are consistent with the login function requirements in Software A's requirements specification. The coverage verification confirms that the three scenarios—normal login, password error, and account lockout—are all covered. The standardization verification confirms that the terminology and steps conform to the requirements of GB / T 25000. All verifications passed.

[0048] The software test document template refers to a pre-set standardized test document template containing a fixed format framework and placeholder marks. For example, the loaded functional test case template has pre-set placeholder marks such as "{Project Name}", "{Test Type}", "{Test Scenario}", "{Test Steps}", and "{Expected Result}". The table structure and header / footer of the template have been pre-set according to Company A's standards. The software test document refers to a standardized test document output after filling the validated test content blocks into the software test document template and completing the information completion. It includes at least one of a test outline, test cases, and test report. For example, the three test items in the user login test content block are respectively filled into the "{Test Scenario}", "{Test Steps}", and "{Expected Result}" placeholder marks in the functional test case template. After information integrity is checked and completed, a complete user login functional test case document for Software A is output.

[0049] The technical solution of this embodiment preprocesses the software requirements document and converts it into plain text. Based on the placeholder rule base, it extracts all structured elements and performs terminology standardization mapping. It uses a large language model constrained by test domain data to generate requirement elements in parallel. After verification, these elements are combined into a test generation input set to generate a test item set. The test items are then broken down into blocks according to test type, business module, and requirement item, and consistency, coverage, and standardization checks are performed. The test content blocks that pass the checks are filled into a preset template. This solution solves the problems of low efficiency and error-proneness of manual compilation and static template generation, lack of intelligent content creation in automated tools and difficulty in automatically generating test content according to complex standards, and scattered and inconsistent data sources due to the lack of placeholder management. It improves the automation and intelligence level of software test document generation, and enhances the standardization and generation efficiency of the documents.

[0050] In one alternative approach, S10 specifically includes: Identify the input format of the software requirements document.

[0051] The input format refers to the original carrier type of the software requirements document, including two basic formats: editable electronic documents and non-editable image documents. For example, if the obtained software requirements specification A is an editable electronic document in Word format, the input format is an editable electronic document, and the text content can be directly extracted without performing optical character recognition.

[0052] When the software requirements document is a scanned copy, optical character recognition is performed on the software requirements document.

[0053] Here, a scanned document refers to an image file generated after optically scanning a paper document using a scanning device, with text content stored in pixel form. For example, when a paper document of Software Requirements Specification A is scanned and saved as a PDF image file, the PDF file is the scanned document, and the text describing the login function requirements in the file exists in image pixel form. Optical Character Recognition (OCR) refers to the technical processing of converting the image-format text information in a scanned document into editable text characters. For example, after performing OCR on a scanned document of Software Requirements Specification A, the text area for "User Login Function" in the image is recognized as the character code "User Login Function," and subsequently processed as plain text.

[0054] The text content of the software requirements document after optical character recognition is extracted, and the text content is converted into plain text format to obtain the text to be parsed.

[0055] Among the above-mentioned optional methods, further identification of the software requirements document input format, optical character recognition of scanned documents, extraction of text content and conversion into plain text are performed, which expands the document preprocessing methods, enables non-electronic documents to obtain structured parsing capabilities, and improves the compatibility range of document sources.

[0056] In one alternative approach, the step of extracting all structured elements from the text to be parsed based on a preset placeholder rule base includes: Using the pre-defined placeholder rule library, test type technical requirements, role prompts, test type elements, test item method elements, and test case writing ideas are extracted from the text to be parsed, resulting in the full set of structured elements. The pre-defined placeholder rule library includes placeholders for basic information, date and time, content creation, data statistics, program logic, and graphics / images. The placeholder rule library is constructed using a combination of regular expression matching and a keyword dictionary: regular expressions are used to identify placeholder markers in the template, and the keyword dictionary maps the natural language descriptions in the requirements document to the corresponding placeholder types and element fields.

[0057] Among them, the test type technical requirement elements refer to the technical indicators and acceptance conditions extracted from the text to be parsed that correspond to the test type; for example, the test type technical requirement element for functional testing extracted from the software requirements specification A is "the login function needs to verify the accuracy of identity authentication and the triggering conditions of the account lockout mechanism," which clarifies the technical acceptance criteria for the login module. The role prompt word element refers to the element extracted from the text to be parsed that describes the user's role identity and operating permissions; for example, the role prompt word element extracted from the software requirements specification A is "login user," prompting the large language model to write the requirement description from the perspective of a logged-in user when generating requirement elements. The test type element refers to the element extracted from the text to be parsed that identifies the test type classification; for example, the test type element extracted from the software requirements specification A is "functional test," confirming that the generated test items and test cases all belong to the functional test category.

[0058] Among them, the test item method element refers to the element extracted from the text to be parsed that indicates the test method and test strategy; for example, the test item method element extracted from the software requirements specification document A is "equivalence class partitioning and boundary value analysis", indicating that the login function uses the equivalence class partitioning method to divide the input into valid equivalence classes and invalid equivalence classes, and uses the boundary value analysis method to test the upper and lower limits of password length. The test case writing idea element refers to the strategic element extracted from the text to be parsed that guides the design and writing of test cases; for example, the test case writing idea element extracted from the software requirements specification document A is "covering three scenarios: normal login, password error, and account lockout", providing a scenario coverage direction for the subsequent writing of test cases.

[0059] Among them, basic information placeholders refer to placeholder types used to mark basic information fields in a document that are directly obtained from user input data or generated through concatenation and combination; for example, the "{Project Name}" placeholder pre-set in the functional test case template is a basic information placeholder, and the project name is directly obtained from the user input "Software A" and then replaced by the placeholder. Date and time placeholders refer to placeholder types used to mark fields in a document that are related to the document generation time and task execution time; for example, the "{Document Generation Date}" placeholder pre-set in the test report template is a date and time placeholder, and the placeholder is replaced by May 1, 2026 when the document is generated. Content creation placeholders refer to placeholder types used to mark fields in a document that are intelligently generated by the large language model; for example, the "{Test Scenario}", "{Test Steps}", and "{Expected Result}" placeholders pre-set in the test case template are content creation placeholders, and the content of the placeholders is automatically generated by the large language model based on the requirements document. Data statistics placeholders are placeholder types used to mark fields in a document that extract statistical information from project data. For example, the "{Total number of test cases}" placeholder pre-set in a test report template is a data statistics placeholder; when the document is generated, the total number of test cases is counted from the test case set and then replaced with the placeholder. Program logic placeholders are placeholder types used to mark program logic processing in a document that uses template engine syntax tags to implement conditional judgments and loop iterations. For example, the loop tag pre-set in a test case template for the Jinja2 template engine is a program logic placeholder; when the template engine parses the tag, it iterates through the test item set and outputs a corresponding table row for each test item. Graphic and image placeholders are placeholder types used to mark locations in a document where graphics and images are embedded. For example, the placeholder pre-set in a test report template for embedding test flowcharts is a graphic and image placeholder; when the document is generated, the flowchart image content is embedded in the placeholder's location.

[0060] In the above optional methods, the placeholder rule base is further used to extract test type technical requirements, role prompts, test types, test item methods, and test case writing ideas from the text to be parsed, and the elements are classified and collected based on multiple types of placeholders to provide a complete data foundation for subsequent terminology mapping.

[0061] In one alternative approach, the step of performing terminology normalization mapping on the full set of structured features to obtain a normalized feature set includes: The non-standardized terms in the full set of structured elements are uniformly mapped to preset test domain standard terms. The mapped full set of structured elements is then deduplicated and completed to obtain the standardized element set.

[0062] Non-standardized terms refer to expressions in the full set of structured elements that do not conform to the pre-defined standard terminology table for the testing domain. For example, "login verification" and "authentication" extracted from the text to be parsed are both non-standardized terms and do not conform to the standard terminology "identity authentication" in the testing domain. Standard terminology in the testing domain refers to standardized terms defined in the software testing field and included in the standard terminology table. For example, the standard terminology table for the testing domain uniformly standardizes the operation of verifying user identity credentials during user login as "identity authentication" and the situation where authentication fails due to incorrect user credentials as "password verification failure".

[0063] In the above optional approach, non-standardized terms in the full set of structured elements are further mapped to standard terms in the test domain, and the mapping results are deduplicated and completed to eliminate terminological ambiguity and data redundancy, so that the standardized element set meets the input requirements of the parallel generation of elements for large language models.

[0064] In one alternative approach, the step of generating requirement elements in parallel using the large language model includes: The standardized element set is input into the large language model constrained by the test domain data, and the large language model generates requirement names, requirement descriptions, and test type labels corresponding to the requirement names in parallel. The requirement names follow a unified naming convention that combines test objects, test scenarios, and test types, and the requirement descriptions cover normal scenarios, boundary scenarios, and abnormal scenarios.

[0065] The requirement name refers to a standardized name composed of the test object, test scenario, and test type according to naming conventions. For example, a requirement name of "Software A - User Login - Functional Test" would be used, where Software A is the test object, user login is the test scenario, and functional test is the test type. The requirement description refers to a textual explanation of the preconditions, business background, and acceptance criteria for the test requirement, generated by the large language model based on standardized element sets and role prompts. For example, a requirement description of "Verify that a user can log in normally after entering a valid username and password on the login interface, and receive an error message when entering invalid credentials, and have their account locked for 30 minutes after three consecutive incorrect entries" covers normal login scenarios, password error exception scenarios, and account lockout boundary scenarios. The test type label refers to a label corresponding to the requirement name that identifies the test type category. For example, the test type label corresponding to the requirement name "Software A - User Login - Functional Test" would be "Functional Test".

[0066] The test object refers to the name of the software or module to be tested; for example, in the requirement name "Software A - User Login - Functional Test", the test object is "Software A". The test scenario refers to the description of the business scenario or operational context on which the test object is based; for example, in the requirement name "Software A - User Login - Functional Test", the test scenario is "User Login".

[0067] The test scenarios are categorized as follows: Normal scenarios refer to test scenarios where, under conditions conforming to business logic and operational specifications, users perform operations according to the expected path and receive the expected responses. For example, a normal user login scenario is: after opening the login interface of software A, the user enters a registered valid username and a correct password and clicks the login button; after successful verification, the user is redirected to the main interface. Boundary scenarios refer to test scenarios where the behavior conforms to expectations when the input parameters or status are at the boundary of the valid value range. For example, a boundary scenario for user login is: when a user enters a password with a length exactly equal to the maximum allowed length on the login interface of software A, the test verifies whether the handling of passwords with boundary lengths is correct. Abnormal scenarios refer to test scenarios where error messages are given or fault tolerance is implemented under conditions that do not meet business logic or operational specifications. For example, an abnormal user login scenario is: after a user enters a registered username and an incorrect password on the login interface of software A and clicks the login button, the test displays "Account or password incorrect" and does not redirect the user.

[0068] In the above optional methods, the standardized element set is further input into a large language model constrained by the test domain data, and requirement names that follow the unified naming convention and requirement descriptions covering normal, boundary and abnormal scenarios are generated in parallel. Test type labels are output synchronously, so that the requirement elements meet the test generation requirements in terms of standardization and scenario coverage.

[0069] In one alternative approach, the step of combining the validated requirement elements with the test item method elements and test case writing idea elements from the full set of structured elements to form a test generation input set includes: Perform consistency and standardization checks on the requirement elements, check whether the terminology, format and logical consistency of the requirement elements conform to the preset check rules, correct requirement elements that do not conform to the preset check rules, and combine the requirement elements that pass the checks with the test item method elements and the test case writing idea elements in the full set of structured elements to form the test generation input set.

[0070] Among them, the preset verification rules refer to: a set of pre-defined verification rules used to verify the consistency, standardization, and logical consistency of requirement elements and test content blocks; for example, the preset verification rules define that the requirement name must follow the naming convention of "test object-test scenario-test type", the terminology in the requirement description must be consistent with the standard terminology in the test domain standard terminology table, and the semantic logic of the requirement description must not contradict the business rules in the original requirement document.

[0071] In the above-mentioned optional methods, further consistency and standardization checks are performed on the requirement elements to verify whether the terminology, format and logical consistency conform to the preset rules, correct requirement elements that do not conform to the rules, and combine the requirement elements that pass the checks with the test item method elements and test case writing idea elements to form a test generation input set to ensure the quality of input data.

[0072] In one alternative approach, the steps of filling the validated test content blocks into a pre-set software test document template to generate the software test document include: Load the pre-set software test document template, which contains pre-set placeholder markers.

[0073] Placeholder tags refer to pre-defined symbols in software test document templates that identify data fields to be replaced, using a specific syntax format. For example, functional test case templates may have pre-defined placeholder tags such as "{Project Name}, {Test Type}, {Test Scenario}, {Test Steps}, and {Expected Result}", each consisting of a field name enclosed in curly braces.

[0074] The validated test content block is matched and replaced with the placeholder mark in the software test document template to generate a first draft of the software test document.

[0075] The initial draft of the software test document refers to a draft document generated after matching and replacing the placeholder marks in the software test document template with the validated test content blocks, but before the information integrity judgment is completed. For example, after replacing the placeholder marks "{Test Scenario}, {Test Steps}, and {Expected Result}" in the template with the three test items in the user login test content block, the initial draft of the software test document is generated. In the initial draft, the placeholder "{Project Name}" has been replaced with "Software A" and the placeholder "{Test Type}" has been replaced with "Functional Test", but the placeholder "{Test Scope}" has not been replaced due to the lack of corresponding data.

[0076] The initial draft of the software test document is scanned for placeholders to determine information completeness. For the initial draft of the software test document with incomplete information, the information gap type is marked. The initial draft of the software test document is then filled in according to the marked information gap type. The initial draft of the software test document with the filled information is then output as the software test document.

[0077] Among them, the information gap type refers to the identification of placeholders that have not been replaced during the scanning of placeholders in the initial draft of software test documents, which are classified and labeled according to the data missing category. For example, if the scan of placeholders in the initial draft of software test documents finds that the placeholder "{test scope}" has not been replaced, the data source of the placeholder is a basic information type placeholder, and the information gap type is labeled as "basic information missing".

[0078] In the above optional method, a preset software test document template is further loaded, and the verified test content blocks are matched and replaced with the placeholder marks in the template to generate a draft. The draft is then scanned for placeholders to determine the information completeness, the information gap types are marked and completion is performed, so that the final output software test document meets the delivery standards.

[0079] This embodiment of the intelligent test document generation method employs locally deployed data management software, a large-scale model application development platform, a large-scale model inference platform, and stand-alone tools for comprehensive management. Variable content in the test document is abstracted into structured placeholders, establishing a six-category placeholder system: basic information placeholders (basic and extended types) are directly obtained from user input data or generated through concatenation; date and time placeholders identify time information such as document generation time and task execution time; content creation placeholders automatically generate test items, test cases, and other creative content based on the large language model; data statistics placeholders extract statistical information such as the total number of test cases from project data; program logic placeholders support special processing of Jinja2 template engine syntax tags; and graphics and image placeholders serve as embedding marks for graphics and image content.

[0080] The three-stage data processing pipeline extracts test requirements and test type information from unstructured data such as software requirements specifications and technical solutions at the input end. The transformation process utilizes data parsing and template-based thinking to convert the unstructured data into structured data units centered around placeholders and their corresponding values. At the output end, based on the structured data, a template engine replaces placeholders with actual values, performs data format transformation, and generates documents such as test outlines, test cases, and test reports that meet testing standards.

[0081] like Figure 2As shown, the document generation flowchart illustrates the sequence and interrelationship of the five steps. The five steps of the document generation process are executed sequentially: placeholder organization and management, generation of basic information data, generation of content creation data, placeholder replacement, and data format conversion.

[0082] The three-process template adaptation mechanism includes the data sorting stage of Process 1, the data acquisition stage of Process 2, and the personalized template adaptation stage of Process 3. For example... Figure 3 As shown in the diagram of the three-process template adaptation mechanism, the first process, data sorting, clarifies all data elements designed in the testing process, defines the placeholder categories, and realizes the automatic filling of basic information; the second process, data acquisition, performs row data to matrix table conversion, realizing the structured presentation of list data; and the third process, template personalization adaptation, supports flexible adaptation to different test document templates.

[0083] A structured placeholder classification mechanism achieves standardized separation of document content and management data, improving template reusability and maintainability. Intelligent creation capabilities based on a large language model automatically generate professional content such as test items and test cases, significantly reducing manual writing workload. A localized deployment architecture ensures the security and controllability of sensitive data such as test requirements and technical solutions. A three-stage data processing pipeline and a five-step generation process automate the conversion from unstructured requirement data to standardized test documents.

[0084] like Figure 4 As shown in the overall framework diagram, the data management software is a placeholder classification and management software, containing six types of placeholders: basic information (direct / extended), date and time, content creation, data statistics, program logic (Jinja2 tags), and graphics / images. The large-scale model application development platform lowers the barrier to entry for AI application development, enabling dynamic filling of content creation placeholders. The platform supports workflow design: it handles development, orchestration of large-scale model calls, data processing, and other processes. After uploading requirement documents, it automatically extracts test requirements and types, generates test items and test case elements, and stores them in the database. The large-scale model execution and inference platform provides the driving force for the platform, forming a fixed workflow and providing large-scale model inference data generation for the creation of content on the platform. The standalone tool is mainly used for basic operations such as document generation and post-processing, and is divided into three types: The first type is a template engine application that uses a template engine to replace the test document template with pre-set placeholder marks and fills the template with structured data; the second type is a conversion process that converts the test case row data generated by Excel into a matrix table format in a Word document, ensuring that the document's format and content meet industry standards; the third type is the final output that generates test outlines, test cases and test reports that conform to standard formats, and supports manual modification and improvement in the later stages.

[0085] The process of Case 1 is as follows. After entering the three-stage data processing pipeline, the user uploads the requirements description at the input end, indicating that the test type is functional testing and the project name is software. The system completes preprocessing and input validation, extracting the core input elements. The conversion process then enters a five-step document generation workflow, sequentially executing placeholder organization and management, basic information data generation, content creation data generation, placeholder replacement, data format conversion, the second step of data acquisition, and the third step of template matching and personalization adaptation.

[0086] In placeholder management, users preset available placeholder content before use, such as placeholders like {Test Type}, {Requirement Name}, {Requirement Content}, and {Expected Result}. In basic information generation, basic information mainly consists of fundamental data under the current regulatory environment. In third-party testing, laws and regulations primarily refer to testing standards such as GJB141 and GB / T25000. {Test Type} is divided into functional testing, performance testing, human-computer interaction interface testing, boundary testing, and security testing according to the GJB141 standard. In content creation generation, requirement documents and technical specifications are input into the large language model, generating professional content for each placeholder: for {Test Scenario}, generating normal, boundary, and abnormal scenarios corresponding to the requirement; for {Test Steps}, generating standardized operating steps; and for {Expected Result}, generating verifiable results consistent with the requirement.

[0087] In the placeholder replacement stage, the enterprise's standardized functional test case template is loaded. Input elements are matched with template placeholders to fill in basic information such as {Project Name}, {Test Type}, and {Test Scope}, generating a draft document. In the data format conversion stage, the draft document is scanned, and unreplaced placeholders such as {Test Scenario}, {Test Steps}, and {Expected Results} are extracted. Incomplete information is identified, and the type of information gap is marked. In the data acquisition stage (Step 2), row data is converted to a matrix table to achieve a structured presentation of list data. In the template matching and personalized adaptation stage (Step 3), industry functional test case templates are matched, the layout is adjusted according to enterprise requirements, and compliant content is supplemented according to standards such as GJB141 and GB / T25000, integrating to generate the final draft. The output stage outputs test documents, exporting test case documents that meet the format requirements and storing them in the test knowledge base, thus completing the five-step document generation process.

[0088] like Figure 5 As shown in the case flowchart, personalized adaptation includes content adjustment, format adjustment, and compliance adaptation, balancing document standardization with the personalized needs of the project. Content creation data is generated by a large model running inference platform, covering normal scenarios, boundary scenarios, and abnormal scenarios, and undergoes consistency verification, standardization verification, and logical self-consistency verification.

[0089] The content creation process is primarily deployed on a large-scale model execution and inference platform. This platform utilizes key-value comparison management software and a large language model to achieve overall content creation. For example... Figure 6 As shown in the S103 structural framework diagram, the user inputs a requirement document, writes the requirement name after data preprocessing, obtains the test type technical requirements, role prompts, test type, test item methods, and test case writing ideas, writes test items, requirement descriptions, and test types, and outputs the results through a large language model after the results are integrated.

[0090] like Figure 7 As shown, the flowchart of the S103 algorithm includes four sub-steps: S1031, S1032, S1033, and S1034.

[0091] S1031 User Input Steps: Receive software requirement documents uploaded by users, supporting multiple formats such as Word, PDF, Markdown, and files exported from the requirement management system, as the raw input for test case generation. Perform format conversion, optical character recognition (for scanned documents), noise removal, and segmentation on the requirement documents to convert unstructured documents into parsable plain text format, completing input preprocessing.

[0092] S1032 Placeholder Data Management Platform - Structured Element Extraction Steps: The placeholder data management platform performs full structured element extraction on the preprocessed requirement document, providing standardized input and rule constraints for large language model generation. Based on a pre-set placeholder rule library, it automatically extracts technical indicators, acceptance criteria, performance requirements, etc., corresponding to the test types from the requirement document, including business rules for functional testing and compliance requirements for security testing. It extracts user roles, operation permissions, and business scenarios involved in the requirements, generating role-based prompts for the large language model to ensure that the generated content conforms to the role's business logic. Based on the business attributes of the requirements, it automatically matches the pre-set test type classification system to determine the scope of the generated test types (e.g., functional testing, performance testing, security testing, compatibility testing). It extracts the explicit test methods, test strategies, and test scope from the requirements, providing methodological constraints for test item generation. It extracts business processes, boundary conditions, abnormal scenarios, and acceptance criteria from the requirements, generating test case writing ideas and constraint rules. It performs key-value standardization mapping on all extracted elements, uniformly mapping non-standard terms to pre-set test domain standard terms to ensure the standardization and consistency of the elements. The extracted full set of features is stored as a structured dataset, which serves as input to the large language model and as a benchmark for subsequent use case validation.

[0093] S1033 Large Model Processing: Large model processing includes two stages: S10331 Demand Element Generation and S10332 Test Content Generation.

[0094] S10331 Requirements Element Generation Steps: The extracted structured elements are formatted, deduplicated, and completed to generate a standardized dataset conforming to the input format of the large language model. The preprocessed structured dataset is input into the large language model constrained by the test domain, generating three types of core requirements elements in parallel. When writing requirement names, standardized and feasible test requirement names are generated based on the extracted test type, technical requirements, and business scenarios, following a unified naming convention for combinations of test objects, test scenarios, and test types. When writing requirement descriptions, detailed test requirement descriptions are generated based on the global requirement parsing results and role prompts, clearly defining the preconditions, business background, and acceptance criteria, covering normal, boundary, and abnormal scenarios. When writing test types, precise test type tags are matched for each requirement based on the extracted test type elements, supporting multi-type tag association to ensure the accuracy of test classification. Consistency and standardization checks are performed on the generated requirement elements, correcting any non-compliant content, and generating a standardized set of requirement elements as input for the next stage.

[0095] S10332 Test Content Generation Steps: The standardized requirement element set generated in S10331, along with the extracted test item methods and test case writing strategies, are merged and input into the large language model. Based on the requirement elements and test methods, test items corresponding to the test requirements are generated, clarifying the test objectives, test scope, and test focus of each test item, forming the upper-level framework of the test cases. Based on the test items, requirement descriptions, and writing strategies, complete test cases are generated for each test item, including preconditions, test steps, expected results, test type, priority, and applicable scenarios, covering normal scenarios, boundary scenarios, and abnormal scenarios.

[0096] S1034 Test Content Segmentation Analysis Steps: This step is a full-link verification process and represents a core innovation. The initial test case drafts generated in S1033 are broken down into independent test content blocks according to test type, business module, and requirement item. A full-dimensional verification analysis is performed on each test content block: Requirement consistency analysis verifies the consistency between test cases and the original requirement document and the elements extracted in S1032, preventing test cases from deviating from requirements; coverage analysis verifies whether test cases cover all requirement points, business scenarios, boundary conditions, and abnormal branches, identifying any missed test scenarios; and standardization analysis verifies whether the terminology, format, and steps of the test cases conform to preset test specifications and enterprise standards.

[0097] Figure 8 This diagram illustrates the structure of an embodiment of a software test document generation system 200 based on large models and placeholders provided by the present invention. Figure 8 As shown, the software test documentation generation system 200 based on large models and placeholders includes: The processing module 201 is used to preprocess the acquired software requirements document, extract the text content, and convert the text content into plain text format to obtain the text to be parsed. The mapping module 202 is used to extract all structured elements from the text to be parsed based on a preset placeholder rule library, and perform terminology standardization mapping on the all structured elements to obtain a standardized element set. Parallel module 203 is used to input the standardized element set into a large language model constrained by test domain data, and generate demand elements in parallel through the large language model; The verification module 204 is used to perform consistency and standardization verification on the requirement elements, and combine the verification-passed requirement elements with the test item method elements and test case writing idea elements in the full set of structured elements to form a test generation input set; The generation module 205 is used to input the test generation input set into the large language model and generate a test item set through the large language model; The output module 206 is used to break down the test item set into blocks according to test type, business module and requirement item, perform requirement consistency verification, coverage verification and standardization verification on the decomposed test content blocks, and fill the verified test content blocks into a pre-set software test document template to generate software test documents.

[0098] In one alternative embodiment, the processing module 201 is specifically used for: Identify the input format of the software requirements document; When the software requirements document is a scanned copy, optical character recognition is performed on the software requirements document. The text content of the software requirements document after optical character recognition is extracted, and the text content is converted into plain text format to obtain the text to be parsed.

[0099] In an alternative embodiment, the mapping module 202 is specifically used for: Using the preset placeholder rule library, test type technical requirements, role prompts, test type, test item methods, and test case writing ideas are obtained from the text to be parsed, resulting in the full set of structured elements. The preset placeholder rule library includes placeholders for basic information, date and time, content creation, data statistics, program logic, and graphics / images.

[0100] In an alternative embodiment, the mapping module 202 is specifically used for: The non-standardized terms in the full set of structured elements are uniformly mapped to preset test domain standard terms. The mapped full set of structured elements is then deduplicated and completed to obtain the standardized element set.

[0101] In an alternative embodiment, the parallel module 203 is specifically used for: The standardized element set is input into the large language model constrained by the test domain data, and the large language model generates requirement names, requirement descriptions, and test type labels corresponding to the requirement names in parallel. The requirement names follow a unified naming convention that combines test objects, test scenarios, and test types, and the requirement descriptions cover normal scenarios, boundary scenarios, and abnormal scenarios.

[0102] In an alternative embodiment, the verification module 204 is specifically used for: Perform consistency and standardization checks on the requirement elements, check whether the terminology, format and logical consistency of the requirement elements conform to the preset check rules, correct requirement elements that do not conform to the preset check rules, and combine the requirement elements that pass the checks with the test item method elements and the test case writing idea elements in the full set of structured elements to form the test generation input set.

[0103] In an alternative embodiment, the output module 206 is specifically used for: Load the pre-set software test document template, which contains pre-set placeholder markers; The verified test content block is matched and replaced with the placeholder mark in the software test document template to generate a first draft of the software test document; The initial draft of the software test document is scanned for placeholders to determine information completeness. For the initial draft of the software test document with incomplete information, the information gap type is marked. The initial draft of the software test document is then filled in according to the marked information gap type. The initial draft of the software test document with the filled information is then output as the software test document.

[0104] It should be noted that the beneficial effects of the software test document generation system 200 based on large models and placeholders provided in the above embodiments are the same as those of the software test document generation method based on large models and placeholders, and will not be repeated here. Furthermore, the system provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the system can be divided into different functional modules according to the actual situation to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiments, and will not be repeated here.

[0105] The software test document generation system 200 based on large models and placeholders of the present invention can be a computer program (including program code) running on a computer device. For example, the software test document generation system 200 based on large models and placeholders of the present invention is an application software that can be used to execute the corresponding steps in the software test document generation method based on large models and placeholders of the present invention.

[0106] In some embodiments, the software test document generation system 200 based on large models and placeholders of the present invention can be implemented in a combination of hardware and software. As an example, the software test document generation system 200 based on large models and placeholders of the present invention can be a processor in the form of a hardware decoding processor, which is programmed to execute the software test document generation method based on large models and placeholders of the present invention. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0107] The modules described in the embodiments of this invention can be implemented in software or hardware. The names of the modules are not, in some cases, limiting the scope of the module itself.

[0108] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned software test document generation methods based on large models and placeholders. That is, an electronic device according to an embodiment of the present invention may include, but is not limited to: a processor and a memory; the memory is used to store the computer program; the processor is used to execute the software test document generation method based on large models and placeholders shown in any embodiment of the present invention by calling the computer program.

[0109] In one alternative embodiment, an electronic device is provided, such as Figure 9 As shown, Figure 9The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0110] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0111] Bus 4002 may include a path for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 9 The bus 4002 is represented by only one thick line, but this does not mean that there is only one bus or one type of bus.

[0112] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0113] The memory 4003 stores application code (computer program) for executing the present invention, and its execution is controlled by the processor 4001. The processor 4001 executes the application code stored in the memory 4003 to implement the content shown in the foregoing method embodiments.

[0114] Among them, electronic devices can also be terminal devices. A terminal device can be any terminal device that can install applications and access web pages through applications, including at least one of smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart TVs, and smart in-vehicle devices.

[0115] It should be noted that, Figure 9 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present invention.

[0116] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-mentioned methods for generating software test documents based on large models and placeholders.

[0117] Alternatively, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device, etc.

[0118] In an exemplary embodiment, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the aforementioned software test document generation method based on large models and placeholders.

[0119] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0120] It should be understood that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0121] The computer-readable storage medium provided in this invention can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0122] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the method shown in the above embodiments.

[0123] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0124] It should be noted that the terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and represent a limitation on a specific order or sequence. Where appropriate, the order of use for similar objects can be interchanged so that the embodiments of this application described herein can be implemented in an order other than that shown or described.

[0125] Those skilled in the art will recognize that this invention can be implemented as a system, method, or computer program product. Therefore, this invention can be specifically implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, this invention can also be implemented as a computer program product contained in one or more computer-readable media, which includes computer-readable program code.

[0126] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for generating software test documentation based on large models and placeholders, characterized in that, include: The obtained software requirements document is preprocessed to extract the text content, and the text content is converted into plain text format to obtain the text to be parsed; Based on a preset placeholder rule base, all structured elements are extracted from the text to be parsed, and terminology standardization mapping is performed on the all structured elements to obtain a standardized element set. The standardized element set is input into a large language model constrained by test domain data, and the requirement elements are generated in parallel through the large language model. Perform consistency and standardization checks on the required elements, and combine the checked required elements with the test item method elements and test case writing idea elements in the full set of structured elements to form a test generation input set; The test-generated input set is input into the large language model, and the large language model generates a set of test items. The test item set is divided into blocks according to test type, business module, and requirement item. The decomposed test content blocks are subjected to requirement consistency verification, coverage verification, and standardization verification. The verified test content blocks are filled into a pre-set software test document template to generate software test documents.

2. The software test document generation method based on large models and placeholders according to claim 1, characterized in that, The steps of preprocessing the acquired software requirements document, extracting the text content, and converting the text content into plain text format to obtain the text to be parsed include: Identify the input format of the software requirements document; When the software requirements document is a scanned copy, optical character recognition is performed on the software requirements document. The text content of the software requirements document after optical character recognition is extracted, and the text content is converted into plain text format to obtain the text to be parsed.

3. The software test document generation method based on large models and placeholders according to claim 1, characterized in that, The steps for extracting all structured elements from the text to be parsed based on a preset placeholder rule base include: Using the preset placeholder rule library, test type technical requirements, role prompts, test type, test item methods, and test case writing ideas are obtained from the text to be parsed, resulting in the full set of structured elements. The preset placeholder rule library includes placeholders for basic information, date and time, content creation, data statistics, program logic, and graphics / images.

4. The software test document generation method based on large models and placeholders according to claim 1, characterized in that, The step of performing terminology normalization mapping on the full set of structured features to obtain a normalized feature set includes: The non-standardized terms in the full set of structured elements are uniformly mapped to preset test domain standard terms. The mapped full set of structured elements is then deduplicated and completed to obtain the standardized element set.

5. The software test document generation method based on large models and placeholders according to claim 1, characterized in that, The steps for generating requirement elements in parallel using the large language model include: The standardized element set is input into the large language model constrained by the test domain data, and the large language model generates requirement names, requirement descriptions, and test type labels corresponding to the requirement names in parallel. The requirement names follow a unified naming convention that combines test objects, test scenarios, and test types, and the requirement descriptions cover normal scenarios, boundary scenarios, and abnormal scenarios.

6. The software test document generation method based on large models and placeholders according to claim 1, characterized in that, The step of combining the validated requirement elements with the test item method elements and test case writing idea elements from the full set of structured elements to form a test generation input set includes: Perform consistency and standardization checks on the requirement elements, check whether the terminology, format and logical consistency of the requirement elements conform to the preset check rules, correct requirement elements that do not conform to the preset check rules, and combine the requirement elements that pass the checks with the test item method elements and the test case writing idea elements in the full set of structured elements to form the test generation input set.

7. The software test document generation method based on large models and placeholders according to any one of claims 1 to 6, characterized in that, The steps for generating software test documentation by filling the validated test content blocks into a pre-set software test document template include: Load the pre-set software test document template, which contains pre-set placeholder markers; The verified test content block is matched and replaced with the placeholder mark in the software test document template to generate a first draft of the software test document; The initial draft of the software test document is scanned for placeholders to determine information completeness. For the initial draft of the software test document with incomplete information, the information gap type is marked. The initial draft of the software test document is then filled in according to the marked information gap type. The initial draft of the software test document with the filled information is then output as the software test document.

8. A software test document generation system based on large models and placeholders, characterized in that, include: The processing module is used to preprocess the acquired software requirements document, extract the text content, and convert the text content into plain text format to obtain the text to be parsed. The mapping module is used to extract all structured elements from the text to be parsed based on a preset placeholder rule library, and to perform terminology standardization mapping on the all structured elements to obtain a standardized element set. The parallel module is used to input the standardized element set into a large language model constrained by the test domain data, and generate the requirement elements in parallel through the large language model; The verification module is used to perform consistency and standardization verification on the requirement elements, and combine the verification-passed requirement elements with the test item method elements and test case writing idea elements in the full set of structured elements to form a test generation input set; The generation module is used to input the test generation input set into the large language model and generate a test item set through the large language model; The output module is used to break down the test item set into blocks according to test type, business module and requirement item, perform requirement consistency verification, coverage verification and standardization verification on the decomposed test content blocks, and fill the verified test content blocks into a pre-set software test document template to generate software test documents.

9. An electronic device, characterized in that, The electronic device includes a processor coupled to a memory storing at least one computer program, which is loaded and executed by the processor to enable the electronic device to implement the software test document generation method based on large models and placeholders as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which, when executed by a processor, implements the software test document generation method based on large models and placeholders as described in any one of claims 1 to 7.

Images