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

Abstract

The invention provides a joint debugging test method and device, electronic equipment and a storage medium, and the method comprises the steps: receiving a demand input operation through a demand input interface, obtaining a joint debugging test demand of a business system, receiving a plan creation operation implemented based on the joint debugging test demand through a plan creation interface, and obtaining a joint debugging test result; and obtaining a joint debugging test plan for performing a joint debugging test on each target sub-service system in the service system, and finally receiving an execution operation on the joint debugging test plan through the plan execution interface so as to execute the joint debugging test plan to perform the joint debugging test on each target sub-service system, thereby obtaining a joint debugging test result. Through the mode, the joint debugging test of the service system can be completed online, and a large amount of manual communication and configuration do not need to be performed offline, so that the efficiency and the accuracy of the joint debugging test are improved.

Description

Technical Field

[0001] The present application relates to the field of testing technology, and in particular to a joint debugging test method, device, electronic equipment and storage medium. Background Art

[0002] A complete business process usually involves the collaboration of multiple application systems. For business needs involving multiple application systems, there is no unified entry point for communicating the needs in the traditional joint debugging and testing process. It is usually necessary for all parties to communicate offline and manually configure and debug the interfaces and data transmission between the various application systems. This method requires a lot of manpower and time investment, is inefficient, and has low accuracy.

[0003] Therefore, the current joint debugging and testing method has technical problems of low efficiency and accuracy and needs to be improved. Summary of the invention

[0004] The embodiments of the present application provide a joint debugging and testing method, device, electronic device and storage medium to alleviate the technical problem of low efficiency and accuracy in the current joint debugging and testing methods.

[0005] To solve the above technical problems, the present application provides the following technical solutions:

[0006] The present application provides a joint debugging test method, including:

[0007] Receiving a demand entry operation through a demand entry interface, and obtaining a joint debugging test requirement of a business system according to the demand entry operation, wherein the business system includes multiple sub-business systems;

[0008] Receiving a plan creation operation based on the joint debugging and testing requirements through a plan creation interface, and obtaining a joint debugging and testing plan for performing joint debugging and testing on each target sub-business system in the business system according to the plan creation operation;

[0009] An execution operation of the joint debugging test plan is received through a plan execution interface, and according to the execution operation, the joint debugging test plan is executed to perform a joint debugging test, and a joint debugging test result is obtained.

[0010] At the same time, the embodiment of the present application also provides a joint debugging test device, including:

[0011] A first obtaining module is used to receive a demand entry operation through a demand entry interface, and obtain a joint debugging test requirement of a business system according to the demand entry operation, wherein the business system includes multiple sub-business systems;

[0012] The second obtaining module is used to receive a plan creation operation based on the joint debugging test requirement through a plan creation interface, and obtain a joint debugging test plan for performing joint debugging tests on each target sub-business system in the business system according to the plan creation operation;

[0013] The execution module is used to receive the execution operation of the joint debugging and testing plan through the plan execution interface, execute the joint debugging and testing plan to perform the joint debugging and testing according to the execution operation, and obtain the joint debugging and testing results.

[0014] The present application also provides an electronic device, comprising a memory and a processor; the memory stores an application, and the processor is used to run the application in the memory to execute the steps in any of the above-mentioned joint debugging and testing methods.

[0015] An embodiment of the present application provides a computer-readable storage medium, which stores a plurality of instructions suitable for loading by a processor to execute the steps in the above-mentioned joint debugging and testing method.

[0016] Beneficial effects: The present application provides a joint debugging and testing method, device, electronic device and storage medium, which can first receive a demand entry operation through a demand entry interface to obtain the joint debugging and testing requirements of the business system, and then receive a plan creation operation based on the joint debugging and testing requirements through a plan creation interface to obtain a joint debugging and testing plan for joint debugging and testing each target sub-business system in the business system, and finally receive an execution operation on the joint debugging and testing plan through a plan execution interface to execute the joint debugging and testing plan to perform joint debugging and testing on each target sub-business system to obtain the joint debugging and testing results. Through the above method, each staff member only needs to perform the demand entry operation, plan creation operation, and plan execution operation in each interface in turn, so as to obtain the information entered by other staff members from the joint debugging and testing system as a reference, and enter the information they need to transmit into the system for reference by other staff members, and finally complete the joint debugging and testing of the business system online without the need for a large amount of manual communication and configuration offline, thereby improving the efficiency and accuracy of the joint debugging and testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The technical solution and other beneficial effects of the present application will be made apparent by describing in detail the specific implementation methods of the present application in conjunction with the accompanying drawings.

[0018] Figure 1 It is a schematic diagram of a scenario in which the joint debugging test method provided in an embodiment of the present application is applied.

[0019] Figure 2 It is a flowchart of the joint debugging test method provided in the embodiment of the present application.

[0020] Figure 3It is a schematic diagram of the interactive process of the joint debugging test method provided in an embodiment of the present application.

[0021] Figure 4 This is a first schematic diagram of the demand query interface in the embodiment of the present application.

[0022] Figure 5 This is a second schematic diagram of the demand query interface in the embodiment of the present application.

[0023] Figure 6 This is a schematic diagram of the demand splitting interface in an embodiment of the present application.

[0024] Figure 7 A schematic diagram of a plan creation interface in an embodiment of the present application.

[0025] Figure 8 A schematic diagram of a scene creation interface in an embodiment of the present application.

[0026] Fig. 9 This is a schematic diagram of the test case management interface in an embodiment of the present application.

[0027] Fig.10 This is a schematic diagram of the test case viewing interface in the embodiment of the present application.

[0028] Fig.11 Schematic diagram of the test result feedback interface in the embodiment of the present application.

[0029] Fig.12 This is a schematic diagram of a joint debugging test report in an embodiment of the present application.

[0030] Fig.13 A schematic diagram of the structure of the joint debugging and testing device provided in an embodiment of the present application.

[0031] Fig.14 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0032] The technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0033] The embodiments of the present application provide a joint debugging and testing method, device, electronic device and computer-readable storage medium, wherein the joint debugging and testing device can be integrated in an electronic device, and the electronic device can be a server, a terminal or other device.

[0034] See also Figure 1 , Figure 1 A schematic diagram of a scenario for the application of the joint debugging and testing method provided in the embodiment of the present application, the scenario may include a first user terminal, a second user terminal, a third user terminal and a server, each user terminal may be a mobile phone, a computer, a tablet or other device that can access the joint debugging and testing system through the network, the joint debugging and testing system runs in the server, the business user performs operations in the first user terminal, the product manager performs operations in the second user terminal, the sub-business system R&D / testing personnel perform operations in the third user terminal, and the server responds to these operations and automatically completes the joint debugging and testing of the business system through the joint debugging and testing line system. Specifically:

