Joint debugging test method, device, equipment, storage medium and product

Abstract

The present disclosure provides a joint debugging test method, device, equipment, storage medium and product, relates to the technical field of artificial intelligence and software testing, and in particular to an intelligent agent and joint debugging test technology. The method comprises the following steps: obtaining change requirement information of a target software system; generating a test case for joint debugging test of a plurality of business modules in the target software system by a first intelligent agent based on the change requirement information and in combination with test experience in a test knowledge base; determining a module calling topology required for the joint debugging test by a second intelligent agent based on the test case generated by the first intelligent agent, and building or matching a test environment containing the plurality of business modules according to the module calling topology; and executing the test case generated by the first intelligent agent in the test environment built by the second intelligent agent by a third intelligent agent to obtain a test result. The present disclosure helps to improve the efficiency and accuracy of joint debugging test.

Description

Technical Field

[0001] This disclosure relates to the fields of artificial intelligence and software testing technology, and in particular to intelligent agents and joint testing technology, specifically to a joint testing method, apparatus, equipment, storage medium and product. Background Technology

[0002] In the iterative development of software systems, scenarios involving the upgrading of multiple business modules are common. Testing involving multiple business modules in this process is called integration testing. Integration testing has a long chain, involves many business modules, and is prone to problems such as test omissions and incomplete verification; moreover, its overall testing efficiency is currently low. Summary of the Invention

[0003] This disclosure provides a method, apparatus, electronic device, non-transient computer-readable storage medium, and computer program product for joint debugging and testing.

[0004] According to one aspect of this disclosure, a method for joint debugging testing is provided, comprising: obtaining change requirement information of a target software system; generating test cases for joint debugging testing of multiple business modules in the target software system by a first intelligent agent based on the change requirement information and combined with testing experience in a test knowledge base; determining the module call topology required for joint debugging testing by a second intelligent agent based on the test cases generated by the first intelligent agent, and building or matching a test environment containing multiple business modules according to the module call topology; and executing the test cases generated by the first intelligent agent by a third intelligent agent in the test environment built by the second intelligent agent to obtain test results.

[0005] According to another aspect of this disclosure, a joint debugging and testing apparatus is provided, comprising: an acquisition module for acquiring change requirement information of a target software system; a first intelligent agent for generating test cases for joint debugging and testing of multiple business modules in the target software system based on the change requirement information and in conjunction with testing experience in a test knowledge base; a second intelligent agent for determining the module call topology required for joint debugging and testing based on the test cases generated by the first intelligent agent, and building or matching a test environment containing multiple business modules according to the module call topology; and a third intelligent agent for executing the test cases generated by the first intelligent agent in the test environment built by the second intelligent agent to obtain test results.

[0006] According to another aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a joint debugging test method.

[0007] According to another aspect of this disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause a computer to perform a joint debugging test method.

[0008] According to another aspect of this disclosure, a computer program product is provided, including a computer program that implements a joint debugging test method when executed by a processor.

[0009] The integration testing method provided by this invention, through the collaborative cooperation of a first, second, and third intelligent agent, can automatically generate test cases for integration testing of multiple business modules in the target software system based on change requirement information. It automatically builds or matches a test environment containing multiple business modules and automatically executes integration tests based on the test cases and the test environment. This helps reduce the operational costs and test deviations of integration testing, improving its efficiency and accuracy. Specifically, the first intelligent agent automatically parses change requirement information and generates test cases based on testing experience in the test knowledge base, lowering the experience threshold for testers and solving the problems of missed test scenarios and incomplete verification that may occur with manual analysis, thus improving the completeness and generation efficiency of test cases. The second intelligent agent automatically determines the module call topology and builds or matches the test environment based on the test cases generated by the first intelligent agent. The third intelligent agent automatically executes the test cases in the test environment built by the second intelligent agent, shortening the test environment preparation time and enabling rapid deployment of the test environment and rapid execution of integration tests, further improving the efficiency and accuracy of integration testing.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 A schematic flowchart of a joint debugging and testing method provided in an embodiment of this disclosure; Figure 2 A schematic flowchart of step S102 in the joint debugging and testing method provided in this embodiment of the present disclosure; Figure 3 This is a schematic diagram of an interface for a test case; Figure 4 A schematic flowchart of step S103 in the joint debugging and testing method provided in this embodiment of the present disclosure; Figure 5 A schematic flowchart of step S403 in the joint debugging and testing method provided in this embodiment of the present disclosure; Figure 6 A schematic diagram of the module call topology; Figure 7 A schematic flowchart of step S103 in the joint debugging and testing method provided in this embodiment of the present disclosure; Figure 8 This is a schematic diagram of the interface of a test environment; Figure 9 A schematic flowchart of step S104 in the joint debugging and testing method provided in this embodiment of the present disclosure; Figure 10 Another schematic flowchart of the joint debugging and testing method provided in the embodiments of this disclosure; Figure 11 A structural block diagram of the joint debugging and testing device provided in the embodiments of this disclosure; Figure 12 Another structural block diagram of the joint debugging and testing device provided in the embodiments of this disclosure; Figure 13 A schematic block diagram of an example electronic device that can be used to implement embodiments of the present disclosure is shown. Detailed Implementation

[0012] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, 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, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0013] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0014] Various modifications and variations can be made to this disclosure without departing from its spirit or scope, as will be apparent to those skilled in the art. Therefore, this disclosure is intended to cover modifications and variations falling within the scope of the corresponding claims (the claimed technical solutions) and their equivalents. It should be noted that the embodiments provided in this disclosure can be combined with each other without contradiction.

[0015] Before describing the technical solutions provided in this disclosure, in order to facilitate understanding of this disclosure, the problems existing in the related technologies will be specifically explained below.

[0016] In the iterative development of software systems, it is common to encounter scenarios involving the upgrade of multiple business modules (microservices). Testing involving multiple business modules in this process is called integration testing. Integration testing has a long chain, involves many business modules, and is prone to problems such as test omissions and incomplete verification. Moreover, its overall testing efficiency is currently low.

[0017] Specifically, as the complexity of software systems increases, microservice architecture is now the primary approach. Microservice architecture breaks down a system into multiple independent business modules (microservices). These modules interact and collaborate through interfaces, and each module can be developed, iterated, and deployed independently, thus improving system development efficiency and scalability. However, the characteristics of microservice architecture also significantly increase the difficulty of integration testing. The coordinated operation of multiple business modules relies on precise interface interactions and logical coordination; even a minor change in any business module can affect the entire chain of operations.

[0018] Currently, integration testing is primarily done manually. Testers need to create test plans based on their experience and requirements documents, including the necessary topology and test cases. This process involves manually interpreting the requirements documents word for word, meticulously analyzing the interaction logic of multiple business modules within the software system, and then writing test cases. This process is not only time-consuming and labor-intensive but also limited by the testers' individual experience, making it prone to overlooking test scenarios. Furthermore, the long cycle of manually writing test cases makes it difficult to adapt to the rapid iteration needs of the software system, thus slowing down the release schedule.

[0019] Secondly, integration testing requires setting up a dedicated test environment containing multiple business modules. Manual configuration can easily lead to errors such as incorrect parameter settings and discrepancies in understanding module dependencies. Furthermore, test environments set up by different testers may differ, resulting in different test results for the same test case in different environments. This increases the difficulty of troubleshooting and further reduces testing efficiency.

[0020] Secondly, the current level of automation in integration testing is low. For example, taking an advertising push system as an example, in whitelist exposure integration testing, when manually executing test cases, it is necessary to manually construct advertising requests carrying whitelist identifiers and user profile tags according to the test cases, manually send them to the retrieval entry module, and then manually verify the whitelist identifier transmission status of the mixer module, the whitelist video style synthesis results, and the whitelist video queue splitting, internal sorting, and deduplication of the sorting module. This process is not only cumbersome and time-consuming, but manual verification is also prone to oversights. Moreover, manual testing cannot achieve end-to-end automated verification. For multi-round, multi-scenario whitelist exposure testing, the amount of repetitive operations is large, further reducing testing efficiency.

[0021] Currently, while some automation tools are used in certain parts or steps of the integration testing process—for example, some tools can automatically send requests or set up test environments—most of these tools rely on static rules and cannot automatically update test data or detect changes in module logic as business iteratively changes. Each business upgrade or rule adjustment requires manual modification of configurations and updating of test cases, resulting in poor flexibility and high maintenance costs. Furthermore, existing optimization methods are limited to single points in the testing process, lacking a comprehensive end-to-end support system from requirements understanding, solution generation, environment setup to test case execution, making it difficult to form a closed-loop delivery system.

[0022] To address at least one of the aforementioned technical problems, this disclosure provides a method, apparatus, electronic device, non-transient computer-readable storage medium, and computer program product for joint debugging testing. Through the coordinated operation of a first intelligent agent, a second intelligent agent, and a third intelligent agent, it achieves automatic generation of test cases, automatic setup of the test environment, and automatic execution of test cases, thereby reducing manual operation costs and test deviations, and improving the efficiency and accuracy of joint debugging testing.

[0023] The following section will first introduce the joint debugging and testing methods provided in this publication.

[0024] Figure 1 This is a schematic flowchart of a joint debugging and testing method provided in an embodiment of this disclosure. Figure 1 As shown, the joint debugging and testing method provided in this embodiment may include the following steps S101 to S104.

[0025] S101: Obtain change request information for the target software system.

[0026] The target software system can be any software system, and this disclosure does not limit it. In this disclosure, for ease of understanding, the target software system is illustrated using an advertising push system as an example, but the target software system can also be other software systems.

[0027] In S101, change request information for the target software system, such as requirement documents and / or change code for business upgrades, can be uploaded by users or automatically retrieved by the system from the code repository or requirements management database. For example, in some examples, users can proactively upload requirement documents and / or change code for business upgrades of the target software system. In other examples, when a user submits change code in the code repository, the system can automatically identify the project card associated with the change and retrieve the corresponding requirement document from the project card, and / or extract the change code from the code repository. The requirement document primarily describes the background, business objectives, and scope of the software system upgrade.

[0028] S102: The first intelligent agent generates test cases for joint testing of multiple business modules in the target software system based on the change requirement information and the testing experience in the test knowledge base.

[0029] The first intelligent agent, also known as the test case generation agent, is primarily used to transform requirement documents described in natural language and / or code-level change code into structured test cases. The first intelligent agent is deployed with at least one large language model, which can be fine-tuned using historical test case data and a test experience knowledge base, enabling it to understand the business logic of the software system, identify the scope of changes, and generate test cases.

[0030] In step S102, change requests for the target software system can be input into the first intelligent agent. The first intelligent agent can perform semantic parsing on the request document to extract information such as the change scenarios and change parameters involved in this change. For example, taking an advertising push system as the target software system, in a whitelist exposure scenario, the first intelligent agent can parse the change scenario as a whitelist exposure scenario, i.e., a whitelist ad priority exposure optimization scenario, where the optimization goal is to improve the exposure accuracy of whitelist ads in specified traffic. Change parameters may include whitelist matching conditions, whitelist ad targets, and / or whitelist exposure effective scope, etc.

