Multi-module automatic test method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a multi-module automatic testing method and device, electronic equipment and a storage medium, a to-be-tested target function module and a corresponding association module are obtained, and the association module is called in the operation process of the target function module and can influence the operation result of the target function module; according to the execution logic of the target function module and the association module, generating a contract file of the association module, the contract file being used for representing an expected operation result corresponding to the target function module when the association module executes at least one execution action; and when the test of the target function module is executed, obtaining a test result of the target function module by configuring the contract file. By generating the contract file corresponding to the association module and configuring the contract file when the target function module is tested, the test case corresponding to the association module is automatically obtained and executed, so that the efficiency and accuracy of software testing are improved.

Description

Technical Field

[0001] This disclosure relates to the field of software development technology, and in particular to a multi-module automated testing method, apparatus, electronic device, and storage medium. Background Technology

[0002] Currently, software systems are becoming increasingly complex, and the division of labor in developing functional modules is becoming more refined. When it is necessary to perform joint testing on functional modules from different technical fields within the same project, the complexity of the business functions often requires the cooperation of developers and testers from the respective fields to complete the task.

[0003] In existing technologies, for joint testing scenarios of multi-functional modules, it is usually necessary to rely on the testers and developers of each functional module to jointly write test cases, and then run the test cases to achieve automated testing of multiple modules.

[0004] However, in existing solutions, due to the involvement of function calls to multiple functional modules, the writing and modification of test cases are difficult and costly, leading to problems that affect the testing efficiency and accuracy of test results for multi-module testing. Summary of the Invention

[0005] This disclosure provides a multi-module automated testing method, apparatus, electronic device, and storage medium to overcome the problems of low testing efficiency and poor accuracy of test results in multi-module testing.

[0006] In a first aspect, embodiments of this disclosure provide a multi-module automated testing method, including:

[0007] Obtain the target functional module to be tested and its corresponding associated modules, wherein the associated modules are called during the operation of the target functional module and affect the operation result of the target functional module; generate a contract file for the associated modules according to the execution logic of the target functional module and the associated modules, the contract file being used to characterize the expected operation result of the target functional module when the associated modules perform at least one execution action; when the test of the target functional module is performed, the test result of the target functional module is obtained by configuring the contract file.

[0008] Secondly, embodiments of this disclosure provide a multi-module automated testing device, comprising:

[0009] An acquisition unit is used to acquire the target functional module to be tested and its corresponding associated module, wherein the associated module is called during the operation of the target functional module and will affect the operation result of the target functional module;

[0010] The generation unit is used to generate a contract file for the associated module based on the execution logic of the target functional module and the associated module. The contract file is used to characterize the expected running result of the target functional module when the associated module performs at least one execution action.

[0011] The testing unit is used to obtain the test results of the target functional module by configuring the contract file when performing tests on the target functional module.

[0012] Thirdly, embodiments of this disclosure provide an electronic device, including: a processor and a memory;

[0013] The memory stores computer-executed instructions;

[0014] The processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the multi-module automated testing method as described in the first aspect and various possible designs of the first aspect.

[0015] Fourthly, embodiments of this disclosure provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the multi-module automated testing method described in the first aspect and various possible designs of the first aspect.

[0016] Fifthly, embodiments of this disclosure provide a computer program product, including a computer program that, when executed by a processor, implements the multi-module automated testing method described in the first aspect and various possible designs of the first aspect.

[0017] The multi-module automated testing method, apparatus, electronic device, and storage medium provided in this embodiment acquire the target functional module to be tested and its corresponding associated modules. The associated modules are called during the operation of the target functional module and affect its execution result. Based on the execution logic of the target functional module and the associated modules, a contract file for the associated modules is generated. This contract file characterizes the expected execution result of the target functional module when the associated modules perform at least one execution action. During testing of the target functional module, the test result is obtained by configuring the contract file. By generating the contract file corresponding to the associated modules and configuring it during testing of the target functional module, test cases corresponding to the associated modules are automatically acquired and executed. This eliminates the need to consider the calls and implementations of the associated modules during the testing of the target functional module, reducing the difficulty of testing the target functional module. It also decouples the target functional module and associated modules, allowing for flexible modification of the testing strategy for the target functional module without affecting the associated modules, thus improving the efficiency and accuracy of software testing. Attached Figure Description

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

[0019] Figure 1 This is an application scenario diagram of the multi-module automated testing method provided in the embodiments of this disclosure;

[0020] Figure 2 Flowchart of the multi-module automated testing method provided in the embodiments of this disclosure Figure 1 ;

[0021] Figure 3 for Figure 2 A flowchart illustrating the specific implementation of step S102 in the illustrated embodiment;

[0022] Figure 4 A schematic diagram showing the comparison between functional modules and contract documents provided in this embodiment of the disclosure;

[0023] Figure 5 for Figure 3 A flowchart illustrating the specific implementation of step S1024 in the illustrated embodiment;

[0024] Figure 6Flowchart of the multi-module automated testing method provided in the embodiments of this disclosure Figure 2 ;

[0025] Figure 7 for Figure 6 A flowchart illustrating the specific implementation of step S204 in the illustrated embodiment;

[0026] Figure 8 for Figure 7 A flowchart illustrating the specific implementation of step S2042 in the illustrated embodiment;

[0027] Figure 9 This is a schematic diagram illustrating a process for testing a target functional module based on a contract document, as provided in an embodiment of this disclosure.

[0028] Figure 10 This is a structural block diagram of the multi-module automated testing device provided in the embodiments of this disclosure;

[0029] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure;

[0030] Figure 12 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0032] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0033] The application scenarios of the embodiments of this disclosure are explained below:

