Test case generation method and device

Abstract

The embodiment of the invention provides a test case generation method and device.The method comprises the steps that a test case generation task is determined, and the test case generation task carries a target document, a task type and a document type of a to-be-generated test case; analyzing the target document according to the document type by using an information extraction agent to generate an analysis result of the target document; generating an intelligent agent by using a test point, and generating an initial test point according to the task type and the analysis result; and generating a first test case corresponding to the test case generation task by using a test case generation agent according to the initial test point and the analysis result. The analysis logic of a qualification test expert is simulated through a plurality of agents, and the efficiency and integrity of test case output are greatly improved.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a test case generation method. This specification also relates to a test case generation apparatus, a computing device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] Current software testing workflows typically encompass multiple stages, including test case writing, test case execution, and report generation. Among these, the heavy reliance on manual completion for test case writing has become a bottleneck hindering testing efficiency. While existing technologies have made progress in areas such as test execution automation, significant shortcomings remain in the test case writing stage: Firstly, it heavily relies on the tester's personal experience and business acumen, requiring manual cross-referencing of PRDs (Product Requirements Documents), design documents, historical test cases, and other multi-dimensional information, leading to inefficiency and a high risk of omissions. Secondly, under diverse employment models, varying skill levels among personnel can result in inconsistent test score quality. The lack of a unified, automated quality assurance mechanism necessitates a significant investment of senior engineers for manual review, making it impossible to guarantee delivery schedules and product quality at scale. Summary of the Invention

[0003] In view of the above, one or more embodiments of this specification provide a test case generation method, a test case generation device, a computing device, a computer-readable storage medium, and a computer program product to solve the technical problems of low efficiency and poor quality in the test case writing process in the prior art.

[0004] According to a first aspect of one or more embodiments of this specification, a test case generation method is provided, comprising: A test case generation task is determined, wherein the test case generation task carries the target document, task type, and document type of the test cases to be generated; An information extraction agent is used to parse the target document according to the document type and generate the parsing result of the target document; A smart agent is generated using test points. Initial test points are generated based on the task type and the parsing results. A smart agent is generated using test cases. Based on the initial test points and the parsing results, the first test case corresponding to the test case generation task is generated.

[0005] According to a second aspect of one or more embodiments of this specification, a test case generation apparatus is provided, comprising: The task determination module is configured to determine the test case generation task, wherein the test case generation task carries the target document, task type and document type of the test cases to be generated; The document parsing module is configured to use an information extraction agent to parse the target document according to the document type and generate the parsing result of the target document; The test point generation module is configured to generate an agent using test points, and generate initial test points based on the task type and the parsing results. The test case generation module is configured to generate an intelligent agent using test cases, and generate the first test case corresponding to the test case generation task based on the initial test points and the parsing results.

[0006] According to a third aspect of one or more embodiments of this specification, a computing device is provided, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the above-described test case generation method.

[0007] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores a computer program / instructions that, when executed by a processor, implement the steps of the test case generation method described above.

[0008] According to a fifth aspect of one or more embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the test case generation method described above.

[0009] The test case generation method provided in one or more embodiments of this specification includes: determining a test case generation task, wherein the test case generation task carries a target document for which test cases are to be generated, a task type, and a document type; using an information extraction agent to parse the target document according to the document type and generate a parsing result of the target document; using a test point generation agent to generate initial test points according to the task type and the parsing result; and using a test case generation agent to generate a first test case corresponding to the test case generation task according to the initial test points and the parsing result.

[0010] Specifically, this test case generation method breaks down the test case generation task into multiple levels of execution, including "parse result generation," "test point generation," and "test case generation." First, it calls an information extraction agent to parse the target document and generate parsing results. Then, it calls a test point generation agent to generate multiple initial test points based on the task type and parsing results. Finally, it calls a test case generation agent to generate the first test case for each initial test point. Firstly, by simulating the analysis logic of experienced testing experts through multiple agents, it automatically reads and integrates multi-dimensional information such as PRDs and design documents in the target document, directly transforming human experience into stable automated output. This overcomes the problem of test point omissions caused by insufficient or negligent human familiarity with the business, greatly improving the efficiency and completeness of test case output. Secondly, through the joint processing of multiple agents, it ensures that the generated test cases follow built-in best practices and standardized processes, eliminating fluctuations in test score quality caused by differences in human skill levels. This provides stable, reliable, and high-quality automated assurance, reducing excessive reliance on manual review by senior engineers. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram illustrating the application of a test case generation method provided in one embodiment of this specification; Figure 2 This is a flowchart of a test case generation method provided in one embodiment of this specification; Figure 3 This is a data mapping diagram in a test case generation method provided in one embodiment of this specification; Figure 4 This is a schematic diagram of the test account preparation and test execution process in a test case generation method provided in one embodiment of this specification; Figure 5 This is a schematic diagram of the structure of a test case generation device provided in one embodiment of this specification; Figure 6 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0014] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0015] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “an,” “an,” “the,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification includes any or all possible combinations of one or more associated listed items.

[0016] The terms “comprising,” “including,” or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded.

[0017] Although the terms "first," "second," etc., may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, "first" may also be referred to as "second," and similarly, "second" may also be referred to as "first," without departing from the scope of one or more embodiments of this specification. Ordinal numbers such as "first," "second," etc., do not necessarily indicate order; often they are used to facilitate the distinction of objects. For example, "first server" and "second server" usually refer to two servers. To distinguish these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0018] Depending on the context, the word "if" as used here can be interpreted as "when," "when," or "in response to determination."

[0019] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0020] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0021] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant regions, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0022] The technical solutions provided in one or more embodiments of this specification can employ deep learning models with relatively large model parameter scales. Here, "large model" is merely an example, and the one or more embodiments of this specification do not limit the number of model parameters supported by the deep learning model used, aiming to meet actual needs. The deep learning models involved in one or more embodiments of this specification can be artificial intelligence-based language models (LM), multimodal models (MM), large language models (LLM), multimodal pre-training models, etc.

[0023] In practical applications, large models only require a small number of samples to fine-tune the pre-trained model before they can be applied to different tasks. Large models can be widely used in fields such as Natural Language Processing (NLP) and Computer Vision. Specifically, they can be applied to computer vision tasks such as Visual Question Answering (VQA), Image Captioning (IC), and Image Generation, as well as NLP tasks such as text-based sentiment classification, text summarization, and machine translation. The main application scenarios for large models include digital assistants, intelligent robots, search, online education, office software, e-commerce, and intelligent design.

[0024] The following explains the terms and concepts used in one or more embodiments of this specification.

[0025] Credit business refers to financial services activities in which financial institutions or quasi-financial institutions provide financial support to eligible borrowers by assessing their credit risk, repayment ability, and the value of their collateral; typical scenarios include personal consumer loans, micro and small enterprise loans, and credit card installment payments.

[0026] Test Case: In software engineering, a test case is the smallest executable unit used to verify whether a system's functionality meets expected requirements. Each test case includes input data, expected results, operational steps, and judgment criteria. In credit business scenarios, test cases need to cover core business processes such as loan application, risk assessment, approval logic, credit limit calculation, and contract generation.

[0027] Test Analysis Document: A systematic summary document of the test case design process, execution results, and defect analysis. Content includes test objectives, test scope, test strategies, test case coverage, defect statistics, risk assessment, and improvement suggestions. In credit operations, this document must demonstrate the completeness of business rule verification, compliance checks, and abnormal scenario simulations.

[0028] Intelligent Generation: The process of automatically generating test cases and test analysis documents based on artificial intelligence technologies (such as natural language processing, machine learning, and knowledge graphs). Its core goal is to improve testing efficiency and quality by replacing repetitive manual work with data-driven and rule-based reasoning.

[0029] Natural Language Processing (NLP) is an important branch of computer science and artificial intelligence that aims to enable computers to understand, parse, and generate human language. In this specification, NLP technology is used to extract key information from credit business contracts, risk control rules, and user requirement documents as input for test case design.

[0030] Multimodal data refers to a collection of information that integrates heterogeneous data formats such as text, tables, flowcharts, and code. This specification uses multimodal data from credit business (such as loan contract terms, approval flowcharts, and risk control rule tables) to generate comprehensive test cases.

[0031] Dynamic Update Mechanism: This mechanism automatically adjusts the test case library and test analysis documents based on changes in credit business rules (such as policy adjustments or model upgrades) or test feedback results (such as defect fixes). This mechanism is implemented through a rules engine and version control to ensure that test assets remain synchronized with actual business operations.

[0032] Rule Engine: An automated decision-making system based on predefined business rules (such as "annual income exceeds twice the liabilities"). In this specification, the Rule Engine is used to verify whether test cases meet the compliance requirements of credit business and generate rule conflict analysis reports.

[0033] Coverage measures the extent to which test cases cover business processes, functional modules, or code paths. In credit business, coverage should reflect both business rule coverage (e.g., "all loan approval conditions are verified") and abnormal scenario coverage (e.g., "system fault tolerance when illegal parameters are input").

[0034] Compliance Check: The process of verifying whether the lending business complies with regulatory requirements or internal risk control standards. This manual uses compliance rules to automatically generate test cases to verify whether the system meets compliance constraints such as "prohibiting the issuance of consumer loans to students."

[0035] To address the technical challenges mentioned above, one approach is to employ a testing platform based on MBT (Model-Based Testing) and a large-model-driven test case generation technology. This platform supports drag-and-drop modeling of business process diagrams, automatically generates both manual and automated test cases, and uses reverse engineering tools to transform manual test cases into automated test cases. In other words, it allows testing experts to create test cases like drawing a process diagram. Figure 1 In this way, the software's operational logic (clicking this button, entering that data, and then a pop-up window) can be drawn on the computer. After viewing this "flowchart," the computer can automatically generate test cases (i.e., step-by-step operation instructions). Furthermore, it can transform test cases that previously required manual testing into scripts that the machine can run automatically. However, this technology suffers from high modeling complexity: it requires professionals to manually construct accurate system models (such as finite state machines or UML (Unified Modeling Language) diagrams), demands a deep understanding of business logic, and significantly increases the cost of modeling complex business rules (such as multiple conditions in credit risk control). It also lacks flexibility: the generated test cases rely on the static definition of the model, making it difficult to dynamically adapt to frequent changes in business rules; coverage of abnormal scenarios (such as inputting illegal parameters) requires additional configuration; automation is limited; maintenance costs are high: the model and test cases need to be updated synchronously; when business logic is adjusted, the model needs to be remodeled and the validity of the generated test cases verified; and reverse engineering capabilities are weak: converting manual test cases to automated test cases requires additional development tools, and the conversion efficiency is low, making it difficult to achieve a seamless "manual-automatic" workflow.