[0031] The first intelligent agent can also parse the changed code to obtain code change information. For example, the code change information may include the changed business module, the environment configuration items involved, the request fields involved, and / or the business processing rules involved. For instance, taking an advertising push system as an example, in a whitelist exposure scenario, the first intelligent agent can parse out the changed code involving the mixer module and the sorter module, and discover that new pass-through logic for the whitelist identifier field and processing rules for the whitelist video queue have been added.

[0032] Then, the first intelligent agent combines the semantic parsing results and / or code change information with the testing experience in the test knowledge base to determine the multiple business modules that need to be integrated and tested, the environment configuration information, the request configuration information, and the verification rules of the target business modules that need to be verified, and finally generates test cases.

[0033] S103: Based on the test cases generated by the first intelligent agent, the second intelligent agent determines the module call topology required for joint debugging and testing, and builds or matches a test environment containing multiple business modules according to the module call topology.

[0034] The second intelligent agent, also known as the test environment setup agent, is primarily used to automatically identify the required test topology based on the test cases and modified code generated by the first intelligent agent, and to build or match the test environment according to the test topology. The second intelligent agent is deployed with at least one classification model or matching model, which can be trained through historical topology data and business scenario annotations, enabling it to identify business scenarios and match module call topologies.

[0035] In S103, the second agent can parse the test cases generated by the first agent to determine the module call topology required for this joint debugging test, i.e., the test topology. The module call topology represents the call relationships between multiple business modules. For example, in a whitelist exposure scenario, the module call topology can represent the call relationships between the retrieval entry module, the advertising library module, the mixer module, the sorting module, and the front-end module.

[0036] After obtaining the module call topology, the second agent can invoke the pre-built environment platform. If a test environment matching the module call topology exists in the environment platform, it is used directly. If no test environment matching the module call topology exists in the environment platform, the environment platform is invoked to automatically build a test environment containing multiple business modules based on the module call topology. After the test environment is built, an access address for the test environment is generated for subsequent test execution.

[0037] S104: The test cases generated by the first agent are executed by the third agent in the test environment built by the second agent to obtain the test results.

[0038] The third-party intelligent agent, also known as the test execution intelligent agent, is mainly used to automatically execute various operations in test cases, such as modifying environment configurations, sending requests, and verifying results. The third-party intelligent agent can be deployed as an independent execution engine, parsing the structured information of test cases and calling the corresponding operation interfaces to complete the test.

[0039] In S104, the third agent can establish a connection with the test environment built by the second agent based on the access address of the test environment. Then, the test cases generated by the first agent are automatically executed in the test environment to obtain the test results. The test results can be persistently stored for later viewing and analysis.

[0040] The integration testing method provided by this invention, through the collaborative cooperation of a first intelligent agent, a second intelligent agent, and a third intelligent agent, can automatically generate test cases for integration testing of multiple business modules in the target software system based on the change requirements information of the target software system, automatically build or match a test environment containing multiple business modules, and automatically execute integration testing based on the test cases and the test environment. This helps to reduce the operational cost and test deviation of integration testing, and improve the efficiency and accuracy of integration testing.

[0041] Specifically, the first intelligent agent automatically parses change requirement information and generates test cases by combining it with testing experience from the test knowledge base. This lowers the experience threshold for testers, solves the problems of missed test scenarios and incomplete verification that may occur with manual analysis, and improves the completeness and generation efficiency of test cases. The second intelligent agent automatically determines the module call topology and builds or matches the test environment based on the results generated by the first agent. The third intelligent agent automatically executes the test cases built by the second agent within the test environment, shortening the test environment preparation time and enabling rapid deployment and execution of integration tests, further improving the efficiency and accuracy of integration tests.

[0042] To facilitate understanding, the joint debugging and testing method provided in this disclosure will be described in detail below with reference to some specific embodiments.

[0043] According to some embodiments of this disclosure, optionally, the change requirement information may include a requirement document for upgrading the target software system's business. The requirement document mainly describes the background, business objectives, and change parameters of this software system upgrade. For example, taking an advertising push system as an example, in a whitelist exposure scenario, the first intelligent agent can parse that the change background is that the exposure rate of some whitelisted ads is unstable under certain traffic conditions, requiring optimization of the whitelist exposure strategy, and the business objective is to improve the exposure accuracy of whitelisted ads in specified traffic. Change parameters may include whitelist matching conditions, whitelisted ad targets, and / or the effective scope of whitelist exposure.

[0044] Accordingly, S102: Based on the change requirement information and combined with the testing experience in the test knowledge base, the first intelligent agent generates test cases for joint debugging tests of multiple business modules in the target software system, which may include the following steps: The first intelligent agent performs semantic parsing on the requirement document to obtain the semantic parsing results. Combining the semantic parsing results with the testing experience in the test knowledge base, the multiple business modules that need to be integrated and tested, the environment configuration information, the request configuration information, and the verification rules of the target business modules that need to be verified are determined, and test cases are obtained.

[0045] Specifically, the first intelligent agent first performs semantic parsing on the requirements document to obtain the semantic parsing results. These results can include information such as the change scenarios and change parameters involved in the change. For example, taking an advertising push system as the target software system, in a whitelist exposure scenario, the first intelligent agent can parse the change scenario as a whitelist exposure scenario, specifically a whitelist ad priority exposure optimization scenario, where the optimization goal is to improve the exposure accuracy of whitelist ads in specified traffic. Change parameters can include whitelist matching conditions, whitelist ad targets, and / or the effective scope of whitelist exposure.

[0046] Then, based on the parsed change scenario and testing experience in the test knowledge base, the first intelligent agent determines the business modules that need to undergo integration testing. Next, based on the change scenario and change parameters, and combined with configuration and request construction experience in the test knowledge base, the first intelligent agent determines the environment configuration information and request configuration information. Then, based on the change scenario and change parameters, and combined with verification experience in the test knowledge base, the first intelligent agent determines the verification rules for the target business modules that need to be verified. For example, taking the whitelist exposure scenario as an example, the verification rules for the mixer module include verifying whether the whitelist identifier field is correctly transmitted and whether the whitelist video style is correctly synthesized. The verification rules for the sorter module include verifying whether the splitting, sorting, deduplication, and quantity boundary values ​​of the whitelist video queue meet expectations.

[0047] Then, the first intelligent agent integrates the identified multiple business modules, environment configuration information, request configuration information, and verification rules for the target business module to be verified into structured test cases. Test cases may include test case names, environment configuration information, request configuration information, and verification point information.

[0048] Thus, by using the first intelligent agent to perform semantic parsing of the requirements document, key information such as change scenarios and change parameters can be automatically extracted, transforming business requirements described in natural language into structured test case elements, reducing the requirements for testers' business understanding. On the other hand, by combining testing experience from the test knowledge base to determine business modules, environment configurations, request configurations, and verification rules, test knowledge accumulated in historical projects can be reused, such as module association experience, configuration experience, request construction experience, and verification experience. This effectively avoids designing from scratch for each integration test, and the full matching based on historical experience can cover test scenarios that are easily overlooked by humans, effectively solving the problems of test omissions and incomplete verification. In particular, by parsing change parameters, such as whitelist matching conditions, whitelist advertising objects, and / or whitelist exposure effective range, corresponding request field value rules and environment configuration effective ranges can be accurately generated, making test cases closely related to the specific content of this change, further improving the relevance and accuracy of testing.

[0049] According to some embodiments of this disclosure, the change requirement information may optionally include change code for the target software system. By analyzing the change code, fine-grained information such as the business module whose code has been changed, the changed business logic or processing rules, the configuration items involved in the change, the request fields involved in the change, and / or the changes in interfaces between modules can be obtained. Compared to the requirements document, the change code can provide more accurate change information, which helps to generate more refined test cases.

[0050] Figure 2 This is a schematic flowchart of step S102 in the joint debugging and testing method provided in this embodiment of the disclosure. Figure 2 As shown, correspondingly, S102: The first intelligent agent generates test cases for joint debugging tests of multiple business modules in the target software system based on the change requirement information and combined with the test experience in the historical test knowledge base. It may also include the following steps S202 and S203.

[0051] S202: The first intelligent agent parses the changed code to obtain code change information.

[0052] In S202, the first intelligent agent can perform static code analysis on the changed code to obtain code change information. In some embodiments, the code change information may optionally include at least one of the following: the changed business module, the environment configuration items involved in the change, the request fields involved in the change, and the business processing rules involved in the change. For example, in a whitelist exposure scenario, after parsing the changed code, the first intelligent agent can obtain the following code change information: the changed business modules are the mixer module and the sorter module; the environment configuration item involved in the change is the addition of a whitelist exposure switch in the mixer module; the request field involved in the change is the addition of a whitelist identifier field in the request; and the business processing rule involved in the change is that the whitelist video quantity boundary value is 5. Additionally, in other embodiments, the code change information may also include the change type (such as addition, deletion, modification, or reconstruction), changes in input or output parameters of inter-module interfaces, etc.

[0053] S203: Based on code change information, correct the verification rules for multiple business modules, environment configuration information, request configuration information, and / or target business modules.

[0054] In S203, the first intelligent agent can combine code change information to correct the verification rules of multiple business modules, environment configuration information, request configuration information and / or target business modules.

[0055] In some embodiments, optionally, S203: Correcting the verification rules of multiple business modules, environment configuration information, request configuration information, and target business module in conjunction with code change information may include at least one of the following: correcting multiple business modules and / or target business modules according to the business modules that have changed; correcting environment configuration information according to the environment configuration items involved in the change; correcting request configuration information according to the request fields involved in the change; and correcting verification rules according to business processing rules.

[0056] Specifically, the initially determined list of business modules can be revised based on the business modules that have changed in the modified code. For example, if the code change shows that business module A has not actually changed, it will be removed from the target business module list. If the code change shows that business module B has been added, it will be added to the target business module list. The configuration switch names, expected values, or effective ranges of configuration switches in the environment configuration information can be corrected based on the environment configuration items involved in the modified code. For example, in a whitelist exposure scenario, if the environment configuration information in the initial test case is a whitelist switch (whitelist_switch), while the actual configuration item name in the modified code is a whitelist exposure switch (enable_whitelist_exposure), the configuration switch name will be corrected to enable_whitelist_exposure. If the default value of the configuration item in the code is false, the expected value will be corrected to false.

[0057] Based on the changes made to the request fields in the modified code, the names, data types, or value rules of the request fields in the request configuration information can be corrected. For example, in a whitelist exposure scenario, if the initial test case uses the whitelist flag (whitelist_flag) field in the request configuration information, but the actual request field name in the modified code is whitelist identifier (whitelist_id), then the request field name should be corrected to whitelist_id. If the field type in the code is string, then the data type should be corrected to string. If the field value rule in the code is that the whitelist user identifier is a string type and not empty, then the value rule should be corrected.

[0058] Based on the changes to the business processing rules in the modified code, the validation objects, validation conditions, or expected results in the validation rules can be corrected. For example, in a whitelist exposure scenario, if the initial test case's validation rule is to verify that the number of whitelisted videos does not exceed 10, while the actual business processing rule in the modified code is that the boundary value for the number of whitelisted videos is 5, then the boundary value for the number of videos in the expected result will be corrected to 5. If the validation object in the code is the output log of the sorting module, then the validation object will be corrected to the output log of the sorting module. If the validation condition in the code is that the length of the whitelisted video list is less than or equal to 5, then the validation condition will be corrected.

