Software testing methods and related equipment based on dual-model collaboration

Abstract

This application discloses a software testing method and related equipment based on dual-model collaboration, relating to the field of software testing technology. The method includes: processing a natural language requirements document using a pre-defined large language model to obtain a test script for testing the software under test; if the software test result is a test failure, verifying and classifying the test result using a pre-defined algorithm model to obtain abnormal scripts and system bugs; correcting the abnormal scripts and system bugs; and iteratively testing the software under test based on the corrected test script and the corrected software under test until the software test is completed. This application, through a collaborative architecture of "large model understanding + small model judgment" and a semantic consistency detection mechanism, effectively corrects logical deviations in the generated content (test script), ensuring a high degree of matching between test cases and system functional behavior, significantly improving the reliability and executability of test cases, and thus achieving high-quality and high-efficiency software testing.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to software testing methods and related equipment based on dual-model collaboration. Background Technology

[0002] Currently, the conversion from requirements to test cases mainly relies on manual writing, which suffers from high costs and low efficiency. Among existing automation technologies, rule-based methods are poorly adaptable to unstructured requirements; large-model-based methods lack domain knowledge, resulting in error-prone and incomplete content coverage; and methods based on interface documents or UI prototypes struggle to understand business processes and semantics. Overall, these technologies generally suffer from insufficient semantic understanding, a lack of system knowledge background, and incomplete consistency checks, leading to unreliable generated test cases and making it difficult to achieve high-quality, high-efficiency automated generation in unstructured requirement environments. Summary of the Invention

[0003] The main purpose of this application is to provide a software testing method and related equipment based on dual-model collaboration, aiming to solve the technical problem of how to complete software testing with high quality and high efficiency.

[0004] To achieve the above objectives, this application proposes a software testing method based on dual-model collaboration, which includes:

[0005] In response to software testing commands, obtain the natural language requirements document corresponding to the software to be tested; The natural language requirement document is processed using a pre-defined large language model to obtain a test script; Based on the test script, the software to be tested is tested to obtain the software test results; If the software test result is a test failure, the software test result is verified and classified using a preset algorithm model to obtain abnormal scripts and system bugs. The abnormal script and the system bug are corrected to obtain a corrected test script and a corrected software to be tested. Based on the corrected test script and the corrected software to be tested, the software to be tested is tested based on the software test script to obtain the software test result. The process continues until the software test result is successful, and the software test is completed.

[0006] In one embodiment, the step of verifying and classifying the software test results using a preset algorithm model to obtain abnormal scripts and system bugs further includes: Based on the natural language requirements document and algorithm selection rules, the target algorithm for verification and classification is determined; Based on the target algorithm, the software test results are verified and classified using a preset algorithm model to obtain abnormal scripts and system bugs.

[0007] In one embodiment, the step of correcting the abnormal script and the system bug to obtain the corrected test script and the corrected software to be tested further includes: Determine the error log and failure screenshots corresponding to the abnormal script; A standardized exception report is generated based on the error log and the failure screenshot. The exception report includes the script identifier, execution environment, failure time, and a comparison of expected and actual results. The anomaly report is sent to the testers so that they can correct the anomaly script and obtain a corrected test script. The system bug is also sent to the developers so that they can correct the system bug and obtain a corrected software to be tested.

[0008] In one embodiment, the step of sending the system bug to the developers for fixing the system bug and obtaining the fixed software to be tested further includes: Obtain the core information and environmental context information corresponding to the system bug. The core information includes the defect ID, severity, priority, scope of impact, reproduction steps, actual performance and expected behavior. The environmental context information includes the operating system version, browser type, database configuration, log files, and network packet capture data. Based on the severity of the system bug and the preset task allocation strategy, the core information and environmental context information are sent to the developers, and tasks are allocated so that the developers can correct the system bug based on the task allocation results, thus obtaining the corrected software to be tested.

[0009] In one embodiment, the step of processing the natural language requirement document using a preset large language model to obtain a test script further includes: Based on the preset test type parsing model and preset knowledge base, the test type corresponding to the natural language requirement document is determined; Based on the test type, determine the prompt word template and keyword extraction strategy corresponding to the natural language requirement document; Based on the prompt word template and the keyword extraction strategy, the natural language requirement document is processed using a preset large language model to obtain a test script.

[0010] In one embodiment, the step of processing the natural language requirement document using a preset large language model to obtain a test script further includes: The natural language requirement document is subjected to dependency parsing, semantic understanding and logical extraction using a pre-defined large language model to obtain the functional objectives, input conditions, operation actions and expected results corresponding to the natural language requirement document. Based on the functional objective, the input conditions, the operation actions, and the expected results, a preliminary semantic representation structure is generated; Based on the preset knowledge base, the preliminary semantic representation results, and the preset script generation rules, a test script is generated.

[0011] In one embodiment, after the step of completing the software testing until the software test result is successful, the method further includes: The preset knowledge base is updated based on the test script and the software to be tested corresponding to the successful test.

[0012] In one embodiment, before the step of processing the natural language requirement document using a preset large language model to obtain a test script, the method further includes: Acquire sample data, which corresponds to the first data processing result; The sample data is processed using the current large language model to obtain the second data processing result; Determine whether the first data processing result is consistent with the second data processing result; If the first data processing result is inconsistent with the second data processing result, the parameters of the current large language model are adjusted. Based on the current large language model with adjusted parameters, the process of using the current large language model to process the sample data is returned to obtain the second data processing result. This process continues until the first data processing result is consistent with the second data processing result, thus obtaining the preset large language model.

[0013] Furthermore, to achieve the above objectives, this application also proposes a software testing device based on dual-model collaboration, the software testing device based on dual-model collaboration comprising: The acquisition module is used to acquire the natural language requirements document corresponding to the software to be tested in response to a software testing command. A document processing module is used to process the natural language requirement document using a preset large language model to obtain a test script; The testing module is used to test the software under test based on the test script and obtain the software test results. A classification module is used to verify and classify the software test result if the software test result is a test failure, thereby obtaining abnormal scripts and system bugs. The correction module is used to correct the abnormal script and the system bug to obtain a corrected test script and a corrected software to be tested. Based on the corrected test script and the corrected software to be tested, the module returns a step to test the software to be tested based on the software test script and obtain the software test result. The software test is completed when the software test result is successful.

