Code testing method and device and electronic equipment

Abstract

The embodiment of the invention provides a code testing method and device and electronic equipment, and the method comprises the steps: obtaining a difference code information set between a basic version code and a to-be-tested version code, and determining a change interface list according to the difference code information set, obtaining a test case set corresponding to the change interface list from a test case knowledge base, generating a test plan based on the test case set, and executing each test case according to the test plan to obtain a test result of the to-be-tested version code. According to the method and the device, the to-be-tested version code can be rapidly and comprehensively subjected to incremental test, so that the test efficiency of the to-be-tested version code is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and more specifically, to a code testing method, device, and electronic device. Background Art

[0002] In the related art, when the R&D personnel submit the code for the version to be tested, if the code for the version to be tested submitted by the R&D personnel needs to be tested, the testers need to communicate with the R&D personnel in a timely and effective manner, and then the testers will conduct corresponding tests. However, during the testing process, the testers usually conduct a complete test on all functional modules of the entire system of the code for the version to be tested to ensure that the new code will not introduce new problems. Although comprehensive regression testing can provide a high coverage rate, since the code for the version to be tested usually has many functional modules that are not affected by the changes and are also tested repeatedly, there is a lot of redundant testing work in the related art, and the testing efficiency is low. Summary of the Invention

[0003] In view of this, the embodiments of the present application propose a code testing method, device and electronic device, which can test only the code parts that have actually changed, avoiding a large amount of redundant testing work, thereby saving manpower, time and resource costs.

[0004] In the first aspect, an embodiment of the present application provides a code testing method, the method comprising: obtaining a difference code information set between a base version code and a version code to be tested; determining a change interface list based on the difference code information set, the change interface list including identifiers of multiple change interfaces; obtaining a test case set corresponding to the change interface list from a test case knowledge base, the test case set including a test case corresponding to each change interface in the change interface list, the test case knowledge base storing multiple interface identifiers and test cases corresponding to each interface identifier; generating a test plan based on the test case set, and executing each test case according to the test plan to obtain a test result of the version code to be tested.

[0005] In the second aspect, an embodiment of the present application provides a code testing device, which includes: a code change detection module, which is used to obtain a difference code information set between a basic version code and a version code to be tested, wherein the difference code information set includes change information of at least one segment of difference code; a change interface determination module, which is used to determine a change interface list based on the difference code information set, wherein the change interface list includes multiple change interfaces; a use case set acquisition module, which is used to obtain a test case set corresponding to the change interface list from a test case knowledge base, wherein the test case set includes a test case corresponding to each change interface in the change interface list; a test execution module, which is used to generate a test plan based on the test case set, and execute each of the test cases according to the test plan to obtain the test results of the version code to be tested.

[0006] In one possible implementation, the difference code information set includes a change class and a change interface determination module, and is also used to call a class loader to load the change class to generate a class object; call an interface acquisition method to obtain an interface that implements the class object; and obtain a change interface list based on the identifier of the interface that implements the class object.

[0007] In one possible implementation, the code change detection module is further configured to use a code comparison tool to perform a code comparison on the base version code and the version code to be tested, to obtain a difference code information set between the base version code and the version code to be tested.

[0008] In one possible implementation, the code change detection module includes a request acquisition submodule, a code acquisition submodule and a change detection submodule; the request acquisition submodule is used to obtain a code comparison request, wherein the code comparison request carries a remote warehouse address, a first identifier and a second identifier; the code acquisition submodule is used to respond to the code comparison request and obtain a base version code corresponding to the first identifier and a version code to be tested corresponding to the second identifier from a system warehouse corresponding to the remote warehouse address; the change detection submodule is used to compare the base version code with the version code to be tested, obtain a difference code information set between the base version code and the version code to be tested, and output the difference code information set.

[0009] In one embodiment, the test execution module is further used to output the difference code information set through the command line tool of the distributed version control system when the code comparison request is received through the command line tool of the distributed version control system; and to output the difference code information set through the application program interface of the distributed version control system when the code comparison request is not received through the command line tool of the distributed version control system.