[0059] For example, taking an advertising recommendation system as an example, in a whitelist exposure scenario, the initial test cases generated based on the requirements document include a mixer module and a sorter module as the target business modules. The environment configuration information includes a whitelist switch (whitelist_switch), the request configuration information includes a whitelist flag (whitelist_flag) field, and the verification rule is to verify that the number of whitelisted videos does not exceed 10. By analyzing the changed code, it was found that the actual changed modules include the mixer module and the sorter module; the actual configuration item name is whitelist exposure switch (enable_whitelist_exposure); the actual request field name is whitelist identifier (whitelist_id); and the boundary value for the number of whitelisted videos in the actual business processing rule is 5. Based on this, the first intelligent agent corrected the test cases: the target business modules remained unchanged, the configuration switch name was corrected to whitelist exposure switch (enable_whitelist_exposure), the request field name was corrected to whitelist identifier (whitelist_id), and the boundary value for the number of videos in the verification rule was corrected to 5. Through these corrections, more accurate integration test cases were obtained.

[0060] In this way, by parsing the changed code through the first intelligent agent, fine-grained change information that cannot be provided in the requirements document can be obtained, such as the actual business module that has changed, the content of the change, the name of the configuration item, the name of the requested field, and / or the business processing rules. This information enables test cases to delve into the code implementation level and generate more accurate test cases.

[0061] On the other hand, by incorporating code change information to correct initial test cases generated from requirements documents, test case deviations caused by inaccurate descriptions in the requirements documents or inconsistencies with the code implementation can be reduced. For example, when the names of configuration items described in the requirements document differ from those in the actual code, code parsing can automatically correct this, effectively reducing test failures due to incorrect configuration item names. Simultaneously, code parsing can accurately identify the modules that have actually changed, effectively preventing testers from misjudging the scope of changes based on business understanding, thereby reducing unnecessary test cases.

[0062] To facilitate understanding, the following example uses the target software system as an advertising push system.

[0063] According to some embodiments of this disclosure, the target software system may optionally include an advertising push system, and the requirements document may include whitelist exposure strategy change information.

[0064] S201: The first intelligent agent performs semantic parsing on the requirement document to obtain the semantic parsing result, which may include the following steps: The first intelligent agent performs semantic analysis on the whitelist exposure strategy change information to extract the change scenarios, whitelist matching conditions, whitelist advertising objects, and whitelist exposure effective scope involved in this change.

[0065] For example, the change scenario can be used to describe the type of business scenario to which this change belongs. Taking an advertising recommendation system as an example, the change scenario may include a whitelist ad priority exposure optimization scenario, a whitelist ad style upgrade scenario, or other scenarios, etc., and this disclosure does not limit it.

[0066] Whitelist matching criteria can be used to define which users or which ads can trigger whitelist exposure logic. For example, whitelist matching criteria can include matching conditions for the user profile corresponding to the whitelist ad (such as user level, active duration, etc.), ad type admission criteria, and / or whitelist identifier matching rules, etc.

[0067] The whitelist of ad objects can be used to define which ads belong to the whitelist and the ad display format. For example, a whitelist of ad objects can include specified whitelist ad resource identifiers, ad placement types, and / or ad content specifications. The whitelist exposure scope can be used to define the effective boundaries of the whitelist exposure strategy. For example, the whitelist exposure scope can include specified user groups and / or exposure periods.

[0068] Accordingly, by combining the semantic parsing results and the testing experience in the test knowledge base, we determine the multiple business modules that need to be integrated and tested, the environment configuration information, the request configuration information, and the verification rules of the target business modules that need to be verified, and obtain test cases, which may include the following steps one to four.

[0069] Step 1: Based on the change scenario, determine the business modules that need to be integrated and tested, including the mixer module and the sorter module.

[0070] In step one, the first intelligent agent, based on the parsed change scenario (such as a whitelist ad exposure optimization scenario) and combined with the module information involved in historical tests under this change scenario recorded in the test knowledge base, determines that the business modules to be covered in this joint debugging test include the mixer module and the sorter module. The mixer module is mainly used to identify whitelist identifiers in requests and perform style synthesis, while the sorter module is mainly used to split, sort, and deduplicate the whitelist video queue. Locating the business modules through the change scenario allows for a rapid narrowing of the test scope.

[0071] Step 2: Based on the effective scope of whitelist exposure and testing experience in the historical test knowledge base, determine the environment configuration information, including the configuration switch for the whitelist exposure logic in the mixer module.

[0072] In step two, the first agent, based on the parsed whitelist exposure effective range and combined with environmental configuration experience from the test knowledge base (such as the whitelist exposure function requiring a corresponding configuration switch to be enabled in the mixer module, and the effective range of the configuration switch being consistent with the whitelist exposure effective range), determines the environmental configuration information, including the configuration switch of the whitelist exposure logic in the mixer module. This whitelist exposure logic configuration switch controls whether the whitelist exposure function is enabled within a specified effective range. For example, if the whitelist exposure effective range is information flow traffic, the environmental configuration information needs to configure the whitelist exposure switch of the mixer module to be enabled, limiting its effective range to information flow traffic.

[0073] Step 3: Based on the whitelist matching criteria and testing experience from the historical test knowledge base, determine the request configuration information, including the whitelist identifier and user profile tag fields that need to be included in the request.

[0074] In step three, the first agent, based on the parsed whitelist matching conditions, such as the whitelist user identifier determination rules, and combined with request construction experience in the test knowledge base (e.g., whitelist exposure requests need to carry a user identifier field for whitelist matching, and a user profile tag field for subsequent ad matching and sorting), determines the request configuration information, including the whitelist identifier field and the user profile tag field that the request must carry. The whitelist identifier field identifies whether the current user is a whitelisted user, and the user profile tag field describes the user's age, gender, and / or interest tags. By carrying these fields, the test request can simulate real-world whitelisted user request scenarios.

[0075] Step 4: Determine the validation rules for the mixer module and the sorter module based on the whitelist matching conditions, the whitelist advertising targets, and the testing experience in the historical test knowledge base.

[0076] In step four, the first agent determines the verification rules for the mixer module based on the parsed whitelist matching conditions and the verification experience in the test knowledge base, such as the need to verify the field pass-through and style synthesis of the mixer module when whitelist exposure is required. Similarly, based on the parsed whitelisted ad objects and the verification experience in the test knowledge base, such as the need to verify the queue processing results of the sorting module when whitelist exposure is required, the first agent determines the verification rules for the sorting module.

[0077] In some examples, optionally, the validation rules of the mixer module can be used to validate the pass-through of the whitelist identifier field and the synthesis of whitelist video styles. Specifically, it verifies whether the whitelist identifier field is correctly extracted from the request and passed through to the downstream module, and whether the styles of the whitelist videos are correctly synthesized. For example, the styles of the whitelist videos include, but are not limited to, coin styles, gift box styles, or treasure chest styles.

[0078] In some examples, optionally, the validation rules of the sorting module can be used to validate at least one of the following: whitelist video queue splitting, internal sorting of whitelist videos, whitelist video deduplication, and whitelist video quantity boundary values. Specifically, it validates whether the whitelist video queue is split into individual videos as expected, whether the sorting result of the whitelist videos conforms to the expected order, whether duplicate whitelist videos are correctly deduplicated, and whether the final output number of whitelist videos does not exceed a preset boundary value, etc.

[0079] Thus, by semantically parsing the whitelist exposure strategy change information, key change information such as change scenarios, whitelist matching conditions, whitelist advertising targets, and whitelist exposure effective scope can be automatically extracted. Compared to manual analysis, the intelligent agent can identify the core content of the changes more quickly and accurately, reducing the requirements for testers' business understanding. On the other hand, by combining the extracted change information with historical testing experience in the test knowledge base, the business modules, environment configuration information, request configuration information, and verification rules of each module required for integration testing can be automatically determined. This makes test case generation no longer dependent on the testers' personal experience, but based on the testing knowledge accumulated from historical projects, effectively reducing the omission of test scenarios due to insufficient experience or negligence.

[0080] According to some embodiments of this disclosure, optionally, S203: Correcting the verification rules of multiple business modules, environment configuration information, request configuration information, and the target business module in conjunction with code change information may include at least one of the following: Verify whether the target business module contains a mixer module and a sorter module; Based on the environment configuration items involved in the change code, correct the configuration switch name, expected value, or effective range of the whitelist exposure logic in the mixer module. Based on the request fields involved in the change code, correct the names, data types, or value rules of the request fields in the request configuration information. The request fields include whitelist identifier fields and / or user profile tag fields. Based on the business processing rules involved in the changes in the change code, correct the verification objects, verification conditions, or expected results in the verification rules.

[0081] Specifically, the first intelligent agent can verify whether the initially determined target business modules include the mixer module and the sorter module based on the business modules that have changed in the change code. If the change code indicates that the mixer module or the sorter module has not actually changed, it is removed from the list of target business modules. If the change code indicates that both the mixer module and the sorter module have changed, they are retained.

[0082] The first agent can correct the configuration switch name, expected value, or effective scope of the whitelist exposure logic in the mixer module based on the environment configuration items involved in the code changes. For example, if the environment configuration information in the initial test case is whitelist switch (whitelist_switch), but the actual configuration item name in the changed code is whitelist exposure switch (enable_whitelist_exposure), then the configuration switch name will be corrected to whitelist exposure switch (enable_whitelist_exposure). If the default value of the configuration item in the code is false, then the expected value will be corrected to false. If the effective scope of the configuration switch in the code is limited to information flow traffic, then the effective scope will be corrected to information flow traffic.

[0083] The first intelligent agent can correct the names, data types, or value rules of request fields in the request configuration information based on the changes involved in the modified code. Request fields may include whitelist identifier fields and / or user profile tag fields. For example, if the whitelist identifier field name in the initial test case is whitelist_flag, but the actual request field name in the modified code is whitelist_id, then the request field name will be corrected to whitelist_id. If the field type in the code is string, then the data type will be corrected to string. If the field value rule in the code is that the whitelist user identifier is a string type and not empty, then the value rule will be corrected. User profile tag fields can also be corrected based on the code modification information in a similar manner.

[0084] The first intelligent agent can adjust the verification objects, verification conditions, or expected results in the verification rules based on the changes to the business processing rules involved in the modified code. For example, if the initial test case's verification rule is to verify that the number of whitelisted videos does not exceed 10, while the actual business processing rule in the modified code is that the boundary value for the number of whitelisted videos is 5, then the boundary value for the number in the expected result will be adjusted to 5. If the verification object in the code is the output log of the sorting module, then the verification object will be adjusted to the output log of the sorting module.

[0085] In this way, precise alignment between test cases and code implementation is achieved through code parsing and correction. Compared to solutions that rely solely on requirements documents to generate test cases, this improves the accuracy of test cases, reduces test rework caused by inconsistencies between requirements and code, and further enhances the efficiency and reliability of integration testing. Furthermore, because the test cases are based on actual code changes and corrections, the test coverage is more targeted, effectively avoiding missing test scenarios or verification errors caused by vague or incomplete requirements documentation or inconsistencies with code implementation.