[0034] Figure 1This diagram illustrates an application scenario of the multi-module automated testing method provided in this disclosure. This method can be applied to automated testing scenarios, and more specifically, to the integration testing of multi-functional modules. The executing entity in this embodiment can be a terminal device or server running a testing environment, or other electronic devices performing similar functions. When the executing entity is a terminal device, it executes the method provided in this embodiment by running the aforementioned application. When the executing entity is a server, the user can access the server through the terminal device and, based on instructions sent by the terminal device, execute the method provided in this embodiment on the server side. The server can then return execution result data, allowing the terminal device to obtain the execution result of the method provided in this embodiment and display it as needed.

[0035] In some embodiments, the terminal device or server can implement the multi-module automated testing method provided in this application by running various computer-executable instructions or computer programs. For example, computer-executable instructions can be program-level commands, machine instructions, or software instructions. Computer programs can be native programs or software modules in an operating system; they can be local applications, i.e., programs that need to be installed in the operating system to run, or mini-programs embedded in any APP, i.e., programs that run in a browser environment. In summary, the aforementioned computer-executable instructions can be any form of instruction, and the aforementioned computer programs can be any form of application, module, or plugin; the specific implementation can be configured as needed. Furthermore, in implementing the multi-module automated testing method provided in this application, the terminal device can execute the method by running computer-executable instructions or computer programs set locally, or by calling computer-executable instructions or computer programs set in an external server. In some embodiments, the server may be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud storage, cloud communication, cloud database, cloud computing, cloud functions, network services, middleware services, domain name services, security services, content delivery network (CDN), and big data and artificial intelligence platforms. Among these, cloud services may be interactive processing services that can be invoked by terminal devices.

[0036] refer to Figure 1As shown, taking a terminal device as an example, after deploying and running the test environment, the terminal device can test the target functional module to be tested within the test environment. Specifically, the target functional module is, for example, a software module used to implement the "create table function" and the "set table visibility function". During the testing of the target functional module through test cases, it is necessary to call other external functional modules, i.e., associated modules, and obtain the execution results returned by the associated modules. For example, a security detection module is used to detect whether there are illegal actions such as "unauthorized read / write" during the execution of the target functional module. When such illegal actions exist in the target functional module, the security detection module (associated module) will intercept and prompt it; when there are no such illegal actions in the target functional module, the corresponding function of the target functional module can be executed normally. That is, the execution result of the associated module will change the running result and test result of the target functional module.

[0037] In existing technologies, based on the principle of modular development, the aforementioned functional modules are usually developed and tested independently by developers or development teams from different technical fields. When it is necessary to perform multi-module joint testing on the target functional module and its related modules, it is usually necessary for module developers from different professional fields to write test cases in a collaborative manner, which leads to additional testing costs, affects testing efficiency and testing accuracy. At the same time, because the target functional module and the related modules called in the test cases are strongly coupled, the test cases cannot be reused, which further increases the overall cost of software testing and reduces the overall testing efficiency.

[0038] This disclosure provides a multi-module automated testing method to solve the above-mentioned problems.

[0039] refer to Figure 2 , Figure 2 Flowchart of the multi-module automated testing method provided in the embodiments of this disclosure Figure 1 The method described in this embodiment can be applied to terminal devices, servers, or other electronic devices. This multi-module automated testing method includes:

[0040] Step S101: Obtain the target functional module to be tested and its corresponding associated modules. The associated modules are called during the operation of the target functional module and will affect the running result of the target functional module.

[0041] For example, refer to Figure 1The illustrated application scenario diagram illustrates how a terminal device (e.g., a personal computer) serves as the execution subject in this embodiment to introduce the provided multi-module automated testing method. Specifically, the terminal device first obtains the associated modules corresponding to the target functional module by parsing the target functional module or by reading the descriptive file corresponding to the target functional module. These are the associated modules that the target functional module will call during operation. Both the target functional module and the associated modules are software modules implemented in the form of program code. For example, the target functional module may be a module for "setting table visibility," while the associated module may be a module for "permission detection." Furthermore, the target functional module has multiple functional interfaces and corresponding interface parameters. By calling different functional interfaces of the target functional module and / or setting different interface parameters, different functions of the target functional module can be achieved, that is, the target functional module can output different information. During the execution of the target functional module, associated modules are called to execute program logic on their side, implementing functions such as "permission detection." This function is essential for the target functional module's functionality and affects its execution result. For example, if the associated module determines insufficient permissions after performing permission detection, it will return a corresponding instruction to the target functional module to prevent it from obtaining a normal execution result, i.e., the "setting table visibility" function cannot be completed. Furthermore, the terminal device can load a test program for the target functional module. This test program contains code instructions for testing the target functional module. By parsing the test program, the target functional module is obtained. Then, based on the target functional module's module name, the module names of one or more associated modules with a mapping relationship are obtained. The mapping relationship between these module names is information pre-stored in the test environment.

[0042] Step S102: Based on the execution logic of the target functional module and the associated module, generate a contract file for the associated module. The contract file is used to characterize the expected running result of the target functional module when the associated module performs at least one execution action.

[0043] Step S103: When performing tests on the target functional module, the test results of the target functional module are obtained by configuring the contract file.

[0044] Further, exemplarily, after determining the target functional module and related modules to be tested, a contract file for the related modules is generated based on their execution logic. The execution logic of the target functional module and related modules, i.e., the logic by which the target functional module calls the related modules, can be obtained from the target functional module's program code or from other static descriptive information. The contract file characterizes the expected operating result of the target functional module when the related module performs at least one execution action. In other words, the contract file can be considered a functional simulation of the related module. After the related module performs any execution action that may affect the target functional module, the target functional module will have a corresponding expected operating result. The influence relationship between the actions of the related module and the expected operating result of the target functional module is stored in a file, i.e., the contract file. Subsequently, when testing the target functional module, after configuring the contract file, the corresponding operating result can be directly obtained from the contract file based on the specific test content (test case content) of the target functional module, without considering the specific execution process and parameter settings on the related module side. Then, the operating results are compared with those in the test cases to obtain the test result of the target functional module.