[0014] Furthermore, to achieve the above objectives, this application also proposes a software testing device based on dual-model collaboration, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the software testing method based on dual-model collaboration as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the software testing method based on dual-model collaboration as described above.

[0016] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the software testing method based on dual-model collaboration as described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: This application proposes a software testing method and related equipment based on dual-model collaboration, belonging to the field of software testing technology. Compared with related technologies, where the conversion from requirements to test cases mainly relies on manual writing, resulting in high costs and low efficiency, this application first obtains the natural language requirement document corresponding to the software to be tested in response to software testing instructions. Then, it processes the natural language requirement document using a preset large language model to obtain a test script. Further, based on the test script, the software to be tested is tested to obtain software test results. Further, if the software test result is a test failure, a preset algorithm model is used to verify and classify the software test result to obtain abnormal scripts and system bugs. Finally, the abnormal scripts and system bugs are corrected to obtain a corrected test script and a corrected software to be tested. Based on the corrected test script and the corrected software to be tested, the process returns to testing the software to be tested based on the software test script to obtain software test results, until the software test result is a successful test, thus completing the software testing.

[0018] Understandably, this application effectively corrects the logical deviations of the generated content (test scripts) through a collaborative architecture of "large model understanding + small model judgment" and a semantic consistency detection mechanism, ensuring that test cases are highly matched with the system's functional behavior, significantly improving the reliability and executability of test cases, and thus achieving high-quality and high-efficiency software testing. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating an embodiment of the software testing method based on dual-model collaboration in this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the software testing method based on dual-model collaboration in this application. Figure 3 This is a flowchart illustrating Embodiment 3 of the software testing method based on dual-model collaboration in this application; Figure 4 This is a schematic diagram of the module structure of the software testing device based on dual-model collaboration in an embodiment of this application. Figure 5 This is a schematic diagram of the hardware operating environment involved in the software testing method based on dual-model collaboration in the embodiments of this application.

[0022] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0024] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0025] The main solution in this application embodiment is: In this embodiment, for ease of description, the following description will focus on a software testing device based on dual-model collaboration.

[0026] Currently, the conversion from requirements to test cases mainly relies on manual coding, resulting in high costs and low efficiency. Existing automation technologies suffer from several drawbacks: rule-based methods are poorly adapted to unstructured requirements; large-model-based methods lack domain knowledge, leading to error-prone logic and incomplete coverage; and methods based on interface documents or UI prototypes struggle to understand business processes and semantics. Overall, these technologies generally suffer from insufficient semantic understanding, a lack of system knowledge background, and inadequate consistency checks, resulting in unreliable test cases and hindering the achievement of high-quality, efficient automated generation in unstructured requirement environments.

[0027] This application provides a solution in which: first, in response to a software testing instruction, a natural language requirements document corresponding to the software to be tested is obtained; then, the natural language requirements document is processed using a preset large language model to obtain a test script; further, based on the test script, the software to be tested is tested to obtain a software test result; further, if the software test result is a test failure, the software test result is verified and classified using a preset algorithm model to obtain abnormal scripts and system bugs; finally, the abnormal scripts and system bugs are corrected to obtain a corrected test script and a corrected software to be tested; based on the corrected test script and the corrected software to be tested, the process returns to the step of testing the software to be tested based on the software test script to obtain a software test result, until the software test result is a successful test, thus completing the software testing.

[0028] Understandably, this application effectively corrects the logical deviations of the generated content (test scripts) through a collaborative architecture of "large model understanding + small model judgment" and a semantic consistency detection mechanism, ensuring that test cases are highly matched with the system's functional behavior, significantly improving the reliability and executability of test cases, and thus achieving high-quality and high-efficiency software testing.

[0029] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions, a software testing device based on dual-model collaboration, etc. The following description uses a software testing device based on dual-model collaboration as an example to illustrate this embodiment and the subsequent embodiments.

[0030] Based on this, the embodiments of this application provide a software testing method based on dual-model collaboration, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the software testing method based on dual-model collaboration in this application.

[0031] In this embodiment, the software testing method based on dual-model collaboration includes steps S10 to S50: Step S10: In response to the software testing instruction, obtain the natural language requirements document corresponding to the software to be tested; It should be noted that a software testing instruction refers to an event that triggers the entire process, which can be a webhook issued by the CI / CD pipeline, a manual click on the testing platform, a scheduled task cron, etc.

[0032] The software to be tested (SUT) refers to the program entity to be verified, which can be a microservice, an application, firmware, an algorithm library, etc.

[0033] Natural Language Requirements Documents (NLRDs) are requirements specifications written in human languages ​​(Chinese / English / multilingual). Common formats include PRDs, user stories, use case descriptions, acceptance criteria, Confluence pages, email minutes, etc. Their core characteristic is that they are "human-readable" rather than "machine-readable."

[0034] In this embodiment, software testing begins first, based on a CI / CD hook, a scheduled task, or by manually clicking the "Start Test" button. Further, based on software test instructions, the repository address, commit ID, and requirement document path are extracted. The NLRD (Required Document Request) is then read into memory via the Git API, Confluence API, or file system.

[0035] Step S20: Process the natural language requirement document using a preset large language model to obtain a test script; It should be noted that the default large language model (LLM) refers to a model that has been fine-tuned or prompt-engineered, has the ability to map "requirements to test steps", and can be deployed locally or call cloud services.

[0036] It should be noted that test scripts refer to code or tables that can be directly executed by automation frameworks (Selenium, Appium, Pytest, Robot, etc.), including preconditions, input data, and assertions.

[0037] In this embodiment, signatures, directories, and figure captions are removed from the NLRD. Then, it is broken down into sections based on "functional points + acceptance criteria." Further, a Prompt is assembled, and the LLM interface is called to obtain the original script. Finally, a static analyzer is used to complete the page objects, resource paths, and data-driven CSV, generating the final executable script package.