[0086] Figure 3 This is a schematic diagram of an interface for a test case. For example... Figure 3 As shown, according to some embodiments of this disclosure, optionally, test cases may include the name of the test case, environment configuration information, request configuration information, and verification point information.

[0087] The environment configuration information can be used to describe the request type and request fields of the request to be sent; the request configuration information can be used to describe the configuration items that need to be modified in the test environment; and the verification point information can be used to describe the target business module to be verified and its verification rules. For example, the target business module may include a mixer module and a sorter module. The verification rules for the mixer module may include whitelist video style synthesis verification rules and whitelist identifier field verification rules, etc. The verification rules for the sorter module may include multiple whitelist video queue splitting verification rules, whitelist video internal PK sorting verification rules, whitelist video deduplication verification rules, and / or whitelist video quantity verification rules, etc.

[0088] In this way, the third-party intelligent agent can directly parse environment configuration information and automatically modify the configuration of each module in the test environment; it can also directly parse request configuration information, automatically construct and send requests, and directly parse verification point information to automatically verify the execution results. Compared with traditional manually written natural language test cases, structured test cases do not require manual translation and interpretation, realizing a rapid conversion from test cases to automated execution.

[0089] Figure 4 This is a schematic flowchart of step S103 in the joint debugging and testing method provided in this embodiment of the disclosure. Figure 4 As shown, according to some embodiments of this disclosure, optionally, S103: determining the module call topology required for joint debugging test by the second agent based on the test cases generated by the first agent may include the following steps S401 to S403.

[0090] S401: The second intelligent agent parses the test cases generated by the first intelligent agent and extracts business scenario features.

[0091] Specifically, the second intelligent agent can perform semantic parsing on the test case names, request configuration information, and verification point information in the test cases generated by the first intelligent agent to identify the business scenario to which the test belongs and extract business scenario features. Business scenario features can include business scenario identifiers. For example, in a whitelist exposure scenario, the second intelligent agent parses the test cases generated by the first intelligent agent, identifies whitelist exposure keywords from the test case names, whitelist identifier fields from the request configuration information, and mixer and sorter modules from the verification point information, thereby determining that the business scenario feature is a whitelist exposure scenario.

[0092] S402: The second intelligent agent parses the change code of the target software system and extracts the features of the changed modules.

[0093] Specifically, the second intelligent agent can perform static code analysis on the modified code, parse the abstract syntax tree of the code, identify the location and type of code changes, and extract the features of the modified modules. These features can include the names of the business modules whose code has been modified and their dependencies. For example, in a whitelist exposure scenario, after parsing the modified code, the second intelligent agent can extract the following features: the modified business modules include the mixer module and the sorter module; the module dependencies are that the mixer module depends on the sorter module.

[0094] S403: From the preset topology library, query the module call topology that matches the business scenario characteristics and changed module characteristics, and use it as the module call topology required for joint debugging and testing.

[0095] Specifically, the pre-defined topology library stores multiple predefined module call topologies, each representing the call relationships between multiple business modules in a specific business scenario. The second agent can query the pre-defined topology library for module call topologies that match the business scenario characteristics and changed module characteristics, and use them as the module call topologies required for integration testing.

[0096] In this way, by parsing test cases and modified code to extract business scenario features and modified module features, candidate topologies that match these features can be quickly and accurately retrieved from the topology library. Compared to manual identification of business scenarios and topologies, the intelligent agent can complete scenario identification and topology matching more quickly and accurately, shortening the test environment preparation time. Through a pre-defined topology library and an automated topology matching mechanism, the test environment can be quickly ready.

[0097] According to some embodiments of this disclosure, the target software system may optionally include an advertising push system. Business scenario characteristics may include a business scenario identifier, and changed module characteristics may include the business modules whose code has been changed and their dependencies.

[0098] Figure 5 This is a schematic flowchart of step S403 in the joint debugging and testing method provided in this embodiment of the disclosure. Figure 5 As shown, S403: Query the module call topology that matches the business scenario characteristics and change module characteristics from the preset topology library, which may include the following steps S501 to S505.

[0099] S501: Query the candidate module call topology corresponding to the business scenario identifier from the preset topology library.

[0100] The second intelligent agent performs a matching query in the topology database based on the business scenario identifier to find the candidate module call topology corresponding to the business scenario identifier.

[0101] S502: Verify whether the candidate module call topology contains business modules that have undergone code changes.

[0102] The second agent verifies whether the candidate module call topology includes business modules that have undergone code changes, such as the mixer module and the sorter module. This disclosure does not limit this.

[0103] S503: Verify whether the call relationships in the candidate module call topology satisfy the module dependency relationship.

[0104] The second agent verifies whether the call relationships in the candidate module call topology satisfy module dependencies. For example, it verifies whether there exists a call relationship in the candidate topology from the mixer module to the sorter module. If it exists, the verification passes; if it does not exist, the verification fails.

[0105] S504: If the candidate module call topology contains a business module that has undergone code changes and the call relationship satisfies the module dependency relationship, then the candidate module call topology will be determined as the module call topology required for joint debugging and testing.

[0106] If a candidate module call topology includes business modules that have undergone code changes and the call relationships satisfy module dependencies, it means that the candidate module call topology includes all the changed business modules and satisfies the actual module dependencies. Therefore, it can be directly used as the module call topology required for integration testing.

[0107] S505: If not satisfied, the candidate module call topology is modified according to the business module and module dependency relationship that has undergone code changes, so as to obtain the module call topology required for joint debugging test.

[0108] When a candidate module call topology does not include a business module that has undergone code changes and / or the call relationships do not satisfy module dependencies, the second agent can modify the candidate module call topology. Specifically, if a changed business module is missing from the candidate topology, the business module is added to the candidate module call topology, and call edges between it and other modules are established based on module dependencies. If the call relationships in the candidate module call topology do not satisfy module dependencies, the call edges in the topology are adjusted to conform to the dependencies.

[0109] For example, in a whitelist exposure scenario, suppose the candidate module call topology includes a mixer module and a sorter module, but there is no direct call relationship between the mixer module and the sorter module in the topology. Based on the module dependency relationship "the mixer module depends on the sorter module", the second agent adds a call edge from the mixer module to the sorter module in the topology to complete the correction.

[0110] Through the above correction operations, even if the initial candidate module call topology does not completely match the actual code changes, the second agent can automatically complete the correction and finally obtain a module call topology that meets the requirements.

[0111] Figure 6 This is a schematic diagram of a module call topology. For example... Figure 6 As shown, in some embodiments, optionally, the module call topology is used to characterize the call relationship between the retrieval entry module 601, the ad library module 602, the mixer module 603, the sorter module 604, and the front-end module 605. Specifically, the user request first arrives at the retrieval entry module 601, which retrieves candidate ads from the ad library module 602, and then passes the request and candidate ads to the mixer module 603 for filtering and style synthesis. After processing, the mixer module 603 calls the sorter module 604 to sort and deduplicate the ad queue, and the final processing result is returned to the front-end module 605 for rendering and display.

[0112] Thus, by querying candidate module call topologies based on business scenario identifiers and then verifying whether these topologies contain the changed business modules and whether the call relationships satisfy module dependencies, a two-stage matching process from coarse to fine is achieved. This combination makes topology matching both fast and accurate. On the other hand, when a candidate module call topology does not meet the verification conditions, the second agent can automatically correct the topology based on the changed business modules and module dependencies, rather than simply returning a matching failure. This automatic correction mechanism improves the success rate of topology matching, reduces the need for manual intervention, and ensures that even with an incomplete topology library, usable module call topologies can be obtained to a large extent.

[0113] Figure 7This is a schematic flowchart of step S103 in the joint debugging and testing method provided in this embodiment of the disclosure. Figure 7 As shown, according to some embodiments of this disclosure, optionally, S103: building or matching a test environment containing multiple business modules according to the module call topology may include the following steps S701 to S703.

[0114] S701: Query the historical test environments that match the module call topology from the environment platform.

[0115] Specifically, the environment platform manages multiple test environments, each of which can contain instances of multiple business modules and their call relationship configurations. The environment platform can store records of historical test environments, each associated with a module call topology. A second agent can initiate a query request to the environment platform based on a defined module call topology to check if a historical test environment matching that topology exists.

[0116] S702: If a historical test environment exists that matches the module call topology, then the historical test environment will be used as the test environment for this joint debugging test, and the access address of the historical test environment will be used as the access address of the test environment.

[0117] If the query results returned by the environment platform indicate the existence of a historical test environment that matches the module call topology, the second agent can directly reuse that historical test environment without needing to rebuild it. The second agent obtains the access address of the historical test environment and uses it as the access address of the test environment for this integration test. Reusing historical test environments can shorten the preparation time for the test environment.

[0118] S703: If there is no historical test environment that matches the module call topology, then build the test environment for this joint debugging test according to the module call topology call environment platform, and generate the access address of the test environment.

[0119] If the query result returned by the environment platform indicates that no historical test environment matches the module call topology, the second agent initiates an environment setup request to the environment platform based on the module call topology. The environment platform automatically deploys instances of each business module according to the module call topology and configures the call relationships between the business modules, thus completing the setup of the test environment.

[0120] Once the test environment is set up, the environment platform generates an access address for that test environment and returns it to the second agent. The second agent uses this access address as the access address for the test environment in this joint debugging test, for subsequent use by the third agent.

[0121] Figure 8 This is a schematic diagram of an interface for a test environment. For example... Figure 8As shown, the test environment interface displays information such as the name of the current test environment, access address, list of included business modules, and a topology diagram of the call relationships between modules. Users can view detailed information about the test environment through this interface, and can also manually modify the environment configuration or troubleshoot problems.

[0122] In this way, by prioritizing the query of historical test environments that match the module call topology, the repeated construction of test environments with the same configuration is effectively avoided. When a matching historical test environment exists, the second agent can reuse it directly without redeploying and configuring each module instance, shortening the test environment preparation time and improving the overall efficiency of joint debugging tests. On the other hand, when no matching historical test environment exists, the second agent can automatically call the environment platform to complete the test environment construction based on the module call topology, realizing on-demand automatic deployment of test environments. By storing newly constructed test environments in the environment platform as historical test environments, the continuous accumulation and reuse of test environments are achieved. As the number of projects increases, the historical test environments accumulated in the environment platform become richer and richer, and the environment matching success rate of subsequent projects becomes higher and higher, further reducing the need for building new environments and continuously reducing the preparation cost of test environments.

[0123] Figure 9 This is a schematic flowchart of step S104 in the joint debugging and testing method provided in this embodiment of the disclosure. Figure 9 As shown, according to some embodiments of this disclosure, optionally, S104: executing the test cases generated by the first agent through the test environment built by the second agent by the third agent may include the following steps S901 to S904.

[0124] S901: Access address for the test environment built based on the second intelligent agent, used to access the test environment.

[0125] The access address of the test environment can point to the test environment entry point provided by the environment platform. The third-party intelligent agent can access the configuration interfaces of various business modules in the test environment through this entry point.