[0045] In one possible implementation, such as Figure 3 As shown, the specific implementation of step S102 includes:

[0046] Step S1021: Obtain the external execution action of the associated module. The external execution action is the execution action that affects the running result of the functional module that calls the associated module.

[0047] Step S1022: Obtain the internal execution actions of the target functional module. The internal execution actions are those that will be affected by the running results of the associated modules.

[0048] Step S1023: Based on the consistency between external and internal execution actions, determine the target's external execution actions and target's internal execution actions that have a coupling relationship.

[0049] Step S1024: Generate a contract file based on the target's external execution actions and target's internal execution actions that have a coupling relationship.

[0050] For example, the functions implemented by both the associated module and the target functional module are based on specific execution actions. Among these, the execution actions in the target functional module that are affected by the results of the associated module's execution are internal execution actions. For instance, the execution action "check setting permissions" requires calling an external associated module to complete, therefore it is an execution action affected by the associated module's execution result, i.e., an internal execution action. Other execution actions in the target functional module are not affected by external associated modules, such as the initialization action. Therefore, testing this action will not call the associated module, and thus it can be left unprocessed. On the other hand, the execution actions in the associated module that affect the execution results of the functional modules that call the associated module are external execution actions. For example, the external execution action "check setting permissions" will affect the execution results of the functional modules (including the target functional module) that call the associated module; that is, if the permission requirements are not met, the functional module cannot execute subsequent execution actions. Similarly, the associated module also contains execution actions that do not affect the execution results of the functional modules that call the associated module, and these can also be left unprocessed for the time being. In this embodiment, obtaining the external execution actions of the associated module can refer to obtaining all the external execution actions of the associated module.

[0051] Furthermore, after determining the external and internal execution actions, a mapping relationship is established between them based on their consistency. For example, in the embodiment described above, internal execution action A-action-1 is "detect and set permissions," and external execution action B-action-1 is also "detect and set permissions." Therefore, internal execution action A-action-1 and external execution action B-action-1 are consistent, meaning they are coupled target internal and target external execution actions. In this case, they are equivalent actions. Then, by obtaining the test results for the external execution action, the results of the corresponding internal execution action can be simulated. This allows obtaining the execution result of the associated module without actively calling it. Based on the above mapping relationship, combined with the corresponding execution parameters and test results, a contract file can be generated.

[0052] Furthermore, the aforementioned internal and external execution actions can be represented through the module interfaces of the corresponding functional modules. Each execution action can correspond to specific execution parameters. In one possible implementation, the contract file includes action mapping information, parameter mapping information, and execution flow information. The action mapping information represents the mapping between the target's external execution actions and the target's internal execution actions. The parameter mapping information represents the mapping between the execution parameters of the target's external execution actions and the execution parameters of the target's internal execution actions. The execution flow information represents the execution process between the target's external execution actions and the target's internal execution actions when the target functional module is run. Figure 4 A schematic diagram showing the comparison between functional modules and contract documents provided in this disclosure embodiment, such as... Figure 4 As shown, the contract file includes execution flow information (Flowlist). The Flowlist represents the execution flow between external and internal execution actions of each target when running the target functional module, for example:

[0053] A-action-1→B-action-1→A-action-2→B-action-3

[0054] This means that the above four execution steps are executed sequentially. The contract file also includes action mapping information MapAction and parameter mapping information MapParam. The action mapping information is used to represent the mapping between external and internal execution actions of the target. For example, as shown in the figure, A-action-1 is mapped to B-action-1, and A-action-2 is mapped to B-action-3. The parameter mapping information is used to represent the execution parameters corresponding to equivalent actions (internal and external execution actions with a coupling relationship). For example, the execution parameters corresponding to the internal execution action A-action-1 of the target are P1 and P2; the execution parameters corresponding to the internal execution action A-action-2 of the target are P3 and P4; and the execution parameters corresponding to the external execution action B-action-1 of the target are P5 and P6; and the execution parameter corresponding to the internal execution action A-action-3 of the target is P9. Furthermore, optionally, the contract document also includes verification mode information, which is used to characterize the method for verifying the running results of the target functional module. For example, as shown in the figure, the verification mode information includes "Verification Mode 1", "Verification Mode 2", and "Verification Mode 3", three schemes for verifying the running results of the target functional module. The above verification mode information uses verification scheme identifiers (names) to indicate different verification schemes. Then, the specific verification method is determined by querying other configuration information. In other possible implementations, the verification method can also be directly recorded in the verification mode information, thereby more clearly indicating the implementation method for verifying the target functional module. The specific settings can be configured as needed, and will not be elaborated here.

[0055] Furthermore, in one possible implementation, such as Figure 5 As shown, the specific implementation of step S1024 includes:

[0056] Step S1024-1: Generate action mapping information based on the target's external and internal execution actions that have a coupling relationship.

[0057] Step S1024-2: Based on the action mapping information, obtain the action parameters corresponding to the target's external and internal execution actions that have a coupling relationship, and generate parameter mapping information based on the corresponding action parameters.

[0058] Step S1024-3: Generate execution flow information based on the execution order of external and internal execution actions of each target in the action mapping information.

[0059] For example, firstly, in the previous steps, by comparing the consistency of external and internal execution actions, several sets of target external and internal execution actions with coupling relationships were identified. Then, based on these sets of coupled target external and internal execution actions, action mapping information was generated. Specifically, when traversing the aforementioned coupled target external and internal execution actions, the order of each set of coupled target external and internal execution actions was determined based on the execution logic of each target internal execution action in the target functional module, thus obtaining the execution order of each target external and internal execution action, i.e., execution flow information. Simultaneously, based on the execution parameters corresponding to each set of coupled target external and internal execution actions, where the execution action is implemented through the interface of the functional module, the execution parameters are the corresponding interface parameters.

[0060] After obtaining the action mapping information, parameter mapping information, and execution flow information respectively, the contract file can be generated based on the action mapping information, parameter mapping information, and execution flow information.