[0035] The business user logs in to the joint debugging and testing system on the first user terminal and performs a demand entry operation on the demand entry interface of the joint debugging and testing system. The server receives the demand entry operation through the interface, obtains the joint debugging and testing requirements of the business system, and synchronizes it to the second user terminal.

[0036] The R&D / testing personnel of each sub-business system log in to the joint debugging and testing system on the third user terminal, and implement the plan creation operation on the plan creation interface of the joint debugging and testing system based on the joint debugging and testing requirements. The server receives the plan creation operation through this interface and obtains a joint debugging and testing plan for joint debugging and testing each target sub-business system in the business system.

[0037] The R&D / testing personnel of each sub-business system implement the execution operation of the joint debugging and testing plan on the plan execution interface of the joint debugging and testing system. The server receives the execution operation through this interface, executes the plan to perform joint debugging and testing on each target sub-business system, and finally obtains the joint debugging and testing results.

[0038] Before creating a plan, the product manager can first log in to the joint debugging and testing system on the second user terminal, and perform the splitting operation of the joint debugging and testing requirements on the requirement splitting interface of the joint debugging and testing system. The server receives the splitting operation through this interface, obtains the sub-joint debugging and testing requirements of each target sub-business system in the business system, and synchronizes them to the third user terminal. The R&D / testing personnel of each sub-business system then execute the plan creation operation on the third user terminal based on each sub-joint debugging and testing requirement. This method can make the communication of requirements more accurate and detailed.

[0039] Through the above method, each staff member only needs to perform the demand entry operation, demand splitting operation, plan creation operation, and plan execution operation in each interface in turn, so as to obtain the information entered by other staff members from the joint debugging and testing system as a reference, and enter the information they need to transmit into the system for reference by other staff members, and finally complete the joint debugging and testing of the business system online without the need for a large amount of manual communication and configuration offline, thereby improving the efficiency and accuracy of the joint debugging and testing.

[0040] It should be noted that Figure 1 The system scenario diagram shown is only an example. The server and scenario described in the embodiment of the present application are intended to more clearly illustrate the technical solution of the embodiment of the present application, and do not constitute a limitation on the technical solution provided in the embodiment of the present application. It is known to those skilled in the art that with the evolution of the system and the emergence of new business scenarios, the technical solution provided in the embodiment of the present application is also applicable to similar technical problems. The following are detailed descriptions. It should be noted that the description order of the following embodiments is not intended to limit the preferred order of the embodiments.

[0041] See also Figure 2 , Figure 2 For a flow chart of the joint debugging test method provided in the embodiment of the present application, please refer to Figure 3 , Figure 3 A schematic diagram of the interaction process of the joint debugging test method provided in the embodiment of the present application, combined with Figure 2 and Figure 3 , the method specifically comprises:

[0042] S1: receiving a demand entry operation through a demand entry interface, and obtaining a joint debugging test requirement of a business system according to the demand entry operation, wherein the business system includes multiple sub-business systems.

[0043] In the embodiments of the present application, the business system refers to a system developed and maintained by a business company that can provide various services required for each link in the complete business process. The business system is a system with a microservice architecture, which implements a complete logistics architecture through a series of small services. Each service can be deployed in multiple nodes to form multiple sub-business systems. Each sub-business system assumes its own service function and completes its own business independently. Each sub-business system provides one or more interfaces to the outside and accepts calls through the interface. Different services can cooperate with each other and ultimately provide overall logistics services. Taking the logistics scenario as an example, the business system can be a logistics system. The complete business process provided by the logistics system can include multiple links such as ordering, collection, routing / transit, delivery, customer service, settlement, etc. Each link is provided by several sub-business systems. For example, the collection link can include multiple collection systems, and each collection system can provide different collection services to meet the various collection needs of the collection link.

[0044] After launching a new product, the front-end needs to call the sub-business systems in the back-end business system and use the services provided by each sub-business system to complete the new business process of the new product. Taking the logistics scenario as an example, the new business process that needs to be completed in the business system after a new product is launched may include multiple links such as order placement, collection, routing / transit, delivery, and settlement. In the order placement link, the order placement system needs to be called to complete the order placement process of the new product. In the collection link, the collection system needs to be called to complete the collection process of the new product, and so on.

[0045] Before launching a new business, it is necessary to conduct joint debugging tests on the backend business system in a test environment to find out the problems in the business system (such as code logic errors, configuration errors, etc.), and adopt corresponding improvement measures to repair, adjust and optimize the business system until the test is successful. Finally, the optimized business system is used in the production environment to complete the new business process of the new business.

[0046] In the embodiments of the present application, the production environment refers to an environment that formally provides services to the outside world, and the test environment refers to an environment that has the same configuration as the production environment, but does not provide services to the outside world and is only used for testing. Joint debugging testing refers to testing the interaction between sub-business systems in a business system, such as testing whether the interface of each sub-business system can be successfully called by other sub-business systems, testing whether data can be transmitted normally between sub-business systems, etc., to ensure that each sub-business system can collaborate correctly to support the complete business process.

[0047] In the embodiment of the present application, the entire joint debugging and testing process is completed online, specifically with the help of a joint debugging and testing system. The joint debugging and testing system can be a part of the business system or a third-party system connected to the business system. The joint debugging and testing system has the function of calling all sub-business systems of the business system. The joint debugging and testing system can provide various interfaces such as the demand entry interface, the demand splitting interface, the plan creation interface, and the plan execution interface. All staff members participating in the joint debugging and testing can log in to the joint debugging and testing system and perform their own operations in the corresponding interface, obtain the information entered by other staff members from the joint debugging and testing system as a reference, and enter the information they need to transmit into the system for reference by other staff members. All staff members cooperate to implement the entire joint debugging and testing process.

[0048] In this step, the business user first performs the demand entry operation in the demand entry interface of the joint debugging and testing system. The business user can be a staff member of the marketing department or the product planning department. The joint debugging and testing system responds to the demand entry operation and can obtain the joint debugging and testing requirements of the business system. The joint debugging and testing requirements refer to the definition and description of the conditions that need to be met by the entire business system during the joint debugging and testing in order to enable the new product to be launched on schedule and achieve the expected results after launch.