[0010] In one possible implementation, the code comparison request also carries account information and password information corresponding to the account information, and the code change detection module also includes an authentication submodule for performing identity authentication based on the account information and the password information; a code acquisition submodule for obtaining the basic version code corresponding to the first identifier and the version code to be tested corresponding to the second identifier from the system repository corresponding to the remote repository address when the authentication is passed.

[0011] In one possible implementation, the use case set acquisition module is also used to traverse the changed interface list and check whether there is an interface identifier among the multiple interface identifiers in the test case knowledge base that matches the identifier of each changed interface; if an interface identifier that matches the identifier of the changed interface is detected, the test case corresponding to the interface identifier is added to the test case set.

[0012] In one possible implementation, the use case set acquisition module is also used to generate prompt information for instructing to add a new test case corresponding to the identifier of the target change interface to the test case library when it is detected that the identifier of the target change interface does not exist among the multiple interface identifiers of the test case knowledge base, and the target change interface is the change interface in the change interface list.

[0013] In a third aspect, an embodiment of the present application provides an electronic device comprising a processor and a memory; one or more programs are stored in the memory and configured to be executed by the processor to implement the above method.

[0014] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which program code is stored, wherein the above method is executed when the program code is executed by a processor.

[0015] The embodiment of the present application provides a code testing method, device and electronic device. First, by obtaining a difference code information set between the base version code and the version code to be tested, the changed interface list is determined according to the difference code information set, which can accurately identify which interfaces are affected by the code change, thereby helping to narrow the test scope that needs to be focused on, avoiding comprehensive regression testing of the entire project, and improving testing efficiency; further, by obtaining a test case set corresponding to the changed interface list from a test case knowledge base; based on the test case set, a test plan is generated, and each test case is executed according to the test plan to obtain the test results of the version code to be tested, ensuring that all affected interfaces are covered by the test, thereby reducing the possibility of missing key test points and improving the accuracy and completeness of the test. Therefore, by adopting the code testing method of the present application, it is achieved that only the interface list that has actually changed is tested, avoiding a large amount of redundant testing work, thereby improving testing efficiency and saving manpower, time and resource costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0017] Figure 1 A schematic diagram of a code testing method according to an embodiment of the present invention is shown;

[0018] Figure 2 A flowchart of a code testing method provided by an embodiment of the present application is shown;

[0019] Figure 3 Shown Figure 1 Flow chart of step S110;

[0020] Figure 4 Shown Figure 1 Flow diagram of step S110;

[0021] Figure 5 Shown Figure 1 Flow chart of step S130;

[0022] Figure 6 Another flowchart of a code testing method provided by an embodiment of the present application is shown;

[0023] Figure 7 Another flowchart of a code testing method provided by an embodiment of the present application is shown;

[0024] Figure 8 A connection block diagram of a code testing device proposed in an embodiment of the present application is shown;

[0025] Figure 9 A structural block diagram of an electronic device for executing the method according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0026] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this application will be thorough and complete and will fully convey the concepts of the example embodiments to those skilled in the art.

[0027] In addition, described feature, structure or characteristic can be combined in one or more embodiments in any suitable manner.In the following description, many specific details are provided so as to provide a full understanding of the embodiments of the present application. However, it will be appreciated by those skilled in the art that the technical scheme of the present application can be put into practice without one or more of the specific details, or other methods, components, devices, steps etc. can be adopted. In other cases, known methods, devices, implementations or operations are not shown or described in detail to avoid blurring the various aspects of the application.

[0028] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically separate entities. That is, these functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0029] The flowcharts shown in the accompanying drawings are for illustrative purposes only and do not necessarily include all contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may be decomposed, while others may be combined or partially combined. Therefore, the actual execution order may vary depending on the actual situation.

[0030] It should be noted that the term "plurality" used in this document refers to two or more. "And / or" describes a relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A alone, A and B together, or B alone. The character " / " generally indicates an "or" relationship between the associated objects.