[0061] Optionally, the steps in this embodiment further include:

[0062] Step S1024-4: Obtain the influence factor parameters corresponding to the internal execution actions of the target, and generate verification mode information based on the influence factor parameters. The influence factor parameters are the execution parameters that affect the running results of the target functional modules.

[0063] For example, in this embodiment, the influencing factor parameter can be further determined from the execution parameters corresponding to the internal actions of the target. The influencing factor parameter is the execution parameter that affects the running result of the target functional module. For example, the influencing factor parameter P0: when P0 = 1, the running result resp of the target functional module is 1; while when P0 = 2, with other execution parameters unchanged, the running result resp of the target functional module is 3. That is, the influencing factor parameter P0 is the execution parameter that affects the running result of the target functional module. More specifically, when the influencing factor parameter changes, the associated modules called by the target functional module may remain unchanged or change, thereby causing a change in the running result of the target functional module.

[0064] Furthermore, different influencing factor parameters will cause changes in the execution results of the target functional module. Therefore, the method for verifying the execution results of the target functional module also needs to be adjusted accordingly. That is, verification mode information is generated based on the influencing factor parameters; the generated verification mode information will also be different when the influencing factor parameters are different. The influencing factor parameters corresponding to the internal execution actions of the target can be pre-marked execution parameters or determined based on pre-generated configuration information; no restrictions are imposed here.

[0065] Furthermore, by configuring the contract file and executing the test cases of the associated module, the test results of the target functional module are obtained. Specifically, after generating the contract information of the associated module, when executing the test of the target functional module, by configuring the contract file, the test cases corresponding to the associated module can be executed based on the contract file during the execution of the test program of the target functional module, and the corresponding execution results can be obtained. This realizes the interaction between the target functional module and the associated module, achieving the purpose of decoupling the target functional module and the associated module. This allows the target functional module and the associated module to be maintained separately without affecting each other, thereby improving the overall testing efficiency of the software.

[0066] This invention discloses a multi-module automated testing method, apparatus, electronic device, and storage medium. It acquires the target functional module to be tested and its corresponding associated modules, where the associated modules are called during the execution of the target functional module and affect its execution result. Based on the execution logic of the target functional module and associated modules, a contract file for the associated modules is generated. This contract file characterizes the expected execution result of the target functional module when the associated modules perform at least one action. During testing of the target functional module, the test results are obtained by configuring the contract file. By generating the contract file corresponding to the associated modules and configuring it during testing of the target functional module, the invention automatically acquires and executes test cases for the associated modules. This eliminates the need to consider the calls and implementations of the associated modules during the testing of the target functional module, reducing the difficulty of testing the target functional module. Furthermore, it decouples the target functional module from the associated modules, allowing for flexible modification of the testing strategy for the target functional module without affecting the associated modules, thus improving the efficiency and accuracy of software testing.

[0067] refer to Figure 6 , Figure 6 Flowchart of the multi-module automated testing method provided in the embodiments of this disclosure Figure 2 This embodiment is in Figure 2 Based on the illustrated embodiment, step S103 is further refined. This multi-module automated testing method includes:

[0068] Step S201: Obtain the target functional module to be tested and its corresponding associated modules. The associated modules are called during the operation of the target functional module and will affect the running result of the target functional module.

[0069] Step S202: Based on the execution logic of the target functional module and the associated module, generate a contract file for the associated module. The contract file is used to characterize the expected running result of the target functional module when the associated module performs at least one execution action.

[0070] Step S203: Based on the contract file, obtain the target's internal execution actions and corresponding execution parameters.

[0071] Step S204: Based on the internal execution actions and corresponding execution parameters of the target, obtain the external execution actions of the target that are coupled with the internal execution actions of the target, as well as the corresponding execution parameters.

[0072] For example, refer to Figure 2 In the illustrated embodiment, after generating the contract file for the associated module, corresponding test cases are constructed based on the contract file to simulate the associated module. Specifically, firstly, the terminal device, for the target functional module to be tested, obtains the relevant internal execution actions based on the specific content of the test program and constructs corresponding execution parameters, such as influencing factor execution parameters. Then, based on the contract file, the internal execution actions and corresponding execution parameters are mapped to corresponding external execution actions and corresponding execution parameters. Specifically, this process can be achieved through the action mapping information and parameter mapping information in the contract file, which will not be elaborated further here.

[0073] For example, such as Figure 7 As shown, the specific implementation of step S204 includes:

[0074] Step S2041: Detect the influencing factor parameters corresponding to the internal execution actions of the target. The influencing factor parameters are the execution parameters that affect the running results of the target's functional modules.

[0075] Step S2042: Based on the contract file, obtain the target's external execution actions corresponding to the target's internal execution actions, and the target's external execution action's influence factor execution parameters corresponding to the influence factor parameters.

[0076] For example, for an internal execution action of a target, execution parameters that can affect the running result of the target functional module are selected from all its execution parameters; these are called influence factor parameters. Then, using the contract file, the execution parameters corresponding to the external execution action of the target, i.e., influence factor execution parameters, can be obtained. Since influence factor parameters are finite parameters that can affect the operation of the target functional module, determining the corresponding influence factor execution parameters based on these parameters and constructing the associated module implementation based on them in subsequent steps can improve testing effectiveness.

[0077] For example, such as Figure 8 As shown, the specific implementation of step S2042 includes:

[0078] Step S2042-1: Obtain parameter mapping information from the contract file. The parameter mapping information represents the mapping between the execution parameters of the external execution actions of the target and the execution parameters of the internal execution actions of the target.

[0079] Step S2042-2: Based on the parameter mapping information and the influence factor parameters, obtain the influence factor execution parameters corresponding to the target external execution actions.