[0038] Specifically, the step of processing the natural language requirement document using a preset large language model to obtain the test script further includes steps S21 to S23: Step S21: Based on the preset test type parsing model and the preset knowledge base, determine the test type corresponding to the natural language requirement document; It should be noted that the test type parsing model is a fine-tuned text classification model (such as BERT or TextCNN). The input is the text features of the requirements document (vocabulary, sentence structure, semantic vectors), and the output is a predefined test type label. The test type label includes the following: Functional testing includes functional descriptions such as "input", "validation", and "return results"; performance testing includes performance metrics such as "concurrency", "response time", and "throughput"; security testing involves security keywords such as "access control", "encryption", and "SQL injection"; compatibility testing describes "multiple browsers", "mobile devices", and "different system versions"; and interface testing includes technical terms such as "API calls", "parameter passing", and "status codes".

[0039] It should be noted that the test knowledge base refers to the storage of historical mapping rules and domain terminology, including: system requirements specification or system core process specification, organized historical defect library, test case library and test code library (after large model semantic analysis, the corresponding code function library can be queried).

[0040] In this embodiment, the test type parsing model ultimately outputs one or more test type labels to determine the processing strategy for subsequent steps.

[0041] Step S22: Based on the test type, determine the prompt word template and keyword extraction strategy corresponding to the natural language requirement document; It should be noted that the Prompt Template refers to an LLM input framework designed for each test type.

[0042] It should be noted that the keyword extraction strategy refers to a differentiated rule set based on information extraction (IE) technology.

[0043] Step S23: Based on the prompt word template and the keyword extraction strategy, the natural language requirement document is processed using a preset large language model to obtain a test script.

[0044] Specifically, the step of processing the natural language requirement document using a preset large language model to obtain the test script further includes steps 1 to 3: Step 1: Use a preset large language model to perform dependency parsing, semantic understanding and logic extraction on the natural language requirement document to obtain the functional goals, input conditions, operation actions and expected results corresponding to the natural language requirement document; It should be noted that dependency parsing refers to breaking down a sentence into directed dependency trees such as subject-verb-object-adjective-adverbial-complement to identify grammatical relationships between words (e.g., nsubj, dobj, case). For example, for the sentence "After the user clicks the login button, they should be redirected to the homepage", we get click-user (subject), click-button (object), button-login (adjective).

[0045] It should be noted that semantic understanding refers to identifying business entities (users, login buttons, homepages) and their intentions (redirection, verification, creation) based on the syntax tree.

[0046] It should be noted that logic extraction refers to making the control flow, such as conditions, loops, sequences, and exceptions, explicit in natural language. For example, extracting "IF inventory < threshold, THEN report an error and block the order" from "If inventory is insufficient, prompt an error and block the order".

[0047] It should be noted that functional objectives refer to the business value that the requirement aims to achieve, such as "verifying the correctness of the login function".

[0048] It should be noted that the input conditions refer to the pre-existing data and environment status, such as "username='test', password='123456', network is normal".

[0049] It should be noted that the operation action refers to the specific interactive steps, such as "open browser - enter URL - click login - fill in form - submit".

[0050] It should be noted that expected results refer to observable assertions, such as "the URL changes to ' / home' and the page contains the text 'Welcome back'".

[0051] In this embodiment, firstly, the NLRD is split into segments according to "user stories" or "feature points" using regular expressions and TextTiling, with each segment corresponding to a potential test case. Then, the LLM's conll output interface or a local parser (such as Stanza or spaCy) is called to generate the dependency tree for each sentence; an ontology dictionary (such as "click = click, input = type, verification = assert") is embedded in the LLM Prompt to allow the model to identify and standardize verbs and nouns; for sentences containing "if / when / unless", the rule engine is triggered to generate a pseudocode structure.

[0052] Understandably, syntactic analysis maps colloquial expressions (such as "click the blue one") to specific elements, improving comprehension accuracy; it mandates that all four elements are indispensable, preventing LLM from generating unfinished scripts that are "lacking assertions" or "lacking preconditions"; and dependency trees can serve as a visual intermediate product, allowing for quick identification of the source of model misjudgments during manual review.

[0053] Step 2: Based on the functional objective, the input conditions, the operation action, and the expected result, generate a preliminary semantic representation structure; It should be noted that the preliminary semantic representation structure refers to a semi-formal, serializable data structure, somewhere between natural language and executable scripts. The preliminary semantic representation structure can be: JSON-LD: JSON with context, making it easier for machines to parse.

[0054] DSL Abstract Syntax Tree (AST): A tree-like representation of a custom domain language, such as LoginAction(UsernameInput, PasswordInput, SubmitButton).

[0055] BDD style structure: Given-When-Then three-part objects.

[0056] In this embodiment, firstly, the multiple "four-element" blocks obtained in step 1 are aggregated by business primary keys (such as user ID and order number), and duplicates are removed and merged. Then, pre-dependencies across use cases are identified, such as "user registration must be executed before login can be executed." An execution sequence after topological sorting is generated. Further, hard-coded values ​​(such as test01) are replaced with variable placeholders ${USERNAME} and written to the variable definition table. Finally, a standard format is output.

[0057] Understandably, this structure does not contain specific framework syntax and can generate multiple scripts for Selenium, Cypress, and Playwright simultaneously, achieving "understand once, run on multiple platforms"; it can be reused, parameterized, and data-driven by humans at this layer without having to rerun the LLM; even if the LLM is changed (such as switching from GPT-4 to Claude), as long as this structure is output, the downstream process does not need to be modified.

[0058] Step 3: Generate a test script based on the preset knowledge base, the preliminary semantic representation results, and the preset script generation rules.

[0059] It should be noted that the preset knowledge base includes three types of assets: page element library, page element library and action template library.

[0060] Page element library: Login button -id=btn_login, xpath= / / button[@type='submit'] (from historical scripts or UI automation recordings).

[0061] Action template library: Input action - driver.find_element(By.ID, "{target}").send_keys("{value}").

[0062] Assertion library: URL assertion - assert driver.current_url.contains("{pattern}").

[0063] It should be noted that the preset script generation rules refer to the template engine rules that translate semantic structure into specific syntax, such as: Rule 1: qa:ClickAction is mapped to click ${target} (Robot Framework).

[0064] Rule 2: If qa:target has data-testid in the knowledge base, use that locator first (to improve stability).