[0036] Another approach is to use test case generation technology based on natural language processing. This technology parses business requirement documents using natural language to generate structured test cases, supporting the generation of business logic mind maps and multi-scenario coverage analysis. However, this technology has semantic limitations: it relies on the semantic understanding capabilities of pre-trained models, resulting in insufficient accuracy in parsing complex business rules (such as risk assessment formulas in credit), weak ability to integrate and process multimodal data (such as contract terms and flowcharts), and insufficient coverage. The generated test cases may omit boundary conditions or abnormal scenarios, requiring manual supplementation, and the response speed to compliance checks (such as changes in regulatory policies) is slow.

[0037] Both MBT and NLP models share a common pain point: when processing large amounts of complex information at once, it's easy to miss key points, misunderstand, or generate irrelevant content. Figure 1 Generating use cases directly from requirements in a step-by-step manner resulted in poor performance.

[0038] To address the aforementioned technical deficiencies, one or more embodiments of this specification provide a data processing method that, through a Multi-Agent architecture, breaks down the test case generation task into multiple defined steps, each collaboratively completed by different specialized agents. One or more embodiments of this specification also relate to a data processing apparatus, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0039] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0040] See Figure 1 , Figure 1 This is a schematic diagram illustrating the application of a test case generation method provided in one or more embodiments of this specification.

[0041] Figure 1 The technology showcased is an AI (Artificial Intelligence) assisted test analysis and generation technology solution that uses a historical knowledge base as its core and integrates human and machine collaboration.

[0042] Specifically, when the system receives a test case generation task, it obtains the project documents (PRD, design documents, etc.) carried in the task as raw input. First, it invokes an information extraction agent to analyze the project document based on its document type, understanding project goals, system context, and other information, generating a parsed result for the project document. Furthermore, after obtaining the parsed result, the system can also invoke a test strategy generation agent to generate a preliminary test strategy suggestion based on the parsed result, such as: "A new interface has been detected; it is recommended to focus on functional testing, interface performance testing, and security testing." Based on this preliminary test strategy suggestion, test engineers can adjust the test strategy through a visual interface, such as confirming, modifying, or re-formulating the test strategy.

[0043] Secondly, the system invokes the test point generation agent to generate one or more test points based on the test strategy and the parsing results of the project document. During test point generation, the agent references historical scoring documents from the knowledge base to deduce historical test points and their design principles. Next, the system invokes the test case generation agent to generate one or more test cases based on the test points and the parsing results of the project document. Similarly, during test case generation, the agent references historical scoring documents from the knowledge base, considering their design principles and step arrangements. Finally, the system invokes the test analysis document generation agent to generate a test document—the scoring document, or test case analysis report—based on the parsing results of the project document, the test points, and the test cases.

[0044] To ensure the accuracy and completeness of the scoring documents, after they are generated, they can be manually adjusted and confirmed by testing experts. For example, testing experts can add, delete, or modify the scoring documents.

[0045] The test case generation method provided in one or more embodiments of this specification firstly breaks down the test case generation task into multiple levels of tasks such as "test point generation" and "test case generation," which are then processed step by step by a dedicated intelligent agent. The system can thoroughly read all change points and project documents to ensure the completeness of the test scope. Simultaneously, by introducing a historical test knowledge base, the intelligent agent can refer to and imitate complex scenarios and boundary cases in historical test solutions during the generation process. This completely overcomes the shortcomings of AI "speaking nonsense in a serious manner" and generating overly direct and superficial content, making the generated test points and test cases closer to actual testing habits, possessing expert-level testing depth, and achieving precise and in-depth test analysis. Secondly, the system can intelligently identify and introduce regression test cases related to the current change points from the historical test knowledge base. This effectively solves the problem that traditional automated scripts cannot automatically generate regression test cases due to a lack of input, forming an automated fallback protection for core functions, greatly reducing the risk of introducing unknown faults due to modifications, and providing high-quality automated regression testing assurance. Finally, the solution transforms personal experience into reusable organizational assets, drives intelligent agents to generate outputs through a knowledge base, ensures high quality and consistency of test outputs from different personnel and projects, solves the quality fluctuation problem caused by skill differences under a diversified employment model, and provides stable and reliable automated quality assurance for the testing process.

[0046] See Figure 2 , Figure 2 This is a flowchart of a test case generation method provided in an embodiment of this specification.

[0047] From a programming perspective, the entity executing the process can be a program hosted on an application server or application terminal. It can be understood that this method can be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities.

[0048] like Figure 2 As shown, the process may include the following steps: Step 202: Determine the test case generation task.

[0049] The test case generation task includes the target document, task type, and document type for which test cases are to be generated.

[0050] Specifically, the application scenarios of the test case generation method provided in one or more embodiments of this specification include, but are not limited to, iterative development testing application scenarios: for example, development teams iterate periodically, adding new features or optimizing existing features; large-scale refactoring and system migration application scenarios: for example, splitting a monolithic application into microservices, data migration, changing the underlying framework, etc.; compliance and security audit application scenarios: for example, software in industries such as finance or healthcare needs to meet strict compliance requirements, and each release requires compliance verification; and acceptance testing application scenarios: for example, before delivery to customers or business partners for acceptance testing, test scenarios covering core business processes need to be prepared. In practical applications, the application scenarios of the test case generation method provided in one or more embodiments of this specification are not limited to the above application scenarios; any application scenario that requires a systematic and high-quality design of test plans can be adapted.

[0051] The test case generation task can be understood as a core part of the software testing process, which is used to verify whether the software system or its specific parts (such as functional modules or code paths) work as expected.

[0052] Target documents can be understood as one or more formal documents that describe relevant information about the software system and serve as the basis and source for test case design. They are crucial reference materials for testers to understand "what the software should do" and "how it should work correctly."

[0053] The task type can be understood as the nature and scope of this test analysis, which determines the processing logic and scope of the entire Agent workflow. Based on the task type, the system can determine whether to focus on finding change points (iterative testing) or ignore change points and perform a full scan (full regression), etc. Task types include, but are not limited to, new feature testing (testing for newly developed functional modules), iteration / optimization testing (testing for modifications to existing functions), and bug fix verification testing (testing for fixing a specific bug), etc.

[0054] Document type can be understood as the form of the target document. The document type determines the reading method and analysis focus of the subsequent information extraction agent and change point identification agent. Document types include, but are not limited to, product requirement documents (e.g., containing detailed business logic, rules, and prototype diagrams), design documents (e.g., containing interface definitions, database changes, and technical solutions), UI (User Interface) / UX (User Experience) design drafts (the agent will attempt to parse the elements and interaction logic within them to generate test cases related to front-end interaction and interface validation), and other document types.

[0055] Here's a concrete example of implementing a test case generation task: On the system's visual interface, the user clicks "Create Test Case Generation Task." Upload Documents: Drag and drop or upload one or more requirement / design documents related to this iteration into the system. Configure Parameters: The system may automatically parse the documents and pre-fill some parameters. The user needs to confirm or select: task type, associated historical knowledge base, regression strategy, or document type, etc. Start Task: After clicking the "Start Generation" or "OK" button, the user creates the test case generation task. The system can then create test cases based on this task.

[0056] Step 204: Utilize the information extraction agent to parse the target document according to the document type and generate the parsing result of the target document.

[0057] Among them, the information extraction intelligent agent, also known as the information extraction agent, is used to convert unstructured natural language documents into structured, machine-readable data. Specific implementation technologies for parsing target documents based on document type using the information extraction agent include, but are not limited to, rule-based and template-based parsing techniques, natural language processing and named entity recognition techniques, multimodal information extraction techniques, and information extraction and structured output techniques from large language models.

[0058] The parsing results include, but are not limited to, system and project identifiers, key business terms and entities, and document structure information. System and project identifiers can be understood as: which large system the current project or function belongs to (e.g., "consumer credit core system," "enterprise risk control platform"); project / iteration background: overview information such as the goals of this development and the business problems to be solved. Key business terms and entities can be understood as: key business objects (e.g., "loan application," "credit limit," "interest rate," "user"), status (e.g., "approved," "disbursed"), and rules mentioned in the extracted target document. Document structure information can be understood as the chapters, titles, lists, etc., in the identified target document, revealing the structured relationships within the content.

[0059] A specific example illustrating the implementation of "using an information extraction agent to parse the target document according to the document type and generate the parsing result of the target document" is provided below: After the user clicks the "Start" button, the system receives and executes the test case generation task. Specifically, the system first loads all target documents uploaded by the user and calls the information extraction agent to work. At this time, the information extraction agent is activated and quickly scans and parses the uploaded target documents, generating the parsing result of the target document based on the extracted key information.

[0060] Assumption: A user uploaded a PRD titled "Iteration of the 'AA' product discount rate function".

[0061] The information extraction agent will perform a quick scan and output the following structured information (i.e., the parsing result): System Name: Consumer Credit Core System.

[0062] Project Background: To add a preferential rate feature for high-quality users to the "AA" product in order to improve conversion rates.

[0063] Key Entities: [Preferential Rates, Premium Users, Credit Score, Interest Rates] Related modules: User credit assessment module, interest rate calculation module, order generation module.

[0064] Therefore, the subsequent change point identification agent will know to look for modification points related to "preferential rates" in that document. When a knowledge base needs to be referenced, the system will also intelligently recommend the historical test knowledge base of the system based on the name "Consumer Credit Core System". The test point generation agent will also know that the test cases it generates are about "interest rate" calculations and will use business terms such as "credit score".

[0065] Step 206: Generate an agent using test points. Generate initial test points based on the task type and the parsing results.

[0066] After extracting the Agent using information and generating the parsing results of the target document, the Agent can be generated using test points. Initial test points can be generated based on the task type and parsing results.

[0067] However, a PRD or design document is often voluminous, containing a large amount of background information, overviews, unchanged design elements, and references. This constitutes "noise" for test analysis. If the test point generation agent directly generates test points based on the task type and parsing results, it will attempt to generate test points for all functions described in the document, including those that already exist and are not currently being used. This results in a large number of redundant test points in the initial generated test points. To avoid this, before generating initial test points using the test point generation agent based on the task type and parsing results, a change point identification agent is used to generate change points. Then, the test point generation agent generates test points based on these change points. The specific implementation is as follows: After the information extraction agent parses the target document according to the document type and generates the parsing result of the target document, the method further includes: The agent is identified by using change points. The parsing results are analyzed according to the task type to obtain change analysis results, and change points are generated based on the change analysis results. The process of generating an intelligent agent using test points, based on the task type and the parsing results, includes generating initial test points, including: A smart agent is generated using test points. Initial test points are generated based on the change points and the analysis results.

[0068] Among them, the change point identification agent, also known as the change point identification agent, is used to find all the places that have changed in the parsing results of the target document.