[0126] S902: Based on the environment configuration information in the test cases generated by the first intelligent agent, modify the configuration of multiple business modules in the test environment.

[0127] The third agent can modify the configuration of multiple business modules in the test environment based on the environment configuration information in the test cases generated by the first agent, such as the business module name, configuration item name, expected value of the configuration item, and / or the effective scope of the configuration item.

[0128] S903: Based on the request configuration information in the test cases generated by the first intelligent agent, construct and send a request to trigger the sequential invocation of multiple business modules.

[0129] The third agent can construct and send a request based on the request configuration information in the test cases generated by the first agent, such as the request type and request fields. For example, in a whitelist exposure scenario, the request configuration information in the test cases may include: "Request type: Ad request; Request fields: Whitelist identifier (whitelist_id) = user 12345; User profile tag (user_profile) = age 18-25 years old". Based on this configuration information, the third agent constructs an ad request carrying the whitelist identifier field and the user profile tag field, and then sends the request to the entry module of the test environment, such as the retrieval entry module, through the access address of the test environment.

[0130] After the request is sent, it will trigger calls to multiple business modules sequentially according to the call relationships defined in the module call topology. For example, in a whitelist exposure scenario, the request first reaches the search entry module, then passes through the ad library module, mixer module, sorter module, and finally returns to the front-end module.

[0131] S904: Based on the verification point information in the test cases generated by the first intelligent agent, verify the execution data of the target business module and obtain the test results.

[0132] The third agent can sequentially verify all verification points based on the verification point information in the test cases generated by the first agent, such as the verification object, verification conditions, and expected results. It records the verification result of each verification point and the specific reason for failure, such as the whitelist identifier field not being found or the whitelist video queue length exceeding the boundary value. Then, the third agent summarizes the verification results of all verification points and generates the test results.

[0133] In this way, by linking the three steps of configuration modification, request sending, and data verification into an automated process, the entire test execution process is automated. The third agent can automatically complete all operations based on the test cases generated by the first agent and the access address of the test environment built by the second agent, without human intervention. This reduces the manual cost of test execution and improves the efficiency and accuracy of joint debugging tests.

[0134] To make it easier to understand, the following explanation uses the whitelist ad exposure scenario of an ad push system as an example to illustrate step S104.

[0135] According to some embodiments of this disclosure, optionally, the target software system may include an advertising push system. Accordingly, S104: executing the test cases generated by the first agent through the test environment built by the second agent by the third agent may include steps five to eight.

[0136] Step 5: Access the test environment based on the access address of the test environment built by the second intelligent agent. The test environment includes the retrieval entry module, the advertising library module, the mixer module, the sorter module, and the front-end module.

[0137] Step 6: Based on the environment configuration information in the test cases generated by the first intelligent agent, modify the whitelist exposure logic configuration of the mixer module and / or sorter module to enable the newly added whitelist priority exposure function.

[0138] Specifically, the third agent parses the environment configuration information in the test cases generated by the first agent. In the whitelist exposure scenario, the environment configuration information may include configuration switches for the whitelist exposure logic in the mixer module and / or sorter module. Based on this configuration information, the third agent calls the configuration interface of the mixer module and / or sorter module through the access address of the test environment to modify its whitelist exposure logic configuration.

[0139] For example, if the environment configuration information in the test case is "Mixer module: whitelist exposure switch (enable_whitelist_exposure) = On (true)", then the third agent will set the whitelist exposure switch of the mixer module to the on state to enable the newly added whitelist priority exposure function. If the test case also contains the configuration information of the sorter module, then the sorter module will be configured accordingly.

[0140] In some embodiments, the environment configuration information may further include the effective range of the configuration switch, and the third agent may configure the effective range to a specified value accordingly. After the configuration is modified, the third agent may read the current value of the configuration item for confirmation to ensure that the configuration modification is successful.

[0141] Step 7: Based on the request configuration information in the test cases generated by the first intelligent agent, construct an advertising request carrying a whitelist identifier and user profile tags, and send it to the retrieval entry module in the test environment to trigger multiple business modules to call sequentially according to the preset module call topology.

[0142] The third agent parses the request configuration information in the test cases generated by the first agent. In whitelist exposure scenarios, the request configuration information may include the request type (such as an ad request), request fields (such as whitelist identifier fields, user profile tag fields, etc.) and their values.

[0143] Then, the third agent sends the constructed advertisement request to the retrieval entry module in the test environment via the access address of the test environment. After receiving the request, the retrieval entry module calls each module sequentially according to the preset module call topology for processing. The third agent can wait for a period of time after sending the request to ensure that each module has completed processing, and record the time the request was sent, the complete content of the request, and the link information of each module call.

[0144] Step 8: Based on the verification point information in the test cases generated by the first intelligent agent, verify at least one of the following in the mixer module: whitelist identifier field pass-through, whitelist video style synthesis, and / or, whitelist video queue splitting, whitelist video internal sorting, whitelist video deduplication, and whitelist video quantity boundary value of the sorter module, and obtain the test results.

[0145] The third agent parses the verification point information in the test cases generated by the first agent. In the whitelist exposure scenario, the verification point information may include the verification rules of the mixer module and / or the verification rules of the sorter module.

[0146] For the mixer module, the validation rules can be used to validate at least one of the following: whether the whitelist identifier field is correctly extracted from the request and passed through to the downstream module; whether the style of the whitelist video is correctly synthesized.

[0147] For the sorter module, the verification rules can be used to verify at least one of the following: whether the whitelisted video queue is split into individual videos for processing as expected; whether the sorting result of the whitelisted videos conforms to the expected order; whether duplicate whitelisted videos are correctly deduplicated; and whether the final output number of whitelisted videos does not exceed a preset boundary value. The third agent verifies all verification points sequentially, recording the verification result of each point and the specific reason for any failure. Then, the third agent summarizes the verification results of all verification points to generate the test results.

[0148] In this way, the third agent can automatically access the test environment containing multiple business modules based on the access address of the test environment built by the second agent, and automatically modify the whitelist exposure logic configuration of the mixer module and / or sorter module according to the environment configuration information in the test cases generated by the first agent, so as to enable the newly added whitelist priority exposure function. Compared with manually logging into the configuration platform of each module and manually modifying the configuration, the third agent can accurately complete all configuration modifications, reducing configuration omissions or errors that may be caused by manual operation, and facilitating the correct activation of the whitelist priority exposure function.

[0149] On the other hand, the third intelligent agent can automatically construct advertising requests carrying whitelist identifiers and user profile tags based on the request configuration information in the test cases generated by the first intelligent agent, and send them to the retrieval entry module, triggering multiple business modules to call sequentially according to the preset module call topology. Compared to manually constructing and sending requests using request construction tools, the third intelligent agent can complete request sending more quickly and accurately, and can automatically trigger the processing of each module according to the correct call order, reducing manual intervention.

[0150] On the other hand, the third intelligent agent can automatically verify at least one of the following based on the verification point information in the test cases generated by the first intelligent agent: the whitelist identifier field pass-through of the mixer module, the whitelist video style synthesis, and the whitelist video queue splitting, internal sorting, deduplication, and quantity boundary values ​​of the sorter module, thus obtaining structured test results. Compared to manually logging into various log platforms to view and compare logs, the third intelligent agent can complete the verification more comprehensively, reducing omissions or judgment biases that may occur during manual verification. In particular, for multi-dimensional verification points in whitelist exposure scenarios, such as field pass-through, style synthesis, queue splitting, sorting, deduplication, and boundary values, the third intelligent agent can automatically verify each item, solving the problem of incomplete verification in traditional manual testing.

[0151] According to some embodiments of this disclosure, optionally, the test results may include at least one of the following: the execution status of the test cases, the full-link execution log, the verification results of each business module, the request and response data, the executor information, and the execution time information.

[0152] The execution status of a test case can be used to indicate the overall result of the test case's execution, such as success or failure. The execution status of a test case can be distinguished by different colors or icons, such as green for success and red for failure.

[0153] The end-to-end execution log can be used to display the complete log chain from request to completion of processing by each module. For example, the execution logs of the retrieval entry module, ad library module, mixer module, sorter module, and front-end module can be displayed in chronological order. Users can expand or collapse the logs of each module to view detailed logs.

[0154] The verification results of each business module can be used to display the verification status of each business module separately.

[0155] Request-response data can be used to display the content of the sent request and the content of the received response. For example, it can display the request URL, request headers, request body, and the final returned response data such as the list of advertisements, advertisement styles, and number of advertisements.

[0156] The executor information can be used to identify the initiator of this test execution, such as a user name or user ID. The execution time information can be used to record the start time, end time, and total duration of this test execution.

[0157] In some embodiments, the test results interface may also provide an export function, allowing users to export test results as structured files such as JSON, CSV, or HTML for offline analysis or archiving. The test results interface may also provide a re-execution button, allowing users to re-execute the same test cases with a single click, facilitating problem reproduction or verification of fixes.

[0158] Thus, by recording the execution status of test cases, the overall results of the test can be displayed intuitively, allowing users to quickly understand whether the test passed or failed. Compared to the traditional manual testing method that requires manually summarizing the verification results of each stage, this embodiment provides a unified entry point for test results, improving the efficiency of viewing test results. On the other hand, by recording the full-link execution log and the verification results of each business module, the execution status of each business module and the verification results of each verification point can be displayed in detail. When a test fails, users can quickly locate the specific module and specific verification item that failed, facilitating rapid analysis and problem localization. Compared to the traditional manual testing method that requires logging into multiple log platforms to view logs one by one, this embodiment displays the full-link log centrally, reducing the time and difficulty of problem localization. Furthermore, by recording request and response data, executor information, and execution time information, a complete test execution context can be provided. Request and response data records the input and output of this test, facilitating the reproduction of test scenarios. Executor information facilitates tracing the responsibility for test operations, especially in multi-person collaborative testing environments. Execution time information facilitates the evaluation of test execution efficiency and performance comparison between different test versions.

[0159] According to some embodiments of this disclosure, the joint debugging test method may optionally include steps nine and ten.

[0160] Step 9: Display the test cases output by the first agent, the module call topology output by the second agent, and the test environment.

[0161] After the first agent generates test cases, it can display the test cases in the user interface. After the second agent determines the module call topology and sets up or matches the test environment, it can also display the module call topology and test environment in the user interface.

[0162] Step 10: Receive manual confirmation from users regarding test cases, module call topology, and / or test environment; or, receive modification suggestions from users and modify the test cases, module call topology, and / or test environment based on the modification suggestions.

[0163] The user interface provides a confirmation button and an edit option. Users can choose to confirm directly or submit modification suggestions.

[0164] For test cases, users can view each field individually. If a user finds any omissions or errors in a test case, they can modify it through the interface. For example, in a whitelist exposure scenario, if a user finds that the validation rule in a test case that the number of whitelisted videos should not exceed 10 should actually be no more than 5, they can directly change the limit value from 10 to 5 on the interface. Users can also add test cases or delete unnecessary ones. After receiving user modification suggestions, the test cases can be corrected accordingly.