[0080] For example, by reading the parameter mapping information in the contract file and querying the parameter mapping information based on the influence factor parameters, the influence factor execution parameters corresponding to the target external execution actions can be obtained. The specific implementation method of the parameter mapping information has been introduced in the previous embodiments and will not be repeated here.

[0081] Step S205: Based on the contract file, determine the execution order of the internal and external execution actions of each target, and based on the execution order and the corresponding execution parameters, execute the external and internal execution actions of the target in sequence to obtain the running results of the target functional modules.

[0082] For example, after determining the target external execution actions and the corresponding influencing factor execution parameters, the execution order of each target internal execution action and target external execution action is determined based on the execution flow information in the contract file. Then, the pre-generated action test cases corresponding to each target external execution action are obtained, combined and called. These action test cases are pre-built for each target external execution action recorded in the contract file, thereby obtaining the running results of the target functional module.

[0083] Step S206: Based on the target's external execution actions and corresponding execution parameters, as well as the running results of the target's functional modules, construct test cases for the associated modules.

[0084] Furthermore, after obtaining the running results of the target functional module, test cases for the associated module can be generated by combining the target external execution actions and corresponding execution parameters. When using the test cases, firstly, the corresponding associated modules are determined according to the target functional module to be tested, and then the corresponding test cases and test parameters are obtained using the contract file to obtain the corresponding running results. Finally, the test of the target functional module can be implemented based on the running results to obtain the test results.

[0085] Optionally, after step S206, the method further includes:

[0086] Step S207: Determine the correctness of the running results based on the verification mode information, influence factor parameters, and running results in the contract file.

[0087] For example, based on the verification mode information and influence factor parameters in the contract file, a corresponding expected running combination can be obtained. Then, by comparing the expected running result with the running result obtained in the previous steps, the correctness of the running result can be determined.

[0088] Figure 9 This is a schematic diagram illustrating a process for testing a target functional module based on a contract document, as provided in an embodiment of this disclosure. The following is in conjunction with... Figure 9 To provide a more detailed explanation of the above process, we will use the case where the terminal device is the executing entity, such as... Figure 9As shown, module A is the target functional module, and module B is the associated module. The following is the testing process for module A (the target functional module): First, execute the relevant automated configurations for modules A and B, such as loading relevant test cases. Then, set and load the contract file. Next, the terminal device reads the test case list from the contract file corresponding to module B. If all test cases are present, the test ends (details omitted). If not, the device retrieves the target external execution action from the action mapping information (MapAction) in the contract file (shown as reading MapAction in the diagram). Then, it sequentially reads the execution flow information (shown as reading FlowList in the diagram) and parameter mapping information (shown as reading MapParam in the diagram) to obtain the execution parameters corresponding to module A. Next, it checks whether the execution parameters of module A include the influencing factor parameter. If not, it directly executes the next test case (details omitted). If so, it continues to construct the influencing factor execution parameter and sequentially executes the target external execution action B-Action1, the target internal execution action A-Action1, the target external execution action B-Action3, and the target internal execution action A-Action2. After execution, the verification mode information in the contract file is read to determine the method for verifying the running result. The running result is then verified based on the verification method to determine whether the running result meets expectations. If yes, that is, the target functional module has passed the test case, then the execution of the next test case is returned. If no, that is, the target functional module has failed the test case, then the test ends and the test result is output.

[0089] In this embodiment, the implementation of steps S201-S202 is the same as that in this disclosure. Figure 2 The implementation methods of steps S101-S102 in the illustrated embodiment are the same, and will not be described in detail here.

[0090] Corresponding to the multi-module automated testing method in the above embodiments, Figure 10 This is a structural block diagram of the multi-module automated testing device provided in the embodiments of this disclosure. The methods described in the above embodiments can be executed by this multi-module automated testing device, which can be implemented by software and / or hardware, and can be integrated into an electronic device with certain data processing capabilities. The electronic device may include, but is not limited to, mobile terminals with big data processing capabilities, as well as fixed terminals with big data processing capabilities such as desktop computers and supercomputers.

[0091] For ease of explanation, only the parts relevant to embodiments of this disclosure are shown. (Refer to...) Figure 10 The multi-module automated testing device 3 includes:

[0092] The acquisition unit 31 is used to acquire the target functional module to be tested and the corresponding associated module. The associated module is called during the operation of the target functional module and will affect the operation result of the target functional module.

[0093] The generation unit 32 is used to generate a contract file for the associated module based on the execution logic of the target functional module and the associated module. The contract file is used to characterize the expected running result of the target functional module when the associated module performs at least one execution action.

[0094] Test unit 33 is used to obtain the test results of the target functional module by configuring the contract file when performing tests on the target functional module.

[0095] According to one or more embodiments of this disclosure, the generation unit 32 is specifically configured to: obtain external execution actions of the associated module, wherein the external execution actions are execution actions that affect the running result of the functional module that calls the associated module; obtain internal execution actions of the target functional module, wherein the internal execution actions are execution actions that will be affected by the running result of the associated module; determine the target external execution actions and target internal execution actions that have a coupling relationship based on the consistency of the external execution actions and the internal execution actions; and generate a contract file based on the target external execution actions and target internal execution actions that have a coupling relationship.

[0096] According to one or more embodiments of this disclosure, the contract file includes action mapping information, parameter mapping information, and execution flow information. The action mapping information represents the mapping between external and internal execution actions of the target; the parameter mapping information represents the mapping between the execution parameters of the external and internal execution actions of the target; and the execution flow information represents the execution flow between the external and internal execution actions of the target when the target functional module is run. When generating the contract file based on the external and internal execution actions of the target, the generation unit 32 is specifically used to: generate action mapping information based on the coupled external and internal execution actions of the target; obtain the action parameters corresponding to the coupled external and internal execution actions of the target based on the action mapping information, and generate parameter mapping information based on the corresponding action parameters; and generate execution flow information based on the execution order of each external and internal execution action of the target in the action mapping information.