[0069] The task type tells the change point identification agent which mode or filter to use to analyze the parsing results, determining the granularity and rigor of the agent's analysis. In other words, based on the task type, the system can determine how to invoke the change point identification agent, guiding its operation. For example, if the task type is new feature testing, the system will invoke the change point identification agent and give it the instruction: "Treat the document content as a completely new feature and extract all feature points." The change point identification agent will then utilize the powerful reasoning capabilities of the Large Language Model (LLM) to carefully read the parsing results; it will look for keywords in the results that hint at "changes" or "additions," such as: "Added XX feature," "Optimized YY process," "Supported ZZ on the original basis," "Deprecated the old AA method." By understanding these semantics, the LLM can infer which parts are likely to be the change points. If the task type is iteration / optimization testing, the system will invoke the change point identification agent and give it the instruction: "Strictly compare and analyze to identify the added and modified points." The specific implementation is as follows: The information extraction agent parses key information such as the system name, document ID, and version number from the current document. Using this information, the system automatically searches for the previous version of the document in the version control system. Once found, it automatically retrieves the previous version as the old version baseline. At this point, the changepoint identification agent receives both the new and old versions of the document and performs a precise difference comparison. If the task type is a bug fix verification test, the system will call the changepoint identification agent and give it the instruction: "Focus on changepoints related to bug fixing." The changepoint identification agent first parses the bug ticket, extracts key information (such as defect symptoms and reproduction steps), and identifies the associated code commit. Next, it retrieves and analyzes the code differences (Diff), accurately locating the modified files, functions, and specific logic. Finally, it generates high-precision changepoints, such as "The XX function has added a YY conditional judgment to fix the ZZ problem," directly indicating the code-level modifications that need to be verified in the test, ensuring that the verification activity is focused and efficient.

[0070] Specifically, the change point identification agent performs change analysis on the parsed results based on the task type. This can be achieved through techniques such as difference comparison (if there is an old version of the document, a text or structured difference comparison will be performed), semantic understanding (using NLP technology to understand the meaning of the content. For example, it can determine that "a certain level field has been added" is a feature change, while "a typo has been corrected" is not), rule matching (filtering based on predefined rules (e.g., all sentences starting with "added", "modified", or "deleted" are important)), and correlation inference (if interface parameters are modified, it can infer that related callers may be affected).

[0071] Change analysis results can be understood as the output of the change point identification agent performing change analysis on the parsed results based on the task type. For example, a change analysis result might be a record: "In the 'User Management' section, the 'Add User Status Field' was mentioned."

[0072] Changepoints can be understood as the final output of a changepoint identification agent after cleaning, merging, and classifying the change analysis results. A changepoint identification agent typically generates a list of changepoints, where each item is a clear description of a changepoint. For example: [Changepoint 1: A 'Member Level' field is added to the user table; Changepoint 2: A 'level' parameter is added to the query interface].

[0073] Therefore, after identifying the agent using change points, performing change analysis on the parsing results according to the task type, obtaining change analysis results, and generating change points based on the change analysis results, the agent can be generated using test points, and initial test points can be generated based on the change points and the parsing results.

[0074] Among them, the test point generating agent, also known as the test point generating agent, is used for test point design.

[0075] The specific implementation is as follows: The test point generation agent receives change points from the change point list (e.g., "a new 'Member Level' field is added to the user table") and the parsing results. Specifically, the change point list is a condensed, target-specific checklist. It only records "what has changed?" For example: [Change point 1: A new 'Member Level' field is added to the user table, Change point 2: A 'level' parameter is added to the query interface]. Through this change point, we only know that we want to test the "Member Level" field, but what are the business rules for this field? What are its enumeration values? These are not reflected in the change point. The parsing results, on the other hand, are complete structured information extracted from the target document of the original requirements, providing rich business background and details; including: system background, business terminology, specific functional rules, interface definitions, data dictionary, etc. For example, in its data dictionary section, it might explicitly record: Member Level: enumeration type, optional values: [1-Level 1, 2-Level 2, 3-Level 3, 4-Level 4]. Therefore, the test point generation agent can know "what has changed" based on the change point and "what it is and why it exists" based on the parsing results. It can generate test points based on a full understanding of the change point.

[0076] When generating test points, the Test Point Generation Agent iterates through each change point in the "Change Point List" and performs the following operations: For a single change point (taking "Add 'Member Level' field" as an example), the Test Point Generation Agent reads the parsing results, obtains the detailed business rules for the current change point, and concretizes the general test pattern to the current business scenario. From the parsing results, it is confirmed that the Member Level is an enumeration field with valid values ​​of 1, 2, 3, and 4; then, a comprehensive and precise test strategy is generated, producing structured test points. For example, the test point is: verify that the Member Level field can successfully write valid values ​​(1, 2, 3, 4) and persist them to the database.

[0077] The test case generation method provided in one or more embodiments of this specification firstly utilizes a changepoint identification agent to filter out newly added, modified, and deleted content (signals) from the parsing results during the current iteration. This content serves as the sole input for subsequent analysis. The test point generation agent no longer needs to process the noisy, structured parsing results of an entire document, which would otherwise result in a large number of invalid tests on existing functions and unchanged parts, thus resolving the signal and noise problem. Secondly, the regression test identification agent can also identify changepoints generated by the agent based on changepoints, analyze which existing functions these changepoints affect, and thus accurately recall relevant regression test cases.

[0078] To ensure the accuracy and completeness of subsequent test point generation based on change points, an analysis report corresponding to each change point can be generated first, allowing for adjustments to the change points based on this report. The specific implementation method is as follows: After the process of using change point identification agents to perform change analysis on the parsing results according to the task type, obtain change analysis results, and generate change points based on the change analysis results, the process further includes: Using a change analysis agent, text analysis is performed on the change points to generate analysis reports corresponding to the change points.

[0079] Among them, the change analysis agent, also known as the change analysis agent, is used to perform text analysis on change points and generate analysis reports corresponding to the change points.

[0080] A specific example is given to illustrate "using a change analysis agent to perform text analysis on the change points and generate an analysis report corresponding to the change points".

[0081] First, the change analysis agent performs text analysis on the change points, including deep text analysis, detailed impact scope analysis, and knowledge linking. Deep text analysis goes beyond simply extracting keywords; it aims to understand the intent and essence of the change. For example, the original change point, "The parameter list of the bb function has been modified," is analyzed as follows: "This change is to support the new compound interest calculation rules. The core change is in the interest calculation module, where the bb parameter has been added, which will directly affect the final calculated user interest amount." Detailed impact scope analysis provides a more specific and clear explanation of the change point's impact. For example, the original change point, "The user table has added a cc field," is analyzed as follows: "This change will affect the following aspects: Database: The user table structure has changed, adding a new column; Backend: The creation, update, and query interfaces for the user service need to be adapted." Knowledge linking connects the change point with existing system knowledge, providing context. For example, in the analysis report, the change point "Optimized the performance of the payment interface" is directly linked to historical "payment timeout" fault tickets and the architecture diagram of the "core payment process," explaining the background and value of this optimization.

[0082] Then, based on the analysis results, the change analysis agent generates analysis reports corresponding to the change points. Furthermore, it can convert the text-based analysis reports into intuitive visual charts.

[0083] Of course, in practical applications, the Change Point Identification Agent can also directly perform text analysis on the change points after they are generated, and generate corresponding analysis reports. The specific implementation method is the same as that of the Change Analysis Agent, and will not be elaborated upon here.

[0084] The test case generation method provided in one or more embodiments of this specification, by using more analysis agents or change point identification agents to generate change analysis reports corresponding to change points, greatly reduces the threshold for testers to understand code changes and provides them with solid data support for efficient and targeted (i.e., "secondary processing and customization") test design.

[0085] In practical applications, to ensure that the generated test points better align with user understanding, historical test knowledge bases can be referenced during test point generation. The specific implementation method is as follows: The test case generation task also includes an associated historical knowledge base; The process of generating an intelligent agent using test points, based on the change points and the parsing results, includes generating initial test points, including: An intelligent agent is generated using test points. The agent searches the associated historical knowledge base based on the change points to obtain a first search result. Based on the first search result and the parsing result, an initial test point is generated.

[0086] The associated historical knowledge base can be understood as one or more knowledge bases selected by the user from multiple existing historical knowledge bases that are most relevant to the current task. This historical knowledge base stores historical testing assets and experience, including historical test plans, test cases, discovered bugs, business rule documents, etc., and is typically processed using vectorization techniques for easy intelligent retrieval. Different projects or business lines (such as "consumer credit," "corporate risk control," and "payment settlement") have completely different testing habits, business rules, and specialized terminology. Subsequent test point generation agents will "imitate" historical test cases from the specified associated historical knowledge base to ensure that the generated test points conform to the business language and testing specifications of the current project.

[0087] This associated historical knowledge base is selected by the user when creating a test case generation task. Based on this associated historical knowledge base, the system can determine when executing the test case generation task: "In this task, all agents that need to refer to historical experience can look for answers in this specified associated historical knowledge base; for example, when the process reaches the test point generation stage, when the test point generation agent starts working, it can know which associated historical knowledge base it is authorized to use; and it will directly use the change points in the 'change point list' as search keywords to search and match in the specified associated historical knowledge base."

[0088] Following the previous example, this paper illustrates how to generate an agent using test points, retrieve the associated historical knowledge base based on the change points to obtain a first retrieval result, and generate initial test points based on the first retrieval result and the parsing result.

[0089] The specific operation steps are as follows: The test point generation agent will traverse each change point in the "Change Point List" and perform the following operations: For a single change point (taking "Add 'Member Level' field" as an example).

[0090] First, search the related knowledge base based on the change point: using the core concepts of the current change point (such as "new field", "member level", "enumeration field") as keywords, initiate a vector search or keyword search to the related historical knowledge base to retrieve all relevant test cases and test plans for testing "new field" and "enumeration type field" in the past.

[0091] Obtain the first search result: retrieve N most similar historical test cases (e.g., test cases that tested the "user name" and "user status" fields in history).

[0092] Based on the initial search and analysis results, initial test points are generated: Test point generation reads the analysis results to obtain detailed business rules for the current change point, specifying the general testing pattern to the current business scenario. From the analysis results, it is confirmed that the membership level is an enumeration field with valid values ​​of 1, 2, 3, and 4. Then, the test point generation Agent performs reasoning: for example, mimicking history: "What aspects were tested when testing the 'user name' field historically?" -> e.g., valid values, invalid values, boundary values, database storage, and front-end display. Applying rules: "What are the standard testing strategies for enumeration fields?" -> e.g., equivalence class partitioning (valid / invalid), boundary values ​​(maximum value, minimum value). Integrating business: "How should I design the test based on the specific business rules of 'membership level'?" -> e.g., values ​​1, 2, 3, and 4 represent different levels, and it is necessary to verify the correctness of their business logic. Finally, a comprehensive and accurate testing approach is generated and transformed into a structured natural language description, forming a structured test point. For example, Test Point 1: Verify that the membership level field can successfully write valid values ​​(1, 2, 3, 4) and persist them to the database. Test Point 2: Verify that when an invalid value (such as 0, 5, 'abc') is input, the system provides a clear error message. Test Point 3: Verify that the API response and the front-end interface correctly display the business meaning corresponding to the membership level (e.g., 1 is displayed as 'Normal'). Test Point 4: Verify the system's processing logic when the membership level field is empty.