[0049] In one embodiment, S1 specifically includes:

[0050] S11: receiving a demand entry operation through a demand entry interface, where the demand entry operation includes configuring at least one of information about a product to be launched, information about a joint debugging task, information about a product launch date, and information about a joint debugging manager.

[0051] The requirement entry operation specifically refers to configuring some requirement information of the entire business system during the joint debugging test in the requirement entry interface, which may specifically include configuring at least one of the information of the product to be launched, the joint debugging task information, the product launch date information, and the joint debugging manager information. The information of the product to be launched refers to the basic information of the product to be launched, which may specifically include the name, code or number of the product to be launched, which is used to indicate that the purpose of proposing the joint debugging test this time is to enable the product to be launched normally. The joint debugging task information refers to the information describing the joint debugging task. The joint debugging task may include the joint debugging process, the expected results of the joint debugging, etc. The joint debugging process is used to indicate which part of the entire business process this joint debugging test needs to cover. For example, it can be the whole process joint debugging (the whole process from order placement to successful delivery) or the partial process joint debugging (for example, the partial process from order placement to collection); the expected results of the joint debugging are used to indicate which services are expected to be supported after the joint debugging of the business system. These services may include basic services such as order services and collection services, and special services such as value-added services. The relevant information of the basic services can be configured directly, or after the joint debugging process is configured, it is assumed that all sub-business systems under the process need to meet the requirements of supporting basic services. In this case, no configuration is required. The relevant information of special services needs to be configured on this interface. The product launch date information refers to the date on which the product to be launched is launched in the production environment. It is used to indicate that this joint debugging test needs to be completed before the launch date. The joint debugging manager information refers to the basic information of the manager of this joint debugging test, such as employee name, employee number, etc. It is used to specify which employee is responsible for the overall situation of this joint debugging test. The joint debugging manager specifically refers to the business manager. In addition, when the business user has other special needs, they can also be configured in this interface.

[0052] Some of the above-mentioned information is necessary, while others are not. For example, the joint debugging task information is necessary to provide the main reference for the subsequent joint debugging. The information of the products to be launched, the product launch date information, and the information of the joint debugging manager are not necessary to provide supplementary references. When only one type of information needs to be configured, the joint debugging task information must be configured. When two or more types of information need to be configured, the joint debugging task information must also be configured. Other information can be selectively configured according to actual needs. The more types of information configured, the more accurate the requirements transmitted.

[0053] S12: According to the demand input operation, first configuration information is obtained, where the first configuration information includes at least one of information about products to be launched, information about joint debugging tasks, information about product launch dates, and information about joint debugging management personnel.

[0054] The joint debugging test system can obtain first configuration information in response to a demand entry operation. The information type included in the first configuration information corresponds to the configuration operation. When the above-mentioned demand entry operation only includes configuring the joint debugging task information, the first configuration information only includes the joint debugging task information. When the above-mentioned demand entry operation includes configuring the product information to be launched, the joint debugging task information, the product launch date information and the joint debugging management personnel information, the first configuration information also includes the product information to be launched, the joint debugging task information, the product launch date information and the joint debugging management personnel information, and so on.

[0055] S13: Construct joint debugging and testing requirements of the business system according to the first configuration information.

[0056] The joint debugging and testing system synthesizes the first configuration information, can construct and store the joint debugging and testing requirements including the first configuration information. Other personnel participating in the joint debugging and testing (such as joint debugging management personnel) can log in to their own joint debugging and testing systems to view and process the joint debugging and testing requirements.

[0057] Business users can perform multiple requirement entry operations, and the joint debugging and testing system can build multiple joint debugging and testing requirements, such as Figure 4 As shown in the figure, when the product manager makes a query, these joint debugging and testing requirements can be displayed in the form of a list. There is a query button and a take / split button after each joint debugging and testing requirement. When the product manager clicks the query button, the following Figure 5 The interface shown in the figure shows the specific content of the joint debugging test requirement. The "XX new product" in the user requirement name corresponds to the previously configured product information to be launched, the "full process joint debugging" in the user requirement name and all the content in the requirement details correspond to the previously configured joint debugging task information, and the expected launch date corresponds to the previously configured product launch date information. The requirement owner is the business user who proposes the requirement, and the main O product manager corresponds to the previously configured joint debugging management personnel information.

[0058] S2: receiving a plan creation operation based on the joint debugging test requirement through a plan creation interface, and obtaining a joint debugging test plan for performing joint debugging tests on each target sub-business system in the business system according to the plan creation operation.

[0059] The business system includes multiple sub-business systems, and the target sub-business system refers to some or all of the sub-business systems that need to participate in this joint debugging test. In this step, the subsystem manager can implement the plan creation operation in the plan creation interface of the joint debugging test system. The joint debugging test system responds to the plan creation operation and can obtain a joint debugging test plan. The joint debugging test plan is used to describe in detail the steps to be performed when performing joint debugging tests on each target sub-business system, the expected results to be achieved, the time and personnel of the test, and other information in a computer-recognizable language. The created joint debugging test plan can be executed by the computer to complete the joint debugging test of each target sub-business system.

[0060] The joint debugging test requirement is used to describe the conditions that the business system needs to meet when conducting joint debugging tests. When creating a plan, the subsystem manager needs to determine the specific content of the plan based on the content of the joint debugging test requirement. For example, the joint debugging test requirement is used to indicate that this is a normal full-process joint debugging. In this case, each subbusiness system involved in the entire process from order placement to successful delivery is used as the target subbusiness system. The subsystem managers of each target subbusiness system must clarify which part they are responsible for based on the joint debugging test requirement, and describe in the created plan which interface of the target subbusiness system is called to participate in the joint debugging test to cooperate with the joint debugging. If the joint debugging test requirement is used to indicate that this joint debugging needs to support certain special services, the subsystem manager of the target subbusiness system responsible for the special service needs to evaluate whether it is necessary to develop new functions (new interfaces) and, if necessary, first develop the corresponding new functions and then describe in the created plan the plan to use the new functions to participate in the joint debugging test.

[0061] In one embodiment, before S2, the method further includes:

[0062] S2a: Receive the splitting operation of the joint debugging and testing requirements through the requirements splitting interface, and obtain the sub-joint debugging and testing requirements of each target sub-business system according to the splitting operation.