[0165] For the module call topology, users can view the modules included in the topology diagram and their call relationships to confirm its accuracy. If a user finds a missing module or an incorrect call relationship in the topology diagram, they can correct it through the interface. For example, users can add missing modules by dragging and dropping, or adjust the call direction by editing edges. After receiving the user's modification suggestions, the module call topology can be corrected accordingly.

[0166] For the testing environment, users can view the module list and status to confirm its availability. If a user finds that a module instance in the testing environment is malfunctioning or needs to be replaced with a different version of the module instance, they can modify the interface. For example, a user can choose to redeploy a module or switch to another available testing environment. After receiving the user's modification suggestions, the testing environment can be modified accordingly.

[0167] In some embodiments, user modifications can be recorded and fed back to the agent for subsequent model iterations and optimizations. For example, if a user frequently modifies a field of a certain type of test case, this pattern can be identified and the agent's generation strategy can be automatically adjusted to make subsequent generated test cases better meet the user's expectations.

[0168] In this way, by displaying the output of the intelligent agent and receiving user confirmation or modification suggestions, a collaborative workflow is achieved with the intelligent agent at the core and human review. The intelligent agent excels at handling repetitive and rule-based tasks and can quickly generate initial solutions. Humans excel at tasks requiring experience and judgment, such as reviewing test plans or module call topologies, ensuring the quality of the solutions. The combination of the two improves both the efficiency and quality of integration testing.

[0169] According to some embodiments of this disclosure, the joint debugging test method may optionally include the following steps: The test results output by the third agent are fed back to the first and second agents respectively. The first agent optimizes the test cases based on the test results and sends the optimized test cases to the third agent to trigger regression testing; The second agent adjusts the module call topology or rebuilds the test environment based on the abnormal test environment information in the test results.

[0170] Specifically, the third agent generates test results after executing the test cases. These results may include the execution status of the test cases (pass / fail), failed test steps and corresponding error messages, response data from the module under test, and log information from the execution process. The third agent then sends the test results to the first and second agents respectively.

[0171] After receiving the test results from the third agent, the first agent analyzes and optimizes the current test cases based on testing experience in its test knowledge base. For example, for test steps that fail to execute, the first agent analyzes the reasons for the failure and adjusts the test logic or test data accordingly. For example, for problems caused by the order or dependencies of test cases, the first agent rearranges the execution order of the test cases or splits / merges test steps. After optimization, the first agent sends the updated test cases to the third agent and triggers a new round of regression testing to verify whether the optimized test cases can execute correctly or detect previously missed defects.

[0172] After receiving the test results from the third agent, the second agent can extract anomaly information from the test results, such as discrepancies between the declared call relationships in the module call topology and the actual module deployment, or business modules failing to start or experiencing timeouts. Based on this anomaly information, the second agent automatically determines a correction strategy. If the anomaly originates from an error in the module call topology, the topology structure is adjusted, such as adding or deleting call edges, or correcting module addresses or ports. If the anomaly originates from configuration issues or module deployment problems within the environment itself, the process of rebuilding the test environment is triggered.

[0173] Thus, by simultaneously feeding back test results to both the first and second intelligent agents, an automated closed-loop mechanism of execution-feedback-optimization-re-execution is constructed. This mechanism enables the entire integration testing process to achieve self-iterative optimization, improving the intelligence level of the testing system. Furthermore, the first intelligent agent optimizes test cases based on real test execution results, dynamically supplementing or correcting test logic for uncovered paths, boundary conditions, or abnormal scenarios exposed during execution, improving defect detection rate and reducing the risk of missed tests. The second intelligent agent can parse abnormal information from the test results and automatically adjust the module call topology or rebuild the test environment, thereby reducing the repeated execution of invalid tests due to environment configuration errors.

[0174] Figure 10 This is another schematic flowchart illustrating the integration testing method provided in this embodiment of the disclosure. Figure 10 As shown, according to some embodiments of this disclosure, the joint debugging test method may optionally include the following steps S105 to S108.

[0175] S105: Obtain the test results output by the third agent and / or the joint debugging test communication information in the target chat group.

[0176] For example, the target chat group may include a project communication group or a test discussion group, etc., and this disclosure does not limit it.

[0177] S106: The fourth agent generates a test experience summary based on the test results output by the third agent and / or the communication information of the joint debugging test. The test experience summary includes the problems found during the test execution and their corresponding solutions.

[0178] The fourth agent can parse the test results output by the third agent, including information such as the test case execution status, full-link execution logs, verification results of each business module, and request and response data. It can identify failure verification points, exception logs, timeouts, and other issues that occur during test execution and analyze the possible causes of these issues.

[0179] For communication information related to integration testing within the target chat group, the fourth agent can analyze the chat logs using natural language processing (NLP) technology to extract the issues discussed by testers during testing, the troubleshooting process, and the final solutions determined. For example, testers might discuss the issue of the whitelist identifier field not appearing in the sorter module logs. After investigation, it's discovered that the mixer module is not correctly transmitting this field, and the solution is to modify the field transmission logic of the mixer module. The fourth agent can extract problem descriptions, root cause analysis, and solutions from these conversations.

[0180] The fourth agent integrates and analyzes the above information to generate a structured summary of test experience. This summary may include solutions, such as modifying the field pass-through logic of the mixer module to ensure the whitelist identifier field is correctly passed to the sorter module. In some embodiments, the summary may also include a problem description, root cause analysis, and applicable scenarios corresponding to the solutions.

[0181] S107: Push test experience summaries to users.

[0182] After the fourth agent generates a summary of test experience, it can display the summary on the interface. In some embodiments, the fourth agent can prioritize the multiple generated summaries of test experience, pushing the most impactful or recurring issues to the user first.

[0183] S108: If a user adopts the test experience summary, the test experience summary and its associated test cases are stored in the test knowledge base.

[0184] After receiving the test experience summary, users can review it and decide whether to adopt it. Users can click the "adopt" or "disadvantage" button provided on the interface.

[0185] If a user adopts a summary of testing experience, the fourth agent stores that summary and its associated test cases in the test knowledge base. The summary can be stored in a structured manner.

[0186] Once stored in the test knowledge base, this test experience summary can be used by subsequent first agents. When the change requirements of subsequent projects match the applicable scenarios of the stored test experience summary, the first agent can automatically retrieve the test experience summary and refer to the experience in it when generating test cases.

[0187] If a user does not adopt a test experience summary, that summary will not be stored in the test knowledge base. Unadopted test experience summaries can be retained in temporary storage for later analysis and reference, but will not be used in the generation of test cases for subsequent projects.

[0188] In some embodiments, the fourth agent can also learn from the user's historical adoption behavior and adjust its tendency to generate subsequent test experience summaries. For example, if the user frequently adopts test experience summaries for a certain type of problem, the fourth agent can prioritize generating test experience summaries for that type of problem; if the user frequently does not adopt test experience summaries for a certain type of problem, the fourth agent can reduce the generation priority of test experience summaries for that type.

[0189] Thus, by using the test results output by the third agent and / or the joint testing communication information in the target chat group, the fourth agent can automatically extract the problems found during the test execution process and their corresponding solutions. Compared to traditional solutions where test experience is scattered in chat logs or local documents and difficult to reuse, this embodiment can automatically extract and integrate experience, reducing the loss and forgetting of experience. On the other hand, by pushing the summary of test experience to users for confirmation and storing it in the test knowledge base after user adoption, quality control of experience accumulation is achieved, ensuring that the experience stored in the knowledge base is accurate and reliable, and reducing the pollution of the knowledge base by erroneous experience. At the same time, experience that users do not adopt can be recorded and analyzed for subsequent optimization of the generation strategy of the fourth agent.

[0190] According to some embodiments of this disclosure, optionally, the target software system may include an advertising push system, and the joint debugging test communication information may include discussion records of problems found during test execution and their corresponding solutions. Accordingly, S106: Generating a test experience summary by the fourth agent based on the test results output by the third agent and / or the joint debugging test communication information may include the following steps: By analyzing the test results and discussion records output by the third agent through the fourth agent, at least one of the following can be extracted: business rule experience, field validation experience, problem-solving experience, and reusable test templates, to obtain a summary of test experience.

[0191] Specifically, the fourth agent can obtain test results from the third agent. These results include the execution status of test cases, end-to-end execution logs, verification results of each business module, request-response data, executor information, and execution time information. Simultaneously, the fourth agent can also obtain project communication information from the target chat group. This information may include issues discovered by testers during test execution, the troubleshooting process, discussion records, and the final solutions determined.

[0192] For example, in a whitelist exposure scenario, testers discussed in a group chat the issue of the whitelist identifier field not appearing in the sorter module logs. After investigation, they discovered that the mixer module was not correctly passing the field, and the solution was to modify the field passing logic of the mixer module. The fourth agent can extract problem descriptions, root cause analysis, and solutions from these conversations.

[0193] In some embodiments, the fourth agent can obtain chat history in real time through the chat group's API interface, or periodically pull historical records from the chat history storage system for analysis. The fourth agent can also filter chat history based on keywords such as questions, errors, solutions, or fixes to select discussion content related to the test issue.

[0194] Business rule-based experience can include business logic rules, filtering conditions, sorting rules, and / or deduplication rules for each business module in the ad push system. For example, in a whitelist exposure scenario, business rule-based experience can include rules such as whitelist user priority exposure: when a whitelist user requests an ad, ads in the whitelist ad object list are displayed first; whitelist video quantity boundary rules: the number of whitelist videos output by the sorting module does not exceed 5; and whitelist video deduplication rules: the same whitelist ad appears only once in the same request.

[0195] Field validation experience can include validation rules for field passing between business modules, field mandatoryness, field data type, and / or field value range. For example, in a whitelist exposure scenario, field validation experience can include ensuring that the whitelist identifier field is correctly extracted from the request and passed through to the mixer and sorter modules, that the whitelist identifier field is a string type, that the user profile tag field takes a value from a preset tag set, and that error logs should be logged when the whitelist identifier field is missing.

[0196] Problem-solving experience can include issues discovered during test execution, root cause analysis of the issues, and corresponding solutions. For example, in a whitelist exposure scenario, problem-solving experience could include: Issue: The whitelist identifier field is missing in the sorting module logs; Root cause: The mixer module is not correctly passing the whitelist identifier field; Solution: Modify the field passing logic of the mixer module to ensure that the whitelist identifier field is correctly passed to the sorting module.

[0197] Reusable test templates can include validated test case templates, test scenario templates, and / or test data templates. For example, in a whitelist exposure scenario, reusable test templates could include a whitelist exposure-mixer module pass-through verification test case template, a whitelist exposure-sorter module queue processing verification test case template, and a whitelist exposure-end-to-end full-link verification test case template. These templates can include the test case structure framework, commonly used environment configuration information, commonly used request configuration information, and commonly used verification point information. Subsequent projects only need to fill in the specific parameter values ​​to quickly generate test cases.

[0198] In this way, by extracting experience in business rules, the business logic rules of the advertising push system can be extracted from test results and communication records. These rules can be directly used to generate verification rules for subsequent test cases, making the verification logic of test cases more in line with actual business and reducing test omissions caused by misunderstandings of business.