[0031] Please refer to Figure 1 and Figure 2 , Figure 1 and Figure 2The code testing method of the present application is shown respectively. The method can be applied to an electronic device, which can be a terminal device or a server. The terminal device can be a mobile terminal or a computer, etc. The method includes:

[0032] Step S110: Obtain a difference code information set between the base version code and the version code to be tested.

[0033] The base version code is a stable program code that has been fully verified and tested and confirmed to be correct. It can be used as the basis for comparison of changes to subsequent versions (such as the version code to be tested).

[0034] The code to be tested can be the code submitted by the R&D personnel for testing. The code to be tested can be obtained by adjusting the base version code once or multiple times.

[0035] The base version code and the version code to be tested generally refer to a series of source code files or other related files in a software project, which can exist in various file formats, such as source code files, configuration files, etc. When the base version code and the version code to be tested exist in source code file format, the corresponding file format can be .java (source code file in Java language), .cpp / .cc / .cxx / .c (source code file in C++ or C language), .py (Python script file), .js (JavaScript script file), or .go (source code file in Go language), etc.

[0036] The difference information set may include information on all changes between the base version code and the version code to be tested, such as the change file (the change file where the changed code in the version code to be tested is located), the difference code change line information (which indicates which specific lines of code in each change file have been modified, added or deleted), the method object (which lists the affected method names and related information (such as parameter types, return types, etc.), which is used to help determine which methods are affected by the change), the module name (indicates in which module the change occurred, which helps to quickly locate the area where the problem is. For example, in a multi-module Maven project, different module names correspond to different sub-projects or modules.) and the modification type (indicating the change type of the difference code change line information (such as addition, modification, deletion), so as to more accurately understand the nature of the change).

[0037] Each change file, method object, module name, and the corresponding difference code change line and modification type of the change file together constitute a change class. That is, the difference code information set includes a change class consisting of change information of at least one difference code segment.

[0038] In one embodiment, see Figure 3 The above step S110 may be: using a code comparison tool to perform a code comparison on the basic version code and the version code to be tested to obtain a difference code information set between the basic version code and the version code to be tested.

[0039] The above-mentioned code comparison tool may be a Diffchecker (difference checker), testDifference (test difference tool), code-diff (code difference comparison tool), or other code comparison tools or functional modules that can be used to compare differences between different versions of codes.

[0040] It is worth mentioning that when using code-diff as a code comparison tool, testers only need to deploy the source code to the code comparison tool without occupying public resources and can perform operations locally. At the same time, it does not involve information security issues and information confidentiality is higher.

[0041] In another embodiment, see Figure 4 The above step S110 may also be: calling the version control system to execute the following steps:

[0042] Step S112: Obtain a code comparison request, where the code comparison request carries a remote repository address, a first identifier, and a second identifier.

[0043] The code comparison request can be manually input by the user through a page or command line interface provided by the distributed version control system, or it can be automatically triggered through an API interface.

[0044] Specifically, in one possible implementation, users can directly select the tags corresponding to the base version code and the version code to be tested on platforms such as GitLab and GitHub to generate a code comparison request, or use the local Git command line tool to enter a command similar to git diff baseVersion (the tag of the base version code) nowVersion (the tag of the version code to be tested) to generate a code comparison request. In another possible implementation, in response to the operation of the version code to be tested submitted by the R&D personnel, the GitLab API or other version control system API can be called to initiate a code comparison request.

[0045] Step S114: In response to the code comparison request, the base version code corresponding to the first identifier and the to-be-tested version code corresponding to the second identifier are obtained from the system repository corresponding to the remote repository address.

[0046] If the code comparison request is received through a command line tool, step S114 may be to directly use the git checkout or git fetch command to obtain the base version code corresponding to the first identifier and the to-be-tested version code corresponding to the second identifier.

[0047] If the code comparison request is obtained through the API interface, the above step S114 can specifically be to call the server corresponding to the version control system to obtain the basic version code corresponding to the first identifier and the version code to be tested corresponding to the second identifier from the system repository corresponding to the remote repository address.

[0048] Step S116: Compare the basic version code with the version code to be tested, obtain a difference code information set between the basic version code and the version code to be tested, and output the difference code information set.