[0093] The test case generation method provided in one or more embodiments of this specification enables the test point generation agent to retrieve and reference historical test plans in real time when generating test points. Referencing historical test plans automatically covers test dimensions that are easily overlooked by beginners, such as boundary values, abnormal scenarios, compatibility, and security. This effectively avoids the problem of overly direct and superficial generated content, significantly improving the depth and comprehensiveness of test point generation. Furthermore, it transforms personal experience into reusable organizational assets, ensuring that test points generated by different personnel at different times maintain a high and stable quality level, solving the problem of quality fluctuations caused by differences in personnel skill levels, and guaranteeing the output quality and consistency of test points. Finally, it enables test design based on enhanced reasoning from historical experience, resulting in test points that better conform to actual testing habits, greatly reducing the workload of manual supplementation and correction, and achieving intelligent generation of test points.

[0094] Step 208: Generate an intelligent agent using test cases. Based on the initial test points and the parsing results, generate the first test case corresponding to the test case generation task.

[0095] After generating the test points, the test cases can be used to generate the intelligent agent. Based on the initial test points and the parsing results, the first test case corresponding to the test case generation task can be generated.

[0096] Similar to generating test points, to ensure that the generated test cases better align with user understanding, historical test knowledge bases can be referenced during test case generation. The specific implementation method is as follows: The test case generation task also includes an associated historical knowledge base; The step of generating an intelligent agent using test cases involves generating a first test case corresponding to the test case generation task based on the initial test points and the parsing results, including: The test case is used to generate an intelligent agent, which retrieves the associated historical knowledge base based on the initial test point to obtain a second retrieval result, and generates a first test case corresponding to the test case generation task based on the second retrieval result and the parsing result.

[0097] Among them, the test case generation agent, also known as the test case generation agent, can be understood as transforming the abstract test point test ideas into specific, executable operation steps.

[0098] The second search result can be understood as a set of historical test cases related to the initial test point, retrieved from the associated historical knowledge base using the initial test point as the search request.

[0099] Specifically, the initial test point, parsing results, and associated knowledge base are input into the test case to generate an Agent. The Agent generated from the test case iterates through each initial test point and performs the following operations for the current initial test point: First, the test case generation agent parses the intent of the current initial test point and understands its verification objective. For example, when validating invalid input values ​​(such as 0, 5, 'abc'), the system provides a clear error message. The test case generation agent understands its intent as "exception handling" and "invalid input validation." Based on the intent of the current initial test point, it retrieves similar historical test cases from the associated historical knowledge base for subsequent learning of their design patterns, step structures, and expression styles. For example, it retrieves a historical test case for "testing invalid name input": Steps: Enter '1' in the name field and click save; Expected result: Prompt "Name input is invalid".

[0100] Secondly, the test case generation agent uses the parsing results to transform abstract intents into specific test data that conforms to the current business requirements. For example, from the parsing results, it knows that the valid values ​​for "Member Level" are 1, 2, 3, and 4. Therefore, it can intelligently deduce: Illegal values / test data: 0, 5, 99, -1, "ABC", "" (empty string), NULL; Boundary values / test data: 1 (lower limit), 4 (upper limit); Valid values / test data: 2, 3 (for other test cases).

[0101] Finally, the test case generation agent uses historical test cases as a reference template, intelligently inferring information from the parsed results to populate a standard test case template, generating the final executable first test case. For example: Test Case ID: TC_LEVEL_002; Title: Verify the system's handling of an invalid integer value of 5 when the Membership Level field is entered; Preconditions: The user is logged in and has entered the information editing page; Test Steps: Enter the number 5 in the Membership Level input box and click the "Save" button. Expected Result: The system displays the error message: "Membership Level values ​​range from 1 to 4." Data was not successfully saved.

[0102] Ultimately, the test case generation agent automates this repetitive task that previously required a lot of manual work by mimicking the design patterns of historical test cases and injecting specific business rules and data, thereby improving testing efficiency.

[0103] The test case generation method provided in one or more embodiments of this specification achieves "standardized, high-quality automated generation" of test cases by introducing a historical knowledge base as a reference during test case generation, thus solving the quality and efficiency bottlenecks in the test case writing stage. First, the test case generation agent directly references the steps, data, and assertion methods of historical test cases, generating "first test cases" that are rich in detail and highly executable, avoiding common problems such as vague step descriptions and lack of checkpoints, and improving the accuracy and operability of test case steps. Second, the knowledge base reflects the team's inherent test design habits and expression styles, ensuring that the AI-generated test cases maintain a high degree of consistency with historical test cases in terms of step organization, language description, and data naming, significantly improving the readability and maintainability of the test suite and unifying team style and standards. Finally, with this test case generation agent, test engineers only need to review and optimize the AI-generated, already highly complete test cases, without having to write them from scratch. This allows them to focus their efforts on more complex test scenario design and strategy analysis, greatly improving the efficiency of test case generation. Therefore, after generating the first test case, the test analysis document generation agent can be invoked to generate the test analysis report corresponding to the test case generation task. The specific implementation method is as follows: After generating the first test case corresponding to the test case generation task based on the initial test points and the parsing results, the method of generating an intelligent agent using test cases further includes: A smart agent is generated using test analysis documents. Based on the parsing results, the change points, the initial test points, and the first test case, a test case analysis report corresponding to the test case generation task is generated.

[0104] The test analysis document generation agent, also known as the test analysis document generation agent, is an intelligent agent responsible for assembly, formatting, and presentation. It integrates the results generated by the upstream information extraction agent, change point identification agent, test point generation agent, and test case generation agent into a clearly structured, professional, and deliverable final document. In other words, the test analysis document generation agent is responsible for information integration, structural organization, and format rendering.

[0105] Specifically, after obtaining the analysis results, change points, initial test points, and first test cases, the analysis results, change points, initial test points, and first test cases are input into the test analysis document generation agent. The test analysis document generation agent will then integrate these four parts into a complete test analysis document (such as a Word or PDF document).

[0106] The specific implementation is as follows: First, the Test Analysis Document Generation Agent establishes a standard document framework template, which defines the chapter structure of the test analysis document. Second, like filling in blanks, the Test Analysis Document Generation Agent matches the outputs of each upstream agent to the corresponding chapters in the template; for example, Chapter 1: Revision History (automatically generated by the Test Analysis Document Generation Agent with version, date, and author information); Chapter 2: Project Background and Test Scope (filled in: system name, project background, and test objectives generated by the Information Extraction Agent); Chapter 3: Changepoint Analysis (filled in: a list of changepoints generated by the Changepoint Identification Agent); Chapter 4: Functional Test Design (filled in: the outputs of the Test Point Generation Agent and the detailed test case set generated by the Test Case Generation Agent, etc.). Then, the Test Analysis Document Generation Agent applies predefined document styles (such as applying corresponding fonts and sizes to different levels of headings, tabulating test cases, and ensuring neat formatting) to ensure aesthetically pleasing and consistent output. It may also perform consistency checks and optimizations, rendering the final formatted content into a test case analysis report in the target format (such as .docx, .pdf). Additionally, the test case analysis report can be saved to a specified location, and the user can be notified that the test case generation task is complete.

[0107] The test case generation method provided in one or more embodiments of this specification utilizes test analysis documents to generate agents, integrating the intelligent outputs of all previous agents into a final, directly usable result, forming an automated closed loop. This avoids the problems of inconsistent formats and time-consuming manual integration, ensuring that the output maintains a professional standard and improving the professionalism and readability of the test case analysis report. Furthermore, the template-based approach ensures that each generated test score document is structurally complete, covers all necessary aspects, and has no major omissions, guaranteeing the completeness of the test case analysis report.

[0108] To improve the efficiency of understanding, communication, and review of test analysis results, the test case analysis report can be visualized after it is generated. The specific implementation method is as follows: After generating an intelligent agent using test analysis documents, and generating a test case analysis report corresponding to the test case generation task based on the parsing results, the change points, the initial test points, and the first test case, the method further includes: A smart agent is generated using visualized images to perform graphical processing on the test case analysis report, thereby obtaining a visualized image analysis report corresponding to the test case analysis report.

[0109] Among them, the visualization image generation intelligent agent, also known as the visualization image generation agent, is a specialized intelligent agent responsible for data visualization and graphical representation. It involves converting the structured text and data information in test case analysis reports into graphics, charts, and diagrams that are easier for users to quickly understand and remember.

[0110] Graphics processing can be understood as the process by which an agent analyzes, refines, and visually transforms test case analysis reports, including but not limited to information extraction: identifying key entities (such as systems, modules, and interfaces) and relationships (such as calls, dependencies, and inclusions) from the report; visual mapping: determining which type of chart is most suitable (such as architecture diagrams, flowcharts, mind maps, and sequence diagrams); and layout and rendering: automatically generating the final image file (visualized image analysis report).

[0111] Visual image analysis reports can be understood as graphical versions of test case analysis reports, including but not limited to mind maps, system architecture diagrams, flowcharts, and pie charts showing test case distribution.

[0112] Specifically, a visualization image generation agent is used to perform graphical processing on the test case analysis report to obtain a corresponding visualization image analysis report. This can be understood as the visualization image generation agent automatically converting the test case analysis report into a visual mind map (facilitating macro-level review, quick memorization and display, complementing the detailed linear document, improving readability and maintainability), and outputting an additional visualization image analysis report.

[0113] The test case generation method provided in one or more embodiments of this specification utilizes a visual image generation agent to generate a visual image analysis report. A clear visual image analysis report, such as a mind map, allows project members (product, development, testing, and management) to grasp the test scope, key points, and overall logic at a glance within minutes, greatly improving information absorption. Furthermore, in review meetings, the visual image analysis report provides a common, unambiguous focus for discussion, making communication more precise and efficient, and making it easier to discover logical flaws or insufficient coverage in the design. Simultaneously, graphical information better aligns with human memory patterns, allowing key testing strategies and inter-system dependencies to be visually preserved, becoming a visual asset of the project, facilitating subsequent auditing and traceability.

[0114] To intelligently analyze the impact scope of each change, historical functional test cases requiring regression testing can be automatically identified from the associated historical knowledge base, preventing situations where "modifying function A breaks function B". The specific implementation method is as follows: The test case generation task also includes an associated historical knowledge base and a regression strategy. After the process of using change point identification agents to perform change analysis on the parsing results according to the task type, obtain change analysis results, and generate change points based on the change analysis results, the process further includes: The system identifies intelligent agents using regression testing, performs regression analysis on the change points according to the regression strategy, obtains regression analysis results, and determines system-related components based on the regression analysis results; and The system-related components are used to retrieve the associated historical knowledge base to obtain a third retrieval result, and a second test case is determined based on the third retrieval result. The system-related components are components that have a direct or indirect dependency relationship with the change point, and the second test case is a historical test case that has a matching relationship with the system-related components.

