Test method, electronic device and storage medium

Abstract

The present application proposes a test method, an electronic device and a storage medium, and relates to the field of test technology. The test method comprises: loading the tested code into a test container, wherein the tested code includes at least one code to be piled; selecting a target pile code matching the tested code from the alternative pile code according to the first attribute information of the code to be piled and the second attribute information of the preset alternative pile code, and loading the target pile code into the test container to obtain the target test code; executing at least one test case corresponding to the preset test requirement based on the target test code, and obtaining the test result corresponding to the tested code. According to the embodiment of the present application, the pile code and the tested code can be logically decoupled, and the code to be piled in the tested code can be efficiently and conveniently replaced, which reduces the difficulty of testing.

Description

Technical Field

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

[0002] In the related art, when unit testing is performed, usually after determining the part that needs to be piled in the business code (i.e. the tested code), the development of pile logic is completed by relying on the auxiliary tools provided by the test framework, and then the pile logic is replaced to the part that needs to be piled in the business code through the related methods provided by the test framework, so as to perform subsequent tests based on the replaced business code. In this test mode, the pile logic code and the business code are strongly coupled, so the pile logic code is difficult to be reused, and the code maintenance cost is high. Summary of the invention

[0003] The present application provides a testing method, an electronic device and a readable storage medium.

[0004] An embodiment of the present application provides a testing method, which includes: loading a code under test into a test container, wherein the code under test includes at least one code to be stubbed; selecting a target stub code matching the code under test from the candidate stub codes according to first attribute information of the code to be stubbed and second attribute information of a preset candidate stub code, and loading the target stub code into the test container to obtain a target test code; and executing at least one test case corresponding to a preset test requirement based on the target test code to obtain a test result corresponding to the code under test.

[0005] An embodiment of the present application provides an electronic device, including: one or more processors; a memory, on which one or more programs are stored. When the one or more programs are executed by one or more processors, the one or more processors implement any one of the testing methods in the embodiment of the present application.

[0006] An embodiment of the present application provides a readable storage medium, which stores a computer program. When the computer program is executed by a processor, any one of the testing methods in the embodiments of the present application is implemented.

[0007] According to the test method, electronic device and storage medium of the embodiment of the present application, the tested code is loaded into the test container, and a relatively independent test environment is provided for the tested code; Since the tested code includes at least one code to be piled, therefore, according to the first attribute information of the code to be piled and the second attribute information of the preset alternative pile code, the target pile code matching the tested code is selected from the alternative pile code, and the target pile code is loaded into the test container to obtain the target test code; at least one test case corresponding to the preset test requirement is executed based on the target test code, and the test result corresponding to the tested code is obtained. It can be seen from this that in the present application, since the alternative pile code is pre-set, the separate maintenance and reuse of the pile code are realized, and there is no need to write the pile code at each test, which effectively simplifies the code maintenance difficulty and the test workload; and for the code to be piled in the tested code, the target pile code matching the code to be piled can be selected from the alternative pile code and replaced, so that the external dependencies in the target test code are all replaced with executable target pile codes, and there is no need to care about how to bind the logic of the target pile code to the logic of the tested code, which simplifies the test difficulty.

[0008] With regard to the above embodiments and other aspects of the present application and their implementation, further description is provided in the accompanying drawings, detailed description and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 A flow chart of a testing method provided in an embodiment of the present application is shown.

[0010] Figure 2 A flow chart of a testing method provided in an embodiment of the present application is shown.

[0011] Figure 3 A scenario schematic diagram showing a testing method provided in an embodiment of the present application.

[0012] Figure 4 A schematic diagram of the processing process of a testing method provided in an embodiment of the present application is shown.

[0013] Figure 5 A block diagram of a testing device provided in an embodiment of the present application is shown.

[0014] Figure 6 A block diagram showing the composition of an electronic device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0015] In order to make the purpose, technical solution and advantages of the present application more clear, the embodiments of the present application will be described in detail below with reference to the accompanying drawings. It should be noted that the embodiments and features in the embodiments of the present application can be combined with each other arbitrarily without conflict.

[0016] In the related art, when code testing is performed, especially in unit testing, pile code is manually replaced in the use case execution process by pile code auxiliary construction tools (for example, pile driving test tool framework mock and powerMock etc.) or manual writing methods. For example, after the technician first determines the tested code based on the scene to be tested, the logic that needs to be piled in the tested code is analyzed, the auxiliary tool class provided by the test framework is relied on to complete the development of pile logic, and then the business code provided by the test framework by the pile logic provides a method to replace it in the logic of the tested code, and the test case is written after completing these prefabricated works. For complex tested code, it may include more than dozens of interfaces, and the business logic is more complicated, and the relationship between the business and the interface may be a strong coupling.

[0017] Because the business gap between multiple test suites is large, and the pile logic and business code are seriously coupled, pile logic (or pile code) is difficult to reuse, which leads to a high test case writing cost. Moreover, the pile logic code is usually determined based on the implementation logic of the business code, so the pile logic code and the business code are strongly coupled, and the existing test cases are often affected when the code is refactored, and the maintenance cost is high. In addition, since the pile logic code is reversed based on the business code, it is difficult to complete the development of end-to-end test cases, and in view of the fact that the developer has a certain subjectivity, therefore, even if the code coverage is very high, it is difficult to ensure the effectiveness of the test case coverage.