[0049] Wherein, the distributed version control system has a built-in code comparison function to compare the differences between the two versions. If the code comparison request is obtained through a command line tool, the above step S116 can execute the git diff command to compare the base version code with the version code to be tested, obtain the difference code information set between the base version code and the version code to be tested, and output the difference code information set. If the code comparison request is obtained through an API interface, the above step S116 can be to call the server to compare the base version code with the version code to be tested, and obtain the difference code information set between the base version code and the version code to be tested.

[0050] Among them, when outputting the difference code information set, if the code comparison request is received through the command line tool of the distributed version control system, the difference code information set is output through the command line tool; if the code comparison request is not received through the command line tool of the distributed version control system, the difference code information set is output through the application program interface of the distributed version control system.

[0051] Considering that access to a remote repository typically requires access rights, which typically involves providing a username and password or a personal access token (PAT) for authentication, in one embodiment, the code comparison request also includes account information and password information corresponding to the account information. Before executing step S114, the method further includes: performing identity authentication based on the account information and the password information; if the authentication is successful, executing step S114.

[0052] The distributed version control system stores multiple preset accounts and reference passwords corresponding to each preset account. When performing identity authentication based on the account information and the password information, it can first be determined whether a target preset account matching the account information exists in the multiple preset account information. If a target preset account identical to the account information exists in the multiple preset accounts, the reference password corresponding to the target preset account is compared with the password information. If the reference password and the password information are consistent, the authentication is successful. If there is no preset account identical to the account information in the multiple preset accounts or the reference password corresponding to the target preset account is inconsistent with the password information, the identity authentication fails. If the identity authentication fails, subsequent code testing cannot be performed.

[0053] It is worth mentioning that the above version control system can be a distributed version control system (Git system) or a centralized version control system (SVN system, Subversion). Both of the above version control systems can ultimately output information sets such as changed code lines, change methods, and changed modules.

[0054] Step S120: determining a changed interface list according to the difference code information set, wherein the changed interface list includes identifiers of multiple changed interfaces.

[0055] In one embodiment, the above step S120 may be: calling a class loader to load the changed class to generate a class object; calling an interface acquisition method to acquire an interface that implements the class object; and obtaining a changed interface list based on the identifier of the interface that implements the class object.

[0056] It is worth mentioning that this method is applicable to source code files where the basic version code and the version code to be tested are written in a language that supports the reflection mechanism, such as .java or .cpp / .cc / .cxx / .c.

[0057] Exemplarily, when the basic version code and the version code to be tested are .java source code files, the interface acquisition method (getInterfaces() method) in the Java reflection application program interface can be used to obtain the changed interface list.

[0058] In another possible implementation, the above step S120 may also be to call a static analysis tool to analyze the difference code information set and the tested version code to obtain a changed class, extract the implementation interface of the changed class, and obtain a changed interface list according to the identifier of the implementation interface of the changed class.

[0059] Step S130: Obtain a test case set corresponding to the changed interface list from a test case knowledge base, wherein the test case set includes a test case corresponding to each changed interface in the changed interface list, and the test case knowledge base stores multiple interface identifiers and a test case corresponding to each interface identifier.

[0060] A test case knowledge base is a database or file system that stores a large number of test cases. It typically stores test cases in a structured manner, with each test case associated with a specific interface (API). This can be a repository for testers to refine test cases based on requirements documents and detailed design documents.

[0061] It is worth mentioning that when the interface changes (such as parameter modification or return value modification), the corresponding test cases need to be updated to ensure the accuracy of the test cases. When new interfaces are added to the project, new test cases need to be written for these interfaces and added to the test case knowledge base.

[0062] In one embodiment, see Figure 5 , the above step S130 includes:

[0063] Step S132: traverse the changed interface list and check whether there is an interface identifier matching the identifier of each changed interface among the multiple interface identifiers in the test case knowledge base.

[0064] Step S134: If an interface identifier matching the identifier of the changed interface is detected, a test case corresponding to the interface identifier is added to the test case set.