[0115] The regression strategy can be understood as the scope of regression testing that the user selects when creating a test case generation task, and that the test needs to cover. This regression strategy guides the regression testing agent in identifying how many historical test cases should be retrieved for testing. Regression strategies can include conservative (regressing only test cases of core modules directly related to the change point and with strong dependencies), standard (regressing all test cases of the functional module containing the change point and its upstream and downstream related modules), and aggressive (regressing test cases of all core business processes of the system). The regression strategy needs to strike a balance between test sufficiency and execution efficiency. A more conservative regression strategy generates fewer regression test cases and executes faster; a more aggressive strategy has higher coverage but takes longer. The specific strategy should be chosen based on actual needs.

[0116] Regression test identification agents, also known as regression test identification agents, are used to predict which existing, seemingly unrelated functions might be broken by a code change, thereby preventing software regression.

[0117] The regression analysis results can be understood as the output of the regression test identification agent performing regression analysis on the change points according to the regression strategy. The regression analysis results can be understood as process data, while the system related components can be understood as a series of software components (microservices, modules, database tables, interfaces, etc.) that will be directly or indirectly affected by the current change point.

[0118] The third search result can be understood as all historical regression test cases used to test these system-related components, retrieved from the associated historical knowledge base using system-related components as keywords.

[0119] The second test case can be understood as the regression test case that needs to be executed in this round of testing, and can be understood as a subset of the third search results.

[0120] Specifically, the process involves using regression testing to identify intelligent agents, performing regression analysis on the change points according to the regression strategy to obtain regression analysis results, and determining system-related components based on the regression analysis results. Furthermore, it includes retrieving the associated historical knowledge base based on the system-related components to obtain a third retrieval result, and determining the second test case based on the third retrieval result. A specific implementation example is as follows: First, the change point, regression strategy, and associated historical knowledge base are input into the regression testing identification agent. Let's assume the change point is "the 'calculate points' method in the 'order service' has been modified," and the regression strategy is "this is a minor version iteration, using a 'core path + high-risk module' regression strategy." The regression testing identification agent then combines code dependencies, call chains, and database relationships to identify directly affected modules (such as the order service and points service) and potentially affected modules (such as user level calculation). At this point, the regression strategy comes into play: it filters or weights the scope of impact. For example, if the strategy is "core path," only modules related to the main processes such as "place an order" and "payment" are retained; if the strategy is "high-risk," the "points calculation" module with a high historical defect rate is prioritized.

[0121] Secondly, the regression test identification agent will use the system-related components obtained in the previous step (such as "place an order", "payment", "points calculation") as keywords to search for all related test cases in the related historical knowledge base. That is, it will look for historical test cases that verify the target or test module field and match the affected system-related components; for example, test case A: verify that the points calculation is correct after placing an order (related to order service).

[0122] Finally, the regression test identification agent will directly use these historical test cases as second test cases and incorporate them into the current test plan.

[0123] The test case generation method provided in one or more embodiments of this specification utilizes a regression test identification agent for dependency analysis. This agent comprehensively identifies all potentially affected system components, avoiding omissions. Furthermore, based on automated retrieval from a historical knowledge base, the agent can instantly and accurately retrieve all historical test cases related to these system components from a massive database, forming a high-confidence regression test case set (the second test case). This not only completely liberates testers from tedious and error-prone manual impact analysis but also provides a reliable automated safety net for software quality through technical means, greatly reducing the risk of regression defects after release and providing a solid guarantee for rapid iteration.

[0124] Furthermore, to ensure comprehensive test analysis, covering not only functional aspects but also quality attributes, the system will invoke a non-functional test agent to generate third test cases after generating changepoints. The specific implementation is as follows: The test case generation task also includes an associated historical knowledge base; After the process of using change point identification agents to perform change analysis on the parsing results according to the task type, obtain change analysis results, and generate change points based on the change analysis results, the process further includes: The non-functional testing agent performs feature analysis on the change points, extracts the key features of the change points, matches the key features with the preset non-functional testing rule base, and generates a third test case based on the associated historical knowledge base and the parsing results if the match is successful.

[0125] Non-functional testing agents, also known as non-functional test agents, can be understood as intelligent agents specifically responsible for quality attribute testing and analysis. They are used to analyze whether changes introduce risks in performance, security, reliability, compatibility, etc. Specifically, non-functional testing focuses on "how" the system works, rather than "what" it does. Unlike functional testing (which verifies whether the software correctly performs specific functions according to the requirements specification), non-functional testing evaluates the software's quality attributes, performance characteristics, and user experience, ensuring the software's quality, efficiency, reliability, and user experience in real-world usage environments. Non-functional testing includes, but is not limited to, performance testing, security testing, usability testing, compatibility testing, reliability testing, and maintainability testing.

[0126] Feature analysis can be understood as a non-functional testing agent scanning change points and identifying their technical characteristics. Key features of change points can be understood as the technical keywords and characteristics extracted by the non-functional testing agent after scanning the change points and identifying their technical characteristics, which may cause non-functional risks. For example, if the change point is the addition of an AA interface, the extracted key features might include: keywords such as "new interface, payment, external call, etc.", and features such as "high-frequency operation, risk-sensitive, network I / O (Input / Output)".

[0127] The pre-defined non-functional test rule base can be understood as a pre-built "IF-THEN" rule base within the non-functional test agent, used to store non-functional test examples. For example: IF (the change point contains "new interface" AND "payment") THEN triggers "performance test" and "security test" requirements.

[0128] Specifically, the non-functional testing agent performs feature analysis on the change points, extracts key features of the change points, matches the key features with a preset non-functional testing rule base, and if the match is successful, generates a third test case based on the associated historical knowledge base and the parsing results. This can be understood as follows: the non-functional testing agent performs feature analysis on the change points, extracts key features of the change points, matches the key features with non-functional test examples in the preset non-functional testing rule base, determines non-functional testing requirements based on the matched non-functional test examples, and generates a third test case based on the non-functional testing requirements, the associated historical knowledge base, and the parsing results.

[0129] Following the previous example, the specific implementation of "using a non-functional testing agent to perform feature analysis on the change points, extracting the key features of the change points, matching the key features with a preset non-functional testing rule base, and generating a third test case based on the associated historical knowledge base and the parsing results when the match is successful" is as follows: Input the change points, associated historical knowledge base, and parsing results into the non-functional test agent.

[0130] First, the non-functional testing agent analyzes each change point, extracts technical keywords and technical features, and obtains the key features of each change point: keywords "new interface, payment, external call, etc.", and features "high-frequency operation, asset loss sensitivity, network I / O".

[0131] The non-functional testing agent matches the extracted key features with the preset non-functional testing rule base. Once a match is successful, a successful non-functional test example is obtained. Then, the non-functional test requirements in the non-functional test example are determined, and a third test case is generated based on the non-functional test requirements, combined with the associated historical knowledge base and the parsing results.

[0132] Using the previous example, successful non-functional test examples are as follows: IF change point includes adding a new interface AND payment -> THEN triggers performance test requirements, security test requirements, and asset loss test requirements; IF change point includes high-frequency operation -> THEN triggers stress test requirements and load test requirements.

[0133] At this point, the non-functional test agent can determine which of the following requirements need to be triggered based on these successfully matched non-functional test examples: "performance test requirements, security test requirements, asset loss test requirements, stress test requirements, and load test requirements".

[0134] Taking the triggering of "performance test requirements" as an example, the non-functional test agent will query the relevant historical knowledge base to see what the performance test standards for similar "payment interfaces" were in the past. If the search finds that "the performance target of interface aa is TP99 < 200ms", the non-functional test agent will generate the initial test requirements based on the historical performance test requirements found in the search: "Performance test: It is recommended to perform performance testing on interface aa, with the performance target referring to the historical standard: TP99 ≤ 200ms". Then, based on the parsing results, the initial test requirements will be adjusted to generate the final test requirements, i.e., the third test case.

[0135] Specifically, the parsing results are used to provide a more precise test context. For example, the non-functional test agent learns from the technical design section of the parsing results that the request body of the interface contains fields such as userId, amount, and channel. Therefore, the non-functional test agent will adjust the initial test requirements based on the parsing results, generating more specific test requirements, such as: "Performance test: Construct request load tests on interface aa using different userId and amount, verifying that the TP99 response time is ≤200ms." Based on this, it can be understood that the third test case is a non-functional test requirement, merely a targeted test instruction or verification standard.

[0136] The test case generation method provided in one or more embodiments of this specification utilizes a non-functional testing agent to generate non-functional test cases. Through feature analysis of change points and matching with a rule base, this non-functional testing agent can proactively identify hidden non-functional risks in technical changes (such as new interfaces potentially failing to withstand pressure or new fields lacking security validation), and automatically propose precise test requirements. This not only overcomes the shortcomings of manual review in easily overlooking non-functional requirements, but also makes specialized tests such as performance and security no longer "optional projects" considered only in the later stages of the project, but rather actions carried out concurrently with functional development, greatly reducing the high costs of online failures caused by non-functional defects. In other words, this achieves early, automated, and systematic intervention in non-functional testing, elevating quality assurance from the "functional correctness" level to the "operational reliability" level, effectively preventing major online performance and security incidents.

[0137] To address potential risks when multiple users access the system simultaneously, a concurrency analysis agent can be used to generate a fourth test case to resolve such issues. The specific implementation is as follows: The process of generating an agent using test points, after generating initial test points based on the change points and the parsing results, further includes: Using a concurrency analysis agent, concurrency analysis is performed on the initial test point to obtain concurrency analysis results. If it is determined from the concurrency analysis results that there is a concurrency scenario at the initial test point, concurrent test points are generated. The test cases are used to generate an intelligent agent, and a fourth test case corresponding to the test case generation task is generated based on the concurrent test points and the parsing results.

[0138] The concurrency analysis agent, also known as the concurrency analysis agent, is a specialized agent responsible for analyzing potential risks in scenarios involving multiple threads and simultaneous access by multiple users. It is used to scan initial test points to identify scenarios that may trigger resource contention or data races.

[0139] Concurrency analysis results can be understood as a conclusion indicating which initial test points involve concurrency risks, and may also include the corresponding risk types (such as data races or deadlocks). For example, the concurrency analysis result might be: the initial test point "user balance deduction" has a "data race" risk.

[0140] Concurrency scenarios can be understood as operation scenarios where shared resources (such as database rows, cached values, and files) may be accessed and modified simultaneously by multiple threads / processes / users.

[0141] Concurrency test points can be understood as additional test points added to the test projects based on a concurrency scenario determined by the concurrency analysis agent at an initial test point. These test points describe the direction and objectives of the concurrency testing. For example, verifying the consistency of inventory data when multiple users simultaneously purchase the same product.

[0142] In practice, a test point generation agent generates an initial test point list, and a concurrent analysis agent scans this list. When it identifies a scenario like "user balance deduction," it modifies the test point list, adding a new test point. For example, a concurrent test point verifies that data accuracy is not compromised when multiple users simultaneously deduct their balances. For this concurrent test point, when the test case generation agent starts working, it generates a corresponding test case, i.e., the fourth test case. Continuing with the previous example, for the aforementioned concurrent test point, a concurrent test case is generated: a script or command simulating 100 users simultaneously initiating requests using a concurrent testing tool.