[0065] In this embodiment, firstly, for qa:target="login_button", the knowledge base is queried to obtain id=btn_login, which is then populated into the template. Then, qa:actionSequence is iterated through, translating each rule one by one. Simultaneously, qa:expectedResult is iterated through to generate assert or expect statements.

[0066] Furthermore, use Jinja2 or Velocity to assemble the above code snippets into a complete script file, adding scaffolding elements such as setUp, tearDown, and import. Add a comment at the beginning of the script stating, "This script was generated by LLM from requirement DOC-123. Please do not modify it manually; please regenerate after changing the requirements."

[0067] Understandably, the knowledge base provides stable locators, and pure rule rendering is faster than LLM directly generating code. The knowledge base can be injected with company private protocols and custom frameworks to make the generated scripts conform to internal specifications, so they can be stored and executed without secondary modification.

[0068] Step S30: Based on the test script, test the software to be tested to obtain the software test results; It should be noted that the software test results refer to the aggregated data such as run-status (PASS / FAIL / SKIP), logs, screenshots, coverage, and performance metrics for each test case.

[0069] In this embodiment, firstly, Kubernetes starts the container, flashes the SUT version, and injects test data. Then, the script is executed in parallel using Jenkins, GitLab CI, or a self-developed orchestrator. Furthermore, in case of failure, automatic screenshots, thread dumps, and network packet captures are performed. Finally, the JSON results of each case are aggregated into a unified report.

[0070] Step S40: If the software test result is a test failure, the software test result is verified and classified using a preset algorithm model to obtain abnormal scripts and system bugs; It should be noted that the preset algorithm model refers to a two-stage model of "anomaly detection + classification". Anomaly detection refers to filtering out environmental noise using log template mining (Drain, Spell) or deep autoencoders; the classifier refers to labeling the remaining anomalies according to the stack pattern (script error, product defect, environmental failure, data problem).

[0071] Abnormal scripts refer to script-related problems caused by factors such as changes to locators or insufficient waiting time.

[0072] A system bug refers to a real defect in software functionality that does not match the requirements.

[0073] In this embodiment, firstly, the console, server log, and trace-id of failed test cases are vectorized. Then, anomaly scoring is performed, and records exceeding a threshold are entered into a classifier. Further, the records entering the classifier are labeled, and finally, two CSV files are output, one for the script developer and the other for the product developer.

[0074] Specifically, the step of using a preset algorithm model to verify and classify the software test results to obtain abnormal scripts and system bugs further includes steps S41-S42: Step S41: Based on the natural language requirements document and algorithm selection rules, determine the target algorithm for verification and classification; It should be noted that the algorithm selection rule refers to a set of condition-policy mapping tables, expressed using a DSL or script. Rule dimensions include: Requirements characteristics: Does the NLRD contain keywords such as "concurrency", "security", "algorithm", and "report"? Failure modes: log length, stack depth, exception type (Timeout, AssertionError, NullPointer); Historical experience: This module's historical false positive rate and script vulnerability score.

[0075] It should be noted that the target algorithm refers to a successfully matched combination of algorithms, such as: log template mining (Drain) + lightweight decision tree, or semantic vectorization (Sentence-BERT) + deep clustering. This serves as the "user manual" for subsequent S42 steps.

[0076] Step S42: Based on the target algorithm, the software test results are verified and classified using a preset algorithm model to obtain abnormal scripts and system bugs.

[0077] It should be noted that the preset algorithm model refers to a reusable algorithm container that has been trained and packaged in historical projects, including: Validator: Determines whether the failure is due to a real defect or environmental noise (such as network jitter or insufficient data). Classifier: Labels failed validations and outputs {type, confidence level, and repair suggestions}.

[0078] In this embodiment, the logs are first cleaned (de-identified, timestamp removed, format standardized). Then, the logs are converted into vectors using an encoder specified by the target algorithm (such as TF-IDF, FastText, CodeBERT). Further, the vectors are input to a validator (such as an isolated forest or a single-class SVM); the scores corresponding to the vectors are obtained, and the vectors are labeled and classified based on the scores.

[0079] Step S50: Correct the abnormal script and the system bug to obtain a corrected test script and a corrected software to be tested. Based on the corrected test script and the corrected software to be tested, return to the step of testing the software to be tested based on the software test script to obtain the software test result, until the software test result is successful, and the software test is completed.

[0080] It should be noted that the revised test script refers to the version after the element locator, wait strategy, and data-driven value have been automatically or manually refreshed.

[0081] It should be noted that the corrected software to be tested refers to the version that the development team has fixed the code and repackaged based on the bug list.

[0082] Understandably, in this embodiment, a closed loop of "requirement-script-execution-diagnosis-repair-re-execution" is formed, eliminating the need for manual switching between tools; each iteration ensures that the script evolves in sync with the product, ultimately achieving the goal of "zero script maintenance" or "low script maintenance", significantly reducing regression testing costs.

[0083] Specifically, after the step of completing the software testing until the software test result is successful, the method further includes step S60: Step S60: Update the preset knowledge base based on the test script and the software to be tested corresponding to the successful test.

[0084] It should be noted that test success refers to the final state when the S50 loop terminates—all test cases are in the PASS state, and all quality thresholds such as performance and coverage are met. This signifies that the requirements and implementation of the current version have reached a deliverable consensus.

[0085] It should be noted that the test script corresponding to a successful test refers to a stable and reproducible version that has undergone multiple rounds of revisions by S50. Its characteristics include: precise locators, reasonable wait strategies, effective assertions, and no flaky behavior. It is a "practice-proven best practice."

[0086] It should be noted that the software under test refers to the final software binary package that has passed all test cases. Its UI layout, interface contracts, and business logic are completely aligned with the current requirements.

[0087] It should be noted that the preset knowledge base refers to the enterprise-level asset library used in S23 for generating scripts.

[0088] Understandably, each completed end-to-end test automatically adds high-quality entries to the knowledge base. After multiple tests, it can cover a large number of common elements, improving the accuracy of script generation. The next time S23 generates a script, it prioritizes using the golden locators in the knowledge base, reducing rework. Traditional automation requires manual synchronization of UI changes (such as renaming button IDs), while this step automatically captures the latest locating strategies in successfully completed scripts, achieving "document update upon test success," significantly saving maintenance manpower. The knowledge base version is strongly bound to the software version; when rolling back the software, the knowledge base can be rolled back with one click, ensuring that historical versions are always testable and avoiding the risk of "knowledge loss leading to the inability to revert to older versions."