[0018] In view of this, the present application provides a testing method, an electronic device and a readable storage medium to solve at least one of the above problems.

[0019] In an embodiment of the present application, the tested code is loaded into a test container, and a relatively independent test environment is provided for the tested code; Since the tested code includes at least one code to be piled, therefore, according to the first attribute information of the code to be piled and the second attribute information of the preset alternative pile code, the target pile code matching the tested code is selected from the alternative pile code, and the target pile code is loaded into the test container to obtain the target test code; at least one test case corresponding to the preset test requirement is executed based on the target test code, and the test result corresponding to the tested code is obtained. It can be seen from this that in the present application, since the alternative pile code is pre-set, the separate maintenance and reuse of the pile code are realized, and there is no need to write the pile code at each test, which effectively simplifies the code maintenance difficulty and the test workload; and for the code to be piled in the tested code, the target pile code matching the code to be piled can be selected from the alternative pile code and replaced, so that the external dependencies in the target test code are all replaced with executable target pile codes, and there is no need to care about how to bind the logic of the target pile code to the logic of the tested code, which simplifies the test difficulty.

[0020] In a first aspect, an embodiment of the present application provides a testing method.

[0021] Figure 1 FIG. 1 is a flow chart of a test method provided in an embodiment of the present application. The method can be applied to test equipment. Figure 1 As shown, the testing method in the embodiment of the present application includes but is not limited to the following steps.

[0022] Step S101, loading the code under test into a test container, wherein the code under test includes at least one code to be stubbed.

[0023] In some optional implementations, the code under test is the code to be tested, and by testing the code under test, it can be determined whether the code under test can accurately execute the preset code logic. For example, the code under test corresponds to a data query function unit and can be used to execute a data query function. Then, by testing the code under test, it can be determined whether the code under test can output matching query results based on the input query parameters.

[0024] It should be noted that the code under test can be written in any development language (for example, Java (an object-oriented programming language), GO (Golang, a statically strongly typed, compiled language), Python (a computer programming language), etc.), and the embodiments of the present application do not limit this.

[0025] In some optional implementations, stub code refers to code used to replace certain codes, and correspondingly, the code to be stubbed is the code that needs to be replaced in the tested code. In other words, there is a part of the code in the tested code that needs to be replaced with the corresponding stub code.

[0026] In some optional implementations, the test container is a container specially set up for code testing. The test container can provide a relatively independent operating environment for code testing, thereby avoiding the interference of code execution inside the test container on external code, and isolating the impact of external code on the code testing process inside the test container.

[0027] In some optional implementations, in response to the test instruction, the code under test is loaded into the test container.

[0028] In some optional implementations, in response to the test case execution instruction, the code under test is loaded into the test container.

[0029] In some optional implementations, the method further includes: determining external dependency information of the code under test; and identifying the code to be stubbed in the code under test based on the external dependency information.

[0030] Among them, external dependencies include some external databases, external interfaces, external systems, etc. that the tested code needs to rely on when executing. External dependency information is information used to describe external dependencies. For example, external dependency information may include interface names, interface parameters, database names, database functions, etc. In an embodiment of the present application, after obtaining the tested code, the external dependency information in the tested code can be determined, and based on this external dependency information, the code to be piled in the tested code that needs to be piled is identified, so as to facilitate the subsequent use of corresponding alternative pile codes to replace these piled codes.

[0031] It should be noted that identifying the code to be stubbed of the code under test can occur after the code under test is loaded into the test container, or before the code under test is loaded into the test container, as long as the identification of the code to be stubbed is completed before the target stub code is selected from the alternative stub codes. The embodiments of the present application do not limit this.

[0032] Step S102, according to the first attribute information of the code to be stubbed and the second attribute information of the preset candidate stub code, select the target stub code matching the code under test from the candidate stub code, and load the target stub code into the test container to obtain the target test code.

[0033] In some optional implementations, the candidate stub code is pre-written stub code that can be used directly, and the number of the candidate stub code can be one or more, each used to implement different stub logics.

[0034] Further, because different alternative pile codes have different pile logics, therefore, it is necessary to select the target pile code that matches the tested code. Wherein, the target pile code that matches the tested code means that the target pile code and the code to be piled in the tested code can realize the same pile logic, and both can be used to complete the same data processing process and realize the same function. In this case, it is considered that the code to be piled matches the alternative pile code.

[0035] In some optional implementations, it may be determined through the attribute information of the code whether there is a matching relationship between the code to be stubbed and the candidate stub code.

[0036] Exemplarily, according to the first attribute information of the code to be piled and the second attribute information of the preset alternative pile code, the target pile code matching the code to be tested is selected from the alternative pile code, and the target pile code is loaded into the test container to obtain the target test code, including: according to the first attribute information and the second attribute information, the replacement relationship between the code to be piled and the alternative pile code is determined; when the replacement relationship is replaceable, the alternative pile code is determined to be the target pile code matching the code to be piled, and the target pile code is loaded into the test container; the code to be piled in the code to be tested is replaced with the corresponding target pile code to obtain the target test code. Among them, the replacement relationship includes replaceable and non-replaceable, and replaceable means that the alternative pile code can replace the corresponding code to be piled in the code to be tested, and non-replaceable means that the alternative pile code cannot replace the corresponding code to be piled in the code to be tested.