[0063] In order to make the requirements for which each subsystem manager is responsible more clear, in this step, the joint debugging manager can first perform the split operation of the joint debugging test requirements in the requirements splitting interface of the joint debugging test system, and split the joint debugging test requirements of the entire business system into sub-joint debugging test requirements for each target sub-business system. The sub-joint debugging test requirements refer to the limitations and descriptions of the conditions that each sub-business system needs to meet when conducting joint debugging tests in order to enable new products to be launched on schedule and achieve the expected results after being launched. After splitting, each subsystem manager can view these sub-joint debugging test requirements in the joint debugging test system.

[0064] The multiple sub-joint debugging and testing requirements obtained by splitting describe the conditions that each target sub-business system needs to meet when conducting joint debugging and testing. When creating a plan, the subsystem manager needs to determine the specific content of the plan based on the content of the sub-joint debugging and testing requirements. For example, if the sub-joint debugging and testing requirements indicate that a new function needs to be developed, the subsystem manager needs to develop the corresponding new function first, and then describe the plan for using the new function to complete the joint debugging and testing in the created plan. For another example, if the sub-joint debugging and testing requirements indicate that no new function needs to be developed and only interface a needs to be called, the subsystem manager only needs to cooperate with the joint debugging and describe the plan for calling interface a to complete the joint debugging and testing in the created plan.

[0065] When each subsystem manager creates a plan directly based on the joint debugging and testing requirements, since each role may have different understandings of the requirements, errors or omissions are inevitable, affecting the accuracy of plan creation. In this embodiment, through the above-mentioned splitting operation, the joint debugging manager first manages, splits and allocates the joint debugging and testing requirements from the overall level, and then each subsystem manager can directly create their own part of the plan according to the content of the sub-joint debugging and testing requirements, without having to first understand the joint debugging and testing requirements and then create a plan based on their own understanding, thereby improving the controllability and correctness of plan creation.

[0066] In one embodiment, S2a specifically includes:

[0067] S21a: receiving a split operation on the joint debugging test requirement through a requirement splitting interface, the splitting operation including multiple sub-splitting operations, the sub-splitting operation including configuring at least one of subsystem information, subsystem interface information, subsystem joint debugging task information, subsystem joint debugging date information, and subsystem management personnel information.

[0068] After checking the joint debugging and testing requirements, the business manager first analyzes the joint debugging and testing requirements to determine which sub-business systems need to participate in this joint debugging and testing, what functions each sub-business system needs to support, which sub-business system interfaces need to be called to use the functions of the sub-business system, whether these interfaces currently exist or need to be newly developed, who is the manager responsible for the joint debugging and testing of each sub-business system, etc. Then, the joint debugging and testing requirements are split on the requirements splitting interface. The splitting operation includes multiple sub-split operations, and each sub-split operation includes configuring at least one of the above information of one of the sub-business systems.

[0069] Specifically, Figure 4 As shown, the business manager clicks the Take Over / Split button to display the following Figure 6The interface shown, in which at least one of the subsystem information, subsystem interface information, subsystem joint debugging task information, subsystem joint debugging date information and subsystem management personnel information of each sub-business system can be configured and submitted. The above operation of clicking the Take Over / Split button and configuring and submitting the information in the displayed interface is a sub-split operation.

[0070] Subsystem information refers to the basic information of the subbusiness system, which may include the name, code or encoding of the subbusiness system, etc., which is used to indicate that the subbusiness system needs to participate in this joint debugging test. When calling a subbusiness system, it is necessary to specify which interface of the subbusiness system to call. The product manager will evaluate whether it is necessary to develop a new function. If it is found that it is not necessary after the evaluation, it means that the interface corresponding to the function already exists, and the identification of the interface and other related information are pre-configured and stored in the joint debugging test system. The subsystem interface information includes the identification of the interface that needs to be called when calling the subbusiness system; if it is found that it is necessary after the evaluation, it means that the interface corresponding to the function does not currently exist, and the subsystem interface information includes the development requirements for the new interface. Subsystem joint debugging task information refers to the information that describes the part of the tasks that each subbusiness system needs to perform in the joint debugging test task. This part of the task may include the expected results of the joint debugging of the subbusiness system. The expected results of the joint debugging are used to indicate what services the subbusiness system is expected to support after the joint debugging, such as the ordering system needs to support the new product ordering service, and the collection system needs to support the new product collection service. The subsystem joint debugging date information is used to limit the date of the sub-business system participating in the joint debugging test. The subsystem manager information refers to the basic information of the sub-business system manager during this joint debugging test, such as employee name, employee number, etc. It is used to specify which employee is responsible for the situation of the sub-business system during this joint debugging test. The subsystem manager specifically refers to the R&D / testing personnel of the sub-business system. These R&D / testing personnel include employees who manage a sub-business system alone and employees who manage all sub-business systems. There can be one or more personnel during configuration. In addition, when the business manager has other special needs, they can also be configured in this interface.

[0071] Similarly, some of the above-mentioned information is necessary and some is not necessary. For example, subsystem joint debugging task information is used to provide the main reference for the execution of subsequent joint debugging, which is necessary. Subsystem information, subsystem interface information, subsystem joint debugging date information and subsystem management personnel information are used to provide supplementary references, which are not necessary. When only one type of information needs to be configured, the subsystem joint debugging task information must be configured. When two or more types of information need to be configured, the subsystem joint debugging task information must also be configured. Other information is selectively configured according to actual needs. The more types of information configured, the more accurate the requirements transmitted.

[0072] S22a: According to each sub-splitting operation, determine each target sub-business system participating in the joint debugging test, and obtain second configuration information, the second configuration information including at least one of subsystem information, subsystem interface information, subsystem joint debugging task information, subsystem joint debugging date information and subsystem management personnel information of each target sub-business system.

[0073] The joint debugging test system responds to each sub-splitting operation, and according to the configured subsystem information, can determine the corresponding sub-business system as the target sub-business system participating in the joint debugging test, and obtain the second configuration information of the target sub-business system. The type of information contained in the second configuration information corresponds to the configuration operation. When the above-mentioned sub-splitting operation only includes the configuration of the subsystem joint debugging task information, the second configuration information only includes the subsystem joint debugging task information. When the above-mentioned sub-splitting operation includes the configuration of the subsystem information, subsystem interface information, subsystem joint debugging task information, subsystem joint debugging date information and subsystem management personnel information of each target sub-business system, the second configuration information also includes the subsystem information, subsystem interface information, subsystem joint debugging task information, subsystem joint debugging date information and subsystem management personnel information of each target sub-business system, and the same applies to other situations.