[0097] According to one or more embodiments of this disclosure, the contract document further includes: verification mode information, which is used to characterize the method for verifying the running result of the target functional module; the generation unit 32 is further used to: obtain the influence factor parameters corresponding to the internal execution action, which are execution parameters that affect the running result of the target functional module; and generate verification mode information based on the influence factor parameters.

[0098] According to one or more embodiments of this disclosure, the test unit 33 is further configured to: obtain the target internal execution actions and corresponding execution parameters based on the contract file; obtain the target external execution actions that are coupled with the target internal execution actions and corresponding execution parameters based on the target internal execution actions and corresponding execution parameters; determine the execution order of each target internal execution action and target external execution action based on the contract file, and execute the target external execution actions and target internal execution actions sequentially based on the execution order and corresponding execution parameters to obtain the running result of the target functional module; and construct test cases for the associated module based on the target external execution actions and corresponding execution parameters, as well as the running result of the target functional module.

[0099] According to one or more embodiments of this disclosure, when the test unit 33 obtains the target external execution action that is coupled with the target internal execution action and the corresponding execution parameters based on the target internal execution action and the corresponding execution parameters, it is specifically used to: detect the influence factor parameters corresponding to the target internal execution action, wherein the influence factor parameters are execution parameters that affect the running results of the target functional module; and obtain the target external execution action corresponding to the target internal execution action and the influence factor execution parameters of the target external execution action corresponding to the influence factor parameters based on the contract file.

[0100] According to one or more embodiments of this disclosure, the test unit 33 is further configured to: determine the correctness of the running result based on the verification mode information, influence factor parameters and running results in the contract file.

[0101] According to one or more embodiments of this disclosure, when the test unit 33 obtains the impact factor execution parameters of the target external execution action corresponding to the impact factor parameters, it is specifically used to: obtain parameter mapping information in the contract file, wherein the parameter mapping information represents the mapping between the execution parameters of the target external execution action and the execution parameters of the target internal execution action; and obtain the impact factor execution parameters of the target external execution action corresponding to the impact factor parameters based on the parameter mapping information and the impact factor parameters.

[0102] The acquisition unit 31, generation unit 32, and testing unit 33 are connected sequentially. The multi-module automated testing device 3 provided in this embodiment can execute the technical solution of the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0103] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure, such as... Figure 11 As shown, the electronic device 4 includes:

[0104] Processor 41, and memory 42 communicatively connected to processor 41;

[0105] Memory 42 stores instructions executed by the computer;

[0106] The processor 41 executes computer execution instructions stored in the memory 42 to achieve, for example, Figures 2-9 The multi-module automated testing method in the illustrated embodiment.

[0107] Optionally, the processor 41 and the memory 42 are connected via a bus 43.

[0108] For relevant instructions, please refer to the corresponding text. Figures 2-9 The relevant descriptions and effects of the steps in the corresponding embodiments are understood, and will not be elaborated on here.

[0109] This disclosure provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement this disclosure. Figures 2-9 The multi-module automated testing method provided in any of the corresponding embodiments.

[0110] This disclosure provides a computer program product, including a computer program, which, when executed by a processor, implements this disclosure. Figures 2-9 The multi-module automated testing method provided in any of the corresponding embodiments.

[0111] To implement the above embodiments, this disclosure also provides an electronic device.

[0112] refer to Figure 12 The diagram illustrates a structural schematic of an electronic device 900 suitable for implementing embodiments of the present disclosure. The electronic device 900 can be a terminal device or a server. The terminal device can include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablet computers, portable media players (PMPs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 12 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0113] like Figure 12As shown, the electronic device 900 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage device 908 into a random access memory (RAM) 903. The RAM 903 also stores various programs and data required for the operation of the electronic device 900. The processing unit 901, ROM 902, and RAM 903 are interconnected via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0114] Typically, the following devices can be connected to I / O interface 905: input devices 906 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 907 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 908 including, for example, magnetic tapes, hard disks, etc.; and communication devices 909. Communication device 909 allows electronic device 900 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 12 An electronic device 900 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

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

[0116] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0117] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

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

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

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

[0121] The units or modules described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units or modules do not necessarily limit the specific unit itself.

[0122] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0123] 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.

[0124] In a first aspect, according to one or more embodiments of this disclosure, a multi-module automated testing method is provided, comprising:

[0125] Obtain the target functional module to be tested and its corresponding associated modules, wherein the associated modules are called during the operation of the target functional module and affect the operation result of the target functional module; generate a contract file for the associated modules according to the execution logic of the target functional module and the associated modules, the contract file being used to characterize the expected operation result of the target functional module when the associated modules perform at least one execution action; when the test of the target functional module is performed, the test result of the target functional module is obtained by configuring the contract file.

[0126] According to one or more embodiments of this disclosure, generating a contract file for the associated module based on the execution logic of the target functional module and the associated module includes: obtaining external execution actions of the associated module, wherein the external execution actions are execution actions that affect the running result of the functional module that calls the associated module; obtaining internal execution actions of the target functional module, wherein the internal execution actions are execution actions that will be affected by the running result of the associated module; determining target external execution actions and target internal execution actions with a coupling relationship based on the consistency of the external execution actions and the internal execution actions; and generating the contract file based on the target external execution actions and target internal execution actions with a coupling relationship.

[0127] According to one or more embodiments of this disclosure, the contract file includes action mapping information, parameter mapping information, and execution flow information, wherein the action mapping information represents the mapping between the target external execution action and the target internal execution action; the parameter mapping information represents the mapping between the execution parameters of the target external execution action and the execution parameters of the target internal execution action; the execution flow information represents the execution flow between the target external execution action and the target internal execution action when the target functional module is run; generating the contract file based on the target external execution action and the target internal execution action includes: generating the action mapping information based on the target external execution action and the target internal execution action with a coupling relationship; obtaining the action parameters corresponding to the target external execution action and the target internal execution action with a coupling relationship based on the action mapping information, and generating the parameter mapping information based on the corresponding action parameters; and generating the execution flow information based on the execution order of each target external execution action and the target internal execution action in the action mapping information.