[0037] In some optional implementations, the first attribute information includes at least one of the first code class, the first method name, the first input and output parameters, and the first return type of the code to be stubbed, and the second attribute information includes at least one of the second code class, the second method name, the second input and output parameters, and the second return type of the candidate stub code. The code class may include at least one of a class, a subclass, a parent class, an implementation class, etc.; the first input and output parameters (or the second input and output parameters) include at least one of an input parameter name, an input parameter type, an output parameter name, and an output parameter type.

[0038] It should be noted that the above first attribute information and second attribute information are merely examples, and the embodiments of the present application do not limit this.

[0039] In some optional implementations, after the tested code is loaded into the test container, the method further includes: obtaining identification information of the preset code in the target path; and extracting the second attribute information of the alternative pile code when the preset code is determined to be an alternative pile code according to the identification information. Wherein, the identification information includes annotations (for example, @AutoFake annotation indicates that the corresponding class belongs to the alternative pile code class), comments, and custom identification, etc. As long as the preset code can be determined to belong to the alternative pile code through the identification information, the embodiment of the present application does not limit this.

[0040] It can be seen that there are several preset codes stored under the target path. In order to obtain the second attribute information of the alternative pile code therefrom, the annotations, comments and other identification information of the preset code can be obtained, and whether the preset code belongs to the alternative pile code can be determined according to the identification information. When it is determined that the preset code belongs to the alternative pile code, the second attribute information of the alternative pile code can be obtained.

[0041] In some optional implementations, the replacement relationship between the code to be piled and the alternative pile code is determined based on the first attribute information and the second attribute information, including: when the second code class is a subclass or implementation class of the first code class, determining that the replacement relationship between the code to be piled and the alternative pile code is replaceable; and / or, when the first method name is the same as the second method name, the first input and output parameters are the same as the second input and output parameters, and the first return type is the same as the second return type, determining that the replacement relationship between the code to be piled and the alternative pile code is replaceable.

[0042] Exemplarily, if the code to be piled code1 corresponds to class class_A, the alternative pile code code2 corresponds to class class_a, and class_a is a subclass or implementation class of class_A, then the replacement relationship between the code to be piled code1 and the alternative pile code code2 is determined to be replaceable, therefore, code2 is determined to be the target pile code corresponding to code1, and code1 in the code under test can be replaced with code2.

[0043] Exemplarily, if the class name, method name, input parameter, output parameter and return type of the code to be piled code1 and the alternative pile code code2 are the same, then the replacement relationship between the code to be piled code1 and the alternative pile code code2 is determined to be replaceable, therefore, code2 is determined to be the target pile code corresponding to code1, and code1 in the code under test can be replaced with code2.

[0044] Furthermore, after determining the target stub code that matches the code to be stubbed, the target stub code can be loaded into the test container to prepare for subsequent replacement between the code to be stubbed and the target stub code.

[0045] In some optional implementations, the candidate pile code is stored in the target path, and accordingly, the target pile code is loaded into the test container, including: scanning the target path, determining the storage location of the target pile code, reading the target pile code from the storage location, and loading the target pile code into the test container. Then, the code to be piled in the tested code is replaced with the corresponding target pile code to obtain the target test code.

[0046] In some optional implementations, the code to be piled in the code under test is replaced with the corresponding target pile code, and obtaining the target test code may include: deleting the code to be piled from the test container; adding the target pile code to the target code position to obtain the target test code, and the target code position is the position of the code to be piled corresponding to the target pile code in the code under test.

[0047] It can be seen that for the code to be piled, it can be deleted from the test container, and the target pile code matching the code to be piled is placed at the position of the code to be piled in the tested code to achieve the "piling" of the tested code. It should be noted that the "piling" in the embodiment of the present application is essentially just a replacement of the code, so the implementation process is relatively simple and convenient.

[0048] Step S103, executing at least one test case corresponding to a preset test requirement based on the target test code to obtain a test result corresponding to the tested code.

[0049] Among them, the execution of the target test code does not need to rely on external databases, external interfaces, external systems, etc. Therefore, the target test code can execute the corresponding test cases to obtain the execution results of the test cases, and perform assertions and other processing based on the execution results to obtain the test results corresponding to the code under test. It can also be determined whether the code under test needs to be adjusted and how to adjust the code under test based on the test results.

[0050] In some optional implementations, the code under test can implement multiple preset functions, or can execute multiple preset processing logics. In order to perform more targeted testing on the code under test, preset test requirements can be set in advance to characterize which preset functions and preset processing logics of the code under test need to be tested through the preset test requirements. For different preset test requirements, one or more corresponding test cases can be written. After executing the test case based on the target test code, the corresponding execution result can be obtained. By performing assertions and other processing on the execution result, it can be determined whether the code under test can implement the corresponding preset function, or whether the preset processing logic can be accurately executed, thereby obtaining the test result of the code under test.