[0089] This application proposes a software testing method and related equipment based on dual-model collaboration, belonging to the field of software testing technology. Compared with related technologies, where the conversion from requirements to test cases mainly relies on manual writing, resulting in high costs and low efficiency, this application first obtains the natural language requirement document corresponding to the software to be tested in response to software testing instructions. Then, it processes the natural language requirement document using a preset large language model to obtain a test script. Further, based on the test script, the software to be tested is tested to obtain software test results. Further, if the software test result is a test failure, a preset algorithm model is used to verify and classify the software test result to obtain abnormal scripts and system bugs. Finally, the abnormal scripts and system bugs are corrected to obtain a corrected test script and a corrected software to be tested. Based on the corrected test script and the corrected software to be tested, the process returns to testing the software to be tested based on the software test script to obtain software test results, until the software test result is a successful test, thus completing the software testing.

[0090] Understandably, this application effectively corrects the logical deviations of the generated content (test scripts) through a collaborative architecture of "large model understanding + small model judgment" and a semantic consistency detection mechanism, ensuring that test cases are highly matched with the system's functional behavior, significantly improving the reliability and executability of test cases, and thus achieving high-quality and high-efficiency software testing.

[0091] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 The step of correcting the abnormal script and the system bug to obtain the corrected test script and the corrected software to be tested further includes steps A10 to A30: Step A10: Determine the error log and failure screenshot corresponding to the abnormal script; It should be noted that abnormal scripts refer to test cases marked as "script-specific problems" by the algorithm model in step S40. Their failure is unrelated to software functionality, but rather due to factors such as element location failure, insufficient waiting time, expired data, or changes in environment configuration.

[0092] It should be noted that the error log is a structured text captured by the testing framework (such as Selenium, Pytest, Playwright) when the script fails. It includes: timestamp, log level (ERROR / WARN); exception stack trace; line number and source code snippet of the failed statement; and console output of the browser or application (Console.log).

[0093] A failure screenshot is an image of the current UI (usually in PNG format) automatically captured by the testing framework at the moment an assertion fails or an exception is thrown. The screenshot filename is bound to the test case ID for easy traceability.

[0094] Understandably, logs provide "code-level" reasons for failures, while screenshots offer a "user-perspective" view of the situation; the two complement each other, improving the speed of troubleshooting. Testers don't need to rerun scripts; they can diagnose directly based on logs and screenshots, saving communication and reproduction costs. Structured logs can be directly parsed by the algorithm model, providing raw materials for A20's automatic report generation.

[0095] Step A20: Generate a standardized exception report based on the error log and the failure screenshot. The exception report includes the script identifier, execution environment, failure time point, and a comparison of expected and actual results. It should be noted that a standardized anomaly report refers to a structured document (usually in JSON+HTML dual format) that is machine-readable and human-reviewable, and is the formal output of failure information after noise reduction, classification, and enhancement.

[0096] It should be noted that the script identifier refers to the metadata that uniquely identifies the failed test case, including: test suite name, test case ID, requirement traceability number (such as DOC-123), author, and last modified time.

[0097] It should be noted that the execution environment refers to the context information of the script runtime, including: operating system and version, browser type and version (such as Chrome 120.0), test environment URL (test / pre-release), execution node IP, and Docker image tag.

[0098] It should be noted that the failure time point refers to a timestamp accurate to milliseconds (e.g., 2024-01-15T14:32:11.234Z), which is used to associate logs, monitoring metrics, and CI build records.

[0099] It should be noted that the comparison between expected and actual results is the core part of the report, presented in a table or Diff view, and includes the following: Expected: Assertion statements from the raw text of the requirements document or from a script; Actual results: The actual return values ​​in the logs, the text recognized by OCR in the screenshots, and fragments of the page source code.

[0100] In this embodiment, firstly, irrelevant logs (such as INFO-level heartbeats) are filtered using regular expressions, retaining ERROR and above. If the same anomaly occurs repeatedly, it is aggregated into one entry and the number of occurrences is marked. Computer vision algorithms (such as OpenCV template matching) are used to highlight discrepancies in the screenshot (such as a button that should be present but is actually missing), generating an annotated image. The image is then filled according to a preset template, generating report.json (for system parsing) and report.html (for manual review), and uploaded to a reporting system (such as Allure or ReportPortal).

[0101] Understandably, condensing thousands of lines of logs into a single page of core information reduces manual reading time. By comparing "expectations vs. reality," testers and developers can quickly reach a consensus, avoiding finger-pointing. Standardized fields facilitate database entry and statistics, enabling continuous optimization of the knowledge base and scripts.

[0102] Step A30: Send the exception report to the tester so that the tester can correct the exception script and obtain the corrected test script. Then send the system bug to the developer so that the developer can correct the system bug and obtain the corrected software to be tested.

[0103] It should be noted that testers refer to QA engineers responsible for maintaining test assets. Their responsibility is to fix issues such as locators, wait strategies, and data dependencies in scripts, rather than modifying product code.

[0104] It should be noted that developers refer to RD engineers who are responsible for implementing product functions. Their job is to fix system bugs such as logical defects, boundary conditions, and performance issues in the code.

[0105] It should be noted that the corrected test script refers to the script version that has been stabilized again after being fixed by testers. This usually involves updating the locator or wait time in the knowledge base and committing to Git to trigger regression verification.

[0106] It should be noted that the corrected software to be tested refers to the software version that has been rebuilt after being fixed by the developers. It usually includes code submission, passing unit tests, and redeployment to the test environment.

[0107] In this embodiment, reports with the label "Abnormal Script" are automatically @mentioned by the test script author via DingTalk / WeChat / Slack, and a Jira Ticket (Type: Task, Priority: Medium) is created, along with a link to report.html. Reports with the label "System BUG" are automatically assigned to the product module manager via email / Jira, and a Bug Ticket (Type: Bug, Priority: High) is created, along with report.html, stack traces, and reproduction steps.

[0108] For the testing side: After receiving the report, the testers will modify the locator (e.g., id=btn-login-v2) according to the diagnostic suggestions, submit a PR, and merge it after code review.