[0128] According to one or more embodiments of this disclosure, the contract file further includes: verification mode information, the verification mode information being used to characterize a method for verifying the running result of the target functional module; the method further includes: obtaining an influence factor parameter corresponding to the internal execution action, the influence factor parameter being an execution parameter affecting the running result of the target functional module; and generating the verification mode information based on the influence factor parameter.

[0129] According to one or more embodiments of this disclosure, the method further includes: obtaining the target internal execution actions and corresponding execution parameters based on the contract file; obtaining the target external execution actions coupled with the target internal execution actions and corresponding execution parameters based on the target internal execution actions and corresponding execution parameters; determining the execution order of each target internal execution action and target external execution action based on the contract file, and executing the target external execution actions and target internal execution actions sequentially based on the execution order and corresponding execution parameters to obtain the running result of the target functional module; and constructing test cases for the associated module based on the target external execution actions and corresponding execution parameters, and the running result of the target functional module.

[0130] According to one or more embodiments of this disclosure, obtaining the target external execution action coupled with the target internal execution action and the corresponding execution parameters based on the target internal execution action and the corresponding execution parameters includes: detecting the influence factor parameters corresponding to the target internal execution action, wherein the influence factor parameters are execution parameters that affect the running results of the target functional module; and obtaining the target external execution action corresponding to the target internal execution action and the influence factor execution parameters of the target external execution action corresponding to the influence factor parameters based on the contract file.

[0131] According to one or more embodiments of this disclosure, the method further includes: determining the correctness of the running result based on the verification mode information in the contract file, the influence factor parameter, and the running result.

[0132] According to one or more embodiments of this disclosure, obtaining the impact factor execution parameters of the target external execution action corresponding to the impact factor parameters includes: obtaining parameter mapping information in the contract file, wherein the parameter mapping information represents the mapping between the execution parameters of the target external execution action and the execution parameters of the target internal execution action; and obtaining the impact factor execution parameters of the target external execution action corresponding to the impact factor parameters based on the parameter mapping information and the impact factor parameters.

[0133] Secondly, according to one or more embodiments of this disclosure, a multi-module automated testing apparatus is provided, comprising:

[0134] An acquisition unit is used to acquire the target functional module to be tested and its corresponding associated module, wherein the associated module is called during the operation of the target functional module and will affect the operation result of the target functional module;

[0135] The generation unit is used to generate a contract file for the associated module based on the execution logic of the target functional module and the associated module. The contract file is used to characterize the expected running result of the target functional module when the associated module performs at least one execution action.

[0136] The testing unit is used to obtain the test results of the target functional module by configuring the contract file when performing tests on the target functional module.

[0137] According to one or more embodiments of this disclosure, the generation unit is specifically configured to: obtain the external execution action of the associated module, wherein the external execution action is an execution action that affects the running result of the functional module that calls the associated module; obtain the internal execution action of the target functional module, wherein the internal execution action is an execution action that will be affected by the running result of the associated module; determine the target external execution action and the target internal execution action that have a coupling relationship based on the consistency of the external execution action and the internal execution action; and generate the contract file based on the target external execution action and the target internal execution action that have a coupling relationship.

[0138] According to one or more embodiments of this disclosure, the contract file includes action mapping information, parameter mapping information, and execution flow information, wherein the action mapping information represents the mapping between the target external execution action and the target internal execution action; the parameter mapping information represents the mapping between the execution parameters of the target external execution action and the execution parameters of the target internal execution action; the execution flow information represents the execution flow between the target external execution action and the target internal execution action when the target functional module is run; the generation unit, when generating the contract file based on the target external execution action and the target internal execution action, is specifically configured to: generate the action mapping information based on the target external execution action and the target internal execution action with a coupling relationship; obtain the action parameters corresponding to the target external execution action and the target internal execution action with a coupling relationship based on the action mapping information, and generate the parameter mapping information based on the corresponding action parameters; and generate the execution flow information based on the execution order of each target external execution action and the target internal execution action in the action mapping information.

[0139] According to one or more embodiments of this disclosure, the contract file further includes: verification mode information, the verification mode information being used to characterize a method for verifying the running result of the target functional module; the generation unit is further configured to: obtain an influence factor parameter corresponding to the internal execution action, the influence factor parameter being an execution parameter affecting the running result of the target functional module; and generate the verification mode information based on the influence factor parameter.

[0140] According to one or more embodiments of this disclosure, the testing unit is further configured to: obtain the target internal execution actions and corresponding execution parameters based on the contract file; obtain the target external execution actions that are coupled with the target internal execution actions and corresponding execution parameters based on the target internal execution actions and corresponding execution parameters; determine the execution order of each target internal execution action and target external execution action based on the contract file, and execute the target external execution actions and target internal execution actions sequentially based on the execution order and corresponding execution parameters to obtain the running result of the target functional module; and construct test cases for the associated module based on the target external execution actions and corresponding execution parameters, and the running result of the target functional module.

[0141] According to one or more embodiments of this disclosure, when the testing unit obtains the target external execution action and the corresponding execution parameters that are coupled with the target internal execution action based on the target internal execution action and the corresponding execution parameters, it is specifically used to: detect the influence factor parameters corresponding to the target internal execution action, wherein the influence factor parameters are execution parameters that affect the running results of the target functional module; and obtain the target external execution action corresponding to the target internal execution action and the influence factor execution parameters of the target external execution action corresponding to the influence factor parameters based on the contract file.

[0142] According to one or more embodiments of this disclosure, the testing unit is further configured to: determine the correctness of the running result based on the verification mode information in the contract file, the influence factor parameter, and the running result.