[0143] Specifically, the method of generating an intelligent agent using test cases and generating the fourth test case corresponding to the test case generation task based on concurrent test points and parsing results can be found in the specific method of generating the initial test cases in the above embodiments, which will not be repeated here.

[0144] The test case generation method provided in one or more embodiments of this specification generates concurrent test points and corresponding fourth test cases using a concurrency analysis agent after generating initial test points. This achieves proactive and automated identification and test coverage of high-concurrency scenarios, effectively preventing major online incidents (such as financial losses or data corruption) caused by concurrency issues, and elevating quality assurance capabilities to production-grade levels.

[0145] Furthermore, to analyze whether an interface or operation is idempotent (i.e., the result is the same regardless of whether the request is made once or multiple times), and to prevent business errors caused by duplicate requests, change points can be identified after they are generated. The interface change points can then be identified, and the idempotency analysis agent can be used to generate a fifth test case. The specific implementation method is as follows: The test case generation task also includes an associated historical knowledge base; After the process of using change point identification agents to perform change analysis on the parsing results according to the task type, obtain change analysis results, and generate change points based on the change analysis results, the process further includes: Using idempotency analysis, the intelligent agent determines the target change point from the change points based on the change points, the parsing results, and / or the associated historical knowledge base, and generates test case generation suggestions corresponding to the target change point. The agent is generated using the test cases, and the fifth test case corresponding to the test case generation task is generated based on the test case generation suggestions and the parsing results.

[0146] Among them, the idempotency analysis agent, also known as the idempotency analysis agent, is a special agent responsible for analyzing whether an interface or operation is idempotent (i.e., the result of repeatedly executing the same operation is the same as executing it once). It is used to identify operations that need idempotency protection and design verification strategies.

[0147] A target change point can be understood as a subset selected from all change points. It refers to those change points that modify or add "write operation" interfaces, whose execution results will change the system state (such as creating an order, deducting payment, or updating status); for example, adding the 'aa' interface can be understood as a target change point.

[0148] Test case generation suggestions can be understood as structured test instructions or plans that describe "what to test" and "why," rather than "how to test specifically." For example, a test case generation suggestion might be: "Idempotency test for interface aa: Send N consecutive requests using the same request parameters (especially the same order number) to verify that only one order is successfully created and that the same result is returned."

[0149] The fifth test case can be understood as a detailed, executable, and step-by-step test case generated by the test case generation agent based on the suggested test cases. It includes, but is not limited to, specific request parameters, the number of times the request is repeated, and detailed assertions verifying the database status and the interface's returned results.

[0150] The following is a specific example illustrating the implementation of "using an idempotency analysis agent to determine a target change point from the change points based on the change points, the parsing results, and / or the associated historical knowledge base, and generate test case generation suggestions corresponding to the target change point; using the test case generation agent to generate a fifth test case corresponding to the test case generation task based on the test case generation suggestions and the parsing results".

[0151] First, the idempotency analysis agent analyzes each change point based on the change point, the parsing results, and / or the associated historical knowledge base to identify the target change point. For example, semantic analysis, rule base matching, and historical knowledge queries can be used to analyze each change point to select the target change point. Semantic analysis involves analyzing the interface name, HTTP method, and interface description extracted from the parsing results in the change point to determine its business intent. Create, pay, and submit operations typically require idempotency. Rule base matching involves the idempotency analysis agent using a built-in rule base containing multiple rule examples, such as the rule example: IF (interface method = POST) AND (interface name contains ['create', 'submit', 'pay']) THEN Idempotency risk = High. This rule base matching determines whether the change point is the target change point. Historical knowledge base query involves querying the historical test knowledge base to check if there are historical test cases with similar interfaces marked as requiring idempotency testing for the change point.

[0152] Secondly, after identifying the target change point, the idempotency analysis agent will generate structured test suggestions for each target change point, i.e., test case generation suggestions. It can also add an attribute or label to the corresponding test point.

[0153] Finally, the test case generation agent and parsing results generate the fifth test case. In specific implementation, when the test point corresponding to the target change point has such an attribute or label, the test case generation agent, while generating detailed test cases for its test point, determines that the test point has such an attribute or label. In addition to generating the corresponding first test case for the test point, it will also generate the corresponding idempotency test case, i.e., the fifth test case.

[0154] The test case generation method provided in one or more embodiments of this specification utilizes an idempotency analysis agent to automatically identify all "write operation" change points (target change points) and intelligently generate accurate test suggestions, ensuring comprehensive test coverage without omissions. This achieves automated and standardized verification of idempotency, a key quality attribute, fundamentally eliminating serious online failures such as data duplication and over-deduction of funds caused by duplicate requests, and greatly improving the reliability and robustness of the system.

[0155] Furthermore, if the test case generation method provided in one or more embodiments of this specification is applied in the financial field, in order to ensure compliance, a resource identification intelligent agent can be used to perform resource analysis on the change points and mark the change points involving resources to attract the attention of testers in the future. The specific implementation method is as follows: After the process of using change point identification agents to perform change analysis on the parsing results according to the task type, obtain change analysis results, and generate change points based on the change analysis results, the process further includes: Using a resource identification intelligent agent, resource analysis is performed on the change points to obtain resource analysis results. Based on the resource analysis results, resource change points are obtained from the change points, and a security level is marked for the resource change points. The resource change points are any one or more change points among the change points. The process of generating an agent using test points, after generating initial test points based on the change points and the parsing results, further includes: From the initial test points, obtain the resource test points corresponding to the resource change points, and set resource tags for the resource test points, wherein the resource test points are any one or more initial test points from the initial test points.

[0156] Among them, the resource identification agent, also known as the resource identification agent, is a specialized agent responsible for analyzing change points from a security and operations perspective. It is used to identify changes involving sensitive or critical system resources and assess their security risks.

[0157] Resource analysis can be understood as the process by which a resource identification agent scans for change points and identifies the resource objects that the agent operates on or affects. The output of resource analysis can be understood as a list containing the identified resources and their context. Resources include, but are not limited to, data (such as user phone numbers and amounts) and infrastructure (server configurations, network policies).

[0158] Security level can be understood as a risk rating label that the resource identification agent assigns to each point of resource change.

[0159] Resource test points can be understood as test points used to test "resource change points" within the initial test points. Resource tags are markings attached to them, usually associated with the corresponding "security level".

[0160] Specifically, the resource identification agent first performs resource analysis on change points through primary filtering based on keywords and patterns, deep analysis based on semantics and context, and correlation analysis based on dependencies. Based on the resource analysis results, it identifies resource change points from the change points and then labels them with risk levels, i.e., sets their security levels. Simultaneously, it retrieves resource test points corresponding to the resource change points from the initial test points and assigns corresponding resource tags to these test points to draw the attention of testers in subsequent testing.

[0161] The test case generation method provided in one or more embodiments of this specification, through the analysis of a resource identification intelligent agent, enables the system to automatically identify risk changes involving sensitive resources (such as funds, privacy data, and permissions) and accurately label their security levels. This makes test design no longer purely function-oriented, but incorporates a security perspective. Finally, all relevant test points are labeled with "resource tags," forming a risk test suite. Subsequent testers can prioritize and focus on executing high-security level tests to ensure asset protection. Furthermore, by significantly advancing the timing of security testing from late-stage penetration testing to the test design phase of development, a "security shift to the left" is achieved, enabling the discovery of potential vulnerabilities earlier and at a lower cost, greatly reducing the risk of online security incidents and asset losses due to improper resource operations.

[0162] In practice, if a change point involves operations on multiple microservices or systems, a sixth test case can be generated using a distributed transaction agent to ensure eventual data consistency. The specific implementation is as follows: After the process of using change point identification agents to perform change analysis on the parsing results according to the task type, obtain change analysis results, and generate change points based on the change analysis results, the process further includes: A distributed transaction agent is used to perform transaction analysis on the change points, obtain transaction analysis results, and obtain transaction change points from the change points based on the transaction analysis results, wherein the transaction change points are any one or more change points among the change points; A smart agent is generated using the test points, and transaction test points are generated based on the transaction change points and the parsing results; Using the test cases, an intelligent agent is generated, and based on the transaction test points and the parsing results, a sixth test case corresponding to the test case generation task is generated.

[0163] Among them, the distributed transaction agent, also known as the distributed transaction agent, is an intelligent agent specifically responsible for analyzing cross-service and cross-database operation processes. It is used to identify change points that may compromise the eventual consistency of data in a distributed environment.

[0164] Transaction analysis can be understood as a distributed transaction agent scanning change points to determine whether they participated in a business operation that spans multiple system boundaries (e.g., analyzing code call chains, message queue dependencies, or database access patterns to determine if an operation involves multiple microservices or databases). The results of transaction analysis can be understood as the output of this distributed transaction agent analysis, including the identified distributed transaction flows and their boundary information.

[0165] A transaction change point can be understood as a subset of change points, referring to those change points that are part of a distributed transaction process. For example, a change point that modifies the interface in the 'Order Service' that calls the 'Inventory Service' to deduct inventory after creating an order is a transaction change point because it is a cross-service transaction: "Create Order - Deduct Inventory".

[0166] Transaction test points can be understood as specific test points generated by the distributed transaction agent for transaction change points. They focus on data consistency and fault recovery. For example, a transaction test point might verify whether the order service can correctly roll back or initiate a compensation operation when the inventory service fails to deduct inventory, ensuring eventual data consistency.

[0167] The sixth test case can be understood as the final, executable distributed transaction test plan, which includes specific steps and assertions to simulate various intermediate failure states (such as network timeout, service crash, database exception).

[0168] In practical implementation, firstly, the distributed transaction agent performs transaction analysis on the change points, identifying the specific functionalities or service interfaces affected by the requirement change and obtaining transaction analysis results. When the transaction analysis results identify a change point that spans multiple microservices (such as order service and inventory service), and these services have data dependencies or state changes (such as deducting inventory when placing an order), then that change point is considered a transaction change point. Secondly, the test point generation agent generates transaction test points based on the transaction change points and the analysis results. For example, it verifies whether the order service can correctly roll back order creation when the inventory service call times out or returns a failure. In other words, the distributed transaction agent determines whether there are multiple change points that constitute a cross-service business process with state changes. Only when the change points of multiple services collaboratively complete a business goal (such as "placing an order and deducting inventory") is a distributed transaction risk considered to exist, thus triggering consistency analysis and generating corresponding transaction test points using the test point generation agent. Finally, the test case generation agent generates the sixth test case corresponding to the test case generation task based on the transaction test points and the analysis results.

[0169] The test case generation method provided in one or more embodiments of this specification utilizes a distributed transaction intelligent agent to generate a sixth test case, thereby achieving automated test design for the complex challenge of data consistency in distributed systems. This effectively prevents system-wide data corruption caused by partial failures, providing crucial assurance for the reliability of microservice architectures. Specifically, the distributed transaction intelligent agent automatically identifies cross-service transaction flows (transaction change points) and intelligently generates test cases (the sixth test case) for various abnormal branches (such as compensation logic in Saga and TCC patterns), achieving full coverage testing of the distributed transaction lifecycle.