[0074] S23a: According to the second configuration information, construct the sub-joint debugging test requirements of each target sub-business system respectively.

[0075] The joint debugging and testing system integrates the second configuration information of each target sub-business system, can construct and store the sub-joint debugging and testing requirements of each target sub-business system. Other personnel participating in this joint debugging and testing (such as subsystem managers) can log in to their own joint debugging and testing systems to view and process each sub-joint debugging and testing requirement.

[0076] like Figure 6As shown, click the Add button to configure the above information of a sub-business system in the pop-up "Add-Split System Requirements" window. Among them, the subsystem information can be configured in the input box after "System Code", the subsystem joint debugging task information can be configured in the input box after "System Requirements", the interface identifier of the subsystem participating in the joint debugging can be configured in the input box after "Module Name", and if "Yes" is selected in the selection box after "Whether to Develop", a new input box can pop up, in which the development requirements of the newly developed interface can be configured, or the new input box can be not popped up, and the configuration can be made directly in the input box after "Remarks". The subsystem management personnel information can be configured in the input box after "Joint Debug Interface Person", and the subsystem joint debugging date information can be configured in the input box after "Joint Debug Date". After the configuration is completed, click "Confirm" to complete a sub-splitting operation, and the joint debugging test system can obtain a sub-joint debugging test requirement. Click the Add button again to configure the above information of another sub-business system to obtain another sub-joint debugging test requirement. Repeat the sub-splitting operation multiple times until the sub-joint debugging test requirements of all target sub-business systems participating in this joint debugging test are obtained.

[0077] In one embodiment, S2 specifically includes:

[0078] S21: receiving a plan creation operation based on the joint debugging test requirement through a plan creation interface, where the plan creation operation includes creating at least one joint debugging test scenario.

[0079] The joint debugging test scenario refers to the test usage scenario built based on the user's actual usage scenario of the product. For example, the actual usage scenario of a new product may include ordering scenarios, coupon usage scenarios, and refund scenarios, so the joint debugging test scenario also includes these scenarios.

[0080] S22: According to the plan creation operation, a joint debugging test plan including various joint debugging test scenarios is created.

[0081] After executing the above plan creation operation, various joint debugging test scenarios can be created, and these joint debugging test scenarios are included in the joint debugging test plan. Generally, the joint debugging test plan will include multiple joint debugging test scenarios to cover all real usage scenarios as much as possible.

[0082] In one embodiment, S21 specifically includes: receiving a scenario creation operation for any joint debugging test scenario through a scenario creation interface; receiving a use case selection operation through a test case management interface associated with the scenario creation interface, the test case management interface provides multiple reference test cases, and the use case selection operation includes selecting at least one test case associated with any joint debugging test scenario from multiple reference test cases, and each test case calls at least one target interface of at least one target sub-business system.

[0083] Each joint debugging test scenario can include at least one test case. A test case is a set of test inputs, execution conditions, and expected results designed to achieve a specific purpose. Its role is to simulate the user's operation in a real scenario to test whether the sub-business system meets a specific requirement in the specific scenario. For example, in the refund scenario, the sub-business system needs to meet the requirements of only refund, refund and return, etc. For each requirement, a corresponding test case needs to be created to simulate the user's operation of only refund or refund and return, so as to test whether the refund system can normally complete the process of only refund or refund and return. Generally, a test case can include information such as the case number, case title, module to which the case belongs, prerequisites, operation steps, test data, and expected results.

[0084] Each test case calls at least one target interface of at least one target sub-business system, that is, each test case is defined when it is written, which target sub-business system and which interface needs to be called in each operation step. When the test case is executed later, if a step needs to call the defined interface, it can be called directly. When there are two or more test cases, the execution order of each test case needs to be specified. In addition, the execution mode of the test case can also be configured, including automatic mode or manual mode, and this information is also used as part of the joint debugging test plan.

[0085] The joint debugging test scenario and the associated test cases can be written and stored in advance, and called directly from the system when they need to be created. If there are some unconventional requirements for this joint debugging test, it is necessary to create a new joint debugging test scenario and write a new test case. Specifically, it is mentioned in the above embodiment that when there are some special requirements for this joint debugging test, some sub-business systems may need to develop new interfaces. In this case, new test cases need to be written in this step. For this situation, the management personnel of the sub-business system will communicate with the business manager offline after querying the corresponding sub-joint debugging test requirements or joint debugging test requirements, develop new interfaces and add them to the joint debugging test system, and then write new test cases that call the new interface for testing in this step. After this writing, the new test case will be stored in the joint debugging test system, and if the same joint debugging test scenario is encountered next time, it can be called directly.

[0086] like Figure 7 As shown in the figure, the plan creation interface specifically includes the scene creation interface. Click the Add button on this interface to execute the scene creation operation, and the following will be displayed: Figure 8 The interface shown in Figure 8 In the "Add-Joint Test Plan" window that pops up, configure the specific content of the joint test scenario in the input box after "Joint Test Scenario", such as "Order new products-Collect new products-Normal display of sorting code and routing code-New products shipped-New products delivered and collected". After configuration, trigger the "Associate Use Case" button to enter the test case management interface associated with the scenario creation interface. Fig. 9 As shown in the figure, the test case management interface can display all the written and stored test cases, that is, reference test cases. The case selection operation is performed on these reference test cases, that is, some or all test cases are selected from them as test cases associated with the joint debugging test scenario. At the same time, the execution order of each test case can be set in this interface. For test cases that need to be added, they can also be added in this interface. Figure 7 In the interface shown, select "Whether to execute automatically". Select "Yes" for automatic mode, and select "No" for manual mode. Finally, click the Save button to use the created joint debugging test scenario and the test cases under the scenario as the content of the new plan.

[0087] S3: receiving an execution operation of the joint debugging test plan through the plan execution interface, executing the joint debugging test plan to perform the joint debugging test according to the execution operation, and obtaining the joint debugging test result.

[0088] In this step, the subsystem manager can implement the execution operation of the joint debugging test plan on the plan execution interface. The joint debugging test system responds to the execution operation, executes the joint debugging test plan to complete the joint debugging test of each target sub-business system. After the joint debugging test is completed, the joint debugging test results can be obtained.

[0089] The joint debugging test plan developed in the previous step can be synchronized to the product manager first. After the product manager confirms that there is no problem, he can initiate a joint debugging implementation notification. After receiving the notification, the sub-business system R&D / testing personnel will execute the joint debugging test plan to avoid errors. During execution, each test case under each joint debugging test scenario is executed.