[0051] It should be noted that, in the present application embodiment, the alternative pile code is maintained separately, different alternative pile codes can realize different pile logics, realize the loose coupling of pile code and business code (i.e. tested code), thus can use corresponding alternative pile code for different business codes to replace the code to be piled under different test scenarios. And, even if code reconstruction is carried out, due to the separate dimension of the alternative pile code and the isolation effect of the test container, it will not affect the existing test case, and the dimensional cost of the test case can be reduced.

[0052] In addition, the alternative stub codes in the embodiments of the present application are relatively independent and can be fully reused in different business codes (i.e., the code under test). They are not stub logic codes deduced based on a specific business code. Therefore, they can alleviate the subjectivity of developers to a certain extent, thereby improving the effectiveness of test case coverage.

[0053] It should be noted that in some optional implementation methods, if there are certain codes to be stubbed in the code under test and no matching stub code can be found from the alternative stub codes, relevant technical personnel can write new stub code, load the newly written stub code into the test container, and use the new stub code to replace the corresponding code to be stubbed.

[0054] In some optional implementations, after selecting a target stub code that matches the code to be tested from the alternative stub codes based on the first attribute information of the code to be stubbed and the second attribute information of the preset alternative stub code, the method further includes: in the case where there is no target stub code that matches the code to be stubbed in the alternative stub codes, writing a target stub code that matches the code to be stubbed based on the code logic of the code to be stubbed, and loading the target stub code into a test container; replacing the code to be stubbed with the target stub code to obtain the target test code.

[0055] It can be seen from this that when replacing the execution pile code, you can first determine whether there is a target pile code that matches the code to be piled in the alternative pile code. If there is a target pile code that matches the code to be piled in the alternative pile code, continue to execute the step of selecting the target pile code that matches the code to be piled from the alternative pile code; if there is no target pile code that matches the code to be piled in the alternative pile code, you can write the target pile code that matches the code to be piled according to the code logic of the code to be piled, load the written target pile code into the test container, and replace the code to be piled with the written target pile code.

[0056] Exemplarily, if there is no first target stub code matching the code to be stubbed code1 in the alternative stub code, a second target stub code code3 matching the code to be stubbed can be written according to the code logic of the code to be stubbed, and the second target stub code code3 can be loaded into the test container through the container interface of the test container (for example, the Application Programming Interface (API)), and then the code to be stubbed code1 in the code under test is replaced with the second target stub code code3.

[0057] It can be seen that in the embodiments of the present application, on the one hand, an appropriate amount of alternative stub codes are prepared in advance for use, and on the other hand, when the alternative stub codes cannot meet the needs, technical personnel can also write new stub codes. Through the above two aspects, it can be ensured that the external dependencies in the code under test can be successfully stubbed, so that the code under test can be tested smoothly.

[0058] In an embodiment of the present application, the tested code is loaded into a test container, and a relatively independent test environment is provided for the tested code; Since the tested code includes at least one code to be piled, therefore, according to the first attribute information of the code to be piled and the second attribute information of the preset alternative pile code, the target pile code matching the tested code is selected from the alternative pile code, and the target pile code is loaded into the test container to obtain the target test code; at least one test case corresponding to the preset test requirement is executed based on the target test code, and the test result corresponding to the tested code is obtained. It can be seen from this that in the present application, since the alternative pile code is pre-set, the separate maintenance and reuse of the pile code are realized, and there is no need to write the pile code at each test, which effectively simplifies the code maintenance difficulty and the test workload; and for the code to be piled in the tested code, the target pile code matching the code to be piled can be selected from the alternative pile code and replaced, so that the external dependencies in the target test code are all replaced with executable target pile codes, and there is no need to care about how to bind the logic of the target pile code to the logic of the tested code, which simplifies the test difficulty.

[0059] Combine the following Figure 2-Figure 4 The testing method of the embodiment of the present application is described in detail.

[0060] Figure 2 A flow chart of a testing method provided in an embodiment of the present application is shown. Figure 2 As shown, the testing method in the embodiment of the present application includes but is not limited to the following steps.

[0061] Step S201, determining the code to be tested according to the determined scenario to be tested.

[0062] Step S202: Load the code under test into the test container.

[0063] Exemplarily, the test container automatically loads the tested code from the project path, and instantiates the tested code to obtain a testable tested code instance. It should be noted that the essence of the code instance is still code, which is only in an executable form.

[0064] Step S203, identifying the external dependencies of the code under test and determining the code to be stubbed.

[0065] Step S204: judging whether there is a first target pile code matching the code to be piled in the candidate pile codes according to the first attribute information of the code to be piled and the second attribute information of the preset candidate pile codes.

[0066] Step S205, when there is a first target stub code matching the code to be stubbed in the candidate stub code, the first target stub code is loaded into the test container, and the code to be stubbed in the tested code is replaced with the corresponding first target stub code.

[0067] Step S206, when there is no first target stub code matching the code to be piled in the alternative stub code, write a second target stub code matching the code to be piled according to the code logic of the code to be piled, load the second target stub code into the test container, and replace the code to be piled with the corresponding second target stub code.