[0170] In practical applications, when generating test case analysis reports for test case generation tasks, the test analysis document generation agent considers not only the parsing results, change points, initial test points, and the first test case, but also the second, third, fourth, fifth, and sixth test cases output by other agents. That is, the output of any of the above agents is considered and included in the test case analysis reports generated by the test analysis document generation agent, thus ensuring the completeness and accuracy of the test case analysis reports.

[0171] The test case generation method provided in one or more embodiments of this specification decomposes the test case generation task into multi-level tasks such as "parse result generation," "test point generation," and "test case generation." First, an information extraction agent is invoked to parse the target document and generate parsing results. Then, a test point generation agent is invoked to generate multiple initial test points based on the task type and parsing results. Finally, a test case generation agent is invoked to generate the first test case for each initial test point. Firstly, by simulating the analysis logic of experienced testing experts through multiple agents, the method automatically reads and integrates multi-dimensional information such as PRDs and design documents in the target document, directly transforming human experience into stable automated output. This overcomes the problem of test point omissions caused by insufficient or negligent personnel familiarity with the business, greatly improving the efficiency and completeness of test case output. Secondly, through the joint processing of multiple agents, it ensures that the generated test cases follow built-in best practices and standardized processes, eliminating fluctuations in test score quality caused by differences in personnel skill levels. This provides stable, reliable, and high-quality automated assurance, reducing excessive reliance on manual review by senior engineers.

[0172] In practice, the test case generation method provided in one or more embodiments of this specification can be understood as the technical foundation supporting the three major usage modes of the business domain: basic, intermediate, and advanced.

[0173] In the foundational phase, this test case generation method can be understood as a test score document generation engine. Through precise change point identification, test point derivation, and test case generation, it achieves automated test score document writing with 70% test case coverage and 80% test case recall within a short time (e.g., 20 minutes), providing testers with high-quality drafts for efficient secondary processing and laying the foundation for intelligent "deployment".

[0174] In the advanced stage, this test case generation method is deeply integrated with data construction capabilities to drive intelligent data construction. When generating test cases (such as asset disposal test cases in a consumer finance system), the system can automatically parse its "data preparation" steps and call external data factory tool interfaces to generate corresponding complex business data (such as asset packages in specific states). This not only transfers testing services to the R&D integration phase but also solves the efficiency bottleneck of test data preparation in complex scenarios. For example, when the test case generation agent generates a test case, it analyzes the preconditions of the test case. If the test case requires "login as a level 11 member user," the agent will automatically call the API of the external "intelligent data construction platform" and send the instruction: "Please construct a user account with a level '11' and return its login information." Subsequently, the account information returned by this API will be directly written into the "preconditions" or "test data" fields of the test case.

[0175] See Figure 3 , Figure 3 This diagram illustrates a data mapping process in a test case generation method provided in one embodiment of this specification.

[0176] Figure 3 This describes the process of integrating diverse and chaotic raw user data into unified and trustworthy identifiers through a strategy model. This is an indispensable infrastructure for building user data intelligence in the advanced stage. Only by completing this "advanced" step in data governance can high-quality and correlated data be provided for upper-level intelligent analysis, precision marketing, and AI applications.

[0177] in, Figure 3 In this context, "production / development data" refers to raw data, which can be understood as original, redundant, and inconsistent user data scattered across various business systems. For example, the same user may have multiple different IDs or protocol numbers. "Policy model" refers to the core rules, which can be understood as a standard for data integration. It defines that regardless of the number of identifiers from different sources, they must all be mapped to a unique and unified user entity. "New account" can be understood as user master data or standard IDs generated after rule-based cleaning and integration.

[0178] The accounts (attributes include credit account contract number, user number, and ID number), agreements (attributes include agreement number, user number, and due date), bills (attributes include credit account contract number, IOU number, and bill number), and assets (attributes include credit account contract number, asset, and institution) mentioned in the strategy model are all specific data entities generated by users in different business scenarios. They are all components of "N" and are objects that need to be integrated into "1" (user). For example, "account" is the user's financial attribute, "agreement" is the user's contractual relationship, "bill" is the user's consumption result, and "assets" are the user's holding value. The role of the strategy model is to associate and unify these scattered entities onto a unique user identity.

[0179] In the advanced stage, this test case generation method is key to achieving a closed loop of "intelligent construction and execution." By structurally decomposing the generated test cases into three elements—"data preparation, business operation, and result verification"—and converting them into machine-readable instructions, AI can automatically execute test cases (such as automatically calling interfaces and verifying database results). Ultimately, this completely liberates testers from the role of repetitive executors to strategy makers and result reviewers, achieving fully intelligent iteration of the testing workflow. In other words, the system can not only generate documents and data but also directly drive the execution engine to run tests and return results.

[0180] See Figure 4 , Figure 4 This diagram illustrates the test account preparation and test execution process in a test case generation method provided in one embodiment of this specification.

[0181] Figure 4 This includes test case acquisition, account selection & data preparation, intelligent execution, and result verification and conversion.

[0182] The goal of test case acquisition is to automatically transform human requirement documents (system analysis documents) into a set of executable and understandable test plans and specific operational instructions. By inputting human system analysis documents, AI automatically generates test cases (AI test case generation). From all AI-generated test cases, a subset that needs to be executed is selected and extracted based on the specific objectives of the test (e.g., regression testing, smoke testing). These three processes constitute an intelligent pipeline from requirement input to an executable test plan, where AI significantly improves the efficiency and coverage of the conversion from requirements to test cases.

[0183] The extracted use cases are then broken down into a series of specific, executable atomic operation steps.

[0184] Account selection and data preparation are used to intelligently select or create the most suitable test accounts and data based on the operational steps broken down from upstream, in order to prepare for test execution. For example, matching existing platform accounts (the system directly finds a ready-made account in the platform's test account pool that fully meets the test case requirements), matching existing platform accounts to generate new accounts (when an existing account meets most of the conditions but some key conditions are not met, the system selects it as a "template" or "base" and modifies it by performing a series of operations to generate a brand new account that meets the requirements), and generating new accounts based on knowledge input (when encountering brand new business or extreme test scenarios, and the first two strategies fail (there are no existing accounts with similar characteristics in the platform), the system will completely fabricate a compliant account from scratch based on its understanding of the business and data models (knowledge).

[0185] Intelligent execution is used to automatically and reliably enact the test cases and accounts output from the first two parts in a real environment. For example, intelligent new test case matching for consumer finance pre-loan testing (in the loan application (pre-loan) approval process in the consumer finance field, the testing platform can intelligently identify the purpose of a newly submitted test case and automatically match, assemble, and execute a complete and compliant test pipeline for it) and platform general link tool matching (when a test task (such as a decomposed test case) arrives, the testing platform can automatically find, select, and assemble existing and general test tools and services on the platform to form a complete and executable test pipeline).

[0186] Result verification and transformation are used to solve the problem of "whether the result is correct". It performs comprehensive and in-depth verification of the system status after execution and generates a final report. Examples include DB (Database) data verification (checking whether the data changes in the database after the interface call are correct), TR interface return value verification (checking whether the direct response of the tested interface (API) meets expectations), and link call relationship verification (verifying whether an interface call triggers the correct downstream service call chain).

[0187] The test case generation method provided in one or more embodiments of this specification systematically integrates multimodal data fusion and semantic enhancement, dynamic update and version control mechanisms, end-to-end automation driven by an intelligent agent framework, and auxiliary functions covering multi-dimensional test scenarios. It achieves the parsing of multimodal data through a combination of natural language processing and a rule engine, supplemented by a structured rule base and dynamic knowledge graph, effectively improving the semantic understanding capability of complex business rules and increasing test case coverage from 70% to over 90%. The LLM-based change analysis function tracks business rule changes in real time and automatically updates the test case library, overcoming the limitations of the MBT platform's reliance on static model maintenance, reducing test case maintenance costs by 50%, and adapting to high-frequency business iteration scenarios. By adopting an intelligent agent framework combined with LLM's input analysis and code generation capabilities, and through chained prompts and vector database optimization, it achieves full-process automation from requirement document parsing to test script generation, improving the processing efficiency of ultra-large-scale requirement documents by 4 times. By integrating modules such as concurrency analysis, loss analysis, and distributed transaction analysis, it covers test dimensions not covered by traditional solutions, and improves test comprehensiveness through rule reasoning and abnormal scenario simulation, reducing the workload of manually supplementing test cases.

[0188] Corresponding to the above method embodiments, this specification also provides embodiments of a test case generation device. Figure 5 A schematic diagram of a test case generation apparatus according to one embodiment of this specification is shown. Figure 5 As shown, the device includes: The task determination module 502 is configured to determine a test case generation task, wherein the test case generation task carries the target document, task type and document type of the test cases to be generated; The document parsing module 504 is configured to use an information extraction agent to parse the target document according to the document type and generate the parsing result of the target document; The test point generation module 506 is configured to generate an intelligent agent using test points, and generate initial test points based on the task type and the parsing results. The test case generation module 508 is configured to generate an intelligent agent using test cases, and generate the first test case corresponding to the test case generation task based on the initial test points and the parsing results.

[0189] Optionally, the device further includes: The change point generation module is configured to identify intelligent agents using change points, perform change analysis on the parsing results according to the task type, obtain change analysis results, and generate change points based on the change analysis results; The test point generation module 506 is further configured to: A smart agent is generated using test points. Initial test points are generated based on the change points and the analysis results.

[0190] Optionally, the test case generation task also includes an associated historical knowledge base; The test point generation module 506 is further configured to: An intelligent agent is generated using test points. The agent searches the associated historical knowledge base based on the change points to obtain a first search result. Based on the first search result and the parsing result, an initial test point is generated.

[0191] Optionally, the test case generation task also includes an associated historical knowledge base; Test case generation module 508 is also configured as follows: The test case is used to generate an intelligent agent, which retrieves the associated historical knowledge base based on the initial test point to obtain a second retrieval result, and generates a first test case corresponding to the test case generation task based on the second retrieval result and the parsing result.

[0192] Optionally, the test case generation task also includes an associated historical knowledge base and a regression strategy; The device further includes: The regression testing module is configured to identify agents using regression testing, perform regression analysis on the change points according to the regression strategy, obtain regression analysis results, and determine system-related components based on the regression analysis results; and The system-related components are used to retrieve the associated historical knowledge base to obtain a third retrieval result, and a second test case is determined based on the third retrieval result. The system-related components are components that have a direct or indirect dependency relationship with the change point, and the second test case is a historical test case that has a matching relationship with the system-related components.

[0193] Optionally, the test case generation task also includes an associated historical knowledge base; The device further includes: The non-functional testing module is configured to use a non-functional testing agent to perform feature analysis on the change points, extract the key features of the change points, match the key features with a preset non-functional testing rule base, and generate a third test case based on the associated historical knowledge base and the parsing results if the match is successful.

[0194] Optionally, the device further includes: The concurrency analysis module is configured to use a concurrency analysis agent to perform concurrency analysis on the initial test point, obtain concurrency analysis results, and generate concurrent test points if it is determined from the concurrency analysis results that the initial test point has a concurrent scenario. The test cases are used to generate an intelligent agent, and a fourth test case corresponding to the test case generation task is generated based on the concurrent test points and the parsing results.

[0195] Optionally, the test case generation task also includes an associated historical knowledge base; The device further includes: The idempotency analysis module is configured to use an idempotency analysis agent to determine a target change point from the change points based on the change points, the parsing results, and / or the associated historical knowledge base, and generate test case generation suggestions corresponding to the target change point; The agent is generated using the test cases, and the fifth test case corresponding to the test case generation task is generated based on the test case generation suggestions and the parsing results.

[0196] Optionally, the device further includes: The resource identification module is configured to use a resource identification agent to perform resource analysis on the change points, obtain resource analysis results, obtain resource change points from the change points based on the resource analysis results, and mark the security level of the resource change points, wherein the resource change points are any one or more change points among the change points; The device further includes: The resource tag setting module is configured to obtain resource test points corresponding to the resource change points from the initial test points, and set resource tags for the resource test points, wherein the resource test points are any one or more initial test points from the initial test points.

[0197] Optionally, the device further includes: The distributed transaction module is configured to use a distributed transaction agent to perform transaction analysis on the change points, obtain transaction analysis results, and obtain transaction change points from the change points based on the transaction analysis results, wherein the transaction change points are any one or more change points among the change points; A smart agent is generated using the test points, and transaction test points are generated based on the transaction change points and the parsing results; Using the test cases, an intelligent agent is generated, and based on the transaction test points and the parsing results, a sixth test case corresponding to the test case generation task is generated.

[0198] Optionally, the device further includes: The change analysis module is configured to use a change analysis agent to perform text analysis on the change points and generate an analysis report corresponding to the change points.

[0199] Optionally, the device further includes: The test analysis document generation module is configured to generate an intelligent agent using the test analysis document, and generate a test case analysis report corresponding to the test case generation task based on the parsing results, the change points, the initial test points, and the first test case.

[0200] Optionally, the device further includes: The visualization image generation module is configured to generate an intelligent agent using visualization images, perform graphical processing on the test case analysis report, and obtain a visualization image analysis report corresponding to the test case analysis report.

[0201] It is understood that the modules mentioned above refer to computer programs or program segments used to perform one or more specific functions. Furthermore, the distinction between these modules does not imply that the actual program code must also be separate.

[0202] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0203] The above is an illustrative scheme of a test case generation device according to this embodiment. It should be noted that the technical solution of this test case generation device and the technical solution of the test case generation method described above belong to the same concept. For details not described in detail in the technical solution of the test case generation device, please refer to the description of the technical solution of the test case generation method described above.