[0065] In another embodiment, step S130 may also be performed by using a rule engine (e.g., Drools) to recall test cases corresponding to each changed interface in the changed interface list according to predefined rules. Specifically, the predefined rules may be (e.g., "If the interface name contains 'User', then recall all test cases related to 'User'"). Based on the interface identifiers in the changed interface list, the predefined rules are applied to recall the relevant test cases, and the recalled rules are added to the test case set.

[0066] In one embodiment, the above-mentioned step S130 also includes step S136: if it is detected that the identifier of the target change interface does not exist among the multiple interface identifiers of the test case knowledge base, a prompt message is generated to indicate that a new test case corresponding to the identifier of the target change interface is to be written into the test case library, and the target change interface is the change interface in the change interface list.

[0067] Please refer to Figure 6Through the above steps, it is possible to obtain test cases for the change interface from the test case knowledge base, and generate a prompt message when the target change interface in the change interface list does not exist in the test case knowledge base, so that the tester or R&D personnel can write the test case corresponding to the target change interface according to the prompt message, and add the written test case to the test case set, and add it to the test case library to ensure that the test case set finally obtained includes the test case corresponding to each change interface in the change interface list, so that in subsequent tests, the test case set can be used to achieve complete test coverage.

[0068] Step S140: Generate a test plan based on the test case set, and execute each test case according to the test plan to obtain a test result of the version code to be tested.

[0069] The test plan can be a JSON, XML, or other file format. It typically includes the execution order of test cases, the input data required for each test case, the expected results, and the execution strategy (such as whether each test case is executed in parallel or serially). It is worth mentioning that the process of obtaining the execution order and execution strategy of test cases involves classifying and sorting the test cases and ensuring that all change interfaces are covered.

[0070] According to the execution order and strategy in the test plan, the corresponding test tools or frameworks (such as JUnit, TestNG, etc.) are called in sequence to execute the test cases to obtain the test results of each test case. Based on the test results of each test case, the test results of the code version to be tested are obtained. The test results include the test plan execution results (such as the success or failure of the test plan execution), the test case execution completion rate (that is, the proportion of completed test cases in the test case set), the total number of tests (the number of completed test cases), the case execution pass rate, the details of failed test cases (including all failed test cases and the reasons for failure), and the execution time.

[0071] The above test results can be output in the form of text or graphical interface to achieve visual display of test results.

[0072] By adopting the above-mentioned testing method, firstly, by obtaining the difference code information set between the basic version code and the version code to be tested, the focus is placed on the code that has changed, thereby reducing unnecessary testing. Furthermore, by determining the changed interface list based on the difference code information set, the interface range (changed interface list) affected by the code change can be accurately located. Furthermore, by obtaining the test case set corresponding to the changed interface list from the test case knowledge base, unnecessary test case execution can be reduced, and the testing cost (such as time cost, human resource cost) can be reduced while ensuring that all affected interfaces are tested, thereby improving the test coverage. Therefore, by adopting the code testing method of the present application, it is achieved that only the interface list that has actually changed is tested, avoiding a large amount of redundant testing work, thereby improving the testing efficiency and saving manpower, time and resource costs.

[0073] See also Figure 7 In order to make the technical solution and effect of the present invention clearer, the example of calling the version control system as the gitlab source code management platform is taken. In an agile development process, the tester improves the test case knowledge base based on the accumulated requirement documents, detailed design documents, UI documents, etc., and the R&D personnel incrementally submit the code (version code to be tested) in the iteration. At this time, the gitlab source code management platform has a code version update, and the interface / api / code / diff / list (get request method) of the difference code information set can be obtained based on the version control system. At this time, the gitUrl remote warehouse address, baseVersion (base version code) branch name, nowVersion (version code to be tested) branch name, gitlab account information and password information can be entered into the gitlab source code management platform. The structure method is as follows

[0074]