[0090] In one embodiment, S3 specifically includes:

[0091] S311: receiving a first execution operation for a first type of test case through a plan execution interface, wherein the execution mode of the first type of test case is automatic execution, and the first execution operation includes triggering an execution button for the first type of test case.

[0092] For the first type of test cases whose execution mode is automatic execution, an execution button can be set on the plan execution interface, and the subsystem administrator can trigger the execution button to implement the first execution operation. Figure 7 As shown, the first execution operation is specifically to trigger the "Execute Use Case" button.

[0093] S312: According to the first execution operation, execute the first type of test cases to perform joint debugging tests, and obtain online joint debugging test results of the first type of test cases.

[0094] In response to the first execution operation, the joint debugging test system can automatically execute the first test case to test the sub-business system called by it. After the test is completed, the online joint debugging test result of the first type of test case can be obtained, such as Fig.10 As shown, the online joint debugging test result may include "pass" or "fail".

[0095] In one embodiment, S3 specifically includes:

[0096] S321: receiving a second execution operation for a second type of test case through a plan execution interface, wherein the execution mode of the second type of test case is manual execution, and the second execution operation includes configuring an offline joint debugging test result of the second type of test case.

[0097] For the second type of test cases whose execution mode is manual execution, a feedback button can be set on the plan execution interface. The subsystem administrator can trigger the feedback button to implement the second execution operation, such as Figure 7 As shown in the figure, the feedback button is the "Update offline joint debugging record" button, such as Fig.11 As shown, the second execution operation is specifically to configure and submit the offline joint debugging test results of the second type of test cases in the interface displayed after the button is triggered, which may specifically include the joint debugging status, blocking environment, use case status, etc.

[0098] S322: According to the second execution operation, an offline joint debugging test result is obtained.

[0099] The joint debugging and testing system can obtain offline joint debugging and testing results of the second type of test cases in response to the second execution operation.

[0100] When the joint debugging test plan only includes the first type of test cases, the steps from S411 to S412 above are used to obtain online joint debugging test results; when the joint debugging test plan only includes the second type of test cases, the steps from S421 to S422 above are used to obtain offline joint debugging test results; when the joint debugging test plan includes both the first type of test cases and the second type of test cases, the steps from S411 to S412 above are used to obtain online joint debugging test results, and the steps from S421 to S422 above are used to obtain offline joint debugging test results.

[0101] In one embodiment, after S3, the following steps are further included:

[0102] S4: Generate a joint debugging test report that records the joint debugging test process and joint debugging test results.

[0103] During the joint debugging and testing process, the joint debugging and testing system will record the problems that occur during the joint debugging and analyze the causes of the problems, including but not limited to system configuration problems, system code logic errors, upstream and downstream interface connection parameter transmission problems, etc. After the joint debugging and testing is completed, the joint debugging and testing system will record the results of the joint debugging and testing, and analyze the requirements for online launch based on the specific content of the results.

[0104] S5: Display the joint debugging test report.

[0105] After the joint debugging test is completed, the joint debugging test system can generate a joint debugging test report based on the above records and analysis content, and display it to users with query permissions, such as product managers, to achieve closed-loop management. Fig.12 The figure below shows the visualization of the joint debugging test report. The product manager can synchronize the joint debugging test report to the business user, who can determine whether the business system needs to be optimized, which sub-business system needs to be optimized, and what kind of optimization needs to be performed based on the specific content of the joint debugging test report. Finally, perform correct configuration and verification in the production environment, and after the new product is officially launched, verify the business system again against the problem list in the joint debugging test report.

[0106] It can be seen from the above embodiments that in the joint debugging and testing method provided by the present application, each staff member only needs to perform the demand entry operation, demand splitting operation, plan creation operation, and plan execution operation in each interface in turn, so as to obtain the information entered by other staff members from the joint debugging and testing system as a reference, and enter the information they need to transmit into the system for reference by other staff members, and finally complete the joint debugging and testing of the business system online without the need for a large amount of manual communication and configuration offline, thereby improving the efficiency and accuracy of the joint debugging and testing.

[0107] Based on the method described in the above embodiment, this embodiment will be further described from the perspective of the joint debugging test device. Fig.13 , the joint debugging test device may include:

[0108] A first obtaining module 10 is used to receive a demand entry operation through a demand entry interface, and obtain a joint debugging test requirement of a business system according to the demand entry operation, wherein the business system includes multiple sub-business systems;

[0109] The second obtaining module 20 is used to receive a plan creation operation based on the joint debugging test requirement through a plan creation interface, and obtain a joint debugging test plan for performing joint debugging tests on each target sub-business system in the business system according to the plan creation operation;

[0110] The execution module 30 is used to receive an execution operation on the joint debugging and testing plan through a plan execution interface, execute the joint debugging and testing plan to perform a joint debugging and testing according to the execution operation, and obtain a joint debugging and testing result.

[0111] In one embodiment, the joint debugging and testing device further includes:

[0112] The third obtaining module is used to receive a splitting operation on the joint debugging and testing requirements through a requirement splitting interface, and obtain sub-joint debugging and testing requirements of each target sub-business system according to the splitting operation.

[0113] In one embodiment, the first obtaining module 10 includes:

[0114] A first receiving submodule is used to receive a demand entry operation through a demand entry interface, wherein the demand entry operation includes configuring at least one of information of a product to be launched, information of a joint debugging task, information of a product launch date, and information of a joint debugging manager;

[0115] A first obtaining submodule is used to obtain first configuration information according to the demand input operation, wherein the first configuration information includes at least one of the product information to be launched, the joint debugging task information, the product launch date information, and the joint debugging manager information;

[0116] The first construction submodule is used to construct the joint debugging test requirements of the business system according to the first configuration information.

[0117] In one embodiment, the third obtaining module includes:

[0118] A second receiving submodule is used to receive a split operation of the joint debugging test requirement through a requirement splitting interface, wherein the split operation includes a plurality of sub-splitting operations, and the sub-splitting operation includes configuring at least one of subsystem information, subsystem interface information, subsystem joint debugging task information, subsystem joint debugging date information, and subsystem management personnel information;

[0119] The second obtaining submodule is used to determine each target sub-business system participating in the joint debugging test according to each of the sub-splitting operations, and obtain second configuration information, wherein the second configuration information includes at least one of subsystem information, subsystem interface information, subsystem joint debugging task information, subsystem joint debugging date information, and subsystem management personnel information of each of the target sub-business systems;