[0109] For the development side: Developers analyze the stack trace, locate source code issues, fix them, and submit the code, triggering CI to rebuild the Docker image.

[0110] After the fix is ​​completed, the Jira Ticket status transitions to "Resolved," and the system automatically links to the original failed test case, providing an entry point for S50's "retest." S50 uses the corrected script to re-execute the test on the corrected software. If it passes, it triggers an update to the S60 knowledge base; if it still fails, it reports back to A10, forming a two-level feedback loop.

[0111] Understandably, automated routing eliminates the need for manual identification and referral, reducing average fix time. Testing and development teams each claim their own problem pools, avoiding finger-pointing and improving collaboration efficiency. Every fix contributes to the knowledge base; bug fixes can feed back into requirement documents (e.g., adding boundary conditions), and bug fixes directly update the knowledge base, achieving "fixing is learning."

[0112] Specifically, the step of sending the system bug to the developers for them to fix and obtain the fixed software to be tested further includes steps A31-A32: Step A31: Obtain the core information and environmental context information corresponding to the system bug. The core information includes the defect ID, severity, priority, scope of impact, reproduction steps, actual performance and expected behavior. The environmental context information includes the operating system version, browser type, database configuration, log files, and network packet capture data. It should be noted that the core information refers to the minimum necessary dataset to describe the nature of the bug, including: Defect ID: A globally unique identifier (e.g., BUG-2024-001) used for full lifecycle tracking.

[0113] Severity: The level of impact on system functionality, such as Critical (system crash), High (core function failure), Medium (minor function malfunction), and Low (UI defects).

[0114] Priority: The urgency of the fix, determined by a combination of severity and business impact (e.g., P0 = fix immediately, P1 = within this week, P2 = next iteration).

[0115] Scope of impact: Modules, user groups, or business scenarios affected by the defect (e.g., "affects all paid users of the Safari browser").

[0116] Reproducibility steps: The minimum reproducible path down to the operation, usually 3-5 steps, each step including input, action, and expectation.

[0117] Actual performance versus expected behavior: A comparative description, such as "Expected: Redirect to the order page after submission; Actual: Page blank, console error 500".

[0118] It should be noted that environmental context information refers to a complete environmental snapshot used for accurate reproduction, including: Operating system version: such as Windows 11 22H2, macOS Sonoma 14.1.

[0119] Browser type: such as Chrome 120.0.6099.71 (arm64), containing the User-Agent string.

[0120] Database configuration: database version, current schema version, key configuration items (such as isolation_level=READ_COMMITTED).

[0121] Log files: server application logs (ERROR level and above), slow query logs, and journalctl system logs.

[0122] Network packet capture data: HAR files (HTTP Archive) or Wireshark packet captures at the moment of failure, used to diagnose network layer problems such as interface timeouts and CORS errors.

[0123] Understandably, a complete environmental context eliminates the need for developers to guess at environmental differences, shortening local reproduction time. Severity and priority are automatically determined, avoiding delays caused by manual assessment. All information is packaged and archived to meet the defect tracking and auditing requirements of industries such as finance and healthcare.

[0124] Step A32: Based on the severity of the system bug and the preset task allocation strategy, the core information and environmental context information are sent to the developers, and tasks are allocated so that the developers can correct the system bug based on the task allocation results, and obtain the corrected software to be tested.

[0125] It should be noted that the preset task allocation strategy refers to intelligent routing rules based on organizational rules, personnel profiles, and historical data. The strategy includes: The modules are responsible for mapping: payment module - Zhang San (core developer), ui module - Li Si (front-end lead).

[0126] Load balancing: Dynamically distributes tasks based on the number of tasks in progress for each person in Jira to avoid overload.

[0127] Skill matching: Based on historical bug fixing records, "performance bugs" are assigned to experts who have fixed similar issues before.

[0128] On-call system: P0 / P1 level bugs are assigned to the on-call staff on priority.

[0129] Task assignment: Convert bugs into traceable work items (Jira Issue, Azure DevOps Bug, ZenTao Defect) and assign them to specific responsible persons.

[0130] Understandably, A31 provides accurate correction information, ensuring sufficient data; A32 precisely allocates correction tasks and performs the corrections, accurately assigning bugs to the most suitable personnel. Together, they form a closed loop of defect handling characterized by "complete data and intelligent routing," minimizing the lead time from discovery to fix.

[0131] Based on the first and second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to that in embodiments one and two above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 Before the step of processing the natural language requirement document using a preset large language model to obtain the test script, steps B10 to B40 are included: Step B10: Obtain sample data, which corresponds to the first data processing result; It should be noted that sample data refers to the input-output pairs used for training and validating the model. In software testing scenarios, it typically refers to: Input: A snippet of a natural language requirements document (e.g., "When a user enters an incorrect password, the system should prompt 'Incorrect password' and prohibit login").

[0132] The first data processing result (Ground Truth): The standard answer corresponding to this input, that is, the ideal test script or expected processing result pre-written by human experts, serves as an unshakable "gold standard".

[0133] Step B20: Process the sample data using the current large language model to obtain the second data processing result; It should be noted that the Current Large Language Model (Current LLM) refers to a model instance that is in the training / tuning process.

[0134] It should be noted that the second data processing result (Model Prediction) refers to the actual output generated by the current model on the sample data, i.e., the prediction script. This is a direct reflection of the model's current capabilities.

[0135] Step B30: Determine whether the first data processing result is consistent with the second data processing result; Step B40: If the first data processing result is inconsistent with the second data processing result, adjust the parameters of the current large language model. Based on the current large language model with adjusted parameters, return to the step of using the current large language model to process the sample data and obtain the second data processing result, until the first data processing result is consistent with the second data processing result, and obtain the preset large language model.

[0136] It should be noted that adjusting the parameters of the current large language model refers to updating the model weights in reverse based on inconsistent error signals. Specific methods include: Fine-tuning: Perform gradient descent on full or partial weights using supervised learning (SFT) to minimize the cross-entropy loss between the prediction and the ground truth.

[0137] LoRA / QLoRA: Frozen pedestal model, only trains low-rank adaptation matrix, saves 90% of GPU memory, suitable for small to medium sample sizes.