[0075] The gitlab source code management platform first authenticates the user based on the gitlab account and password information. If the authentication is successful, the base version code corresponding to the baseVersion branch name and the version code to be tested corresponding to the nowVersion branch name are obtained from the system repository corresponding to the gitUrl remote repository address, and the difference code information set is obtained by comparison. The difference code information includes the change class, which can be a classFile file (java file) including lines (difference code change line information), methodInfos (method object), moduleName (module name) and type (modification type), etc. Subsequently, the getInterfaces() method in the java reflection API is used to obtain all the change interfaces involved in all change classes (i.e., the change interface list), and the input change interface list is traversed. If the interface name in the change interface list is the same as the API interface name in the "Interface Definition" of the test case knowledge base, the test case involved in the API is added to the test case set; if the interface name in the change interface list cannot match the API interface name in the "Interface Definition" of the use case knowledge base, the tester is prompted to supplement the test case corresponding to the interface name and add it to the test case set. Aggregate the test cases in the test case set to generate a test plan, execute each test case according to the test plan, and set a retry or stop executing the test case if the test case fails until all test cases in the test plan are tested and a test report is output.

[0076] By adopting the above settings, since the test case knowledge base is improved by testers based on the accumulated demand documents, detailed design documents, UI documents, etc., the test case library has strong robustness, does not rely on the software quality of the program being tested, and is independently maintained and used; and is highly reusable. After development is completed, it can be used in different project business lines. In the process of program version updates, subsequent R&D personnel will inevitably have multiple versions of code change operations, and each change requires regression testing. Based on the above method of this application, the impact range of the test change (i.e., the list of changed interfaces) is obtained based on incremental code analysis, and then the test case set is accurately obtained based on this change range. Therefore, the test cases executed according to the test plan have high accuracy, avoid case redundancy, and also ensure the test coverage of the program being tested. In addition, each test can automatically complete the incremental content test and output the report, realizing a full closed loop of test activities and greatly reducing the testing cost.

[0077] It should be understood that, although the steps in the flowcharts of the above embodiments are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be performed in other orders. Moreover, at least a portion of the steps in the flowcharts of the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these steps or stages is not necessarily to be performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0078] See also Figure 8 Another embodiment of the present application provides a code testing device 200, including: a code change detection module 210, used to obtain a difference code information set between a base version code and a version code to be tested, wherein the difference code information set includes change information of at least one section of difference code; a change interface determination module 220, used to determine a change interface list based on the difference code information set, wherein the change interface list includes multiple change interfaces; a use case set acquisition module 230, used to obtain a test case set corresponding to the change interface list from a test case knowledge base, wherein the test case set includes a test case corresponding to each change interface in the change interface list; a test execution module 240, used to generate a test plan based on the test case set, and execute each test case according to the test plan to obtain a test result of the version code to be tested.

[0079] In one possible implementation, the difference code information set includes a changed class, a changed interface determination module 220, and is also used to call a class loader to load the changed class to generate a class object; call an interface acquisition method to obtain an interface that implements the class object; and obtain a changed interface list based on the identifier of the interface that implements the class object.

[0080] In one embodiment, the code change detection module 210 is further configured to use a code comparison tool to perform a code comparison on the base version code and the version code to be tested to obtain a difference code information set between the base version code and the version code to be tested.

[0081] In one embodiment, the code change detection module 210 includes a request acquisition submodule, a code acquisition submodule and a change detection submodule; the request acquisition submodule is used to obtain a code comparison request, wherein the code comparison request carries a remote warehouse address, a first identifier and a second identifier; the code acquisition submodule is used to respond to the code comparison request and obtain a base version code corresponding to the first identifier and a version code to be tested corresponding to the second identifier from the system warehouse corresponding to the remote warehouse address; the change detection submodule is used to compare the base version code with the version code to be tested, obtain a difference code information set between the base version code and the version code to be tested, and output the difference code information set.

[0082] In one embodiment, the test execution module 240 is also used to output the difference code information set through the command line tool of the distributed version control system when the code comparison request is received through the command line tool of the distributed version control system; and to output the difference code information set through the application program interface of the distributed version control system when the code comparison request is not received through the command line tool of the distributed version control system.