[0068] Step S207, after all the codes to be stubbed in the tested code have been replaced, the target test code is obtained.

[0069] Step S208, writing test cases according to preset test requirements.

[0070] Step S209, executing the test case based on the target test code to obtain an execution result corresponding to the test case.

[0071] Step S210, making assertions based on the execution results to obtain test results of the tested code.

[0072] In the present application embodiment, by introducing the concept of test container in the test case stage, the automatic loading of the tested code (for example, various types of business codes) can be realized, the pile logic is automatically injected and the logic that needs to be piled is automatically replaced when loading the tested code, and the logic decoupling of pile logic and tested code is realized, so that the pile logic code can be maintained separately. The technician does not need to care about how to bind the pile code to the tested business code logic, and does not need to care about how the business code instance is created, therefore, the creation of the test case can be considered from the design angle of the end-to-end unit function test. For example, from the functional perspective provided by software engineering, consider which data or business logic can be piled in the test process, write pile driving business logic or pile driving interface based on this, realize the one-time writing and multiple reuse (for example, all can be reused in engineering) of pile logic code.

[0073] Moreover, in an embodiment of the present application, a test container that can automatically load all object instances in the project can be introduced in the unit testing phase. The technical personnel can add the missing stub code in the test container by sorting out the external dependencies of the code under test, the existing stub code in the test container, etc., and reuse the existing stub code in the test container, and finally perform end-to-end test case development, thereby greatly reducing the development workload and difficulty of the test case, reducing the cost of writing test cases, improving the stability and effectiveness of test cases, improving the effectiveness of test scenarios and test function coverage, and ensuring development quality.

[0074] Figure 3 A schematic diagram of a testing method provided in an embodiment of the present application is shown. Figure 3 As shown, the code under test is stored in the project path, and the alternative stub code is stored in the test path.

[0075] When testing, the test container can provide an independent and stable operating environment for the tested code and the pile code. Exemplarily, the test container can load the tested code into the test container by automatically scanning the engineering path, and create a corresponding test instance. In addition, the test container finds the target pile code that matches the code to be piled from the alternative pile code based on the code attribute information by automatically scanning the test path, loads the target pile code into the test container, and creates a corresponding pile code instance, wherein the code attribute information can include the first code class, the first method name, the first input and output parameter, the first return type, etc. of the code to be piled, and the second code class, the second method name, the second input and output parameter, the second return type, etc. of the alternative pile code. Further, the code to be piled is replaced with the pile code instance of the corresponding target pile code. When all the codes to be piled in the tested code are replaced with the corresponding pile code instance, the target test code is obtained, and the corresponding test case can be executed based on the target test code.

[0076] It should be noted that when replacing the code to be stubbed, an automatic replacement method or a manual replacement method can be used.

[0077] Exemplarily, the automatic replacement method refers to the test container scanning the code carrying annotations, comments or other custom identifiers under the test path, and when it is determined that it belongs to the alternative stub code, the class, method and other attribute information of the alternative stub code is extracted, and based on this information, the tested code that has been loaded in the test container is traversed. If it is determined that the class of the alternative stub code belongs to a subclass or implementation class of a certain code to be piled in the tested code, or the method name, input and output parameters, return type, etc. of the alternative stub code are consistent, then it is determined that there is a replacement relationship between the alternative stub code and the code to be piled. Therefore, the code to be piled is deleted from the test container, the alternative stub code is loaded into the test container, and placed in the original position of the code to be piled, so as to realize the replacement of the stub code.

[0078] Exemplarily, the manual replacement method refers to the target pile code written by the technician calling the interface provided by the test container, and the test container extracts the attribute information such as the class and method of the target pile code, and traverses the tested code loaded in the test container based on the attribute information, by determining whether the target pile code belongs to the subclass or implementation class of the code to be piled of the tested code, or whether the method name, input and output parameters, and return type of the target pile code are consistent, thereby determining whether the code to be piled and the target pile code have a replacement relationship. In the case where the two have a replacement relationship, the matched code instance to be piled is removed from the test container, and the target pile code is added to the original position of the tested code in the container, thereby completing the replacement of the pile code.

[0079] In summary, the automatic replacement method is relatively more convenient and efficient, and can meet most stub code replacement scenarios. The manual replacement method can be used as an effective supplementary implementation method. When the alternative stub code cannot meet the usage requirements, the stub code can be manually written and loaded into the test container to replace the corresponding stub code. This method can achieve the replacement of all stub codes in the tested code and ensure the smooth progress of the test. By combining the automatic replacement method with the manual replacement method, the test efficiency can be improved and the diverse test requirements can be met.

[0080] Figure 4 A schematic diagram of the processing process of a test method provided in an embodiment of the present application is shown. Figure 4 As shown, alternative stub codes can be pre-written based on experience, statistical data, stub requirements, etc., and the alternative stub codes include stub code 1, stub code 2, ..., stub code m, where m≥1. When the code under test needs to be tested, the code under test can be loaded into a test container, wherein the code under test includes n codes to be stubbed, namely, code to be stubbed 1, ..., code to be stubbed n, where n≥1.