[0120] The second construction submodule is used to construct the sub-joint debugging test requirements of each of the target sub-business systems according to the second configuration information.

[0121] In one embodiment, the second obtaining module 20 includes:

[0122] A third receiving submodule is used to receive a plan creation operation based on the joint debugging and testing requirements through a plan creation interface, wherein the plan creation operation includes creating at least one joint debugging and testing scenario;

[0123] A creation submodule is used to create a joint debugging test plan including each of the joint debugging test scenarios according to the plan creation operation.

[0124] In one embodiment, the third receiving submodule includes:

[0125] A first receiving unit, configured to receive a scenario creation operation for any joint debugging test scenario through a scenario creation interface;

[0126] A second receiving unit is used to receive a use case selection operation through a test case management interface associated with the scenario creation interface, wherein the test case management interface provides multiple reference test cases, and the use case selection operation includes selecting at least one test case associated with any joint debugging test scenario from the multiple reference test cases, and each of the test cases calls at least one target interface of at least one of the target sub-business systems.

[0127] In one embodiment, the execution module 30 includes:

[0128] A fourth receiving submodule is used to receive a first execution operation for a first type of test case through a plan execution interface, wherein the execution mode of the first type of test case is automatic execution, and the first execution operation includes triggering an execution button for the first type of test case;

[0129] A third obtaining submodule is used to execute the first type of test case to perform joint debugging test according to the first execution operation, and obtain the online joint debugging test result of the first type of test case;

[0130] and / or include:

[0131] A fifth receiving submodule, configured to receive a second execution operation for a second type of test case through a plan execution interface, wherein the execution mode of the second type of test case is manual execution, and the second execution operation includes configuring an offline joint debugging test result of the second type of test case;

[0132] The fourth obtaining submodule is used to obtain the offline joint debugging test result according to the second execution operation.

[0133] In one embodiment, the joint debugging and testing device further includes:

[0134] A generation module, used to generate a joint debugging test report that records the joint debugging test process and the joint debugging test results;

[0135] The display module is used to display the joint debugging test report.

[0136] Different from the existing technology, the joint debugging and testing device provided by the present application only requires each staff member to perform the demand entry operation, demand splitting operation, plan creation operation, and plan execution operation in each interface in turn, so as to obtain the information entered by other staff members from the joint debugging and testing system as a reference, and enter the information they need to transmit into the system for reference by other staff members, and finally complete the joint debugging and testing of the business system online without the need for a large amount of manual communication and configuration offline, thereby improving the efficiency and accuracy of the joint debugging and testing.

[0137] Accordingly, the present application also provides an electronic device, such as Fig.14 As shown, the electronic device may include a radio frequency (RF) circuit 101, a memory 102 including one or more computer-readable storage media, an input unit 103, a display unit 104, a sensor 105, an audio circuit 106, a WiFi module 107, a processor 108 including one or more processing cores, and a power supply 109. Those skilled in the art will appreciate that Fig.14 The electronic device structure shown in the figure does not constitute a limitation on the electronic device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0138] The radio frequency circuit 101 can be used for receiving and sending signals during information transmission or calls. In particular, after receiving the downlink information of the base station, it is handed over to one or more processors 108 for processing; in addition, the data related to the uplink is sent to the base station. The memory 102 can be used to store plug-in programs and modules. The processor 108 executes various functional applications and joint debugging by running the plug-in programs and modules stored in the memory 102. The input unit 103 can be used to receive input digital or character information, and generate keyboard, mouse, joystick, optical or trackball signal input related to customer settings and function control.

[0139] The display unit 104 may be used to display information input by a client or information provided to a client and various graphical client interfaces of the server. These graphical client interfaces may be composed of graphics, texts, icons, videos and any combination thereof.

[0140] The electronic device may also include at least one sensor 105, such as a light sensor, a motion sensor, and other sensors. The audio circuit 106 includes a speaker, which may provide an audio interface between the user and the electronic device.

[0141] WiFi is a short-range wireless transmission technology. Electronic devices can help customers send and receive emails, browse web pages, and follow streaming media through WiFi modules 107. It provides customers with wireless broadband Internet follow-up. Fig.14 A WiFi module 107 is shown, but it is understandable that it is not an essential component of the electronic device and can be omitted as needed without changing the essence of the application.

[0142] The processor 108 is the control center of the electronic device. It uses various interfaces and lines to connect various parts of the entire mobile phone. It executes various functions of the electronic device and processes data by running or executing plug-ins and / or modules stored in the memory 102, and calling data stored in the memory 102, thereby monitoring the mobile phone as a whole.

[0143] The electronic device also includes a power source 109 (such as a battery) for supplying power to each component. Preferably, the power source can be logically connected to the processor 108 through a power management system, so that the power management system can manage charging, discharging, power consumption and other functions.

[0144] Although not shown, the electronic device may also include a camera, a Bluetooth module, etc., which will not be described in detail here. Specifically in this embodiment, the processor 108 in the server will load the executable files corresponding to the processes of one or more applications into the memory 102 according to the following instructions, and the processor 108 will run the application stored in the memory 102, thereby realizing the following functions:

[0145] Receiving a demand entry operation through a demand entry interface, and obtaining a joint debugging test requirement of a business system according to the demand entry operation, wherein the business system includes multiple sub-business systems;

[0146] Receiving a plan creation operation based on the joint debugging and testing requirements through a plan creation interface, and obtaining a joint debugging and testing plan for performing joint debugging and testing on each target sub-business system in the business system according to the plan creation operation;

[0147] An execution operation of the joint debugging test plan is received through a plan execution interface, and according to the execution operation, the joint debugging test plan is executed to perform a joint debugging test, and a joint debugging test result is obtained.

[0148] In the above embodiments, the description of each embodiment has its own emphasis. For the part that is not described in detail in a certain embodiment, please refer to the detailed description above and will not be repeated here.

[0149] A person of ordinary skill in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be completed by instructions, or by controlling related hardware through instructions. The instructions may be stored in a computer-readable storage medium and loaded and executed by a processor.

[0150] To this end, an embodiment of the present application provides a computer-readable storage medium, in which a plurality of instructions are stored, and the instructions can be loaded by a processor to implement the following functions:

[0151] Receiving a demand entry operation through a demand entry interface, and obtaining a joint debugging test requirement of a business system according to the demand entry operation, wherein the business system includes multiple sub-business systems;