[0083] In one possible implementation, the code comparison request also carries account information and password information corresponding to the account information. The code change detection module 210 also includes an authentication submodule for performing identity authentication based on the account information and the password information; a code acquisition submodule for obtaining the basic version code corresponding to the first identifier and the version code to be tested corresponding to the second identifier from the system repository corresponding to the remote repository address when the authentication is passed.

[0084] In one embodiment, the use case set acquisition module 230 is also used to traverse the changed interface list and check whether there is an interface identifier among the multiple interface identifiers of the test case knowledge base that matches the identifier of each of the changed interfaces; if an interface identifier that matches the identifier of the changed interface is detected, the test case corresponding to the interface identifier is added to the test case set.

[0085] In one embodiment, the use case set acquisition module 230 is also used to generate prompt information for instructing to add a test case corresponding to the identifier of the target change interface to the test case library when it is detected that the identifier of the target change interface does not exist in the multiple interface identifiers of the test case knowledge base, and the target change interface is the change interface in the change interface list.

[0086] Each module in the above-mentioned device can be implemented in whole or in part by software, hardware, or a combination thereof. Each of the above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to each of the above modules. It should be noted that the device embodiment in this application corresponds to the aforementioned method embodiment. The specific principles in the device embodiment can be found in the contents of the aforementioned method embodiment, which will not be repeated here.

[0087] The following will be combined Figure 9 An electronic device provided by this application is described.

[0088] See also Figure 9 Based on the code testing method provided in the above embodiment, the embodiment of the present application also provides another electronic device 100 including a processor 102 that can execute the above method. The electronic device 100 can be a vehicle.

[0089] The electronic device 100 further includes a memory 104 . The memory 104 stores a program capable of executing the contents of the aforementioned embodiments, and the processor 102 can execute the program stored in the memory 104 .

[0090] The processor 102 may include one or more cores for processing data and a message matrix unit. The processor 102 utilizes various interfaces and circuits to connect various components within the electronic device 100. It executes instructions, programs, code sets, or instruction sets stored in the memory 104, and accesses data stored in the memory 104 to perform various functions and process data within the electronic device 100. Optionally, the processor 102 may be implemented using at least one of the following hardware forms: a digital signal processing (DSP), a field-programmable gate array (FPGA), or a programmable logic array (PLA). The processor 102 may integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU primarily processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing display content; and the modem handles wireless communications. It is understood that the modem may not be integrated into the processor 102 and may be implemented separately via a communication chip.

[0091] In this embodiment, the processor 102 includes a main controller and a system-on-chip to implement the aforementioned method steps.

[0092] The memory 104 may include random access memory (RAM) or read-only memory (ROM). The memory 104 may be used to store instructions, programs, codes, code sets, or instruction sets. The memory 104 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function, instructions for implementing the various method embodiments described below, and the like. The data storage area may also store data acquired by the electronic device 100 during use.

[0093] The electronic device 100 may also include a network module and a screen. The network module is used to receive and send electromagnetic waves, realize the mutual conversion between electromagnetic waves and electrical signals, and thus communicate with a communication network or other devices, such as communicating with a playback device. The network module may include various existing circuit components for performing these functions, such as an antenna, a radio frequency transceiver, a digital signal processor, an encryption / decryption chip, a user identity module (SIM) card, a memory, and the like. The network module can communicate with various networks such as the Internet, an intranet, a wireless network, or communicate with other devices via a wireless network. The above-mentioned wireless network may include a cellular telephone network, a wireless local area network, or a metropolitan area network. The screen can display interface content and perform data interaction, such as displaying the aforementioned interface and triggering operations through the screen.

[0094] The present application also provides a computer-readable storage medium that stores program code, which can be called by a processor to execute the method described in the above method embodiment.

[0095] The computer-readable storage medium may be an electronic memory such as a flash memory, an EEPROM (Electrically Erasable Programmable Read-Only Memory), an EPROM, a hard disk, or a ROM. Alternatively, the computer-readable storage medium includes a non-transitory computer-readable storage medium. The computer-readable storage medium has storage space for program codes for executing any of the method steps described above. These program codes can be read from or written to one or more computer program products. The program codes can be compressed, for example, in an appropriate form.