[0081] For the code 1 to be piled, its first attribute information s11 is obtained, and the second attribute information s21 to s2m (s2i represents the second attribute information of pile code i, 1≤i≤m) of each pile code in the alternative pile codes is obtained. If it is determined according to the first attribute information s11 and the second attribute information s2k that the code 1 to be piled and the pile code k satisfy the replaceable relationship (1≤k≤m), it is confirmed that the pile code k is the target pile code 1 that matches the code to be piled. Based on this, the code 1 to be piled is deleted from the test container, and the target pile code 1 is loaded into the test container and placed at the corresponding position of the code 1 to be piled, so as to realize the replacement of the code 1 to be piled.

[0082] Other codes to be piled are similar to the above, and will not be described in detail here. When all the codes to be piled in the tested code are replaced with the corresponding target pile codes, the target test code is obtained, and at least one test case can be executed using the target test code to obtain the execution result corresponding to each test case, and the test result of the tested code is obtained by asserting the execution result.

[0083] It should be noted that if there is no target stub code matching the code to be stubbed in the alternative stub code, the target stub code can be written according to the code logic of the code to be stubbed, and the written target stub code can be loaded into the test container through the interface of the test container to replace the corresponding code to be stubbed.

[0084] The following uses Java language as an example to explain the testing method of the embodiment of the present application.

[0085] First, there is a software development requirement. A sub-function needs to be set in the software. The sub-function is used to create an order for the user through the REST Representational State Transfer (RESTful) interface. The order information can be saved in the database, and the order data can also be queried. Among them, RESTful is a design style and development method of a network application, based on the Hypertext Transfer Protocol (HTTP) protocol, and can be defined in the eXtensible Markup Language (XML) format or the JavaScript Object Notation (JSON) format. The software includes an order creation interface for receiving requests from the RESTful interface, an order service for generating database records, and a database service for storing database records in a MySQL (relational database management system) database. In addition, the database service includes a MySQL client for implementing data access, corresponding to the MySQL client class, and the MySQL client class includes methods for creating, deleting, modifying and querying. The MySQL client here belongs to the external dependency service class.

[0086] The corresponding development process includes the following:

[0087] First, considering that there is no database configuration in the unit test environment, it is difficult for the database service to actually run in the unit test phase. Therefore, it is necessary to pile the mysql client in the database service (i.e., it belongs to the code to be piled). Based on this, the mysql pile client (MySqlClientFake) is written by inheriting the mysql client class (MySqlClient) of the business code, and the creation method and query method of MySqlClient are overwritten to obtain an alternative pile code, and its corresponding pile code logic is to create a list, and the newly added data can be saved to the list based on the new data request, and the corresponding data can be queried from the list based on the query data request and feedback. Further, the @AutoFake annotation is added to the MySqlClientFake class to indicate that the MySqlClientFake class belongs to the alternative pile code, which is convenient for subsequent reuse. Then, test cases can be written according to the test requirements, and the order creation interface is called to execute the test case to obtain the execution result. By assertion, it is judged whether the newly created order can be queried.

[0088] For example, the test container scans all classes in the test path storing the alternative stub code through reflection scanning, obtains all classes with @AutoFake annotation, finds the MySqlClientFake class, obtains the MySqlClient class through inheritance relationship, and determines that the MySqlClient class needs to be replaced by the alternative stub code MySqlClientFake class. Based on this, the MySqlClient instance in the tested code in the test container is deleted, and the MySqlClientFake instance is created based on the MySqlClientFake class and placed in the original position of the MySqlClient instance, thereby completing the replacement of the stub logic. When the tested code calls the MySqlClient instance, it actually calls the MySqlClientFake instance to create and query the order data. After the call is completed, the execution result of the test case can be viewed.

[0089] Furthermore, in some optional implementations, based on the above embodiments, it may be necessary to support order modification and deletion operations, both of which are operations on the database.

[0090] The corresponding development process includes the following:

[0091] First, extend the MySqlClientFake class, and on the basis of sharing the original creation method and query method, copy the modification method and deletion method to support the operations of modifying and deleting data. Among them, modifying data means that the corresponding records in the list can be queried and updated, and deleting data means that the corresponding records in the list can be queried and deleted. At the same time, it is also necessary to support prefabricated data. For example, the data in the pre-prepared database includes order 1 and order 2, where the record corresponding to order 1 is xx1, and the record corresponding to order 2 is xx2. Further, you can write and run test cases to get the test case execution results.

[0092] For example, the test container scans all classes in the test path storing the alternative stub code through reflection scanning, obtains all classes with @AutoFake annotation, obtains MySqlClient through inheritance relationship, and determines that the MySqlClient class needs to be replaced by the alternative stub code MySqlClientFake class. Based on this, the MySqlClient instance in the tested code in the test container is deleted, and the MySqlClientFake instance is created based on the MySqlClientFake class and placed in the original position of the MySqlClient instance, thereby completing the replacement of the stub logic. When the tested code calls MySqlClient, it actually calls the MySqlClientFake instance to modify and delete the order data. After the call is completed, the execution result of the test case can be viewed.