[0152] Receiving a plan creation operation based on the joint debugging and testing requirements through a plan creation interface, and obtaining a joint debugging and testing plan for performing joint debugging and testing on each target sub-business system in the business system according to the plan creation operation;

[0153] An execution operation of the joint debugging test plan is received through a plan execution interface, and according to the execution operation, the joint debugging test plan is executed to perform a joint debugging test, and a joint debugging test result is obtained.

[0154] The above is a detailed introduction to a joint debugging test method, device, electronic device and computer-readable storage medium provided in the embodiments of the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the technical solution and its core idea of ​​the present application. Ordinary technical personnel in this field should understand that they can still modify the technical solutions recorded in the aforementioned embodiments, or replace some of the technical features therein with equivalents; and these modifications or replacements do not make the essence of the corresponding technical solution deviate from the scope of the technical solution of the embodiments of the present application.

Claims

1. A joint debugging test method, characterized in that: include: Receiving a demand entry operation through a demand entry interface, and obtaining a joint debugging test requirement of a business system according to the demand entry operation, wherein the business system includes multiple sub-business systems; Receiving a plan creation operation based on the joint debugging and testing requirements through a plan creation interface, and obtaining a joint debugging and testing plan for performing joint debugging and testing on each target sub-business system in the business system according to the plan creation operation; An execution operation of the joint debugging test plan is received through a plan execution interface, and according to the execution operation, the joint debugging test plan is executed to perform a joint debugging test, and a joint debugging test result is obtained.

2. The joint debugging test method according to claim 1, characterized in that: Before the step of receiving a plan creation operation based on the joint debugging test requirement through the plan creation interface, the method further includes: The splitting operation of the joint debugging and testing requirement is received through the requirement splitting interface, and the sub-joint debugging and testing requirements of each target sub-business system are obtained according to the splitting operation.

3. The joint debugging and testing method according to claim 1 or 2, characterized in that: The step of receiving a requirement entry operation through a requirement entry interface and obtaining a joint debugging test requirement of a business system according to the requirement entry operation includes: Receiving a demand entry operation through a demand entry interface, wherein the demand entry operation includes configuring at least one of information of a product to be launched, information of a joint debugging task, information of a product launch date, and information of a joint debugging manager; According to the demand input operation, first configuration information is obtained, where the first configuration information includes at least one of the product information to be launched, the joint debugging task information, the product launch date information, and the joint debugging manager information; According to the first configuration information, the joint debugging and testing requirements of the business system are constructed.

4. The joint debugging test method according to claim 2, characterized in that: The step of receiving a split operation of the joint debugging and testing requirement through a requirement splitting interface, and obtaining a sub-joint debugging and testing requirement of each target sub-business system according to the splitting operation includes: Receiving a split operation on the joint debugging test requirement through a requirement splitting interface, the split operation including a plurality of sub-splitting operations, the sub-splitting operations including configuring at least one of subsystem information, subsystem interface information, subsystem joint debugging task information, subsystem joint debugging date information, and subsystem management personnel information; According to each of the sub-splitting operations, each target sub-business system participating in the joint debugging test is determined, and second configuration information is obtained, wherein the second configuration information includes at least one of subsystem information, subsystem interface information, subsystem joint debugging task information, subsystem joint debugging date information, and subsystem management personnel information of each of the target sub-business systems; According to the second configuration information, sub-joint debugging test requirements of each of the target sub-business systems are respectively constructed.

5. The joint debugging and testing method according to claim 1 or 2, characterized in that: The steps of receiving a plan creation operation based on the joint debugging test requirement through a plan creation interface, and obtaining a joint debugging test plan for performing joint debugging tests on each target sub-business system in the business system according to the plan creation operation include: Receiving, through a plan creation interface, a plan creation operation implemented based on the joint debugging and testing requirements, the plan creation operation including creating at least one joint debugging and testing scenario; According to the plan creation operation, a joint debugging test plan including each of the joint debugging test scenarios is created.

6. The joint debugging and testing method according to claim 5, characterized in that: Receiving a plan creation operation based on the joint debugging test requirement through a plan creation interface, wherein the plan creation operation includes a step of creating at least one joint debugging test scenario, including: Receive a scenario creation operation for any joint debugging test scenario through the scenario creation interface; A use case selection operation is received through a test case management interface associated with the scenario creation interface, wherein the test case management interface provides multiple reference test cases, and the use case selection operation includes selecting at least one test case associated with any joint debugging test scenario from the multiple reference test cases, and each of the test cases calls at least one target interface of at least one of the target sub-business systems.

7. The joint debugging and testing method according to claim 5, characterized in that: The steps of receiving an execution operation of the joint debugging test plan through a plan execution interface, executing the joint debugging test plan to perform a joint debugging test according to the execution operation, and obtaining a joint debugging test result include: Receiving a first execution operation for a first type of test case through a plan execution interface, wherein the execution mode of the first type of test case is automatic execution, and the first execution operation includes triggering an execution button for the first type of test case; According to the first execution operation, the first type of test case is executed to perform a joint debugging test, and an online joint debugging test result of the first type of test case is obtained; and / or include: Receiving a second execution operation for a second type of test case through a plan execution interface, where the execution mode of the second type of test case is manual execution, and the second execution operation includes configuring an offline joint debugging test result of the second type of test case; According to the second execution operation, the offline joint debugging test result is obtained.

8. The joint debugging and testing method according to claim 1 or 2, characterized in that: After obtaining the joint debugging test results, it also includes: Generate a joint debugging test report that records the joint debugging test process and the joint debugging test results; The joint debugging test report is displayed.

9. A joint debugging and testing device, characterized in that: include: A first obtaining module is used to receive a demand entry operation through a demand entry interface, and obtain a joint debugging test requirement of a business system according to the demand entry operation, wherein the business system includes multiple sub-business systems; The second obtaining module is used to receive a plan creation operation based on the joint debugging test requirement through a plan creation interface, and obtain a joint debugging test plan for performing joint debugging tests on each target sub-business system in the business system according to the plan creation operation; The execution module is used to receive the execution operation of the joint debugging test plan through the plan execution interface, execute the joint debugging test plan to perform the joint debugging test according to the execution operation, and obtain the joint debugging test result.

10. An electronic device, characterized in that: It comprises a memory and a processor; the memory stores an application program, and the processor is used to run the application program in the memory to execute the steps in the joint debugging and testing method described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and the computer program is executed by a processor to implement the steps in the joint debugging and testing method according to any one of claims 1 to 8.

Images