[0096] The present application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods described in the various optional implementations described above.

[0097] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A code testing method, characterized in that: The method comprises: Get the difference code information set between the base version code and the version code to be tested; Determining a changed interface list according to the difference code information set, wherein the changed interface list includes identifiers of multiple changed interfaces; Acquire a test case set corresponding to the changed interface list from a test case knowledge base, wherein the test case set includes a test case corresponding to each changed interface in the changed interface list, and the test case knowledge base stores a plurality of interface identifiers and a test case corresponding to each interface identifier; Based on the test case set, a test plan is generated, and each test case is executed according to the test plan to obtain the test result of the version code to be tested.

2. The method according to claim 1, characterized in that The difference code information set includes a change class, and determining a change interface list according to the difference code information set includes: Calling a class loader to load the changed class to generate a class object; Calling the interface acquisition method to obtain the interface that implements the class object; According to the identifier of the interface that implements the class object, a list of changed interfaces is obtained.

3. The method according to claim 1, characterized in that The step of obtaining a difference code information set between the base version code and the version code to be tested includes: A code comparison tool is used to perform a code comparison on the basic version code and the version code to be tested, to obtain a difference code information set between the basic version code and the version code to be tested.

4. The method according to claim 1, wherein The step of obtaining the difference code information set between the base version code and the version code to be tested includes: calling the version control system to execute the following steps: Obtain a code comparison request, where the code comparison request carries a remote repository address, a first identifier, and a second identifier; In response to the code comparison request, obtaining a base version code corresponding to the first identifier and a to-be-tested version code corresponding to the second identifier from a system repository corresponding to the remote repository address; The basic version code is compared with the version code to be tested to obtain a difference code information set between the basic version code and the version code to be tested, and the difference code information set is output.

5. The method according to claim 4, characterized in that Outputting the difference code information set includes: If the code comparison request is received through a command line tool of a distributed version control system, outputting the difference code information set through the command line tool; If the code comparison request is not received through a command line tool of a distributed version control system, the difference code information set is output through an application program interface of the distributed version control system.

6. The method according to claim 4, characterized in that The code comparison request also carries account information and password information corresponding to the account information. Before obtaining the base version code corresponding to the first identifier and the to-be-tested version code corresponding to the second identifier from the system repository corresponding to the remote repository address, the method further includes: Performing identity authentication based on the account information and the password information; If the authentication is successful, the step of obtaining the basic version code corresponding to the first identifier and the version code to be tested corresponding to the second identifier from the system warehouse corresponding to the remote warehouse address is executed.

7. The method according to claim 1, characterized in that The acquiring of a test case set corresponding to the changed interface list from a test case knowledge base includes: Traversing the list of changed interfaces, checking whether there is an interface identifier matching the identifier of each of the changed interfaces among the multiple interface identifiers in the test case knowledge base; If an interface identifier that matches the identifier of the changed interface is detected, a test case corresponding to the interface identifier is added to the test case set.

8. The method according to claim 7, characterized in that The method further comprises: If it is detected that the target change interface identifier does not exist among the multiple interface identifiers of the test case knowledge base, a prompt message is generated to instruct the test case library to add a new test case corresponding to the identifier of the target change interface, and the target change interface is the change interface in the change interface list.

9. A code testing device, characterized in that: The device comprises: A code change detection module is used to obtain a difference code information set between a base version code and a version code to be tested, wherein the difference code information set includes change information of at least one section of the difference code; a change interface determination module, configured to determine a change interface list according to the difference code information set, wherein the change interface list includes a plurality of change interfaces; A test case set acquisition module is used to acquire a test case set corresponding to the change interface list from a test case knowledge base, wherein the test case set includes a test case corresponding to each change interface in the change interface list; The test execution module is used to generate a test plan based on the test case set, and execute each test case according to the test plan to obtain the test result of the version code to be tested.

10. An electronic device, characterized in that: include: one or more processors; Memory; One or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs are configured to perform the method according to any one of claims 1 to 8.

Images