[0093] For example, call the order modification interface to modify order 1, assert the call to the order query interface to determine whether the modification is successful; call the order deletion interface to delete order 2, and assert the query result of order 2 to determine whether it is successfully deleted.

[0094] In some optional implementations, there are also some test scenarios where the newly created order fails when the database connection fails. The current MySqlClientFake class cannot meet this test scenario, so a new stub logic needs to be added to the MySqlClient class to meet this test scenario.

[0095] The corresponding development process includes the following:

[0096] For the MySqlClient class, add a fake implementation MySqlClientExceptionFake class, where the MySqlClientExceptionFake class overrides the creation method in the MySqlClient class, and its business logic is to throw an exception, and the @AutoFake annotation is not made for MySqlClientExceptionFake. Write a test case, and manually create a MySqlClientExceptionFake instance, call addFake to register the MySqlClientExceptionFake instance to the test container for the new order result exception throwing function, run the test case, and obtain the execution result of the test case.

[0097] For example, the test container receives the MySqlClientExceptionFake instance through addFake, and obtains the MySqlClient class through inheritance, and determines that the MySqlClient class needs to be replaced by the stub logic MySqlClientExceptionFake class. Therefore, the MySqlClient instance in the test container is deleted, and the MySqlClientExceptionFake instance is placed in the original position of the MySqlClient instance, thereby completing the replacement of the stub logic. When the tested code calls the MySqlClient instance during the execution of the test case, it actually calls the MySqlClientExceptionFake instance and gives the corresponding execution result. By asserting the execution result, the test result of the tested code can be obtained.

[0098] In a second aspect, an embodiment of the present application provides a testing device.

[0099] Figure 5 FIG. 1 is a block diagram showing a test device according to an embodiment of the present application. Figure 5 As shown, the testing device 500 in the embodiment of the present application includes but is not limited to the following modules.

[0100] A loading module 501 is used to load the code under test into the test container, wherein the code under test includes at least one code to be stubbed;

[0101] The stubbing module 502 is used to select a target stubbing code matching the code under test from the candidate stubbing codes according to the first attribute information of the code to be stubbing and the second attribute information of the preset candidate stubbing code, and load the target stubbing code into the test container to obtain the target test code;

[0102] The testing module 503 is used to execute at least one test case corresponding to a preset test requirement based on the target test code to obtain a test result corresponding to the tested code.

[0103] In an embodiment of the present application, the tested code is loaded into the test container by the loading module, and a relatively independent test environment is provided for the tested code; Since the tested code includes at least one code to be piled, therefore, through the pile driving module, according to the first attribute information of the code to be piled and the second attribute information of the preset alternative pile code, the target pile code matching the tested code is selected from the alternative pile code, and the target pile code is loaded into the test container to obtain the target test code; Through the test module, at least one test case corresponding to the preset test requirement is executed based on the target test code, and the test result corresponding to the tested code is obtained. It can be seen from this that in the present application, since the alternative pile code is pre-set, the separate maintenance and reuse of the pile code are realized, and there is no need to write the pile code at each test, which effectively simplifies the code maintenance difficulty and the test workload; and for the code to be piled in the tested code, the target pile code matching the code to be piled can be selected from the alternative pile code and replaced, so that the external dependencies in the target test code are all replaced with executable target pile codes, and there is no need to care about how to bind the logic of the target pile code to the logic of the tested code, which simplifies the test difficulty.

[0104] It should be clear that the present invention is not limited to the specific configurations and processes described in the above embodiments and shown in the figures. For the convenience and brevity of description, a detailed description of the known methods is omitted here, and the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, which will not be repeated here.

[0105] Figure 6 FIG. 1 is a block diagram showing the composition of an electronic device provided in an embodiment of the present application. Figure 6 As shown, the electronic device 600 includes an input device 601, an input interface 602, a central processing unit 603, a memory 604, an output interface 605, an output device 606, and a bus 607. The input interface 602, the central processing unit 603, the memory 604, and the output interface 605 are interconnected via the bus 607, and the input device 601 and the output device 606 are connected to the bus 607 via the input interface 602 and the output interface 605, respectively, and are further connected to other components of the electronic device 600.

[0106] Specifically, the input device 601 receives input information from the outside and transmits the input information to the central processing unit 603 through the input interface 602; the central processing unit 603 processes the input information based on the computer executable instructions stored in the memory 604 to generate output information, temporarily or permanently stores the output information in the memory 604, and then transmits the output information to the output device 606 through the output interface 605; the output device 606 outputs the output information to the outside of the electronic device 600 for user use.

[0107] In one embodiment, Figure 6 The electronic device shown may include: a memory configured to store a program; and a processor configured to run the program stored in the memory to execute the test method described in the above embodiment.

[0108] In one embodiment, Figure 6 The electronic device shown may be implemented as a testing device, which may include: a memory configured to store a program; and a processor configured to run the program stored in the memory to execute the testing method described in the above embodiment.

[0109] In one example, an embodiment of the present application further provides a readable storage medium, which stores a computer program. When the computer program is executed by a processor, any one of the test methods in the embodiments of the present application is implemented.