[0143] According to one or more embodiments of this disclosure, when the testing unit obtains the impact factor execution parameters of the target external execution action corresponding to the impact factor parameters, it is specifically used to: obtain parameter mapping information in the contract file, wherein the parameter mapping information represents the mapping between the execution parameters of the target external execution action and the execution parameters of the target internal execution action; and obtain the impact factor execution parameters of the target external execution action corresponding to the impact factor parameters based on the parameter mapping information and the impact factor parameters.

[0144] Thirdly, according to one or more embodiments of the present disclosure, an electronic device is provided, comprising: at least one processor and a memory;

[0145] The memory stores computer-executed instructions;

[0146] The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the multi-module automated testing method as described in the first aspect and various possible designs of the first aspect.

[0147] Fourthly, according to one or more embodiments of the present disclosure, a computer-readable storage medium is provided, wherein computer-executable instructions are stored therein, and when a processor executes the computer-executable instructions, the multi-module automated testing method described in the first aspect and various possible designs of the first aspect is implemented.

[0148] Fifthly, according to one or more embodiments of the present disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the multi-module automated testing method described in the first aspect above and various possible designs of the first aspect.

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

[0150] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0151] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A multi-module automated testing method, characterized in that, include: Obtain the target functional module to be tested and its corresponding associated modules, wherein the associated modules are called during the operation of the target functional module and will affect the operation result of the target functional module; Based on the execution logic of the target functional module and the associated module, a contract file for the associated module is generated. The contract file is used to characterize the expected running result of the target functional module when the associated module performs at least one execution action. When performing tests on the target functional module, the test results of the target functional module are obtained by configuring the contract file.

2. The method according to claim 1, characterized in that, The step of generating the contract file for the associated module based on the execution logic of the target functional module and the associated module includes: Obtain the external execution action of the associated module, wherein the external execution action is the execution action that affects the running result of the functional module that calls the associated module; Obtain the internal execution actions of the target functional module, wherein the internal execution actions are execution actions that will be affected by the running results of the associated modules; Based on the consistency between the external execution action and the internal execution action, determine the target external execution action and the target internal execution action that have a coupling relationship; The contract file is generated based on the target's external execution actions and target's internal execution actions that have a coupling relationship.

3. The method according to claim 2, characterized in that, The contract file includes action mapping information, parameter mapping information, and execution flow information. The action mapping information represents the mapping between the target's external execution actions and the target's internal execution actions. The parameter mapping information represents the mapping between the execution parameters of the target's external execution actions and the execution parameters of the target's internal execution actions. The execution flow information represents the execution process between the target's external execution actions and the target's internal execution actions when the target functional module is run. The step of generating the contract file based on the target's external execution actions and internal execution actions includes: The action mapping information is generated based on the target's external and internal execution actions that have a coupling relationship. Based on the action mapping information, obtain the action parameters corresponding to the external and internal execution actions of the target with coupling relationship, and generate the parameter mapping information based on the corresponding action parameters. The execution flow information is generated based on the execution order of the external and internal execution actions of each target in the action mapping information.

4. The method according to claim 3, characterized in that, The contract document also includes: verification mode information, which is used to characterize the method for verifying the running results of the target functional module; The method further includes: Obtain the influencing factor parameters corresponding to the internal execution action, wherein the influencing factor parameters are execution parameters that affect the running result of the target functional module; The verification mode information is generated based on the influence factor parameters.

5. The method according to claim 2, characterized in that, The method further includes: Based on the contract file, obtain the target's internal execution actions and corresponding execution parameters; Based on the internal execution actions and corresponding execution parameters of the target, the external execution actions of the target that are coupled with the internal execution actions of the target, as well as the corresponding execution parameters, are obtained; Based on the contract document, the execution order of the internal and external execution actions of each target is determined, and based on the execution order and the corresponding execution parameters, the external and internal execution actions of the target are executed sequentially to obtain the running result of the target functional module; Based on the target's external execution actions and corresponding execution parameters, as well as the execution results of the target's functional modules, construct test cases for the associated modules; The step of obtaining the test results of the target functional module by configuring the contract file includes: By configuring the contract file, the test cases of the associated module are executed to obtain the test results of the target functional module.

6. The method according to claim 5, characterized in that, The step of obtaining the target external execution action coupled with the target internal execution action and the corresponding execution parameters, based on the target internal execution action and the corresponding execution parameters, includes: The influencing factor parameters corresponding to the internal execution actions of the target are detected. The influencing factor parameters are the execution parameters that affect the running results of the target's functional modules. Based on the contract document, the target external execution actions corresponding to the target internal execution actions are obtained, as well as the target external execution action impact factor execution parameters corresponding to the impact factor parameters.

7. The method according to claim 6, characterized in that, The method further includes: The correctness of the running results is determined based on the verification mode information in the contract file, the influence factor parameters, and the running results.

8. The method according to claim 6, characterized in that, The step of obtaining the impact factor execution parameters corresponding to the target external execution action of the impact factor parameters includes: Obtain parameter mapping information from the contract file, wherein the parameter mapping information represents the mapping between the execution parameters of the external execution actions of the target and the execution parameters of the internal execution actions of the target; Based on the parameter mapping information and the influence factor parameters, the influence factor execution parameters corresponding to the target external execution actions are obtained.

9. A multi-module automated testing device, characterized in that, include: An acquisition unit is used to acquire the target functional module to be tested and its corresponding associated module, wherein the associated module is called during the operation of the target functional module and will affect the operation result of the target functional module; The generation unit is used to generate a contract file for the associated module based on the execution logic of the target functional module and the associated module. The contract file is used to characterize the expected running result of the target functional module when the associated module performs at least one execution action. The testing unit is used to obtain the test results of the target functional module by configuring the contract file when performing tests on the target functional module.

10. An electronic device, characterized in that, include: Processor and memory; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the multi-module automated testing method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by the processor, implement the multi-module automated testing method as described in any one of claims 1 to 8.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the multi-module automated testing method as described in any one of claims 1 to 8.

Images