[0138] Prompt Tuning: It optimizes only the soft prompt embedding vector without changing the model weights, which is fast but has limited capacity.

[0139] Reinforcement Learning (RLHF): If the consistency determination is based on functional equivalence, a reward function can be designed and the PPO algorithm can be used to optimize the strategy.

[0140] It should be noted that the Preset Large Language Model (Preset LLM) refers to the final model that has undergone multiple iterations from B10 to B40, achieving 100% consistency on the training set (or reaching the target threshold on the validation set), and is a reliable version that can be deployed to the production environment.

[0141] Understandably, through model training, the model's capabilities are vertically integrated into the software testing domain, improving the grammatical accuracy of generated scripts. Iterative optimization ensures that the error decreases monotonically, avoiding the "oscillation" phenomenon of traditional LLM training. Efficient methods such as LoRA can effectively reduce training costs.

[0142] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the software testing method based on dual-model collaboration in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0143] This application also provides a software testing device based on dual-model collaboration, please refer to... Figure 4 The software testing device based on dual-model collaboration includes: Acquisition module 10, the acquisition module is used to acquire the natural language requirements document corresponding to the software to be tested in response to the software testing command; Document processing module 20, which is used to process the natural language requirement document using a preset large language model to obtain a test script; Test module 30, the test module is used to test the software to be tested based on the test script, and obtain software test results; Classification module 40, the classification module is used to verify and classify the software test result using a preset algorithm model if the software test result is a test failure, and to obtain abnormal scripts and system bugs; The correction module 50 is used to correct the abnormal script and the system bug to obtain a corrected test script and a corrected software to be tested. Based on the corrected test script and the corrected software to be tested, the module returns a step to test the software to be tested based on the software test script and obtain the software test result, until the software test result is successful and the software test is completed.

[0144] In one embodiment, the classification module further includes: The first determining unit is used to determine the target algorithm for verification and classification based on the natural language requirements document and the algorithm selection rules; The classification unit is used to verify and classify the software test results based on the target algorithm using a preset algorithm model, thereby obtaining abnormal scripts and system bugs.

[0145] In one embodiment, the correction module further includes: The second determining unit is used to determine the error log and failure screenshot corresponding to the abnormal script; The first generation unit is used to generate a standardized exception report based on the error log and the failure screenshot. The exception report includes script identifier, execution environment, failure time point, expected result and actual result comparison. The first correction unit is used to send the exception report to the testers so that the testers can correct the exception script and obtain the corrected test script, and to send the system bug to the developers so that the developers can correct the system bug and obtain the corrected software to be tested.

[0146] In one embodiment, the correction module further includes: The first acquisition unit is used to acquire the core information and environmental context information corresponding to the system BUG. The core information includes defect ID, severity, priority, scope of impact, reproduction steps, actual performance and expected behavior. The environmental context information includes operating system version, browser type, database configuration, log file, and network packet capture data. The second correction unit is used to send the core information and environmental context information to the developers based on the severity of the system bug and the preset task allocation strategy, and to allocate tasks so that the developers can correct the system bug based on the task allocation results, thereby obtaining the corrected software to be tested.

[0147] In one embodiment, the document processing module further includes: The third determining unit is used to determine the test type corresponding to the natural language requirement document based on the preset test type parsing model and the preset knowledge base; The fourth determining unit is used to determine the prompt word template and keyword extraction strategy corresponding to the natural language requirement document based on the test type. The first document processing unit is used to process the natural language requirement document using a preset large language model based on the prompt word template and the keyword extraction strategy to obtain a test script.

[0148] In one embodiment, the document processing module further includes: The second document processing unit is used to perform dependency parsing, semantic understanding and logical extraction on the natural language requirement document using a preset large language model, so as to obtain the functional objectives, input conditions, operation actions and expected results corresponding to the natural language requirement document. The second generation unit is used to generate a preliminary semantic representation structure based on the functional objective, the input conditions, the operation action, and the expected result; The third generation unit is used to generate test scripts based on the preset knowledge base, the preliminary semantic representation results, and the preset script generation rules.

[0149] In one embodiment, the software testing apparatus based on dual-model collaboration further includes a database update module, which further includes: The update unit is used to update the preset knowledge base based on the test script and the software to be tested corresponding to the successful test.

[0150] In one embodiment, the software testing device based on dual-model collaboration further includes a model training module, which further includes: The second acquisition unit is used to acquire sample data, which corresponds to the first data processing result. The data processing unit is used to process the sample data using the current large language model to obtain a second data processing result; A judgment unit is used to determine whether the first data processing result is consistent with the second data processing result; The iterative training unit is used to adjust the parameters of the current large language model if the first data processing result is inconsistent with the second data processing result, and based on the current large language model with adjusted parameters, return to the step of using the current large language model to process the sample data to obtain the second data processing result, until the first data processing result is consistent with the second data processing result, and obtain the preset large language model.

[0151] The software testing apparatus based on dual-model collaboration provided in this application, employing the software testing method based on dual-model collaboration in the above embodiments, can solve the technical problems of software testing based on dual-model collaboration. Compared with related technologies, the beneficial effects of the software testing apparatus based on dual-model collaboration provided in this application are the same as those of the software testing method based on dual-model collaboration provided in the above embodiments, and other technical features in the software testing apparatus based on dual-model collaboration are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0152] This application provides a software testing device based on dual-model collaboration. The software testing device based on dual-model collaboration includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the software testing method based on dual-model collaboration in the above embodiment 1.

[0153] The following is for reference. Figure 5 This document illustrates a structural schematic diagram of a software testing device based on dual-model collaboration suitable for implementing embodiments of this application. The software testing device based on dual-model collaboration in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 5 The software testing device based on dual-model collaboration shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0154] like Figure 5 As shown, the dual-model collaborative software testing device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the dual-model collaborative software testing device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the dual-model collaborative software testing equipment to exchange data wirelessly or via wired communication with other devices. Although a dual-model collaborative software testing equipment with various systems is shown in the figure, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0155] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0156] The software testing device based on dual-model collaboration provided in this application, employing the software testing method based on dual-model collaboration in the above embodiments, can solve the technical problems of software testing based on dual-model collaboration. Compared with related technologies, the beneficial effects of the software testing device based on dual-model collaboration provided in this application are the same as those of the software testing method based on dual-model collaboration provided in the above embodiments, and other technical features in this software testing device based on dual-model collaboration are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0157] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0158] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0159] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the software testing method based on dual-model collaboration in the above embodiments.