[0199] On the other hand, by extracting experience in field validation, we can identify field pass-through issues during testing and summarize validation rules for field transmission between modules, such as requiring whitelisted fields to be passed through, field type validation, and field value validation. This experience in field validation can help the first agent automatically generate validation points related to field validation, reducing the recurrence of similar field pass-through issues.

[0200] On the other hand, by extracting problem-solving experience, the problems, root cause analyses, and solutions discovered during testing can be stored in a structured manner. When similar problems arise in subsequent projects, testers can quickly retrieve relevant solutions, shortening the time for problem localization and resolution. Simultaneously, this experience can also be used by the primary intelligent agent to generate targeted test cases for abnormal scenarios, identifying potential problems in advance.

[0201] Based on the same technical concept as the joint debugging and testing method provided in any of the above embodiments, this disclosure also provides a joint debugging and testing device, or joint debugging and testing platform.

[0202] Figure 11 This is a structural block diagram of a joint debugging and testing device provided in an embodiment of this disclosure. Figure 11 As shown, the joint debugging and testing device 130 provided in this embodiment may include: Module 131 is used to acquire change request information of the target software system; The first intelligent agent 132 is used to generate test cases for joint debugging tests of multiple business modules in the target software system based on change requirement information and combined with testing experience in the test knowledge base. The second intelligent agent 133 is used to determine the module call topology required for joint debugging tests based on the test cases generated by the first intelligent agent, and to build or match a test environment containing multiple business modules according to the module call topology. The third agent 134 is used to execute the test cases generated by the first agent in the test environment built by the second agent and obtain the test results.

[0203] The specific implementation process of each of the above modules or agents has been described in detail above, and will not be repeated here.

[0204] The joint debugging and testing device provided by this invention, through the coordinated cooperation of a first intelligent agent, a second intelligent agent, and a third intelligent agent, can automatically generate test cases for joint debugging and testing of multiple business modules in the target software system based on the change requirements information of the target software system, automatically build or match a test environment containing multiple business modules, and automatically execute joint debugging and testing based on the test cases and the test environment. This helps to reduce the operating cost and test deviation of joint debugging and testing, and improve the efficiency and accuracy of joint debugging and testing.

[0205] Specifically, the first intelligent agent automatically parses change requirement information and generates test cases by combining it with testing experience from the test knowledge base. This lowers the experience threshold for testers, solves the problems of omissions in test scenarios and incomplete verification that may occur with manual analysis, and improves the completeness and generation efficiency of test cases. The second intelligent agent automatically determines the module call topology and builds or matches the test environment based on the results generated by the first agent. The third intelligent agent automatically executes test cases in the test environment built by the second agent, shortening the test environment preparation time, enabling rapid deployment of the test environment and rapid execution of integration testing, reducing inconsistencies and configuration errors caused by manual configuration, and further improving the efficiency and accuracy of integration testing.

[0206] In some embodiments, the change requirement information may optionally include a requirement document for upgrading the target software system's business. Specifically, the first intelligent agent 132 may be used to: perform semantic parsing on the requirement document to obtain semantic parsing results; combine the semantic parsing results with testing experience in the test knowledge base to determine multiple business modules requiring joint debugging testing, environment configuration information, request configuration information, and verification rules for the target business modules requiring verification, thereby obtaining test cases.

[0207] In some embodiments, the change requirement information may optionally include change code for the target software system. The first intelligent agent 132 may also be used to: parse the change code to obtain code change information; and, in conjunction with the code change information, correct the verification rules for multiple business modules, environment configuration information, request configuration information, and / or the target business module.

[0208] In some embodiments, optionally, the code change information includes at least one of the following: the business module that has been changed, the environment configuration items involved in the change, the request fields involved in the change, and the business processing rules involved in the change. Combining the code change information, the verification rules of multiple business modules, environment configuration information, request configuration information, and the target business module are corrected, including at least one of the following: correcting multiple business modules and / or the target business module based on the business module that has been changed; correcting the environment configuration information based on the environment configuration items involved in the change; correcting the request configuration information based on the request fields involved in the change; and correcting the verification rules based on the business processing rules.

[0209] In some embodiments, optionally, the target software system includes an advertising push system, and the requirements document includes whitelist exposure strategy change information. The first intelligent agent 132 can specifically be used to: perform semantic analysis on the whitelist exposure strategy change information, extracting the change scenario, whitelist matching conditions, whitelist advertising objects, and whitelist exposure effective scope involved in this change; based on the change scenario, determine the business modules that need to be integrated for testing, including the mixer module and the sorter module; based on the whitelist exposure effective scope and testing experience in the historical test knowledge base, determine the environment configuration information, including the configuration switch for the whitelist exposure logic in the mixer module; based on the whitelist matching conditions and testing experience in the historical test knowledge base, determine the request configuration information, including the whitelist identifier and user profile tag fields that need to be carried in the request; and based on the whitelist matching conditions, whitelist advertising objects, and testing experience in the historical test knowledge base, determine the verification rules for the mixer module and the sorter module.

[0210] In some embodiments, optionally, the verification rules of multiple business modules, environment configuration information, request configuration information, and target business modules are corrected in conjunction with code change information, including at least one of the following: verifying whether the target business module contains a mixer module and a sorter module; correcting the configuration switch name, expected value, or effective range of the whitelist exposure logic in the mixer module according to the environment configuration items involved in the changes in the changed code; correcting the name, data type, or value rules of the request fields in the request configuration information according to the request fields involved in the changes in the changed code, where the request fields include whitelist identifier fields and / or user profile tag fields; and correcting the verification object, verification conditions, or expected results in the verification rules according to the business processing rules involved in the changes in the changed code.

[0211] In some embodiments, optionally, the test case includes the test case name, environment configuration information, request configuration information, and verification point information; wherein, the environment configuration information is used to describe the request type and request fields of the request to be sent, the request configuration information is used to describe the configuration items that need to be modified in the test environment, and the verification point information is used to describe the target business module to be verified and its verification rules.

[0212] In some embodiments, optionally, the second intelligent agent 133 may be used to: parse the test cases generated by the first intelligent agent and extract business scenario features; parse the changed code of the target software system and extract the changed module features; query the module call topology that matches the business scenario features and changed module features from the preset topology library, and use it as the module call topology required for joint debugging test, wherein the module call topology is used to characterize the call relationship between multiple business modules.

[0213] In some embodiments, the target software system may optionally include an advertising push system, the business scenario features include a business scenario identifier, and the changed module features include the business modules that have undergone code changes and module dependencies.

[0214] The second intelligent agent 133 can be specifically used to: query candidate module call topologies corresponding to business scenario identifiers from a preset topology library; verify whether the candidate module call topologies contain business modules that have undergone code changes; verify whether the call relationships in the candidate module call topologies satisfy module dependencies; if the candidate module call topology contains business modules that have undergone code changes and the call relationships satisfy module dependencies, then the candidate module call topology is determined as the module call topology required for joint debugging testing; if it does not satisfy the requirements, then the candidate module call topology is corrected according to the business modules that have undergone code changes and the module dependencies to obtain the module call topology required for joint debugging testing; wherein, the module call topology is used to represent the call relationships between the retrieval entry module, the advertising library module, the mixer module, the sorter module, and the front-end module.

[0215] In some embodiments, optionally, the second intelligent agent 133 may be specifically used to: query the environment platform for a historical test environment that matches the module call topology; if a historical test environment that matches the module call topology exists, then the historical test environment is used as the test environment for this joint debugging test, and the access address of the historical test environment is used as the access address of the test environment; if no historical test environment that matches the module call topology exists, then the test environment for this joint debugging test is built according to the module call topology calling environment platform, and the access address of the test environment is generated.

[0216] In some embodiments, optionally, the third intelligent agent 134 may be used to: access the test environment based on the access address of the test environment built by the second intelligent agent; modify the configuration of multiple business modules in the test environment according to the environment configuration information in the test cases generated by the first intelligent agent; construct and send a request according to the request configuration information in the test cases generated by the first intelligent agent to trigger the sequential invocation of multiple business modules; and verify the execution data of the target business module according to the verification point information in the test cases generated by the first intelligent agent to obtain the test result.

[0217] In some embodiments, the test results may optionally include at least one of the following: the execution status of the test cases, the full-link execution log, the verification results of each business module, the request and response data, the executor information, and the execution time information.

[0218] In some embodiments, the target software system may optionally include an advertising push system. The third intelligent agent 134 can specifically be used to: access the test environment based on the access address of the test environment built by the second intelligent agent; the test environment includes a retrieval entry module, an advertising library module, a mixer module, a sorting module, and a front-end module; modify the whitelist exposure logic configuration of the mixer module and / or the sorting module according to the environment configuration information in the test cases generated by the first intelligent agent, to enable the newly added whitelist priority exposure function; construct an advertising request carrying a whitelist identifier and user profile tag according to the request configuration information in the test cases generated by the first intelligent agent, and send it to the retrieval entry module in the test environment, triggering multiple business modules to call sequentially according to a preset module call topology; and verify at least one of the following in the test cases generated by the first intelligent agent: the whitelist identifier field pass-through of the mixer module, the whitelist video style synthesis, and / or the whitelist video queue splitting, whitelist video internal sorting, whitelist video deduplication, and whitelist video quantity boundary value of the sorting module, to obtain test results.

[0219] In some embodiments, the joint debugging and testing device 130 may optionally include an interaction module for displaying test cases output by the first intelligent agent, module call topology and test environment output by the second intelligent agent; receiving manual confirmation results from the user for the test cases, module call topology and / or test environment, or receiving modification suggestions from the user and modifying the test cases, module call topology and / or test environment based on the modification suggestions.

[0220] In some embodiments, optionally, the third agent can also be used to feed back the test results to the first agent and the second agent respectively. The first agent can also be used to optimize test cases based on the test results and send the optimized test cases to the third agent to trigger regression testing. The second agent can also be used to adjust the module call topology or rebuild the test environment based on the test environment anomaly information in the test results.

[0221] Figure 12 Another structural block diagram of the joint debugging and testing device provided in the embodiments of this disclosure. For example... Figure 12 As shown, in some embodiments, optionally, the joint debugging test device 130 may further include a fourth intelligent agent 135, used to obtain the test results output by the third intelligent agent and / or the joint debugging test communication information in the target chat group, generate a test experience summary based on the test results and / or the joint debugging test communication information, the test experience summary including the problems found during the test execution process and their corresponding solutions; push the test experience summary to the user; if the user adopts the test experience summary, the test experience summary and its associated test cases are stored in the test knowledge base.

[0222] In some embodiments, the target software system may optionally include an advertising push system. The fourth intelligent agent 135 may specifically be used to: obtain the test results and joint debugging test communication information of the advertising push system output by the third intelligent agent, the joint debugging test communication information including discussion records of problems discovered during test execution and their corresponding solutions; analyze the test results and discussion records through the fourth intelligent agent, extracting at least one of business rule-related experience, field validation-related experience, problem-solving-related experience, and reusable test templates to obtain a test experience summary.