[0204] See Figure 6 , Figure 6 A structural block diagram of a computing device 600 according to one or more embodiments of this specification is shown. The components of the computing device 600 include, but are not limited to, a memory 610 and a processor 620. The processor 620 is connected to the memory 610 via a bus 630, and a database 650 is used to store data.

[0205] The computing device 600 also includes an access device 640, which enables the computing device 600 to communicate via one or more networks 660. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 640 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0206] In one embodiment of this application, the aforementioned components of the computing device 600 and Figure 6 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 6 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.

[0207] The computing device 600 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 600 can also be a mobile or stationary server.

[0208] The processor 620 is used to execute the following computer program / instructions, which, when executed by the processor, implement the steps of the above-described data processing method.

[0209] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the data processing method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the test case generation method described above.

[0210] An embodiment of this specification also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the test case generation method described above.

[0211] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, the computer-readable storage medium embodiment is described simply because it is substantially similar to the test case generation method embodiment; relevant parts can be found in the description of the test case generation method embodiment.

[0212] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the test case generation method described above.

[0213] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the test case generation method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the test case generation method described above.

[0214] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the embodiments of [apparatus, device, system], since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The [apparatus, device, system] provided in the embodiments of this specification correspond to the methods, and therefore the [apparatus, device, system] also has similar beneficial technical effects as the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the corresponding [apparatus, device, system] will not be repeated here.

[0215] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0216] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0217] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0218] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0219] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0220] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, the invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0221] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0222] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0223] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0224] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0225] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0226] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital character versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0227] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0228] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A test case generation method applied to a multi-intelligent architecture, comprising: determining a test case generation task, wherein the test case generation task carries a target document to be generated, a task type, and a document type; using an information extraction intelligent agent to parse the target document according to the document type, and generating a parsing result of the target document; using a change point identification intelligent agent to perform change analysis on the parsing result according to the task type, to obtain a change analysis result, and to generate a change point according to the change analysis result; using a test point generation intelligent agent to generate an initial test point according to the change point and the parsing result; using a test case generation intelligent agent to generate a first test case corresponding to the test case generation task according to the initial test point and the parsing result. 2.The test case generation method of claim 1, wherein the test case generation task further carries an associated historical knowledge base; the test point generation intelligent agent generates an initial test point according to the change point and the parsing result, comprising: the test point generation intelligent agent retrieves the associated historical knowledge base according to the change point, to obtain a first retrieval result, and generates an initial test point according to the first retrieval result and the parsing result. 3.The test case generation method of claim 1, wherein the test case generation task further carries an associated historical knowledge base; the test case generation intelligent agent generates a first test case corresponding to the test case generation task according to the initial test point and the parsing result, comprising: the test case generation intelligent agent retrieves the associated historical knowledge base according to the initial test point, to obtain a second retrieval result, and generates a first test case corresponding to the test case generation task according to the second retrieval result and the parsing result. 4.The test case generation method of any one of claims 1-3, wherein the test case generation task further carries an associated historical knowledge base and a regression strategy; after the change point identification intelligent agent generates a change point according to the change analysis result, the method further comprises: a regression test identification intelligent agent performs regression analysis on the change point according to the regression strategy, to obtain a regression analysis result, and determines a system associated component according to the regression analysis result; and retrieving the associated historical knowledge base according to the system associated component, to obtain a third retrieval result, and determining a second test case according to the third retrieval result, wherein the system associated component is a component having a direct or indirect dependency relationship with the change point, and the second test case is a historical test case having a matching relationship with the system associated component. 5.The test case generation method of any one of claims 1-3, wherein the test case generation task further carries an associated historical knowledge base. The change point recognition agent further comprises: The non-functional test agent analyzes the change point, extracts the key features of the change point, matches the key features with a preset non-functional test rule library, and generates a third test case according to the associated historical knowledge base and the analysis result when the matching is successful.

6. The test case generation method according to any one of claims 1-3, wherein the test point generation agent further comprises: The concurrency analysis agent analyzes the initial test point, obtains a concurrency analysis result, and generates a concurrency test point when it is determined that the initial test point has a concurrency scenario according to the concurrency analysis result. The test case generation agent generates a fourth test case corresponding to the test case generation task according to the concurrency test point and the analysis result.

7. The test case generation method according to any one of claims 1-3, wherein the test case generation task further carries an associated historical knowledge base. The change point recognition agent further comprises: The idempotency analysis agent determines a target change point from the change point according to the change point, the analysis result, and / or the associated historical knowledge base, and generates a test case generation suggestion corresponding to the target change point. The test case generation agent generates a fifth test case corresponding to the test case generation task according to the test case generation suggestion and the analysis result.

8. The test case generation method according to any one of claims 1-3, wherein the change point recognition agent further comprises: The resource recognition agent analyzes the change point, obtains a resource analysis result, and acquires a resource change point from the change point according to the resource analysis result, and marks a security level for the resource change point, wherein the resource change point is any one or more of the change points. The test point generation agent further comprises: The resource recognition agent analyzes the change point, obtains a resource analysis result, and acquires a resource change point from the change point according to the resource analysis result, and marks a security level for the resource change point, wherein the resource change point is any one or more of the change points. The test point generation agent further comprises: The resource recognition agent analyzes the change point, obtains a resource analysis result, and acquires a resource change point from the change point according to the resource analysis result, and marks a security level for the resource change point, wherein the resource change point is any one or more of the change points. 9.The test case generation method of any one of claims 1-3, after the change point identification agent analyzes the change in the parsed result according to the task type to obtain a change analysis result and generates the change point based on the change analysis result, further comprising: a transaction analysis agent that analyzes the change point based on a distributed transaction to obtain a transaction analysis result and acquires a transaction change point from the change point based on the transaction analysis result, wherein the transaction change point is any one or more of the change points; a test point generation agent that generates a transaction test point based on the transaction change point and the parsed result; a test case generation agent that generates a sixth test case corresponding to the test case generation task based on the transaction test point and the parsed result. 10.The test case generation method of any one of claims 1-3, after the change point identification agent analyzes the change in the parsed result according to the task type to obtain a change analysis result and generates the change point based on the change analysis result, further comprising: a change analysis agent that analyzes the change point based on a text to generate an analysis report corresponding to the change point. 11.The test case generation method of claim 1, after the test case generation agent generates the first test case corresponding to the test case generation task based on the initial test point and the parsed result, further comprising: a test analysis document generation agent that generates a test case analysis report corresponding to the test case generation task based on the parsed result, the change point, the initial test point, and the first test case. 12.The test case generation method of claim 11, after the test analysis document generation agent generates the test case analysis report corresponding to the test case generation task based on the parsed result, the change point, the initial test point, and the first test case, further comprising: a visual image generation agent that performs graphic processing on the test case analysis report to obtain a visual image analysis report corresponding to the test case analysis report. 13.A test case generation device applied to a multi-agent architecture, comprising: a task determination module configured to determine a test case generation task, wherein the test case generation task carries a target document to be generated, a task type, and a document type; a document parsing module configured to use an information extraction agent to parse the target document according to the document type to generate a parsed result of the target document; a change point generation module configured to use a change point identification agent to analyze the change in the parsed result according to the task type to obtain a change analysis result and generate a change point based on the change analysis result; a test point generation module configured to use a test point generation agent to generate an initial test point based on the change point and the parsed result; The test case generation module is configured to utilize a test case generation agent to generate a first test case corresponding to the test case generation task according to the initial test points and the analysis result.

14. A computing device comprising: a memory and a processor; the memory is configured to store computer programs / instructions, and the processor is configured to execute the computer programs / instructions, and the computer programs / instructions, when executed by the processor, implement the steps of the data processing method of any one of claims 1 to 12.

15. A computer readable storage medium storing computer programs / instructions, and the computer programs / instructions, when executed by a processor, implement the steps of the data processing method of any one of claims 1 to 12.

16. A computer program product comprising computer programs / instructions, and the computer programs / instructions, when executed by a processor, implement the steps of the data processing method of any one of claims 1 to 12.

Images