[0160] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, 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 devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0161] The aforementioned computer-readable storage medium may be included in a software testing device based on dual-model collaboration; or it may exist independently and not be assembled into a software testing device based on dual-model collaboration.

[0162] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by a dual-model collaborative software testing device, cause the dual-model collaborative software testing device to: In response to software testing commands, obtain the natural language requirements document corresponding to the software to be tested; The natural language requirement document is processed using a pre-defined large language model to obtain a test script; Based on the test script, the software to be tested is tested to obtain the software test results; If the software test result is a test failure, the software test result is verified and classified using a preset algorithm model to obtain abnormal scripts and system bugs. The abnormal script and the system bug are corrected to obtain a corrected test script and a corrected software to be tested. Based on the corrected test script and the corrected software to be tested, the software to be tested is tested based on the software test script to obtain the software test result. The process continues until the software test result is successful, and the software test is completed.

[0163] Computer program code for performing the operations of this application 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 the "C" language or similar programming 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).

[0164] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. 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 a 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, can 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.

[0165] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0166] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described software testing method based on dual-model collaboration, thereby solving the technical problems of software testing based on dual-model collaboration. Compared with related technologies, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the software testing method based on dual-model collaboration provided in the above embodiments, and will not be repeated here.

[0167] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the software testing method based on dual-model collaboration as described above.

[0168] The computer program product provided in this application can solve the technical problem of software testing based on dual-model collaboration. Compared with related technologies, the beneficial effects of the computer program product provided in this application are the same as those of the software testing method based on dual-model collaboration provided in the above embodiments, and will not be repeated here.

[0169] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A software testing method based on dual-model collaboration, characterized in that, The software testing method based on dual - model collaboration includes: In response to a software testing instruction, obtain the natural - language requirement document corresponding to the software to be tested; Use a preset large - language model to process the natural - language requirement document to obtain a test script; Based on the test script, test the software to be tested to obtain a software test result; If the software test result is a test failure, use a preset algorithm model to verify and classify the software test result to obtain an abnormal script and a system BUG; Correct the abnormal script and the system BUG to obtain a corrected test script and a corrected software to be tested. Based on the corrected test script and the corrected software to be tested, return to the step of testing the software to be tested based on the software test script to obtain a software test result until the software test result is a test success, and complete the software test.

2. The software testing method based on dual-model collaboration as described in claim 1, characterized in that, The step of using a preset algorithm model to verify and classify the software test result to obtain an abnormal script and a system BUG further includes: Based on the natural - language requirement document and an algorithm selection rule, determine a target algorithm for verification and classification; Based on the target algorithm, use a preset algorithm model to verify and classify the software test result to obtain an abnormal script and a system BUG.

3. The software testing method based on dual-model collaboration as described in claim 1, characterized in that, The step of correcting the abnormal script and the system BUG to obtain a corrected test script and a corrected software to be tested further includes: Determine the error log and failure screenshot corresponding to the abnormal script; Generate a standardized abnormal report based on the error log and the failure screenshot. The abnormal report includes script identification, execution environment, failure time point, comparison of expected results and actual results; Send the abnormal report to the tester for the tester to correct the abnormal script to obtain a corrected test script, and send the system BUG to the developer for the developer to correct the system BUG to obtain a corrected software to be tested.

4. The software testing method based on dual-model collaboration as described in claim 3, characterized in that, The step of sending the system BUG to the developer for the developer to correct the system BUG to obtain a corrected software to be tested further includes: Obtain the core information and environment context information corresponding to the system BUG. The core information includes defect ID, severity, priority, impact scope, reproduction steps, comparison of actual performance and expected behavior, and the environment context information includes operating system version, browser type, database configuration, log file, network capture data; Based on the severity of the system BUG and a preset task assignment strategy, send the core information and environment context information to the developer and perform task assignment for the developer to correct the system BUG based on the task assignment result to obtain a corrected software to be tested.

5. The software testing method based on dual-model collaboration as described in claim 1, characterized in that, The step of using a preset large - language model to process the natural - language requirement document to obtain a test script further includes: Based on a preset test - type parsing model and a preset knowledge base, determine the test type corresponding to the natural - language requirement document; Based on the test type, determine the prompt word template and keyword extraction strategy corresponding to the natural language requirement document; Based on the prompt word template and the keyword extraction strategy, the natural language requirement document is processed using a preset large language model to obtain a test script.

6. The software testing method based on dual-model collaboration as described in claim 5, characterized in that, The step of processing the natural language requirement document using a preset large language model to obtain a test script further includes: The natural language requirement document is subjected to dependency parsing, semantic understanding and logical extraction using a pre-defined large language model to obtain the functional objectives, input conditions, operation actions and expected results corresponding to the natural language requirement document. Based on the functional objective, the input conditions, the operation actions, and the expected results, a preliminary semantic representation structure is generated; Based on the preset knowledge base, the preliminary semantic representation results, and the preset script generation rules, a test script is generated. After the steps of completing the software testing process until the software test result is successful include: The preset knowledge base is updated based on the test script and the software to be tested corresponding to the successful test.

7. The software testing method based on dual-model collaboration as described in claim 1, characterized in that, Before the step of processing the natural language requirement document using a preset large language model to obtain the test script, the method further includes: Acquire sample data, which corresponds to the first data processing result; The sample data is processed using the current large language model to obtain the second data processing result; Determine whether the first data processing result is consistent with the second data processing result; If the first data processing result is inconsistent with the second data processing result, the parameters of the current large language model are adjusted. Based on the current large language model with adjusted parameters, the process of using the current large language model to process the sample data is returned to obtain the second data processing result. This process continues until the first data processing result is consistent with the second data processing result, thus obtaining the preset large language model.

8. A software testing device based on dual-model collaboration, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the software testing method based on dual-model collaboration as described in any one of claims 1 to 7.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the software testing method based on dual-model collaboration as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the software testing method based on dual-model collaboration as described in any one of claims 1 to 7.

Images