[0223] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0224] Figure 13 A schematic block diagram of an example electronic device 1300 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0225] like Figure 13 As shown, the electronic device 1300 includes a computing unit 1301, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 1302 or a computer program loaded from a storage unit 1308 into a random access memory (RAM) 1303. The RAM 1303 may also store various programs and data required for the operation of the device 1300. The computing unit 1301, ROM 1302, and RAM 1303 are interconnected via a bus 1304. An input / output (I / O) interface 1305 is also connected to the bus 1304.

[0226] Multiple components in electronic device 1300 are connected to I / O interface 1305, including: input unit 1306, such as keyboard, mouse, etc.; output unit 1307, such as various types of displays, speakers, etc.; storage unit 1308, such as disk, optical disk, etc.; and communication unit 1309, such as network card, modem, wireless transceiver, etc. Communication unit 1309 allows device 1300 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0227] The computing unit 1301 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1301 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1301 performs the various methods and processes described above, such as the integration testing method. For example, in some embodiments, the integration testing method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1308. In some embodiments, part or all of the computer program may be loaded and / or installed on device 1300 via ROM 1302 and / or communication unit 1309. When the computer program is loaded into RAM 1303 and executed by the computing unit 1301, one or more steps of the integration testing method described above may be performed. Alternatively, in other embodiments, the computing unit 1301 may be configured to perform a joint debugging test method by any other suitable means (e.g., by means of firmware).

[0228] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0229] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0230] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0231] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0232] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0233] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0234] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0235] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A joint debugging and testing method, comprising: Obtain change request information for the target software system; Based on the change requirement information and combined with the testing experience in the test knowledge base, the first intelligent agent generates test cases for joint debugging and testing of multiple business modules in the target software system. The second agent determines the module call topology required for joint debugging tests based on the test cases generated by the first agent, and builds or matches a test environment containing the multiple business modules according to the module call topology. The test cases generated by the first agent are executed by the third agent in the test environment built by the second agent, and the test results are obtained.

2. The method according to claim 1, wherein, The change request information includes the requirement document for upgrading the business functions of the target software system; Based on the changed requirement information and combined with testing experience from the historical test knowledge base, the first intelligent agent generates test cases, including: The first intelligent agent performs semantic parsing on the requirement document to obtain the semantic parsing result; By combining the semantic parsing results and testing experience from the test knowledge base, we determine the multiple business modules that need to be integrated and tested, the environment configuration information, the request configuration information, and the verification rules of the target business modules that need to be verified, and thus obtain test cases.

3. The method according to claim 2, wherein, The change request information also includes the change code for the target software system; Based on the change requirement information and combined with testing experience from the historical test knowledge base, the first intelligent agent generates test cases for joint debugging tests of multiple business modules in the target software system, which also includes: The first intelligent agent parses the modified code to obtain code modification information; Based on the code change information, the verification rules of the multiple business modules, the environment configuration information, the request configuration information, and / or the target business module are corrected.

4. The method according to claim 3, wherein, The code change information includes at least one of the following: the business module that has been changed, the environment configuration items involved in the change, the request fields involved in the change, and the business processing rules involved in the change; Based on the code change information, the verification rules for the multiple business modules, the environment configuration information, the request configuration information, and the target business module are corrected, including at least one of the following: Correct the multiple business modules and / or the target business module according to the business modules that have been changed; Correct the environment configuration information based on the environment configuration items involved in the change; Correct the request configuration information according to the request fields involved in the change; The verification rules are corrected according to the business processing rules.

5. The method according to claim 3 or 4, wherein, The target software system includes an advertising push system, and the requirements document includes information on changes to the whitelist exposure strategy. The first intelligent agent performs semantic parsing on the requirement document to obtain the semantic parsing results, including: The first intelligent agent performs semantic analysis on the whitelist exposure strategy change information to extract the change scenarios, whitelist matching conditions, whitelist advertising objects and whitelist exposure effective scope involved in this change; Based on the semantic parsing results and testing experience from the test knowledge base, we determine the multiple business modules requiring integration testing, environment configuration information, request configuration information, and verification rules for the target business modules that need to be verified, thus obtaining test cases, including: Based on the aforementioned change scenario, the business modules that require joint debugging and testing include the mixer module and the sorter module. Based on the effective scope of the whitelist exposure and the testing experience in the historical test knowledge base, the environment configuration information is determined to include the configuration switch of the whitelist exposure logic in the mixer module; Based on the whitelist matching conditions and testing experience in the historical test knowledge base, it is determined that the request configuration information includes the whitelist identifier and user profile tag fields that need to be carried in the request. Based on the whitelist matching conditions, whitelisted advertising objects, and testing experience in the historical test knowledge base, the verification rules for the mixer module and the sorter module are determined.

6. The method according to claim 5, wherein, Based on the code change information, the verification rules for the multiple business modules, the environment configuration information, the request configuration information, and the target business module are corrected, including at least one of the following: Verify whether the target service module contains the mixer module and the sorter module; Based on the environment configuration items involved in the changes in the change code, correct the configuration switch name, expected value, or effective range of the whitelist exposure logic in the mixer module; Based on the request fields involved in the changes in the change code, correct the names, data types, or value rules of the request fields in the request configuration information. The request fields include whitelist identifier fields and / or user profile tag fields. Based on the business processing rules involved in the changes in the change code, correct the verification objects, verification conditions, or expected results in the verification rules.

7. The method according to claim 1, wherein, The test cases include the test case name, environment configuration information, request configuration information, and verification point information; The environment configuration information describes the request type and request fields of the request to be sent, the request configuration information describes the configuration items that need to be modified in the test environment, and the verification point information describes the target business module to be verified and its verification rules.

8. The method according to claim 1, wherein, Based on the test cases generated by the first agent, the second agent determines the module call topology required for joint debugging tests, including: The second intelligent agent parses the test cases generated by the first intelligent agent and extracts business scenario features. The second intelligent agent parses the modified code of the target software system and extracts the features of the modified modules. From the preset topology library, query the module call topology that matches the business scenario characteristics and the changed module characteristics, and use it as the module call topology required for joint debugging and testing. The module call topology is used to characterize the call relationship between the multiple business modules.

9. The method according to claim 8, wherein, The target software system includes an advertising push system; the business scenario features include a business scenario identifier; and the changed module features include the business modules that have undergone code changes and their module dependencies. From a pre-defined topology library, query module call topologies that match the business scenario characteristics and the changed module characteristics, including: Query the candidate module call topology corresponding to the business scenario identifier from the preset topology library; Verify whether the candidate module call topology includes the business module that has undergone code changes; Verify whether the call relationships in the candidate module call topology satisfy the module dependency relationship; If the candidate module call topology includes the business module that has undergone code changes and the call relationship satisfies the module dependency relationship, then the candidate module call topology is determined as the module call topology required for joint debugging and testing. If the conditions are not met, the candidate module call topology is modified according to the business module whose code has changed and the module dependency relationship to obtain the module call topology required for joint debugging test.

10. The method according to claim 1, wherein, Based on the module call topology, a test environment containing the multiple business modules is built or matched, including: Query the historical test environments that match the module call topology from the environment platform; If a historical test environment exists that matches the module call topology, then the historical test environment will be used as the test environment for this joint debugging test, and the access address of the historical test environment will be used as the access address of the test environment. If no historical test environment matches the module call topology, the test environment for this joint debugging test will be built based on the module call topology call environment platform, and the access address of the test environment will be generated.

11. The method according to claim 1, wherein, The test cases generated by the first agent are executed by the third agent in the test environment built by the second agent, including: Access the test environment based on the access address of the test environment built by the second intelligent agent; Based on the environment configuration information in the test cases generated by the first intelligent agent, modify the configuration of the multiple business modules in the test environment; Based on the request configuration information in the test cases generated by the first intelligent agent, a request is constructed and sent to trigger the sequential invocation of the multiple business modules; Based on the verification point information in the test cases generated by the first intelligent agent, the execution data of the target business module is verified to obtain the test results.

12. The method according to claim 1, wherein, The test results include at least one of the following: the execution status of the test cases, the full-link execution log, the verification results of each business module, the request and response data, the executor information, and the execution time information.

13. The method according to claim 1, wherein, The target software system includes an advertising push system, which executes test cases generated by the first intelligent agent through a test environment built by the second intelligent agent using a third intelligent agent, including: Access the test environment based on the access address of the test environment built by the second intelligent agent. The test environment includes a retrieval entry module, an advertising library module, a mixer module, a sorting module, and a front-end module. Based on the environment configuration information in the test cases generated by the first intelligent agent, modify the whitelist exposure logic configuration of the mixer module and / or the sorter module to enable the newly added whitelist priority exposure function. Based on the request configuration information in the test cases generated by the first intelligent agent, an advertising request carrying a whitelist identifier and user profile tags is constructed and sent to the retrieval entry module in the test environment, triggering the multiple business modules to be called sequentially according to the preset module call topology; Based on the verification point information in the test cases generated by the first intelligent agent, at least one of the following is verified: the whitelist identifier field of the mixer module is passed through, the whitelist video style is synthesized, and / or the whitelist video queue splitting, whitelist video internal sorting, whitelist video deduplication, and whitelist video quantity boundary value of the sorter module, to obtain the test result.

14. The method according to claim 1, wherein, The method further includes: Displays the test cases output by the first intelligent agent, the module call topology output by the second intelligent agent, and the test environment; Receive manual confirmation from users regarding test cases, module call topology, and / or test environment; or receive modification suggestions from users and modify the test cases, module call topology, and / or test environment based on the modification suggestions.

15. The method according to claim 1, wherein, The method further includes: The test results output by the third agent are fed back to the first agent and the second agent, respectively. The first agent optimizes the test cases based on the test results and sends the optimized test cases to the third agent to trigger regression testing. The second intelligent agent adjusts the module call topology or rebuilds the test environment based on the abnormal test environment information in the test results.

16. The method according to claim 1, wherein, The method further includes: Obtain the test results output by the third intelligent agent and / or the joint debugging test communication information in the target chat group; A fourth agent generates a test experience summary based on the test results output by the third agent and / or the joint debugging test communication information. The test experience summary includes the problems found during the test execution process and their corresponding solutions. The test experience summary will be pushed to users; If a user adopts the test experience summary, the test experience summary and its associated test cases are stored in the test knowledge base.

17. The method according to claim 16, wherein, The target software system includes an advertising push system, and the joint debugging test communication information includes discussion records of problems found during the test execution process and their corresponding solutions; A test experience summary is generated by a fourth agent based on the test results output by the third agent and / or the joint debugging test communication information, including: The fourth agent analyzes the test results output by the third agent and the discussion records, and extracts at least one of the following: business rule experience, field validation experience, problem-solving experience, and reusable test templates, to obtain the test experience summary.

18. A joint debugging and testing device, comprising: The acquisition module is used to acquire change request information for the target software system. The first intelligent agent is used to generate test cases for joint debugging tests of multiple business modules in the target software system based on the change requirement information and combined with the testing experience in the test knowledge base. The second intelligent agent is used to determine the module call topology required for joint debugging tests based on the test cases generated by the first intelligent agent, and to build or match a test environment containing the multiple business modules according to the module call topology. The third intelligent agent is used to execute the test cases generated by the first intelligent agent in the test environment built by the second intelligent agent, and obtain the test results.

19. An electronic device comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-17.

20. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-17.

21. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-17.

Images