[0110] The above is only an exemplary embodiment of the present disclosure and is not intended to limit the scope of protection of the present disclosure. In general, various embodiments of the present disclosure can be implemented in hardware or dedicated circuits, software, logic or any combination thereof. For example, some aspects can be implemented in hardware, while other aspects can be implemented in firmware or software that can be executed by a controller, microprocessor or other computing device, although the present disclosure is not limited thereto.

[0111] Embodiments of the present disclosure may be implemented by a processor executing computer program instructions, such as in a processor entity, or by hardware, or by a combination of software and hardware. The computer program instructions may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages.

[0112] The block diagram of any logic flow in the drawings of the present disclosure may represent program steps, or may represent interconnected logic circuits, modules and functions, or may represent a combination of program steps and logic circuits, modules and functions. The computer program may be stored on a memory. The memory may have any type suitable for the local technical environment and may be implemented using any suitable data storage technology, such as but not limited to read-only memory (ROM), random access memory (RAM), optical memory devices and systems (digital versatile discs DVD or CD discs), etc. Computer-readable media may include non-transient storage media. The processor may be any type suitable for the local technical environment, such as but not limited to a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a programmable logic device (FGPA) and a processor based on a multi-core processor architecture.

[0113] By way of exemplary and non-limiting examples, a detailed description of exemplary embodiments of the present disclosure has been provided above. However, various modifications and adjustments to the above embodiments will be apparent to those skilled in the art when considered in conjunction with the accompanying drawings and claims, but will not depart from the scope of the present disclosure. Therefore, the proper scope of the present disclosure will be determined according to the claims.

Claims

1. A testing method, characterized in that: The method comprises: Loading the tested code into the test container, wherein the tested code includes at least one code to be stubbed; According to the first attribute information of the code to be piled and the second attribute information of the preset candidate pile code, a target pile code matching the code under test is selected from the candidate pile code, and the target pile code is loaded into the test container to obtain a target test code; At least one test case corresponding to a preset test requirement is executed based on the target test code to obtain a test result corresponding to the code under test.

2. The method according to claim 1, characterized in that: The method of selecting a target stub code matching the code under test from the candidate stub codes according to the first attribute information of the code to be stubbed and the second attribute information of the preset candidate stub code, and loading the target stub code into the test container to obtain the target test code comprises: Determine a replacement relationship between the to-be-stacked code and the candidate stack code according to the first attribute information and the second attribute information; In the case where the replacement relationship is replaceable, determining that the candidate stub code is a target stub code that matches the code to be stubbed, and loading the target stub code into the test container; The code to be stubbed in the code under test is replaced with the corresponding target stub code to obtain the target test code.

3. The method according to claim 2, characterized in that According to the first attribute information of the code to be stubbed and the second attribute information of the preset candidate stub code, a target stub code matching the code under test is selected from the candidate stub code, and the target stub code is loaded into the test container, before obtaining the target test code, the method further includes: Determining external dependency information of the code under test; According to the external dependency information, the code to be stubbed in the code under test is identified.

4. The method according to claim 3, characterized in that The first attribute information includes at least one of a first code class, a first method name, a first input and output parameter, and a first return type of the code to be stubbed, and the second attribute information includes at least one of a second code class, a second method name, a second input and output parameter, and a second return type of the alternative stub code.

5. The method according to claim 4, characterized in that The determining, according to the first attribute information and the second attribute information, a replacement relationship between the to-be-stacked code and the candidate stack code comprises: In the case where the second code class is a subclass or an implementation class of the first code class, determining that the replacement relationship between the to-be-piled code and the candidate stub code is replaceable; and / or, When the first method name is the same as the second method name, the first input parameter is the same as the second input parameter, and the first return type is the same as the second return type, it is determined that the replacement relationship between the to-be-stubbed code and the candidate stub code is replaceable.

6. The method according to claim 1, characterized in that After the code under test is loaded into the test container, the method further includes: Obtain identification information of a preset code in a target path; When it is determined that the preset code is a candidate code according to the identification information, second attribute information of the candidate code is extracted.

7. The method according to claim 1, characterized in that After selecting a target stub code matching the code under test from the candidate stub codes according to the first attribute information of the code to be stubbed and the second attribute information of the preset candidate stub codes, the method further includes: In the case where there is no target pile code matching the code to be piled in the candidate pile code, writing the target pile code matching the code to be piled according to the code logic of the code to be piled, and loading the target pile code into the test container; The code to be stubbed is replaced with the target stub code to obtain the target test code.

8. The method according to claim 2, characterized in that: The step of replacing the to-be-studded code in the tested code with the corresponding target stub code to obtain the target test code includes: Deleting the code to be stubbed from the test container; The target stub code is added to the target code position to obtain the target test code, where the target code position is the position of the code to be stubbed corresponding to the target stub code in the code under test.

9. An electronic device, characterized in that: include: one or more processors; A memory having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the testing method according to any one of claims 1 to 8.

10. A readable storage medium, characterized in that: The readable storage medium stores a computer program, and when the computer program is executed by a processor, the test method according to any one of claims 1 to 8 is implemented.

Images