Code testing method and device, electronic equipment and readable medium

Abstract

The embodiment of the invention provides a code testing method and device, electronic equipment and a readable medium, and relates to the technical field of computers.The method comprises the steps that in response to a code submission request of a target program, a to-be-submitted code indicated by the code submission request is tested based on a first test case currently recorded in a pre-created blacklist, and the first test case is used for testing the to-be-submitted code; and obtaining a blacklist test result. And testing the to-be-submitted code based on a second test case currently recorded in a pre-created white list to obtain a white list test result. And if the white list test result represents that the test is passed, submitting a to-be-submitted code to the target program, and under the condition that a first test case passing the test exists in the black list test result, respectively updating the black list and the white list according to the black list test result so as to obtain the updated black list and white list. In this way, by automatically testing the code indicated by the code submission request, the testing efficiency can be improved.

Description

Technical Field

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

[0002] With the continuous development of computer technology, electronic devices are increasingly used. To facilitate user experience with electronic devices, program development is necessary. During this process, developers often need to submit code multiple times. To ensure development quality, each code submission requires testing.

[0003] In related technologies, codes are often tested manually, which has the problem of low testing efficiency. Summary of the Invention

[0004] Embodiments of the present invention provide a code testing method, device, electronic device, and readable medium, which can solve the problem of low testing efficiency.

[0005] In order to solve the above problems, an embodiment of the present invention discloses a code testing method, which includes:

[0006] In response to a code submission request of a target program, based on a first test case currently recorded in a pre-created blacklist, the code to be submitted indicated by the code submission request is tested to obtain a blacklist test result;

[0007] Based on the second test case currently recorded in the pre-created whitelist, the code to be submitted is tested to obtain a whitelist test result;

[0008] If the whitelist test result indicates that the test has passed, the code to be submitted is submitted for the target program, and if there is a first test case that has passed the test in the blacklist test result, the blacklist and the whitelist are updated respectively according to the blacklist test result to obtain the updated blacklist and the whitelist.

[0009] On the other hand, an embodiment of the present invention discloses a code testing device, comprising:

[0010] A first testing module is configured to respond to a code submission request of a target program and, based on a first test case currently recorded in a pre-created blacklist, test the code to be submitted indicated by the code submission request to obtain a blacklist test result;

[0011] A second testing module is used to test the code to be submitted based on a second test case currently recorded in the pre-created whitelist to obtain a whitelist test result;

[0012] The first processing module is used to submit the code to be submitted for the target program if the whitelist test result indicates that the test has passed, and if there is a first test case that has passed the test in the blacklist test result, the blacklist and the whitelist are updated respectively according to the blacklist test result to obtain the updated blacklist and whitelist.

[0013] On the other hand, an embodiment of the present invention discloses an electronic device, comprising: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, and the executable instruction enables the processor to execute the aforementioned method.

[0014] An embodiment of the present invention further discloses a machine-readable medium having instructions stored thereon. When executed by one or more processors, the processors are enabled to execute the method described above.

[0015] Embodiments of the present invention have the following advantages: In the code testing method provided by the embodiment of the present invention, in response to a code submission request from a target program, the code to be submitted indicated by the code submission request is tested based on a first test case currently recorded in a pre-created blacklist, obtaining a blacklist test result. The code to be submitted is tested based on a second test case currently recorded in a pre-created whitelist, obtaining a whitelist test result. If the whitelist test result indicates a pass, the code to be submitted is submitted for the target program. If the blacklist test result contains a first test case that has passed the test, the blacklist and whitelist are updated based on the blacklist test result to obtain updated blacklists and whitelists. In this way, the code indicated by the code submission request is automatically tested using the test cases in the blacklist and whitelist, respectively, improving testing efficiency. Furthermore, each time a code submission request is requested, the blacklist and whitelist are updated accordingly, allowing the user to accurately identify the test cases that the target program currently failed to test based on the updated blacklist. Since a test case is used to test only one function of a program, the test cases that the target program currently failed to test can indicate that the target program does not yet have a function or has a function that has problems. In this way, the user can carry out subsequent development of the target program in accordance with the functions represented by the test cases that have not passed the test, thereby improving the efficiency of subsequent development to a certain extent. Based on the whitelist, the present application can accurately know the test cases that the target program has passed the test. Accordingly, after submitting the code for the target program, if it can still pass the test of all the second test cases in the whitelist, the submitted code will not cause the target program to fail the test cases that have passed the test before, that is, the submitted code is credible, thereby avoiding introducing new problems for the target program after submitting the code, and ensuring the stability of the target program code. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0017] Figure 1 This is a flowchart of the steps of a code testing method provided by an embodiment of the present invention;

[0018] Figure 2 is a block diagram of a code testing device provided by an embodiment of the present invention;

[0019] Figure 3 It is a structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0020] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0021] Figure 1 This is a flowchart of a code testing method provided by an embodiment of the present invention. Figure 1 As shown, the code testing method may include the following steps:

[0022] Step 101: In response to a code submission request of a target program, based on a first test case currently recorded in a pre-created blacklist, the code to be submitted indicated by the code submission request is tested to obtain a blacklist test result.

[0023] Step 102: Based on the second test case currently recorded in the pre-created whitelist, the code to be submitted is tested to obtain a whitelist test result.

[0024] Step 103: If the whitelist test result indicates that the test has passed, the code to be submitted is submitted for the target program, and if there is a first test case that has passed the test in the blacklist test result, the blacklist and the whitelist are updated respectively according to the blacklist test result to obtain the updated blacklist and the whitelist.

[0025] In an embodiment of the present invention, the user may be the developer of the target program where the code resides. The target program may be any program being developed. The code indicated by the code submission request is the code written during the development of the target program. The code indicated by the code submission request is the code that the user requests to submit (hereinafter referred to as the code to be submitted). The user may trigger a code submission request when the code for the target program needs to be submitted. For example, the code to be submitted may be code used to modify a problem in the original code of the target program, or it may be code used to add new functionality to the target program. The original code of the target program is the code previously submitted for the target program. The test cases passed by the target program refer to the test cases that the code of the target program passed. When testing the code to be submitted, the code to be submitted is uploaded to a test environment that includes the original code of the target program, and the code is tested in the test environment. In this way, the code to be submitted is tested in conjunction with the original code. That is, the target program is tested once based on the addition of the code to be submitted to the original code, thereby verifying whether this code submission will have a negative impact on the target program (i.e., cause the target program to fail the second test case test). For any test case (the first test case or the second test case), if the target program is tested using the test case and the test result is a success, then the code to be submitted can be considered to have passed the test of the test case, that is, the target program has passed the test of the test case, and the test case is a passed test case. Conversely, if the test result is a failure, then the code to be submitted can be considered to have failed the test of the test case, that is, the test case is a failed test case.

[0026] The blacklist and the whitelist can be lists created in advance for the target program, wherein the blacklist is used to record the first test case. In the initial state, the blacklist includes all test cases used for testing, and the whitelist is used to record the second test case, that is, the test case that has passed the test. The blacklist and the whitelist can record the test case itself or the content used to indicate the test case. For a first test case, when the code submitted by the request is tested using the first test case, and the test passes, the first test case is updated to the second test case and recorded in the whitelist. The first test case recorded in the blacklist can be a test case written by the developer for the target program, or it can be a test case included in an existing test suite. Separate test cases can be set for different target programs.

[0027] In an embodiment of the present invention, a first test case and a second test case are managed through a blacklist and a whitelist. In the initial state, the whitelist is empty, and all test cases are recorded in the blacklist. At this time, all test cases are first test cases, that is, the blacklist can be regarded as a collection of all test cases. When the developer needs to submit code, the test cases currently recorded in the blacklist and the whitelist are respectively automated tests. If the whitelist test result corresponding to the code to be submitted is a test pass, and the blacklist records the first test case that the code to be submitted passed, then the first test case originally recorded in the blacklist that passed the code to be submitted can be updated from the blacklist to the whitelist. It is understandable that only a portion of the first test cases that passed the test of the code to be submitted may be the first test cases. For the remaining first test cases, when the code for the target program is subsequently submitted, they will continue to be used to test the code of the target program and be updated to the whitelist. In this way, as the developer continuously submits the code of the target program to the code repository, the first test cases recorded in the blacklist will be gradually iteratively updated to the whitelist until the blacklist is empty and the whitelist converges, that is, all test cases are recorded in the whitelist.

[0028] In the case of detecting a code submission request, it can be determined first whether the pre-created blacklist is empty, that is, whether there is still a first test case recorded in the blacklist. If it is not empty, it means that there are still test cases in the blacklist that the target program has not passed. Accordingly, the code to be submitted can be tested based on the first test case currently recorded in the blacklist to obtain a blacklist test result. Further, the code to be submitted can be tested based on the second test case currently recorded in the whitelist to obtain a whitelist test result. Among them, the execution order of the operation of testing the code to be submitted based on the first test case currently recorded in the blacklist and the operation of testing the code to be submitted based on the second test case currently recorded in the whitelist are not unique. For example, the two can be executed synchronously, or the operation of testing the code to be submitted based on the second test case currently recorded in the whitelist can be executed first, and then the operation of testing the code to be submitted based on the first test case currently recorded in the blacklist is executed. The embodiment of the present invention does not impose any restrictions on this.

[0029] In an embodiment of the present invention, the first test cases in the blacklist include test cases that have been tested with the code of the target program and failed the test. And test cases that have not been tested with the code of the target program. For example, after adding a new test case to the blacklist, the newly added test case has not been used to test the code of the target program, then the newly added test case is deemed to have failed the test case. The test cases in the blacklist can be understood as test cases that the target program needs to be able to pass. By continuously updating and optimizing the code of the target program, the target program can eventually pass the test of all test cases in the blacklist, thereby obtaining the final optimized target program code. Therefore, regardless of whether the code passes the test of each test case in the blacklist, it does not affect the code submission. The second test cases recorded in the whitelist are test cases that the target program has been able to pass before. Therefore, each time you submit code for the target program, you need to ensure that you can still guarantee that the test performed by these second test cases can pass.

[0030] Furthermore, embodiments of the present invention can actively output updated blacklists and whitelists to facilitate developers to view them in a timely manner, or, alternatively, can display updated blacklists and whitelists when users request to view them. By viewing the test cases currently recorded in the updated blacklists and whitelists, developers can learn which test cases are test cases that the target program has failed to test after the most recent development iteration (submitting a code once can be considered a development iteration of the target program), and which test cases the target program has currently passed. This allows developers to optimize the development of the target program in a targeted manner, better provides developers with test result evaluation, and enables program development to be driven by updating the test cases recorded in the blacklists and whitelists. For example, if a failed test case is used to test whether the image resizing function of the target program is normal, the code for implementing the image resizing function in the code of the target program can be adjusted to achieve targeted subsequent development of the target program, thereby improving subsequent development efficiency to a certain extent. In embodiments of the present invention, by iterating the internal blacklists and whitelists and updating the test cases in the blacklists, program development is assisted in this way, development efficiency is improved, and the development iteration cycle is shortened.

[0031] The following is an explanation using a practical application scenario. Currently, there is an increasing demand for domestically produced Graphics Processing Units (GPUs). Accordingly, there is a need to develop GPU drivers for GPUs, with a short development cycle and independent control.

[0032] In an embodiment of the present invention, the target program may be a GPU driver under a Linux system, and the first test case recorded in the blacklist may be a test case included in a test suite for evaluating GPU drivers, such as a test case included in the Khronos Group's conformance test suite. Thus, using a highly recognized test suite as the first test case in the blacklist, i.e., using a highly recognized test suite as the evaluation criteria for the target program, provides a good foundation and feasibility for developing a test case driver.

[0033] In summary, in the code testing method provided by an embodiment of the present invention, in response to a code submission request from a target program, the code to be submitted indicated by the code submission request is tested based on the first test case currently recorded in a pre-created blacklist, obtaining a blacklist test result. The code to be submitted is tested based on the second test case currently recorded in a pre-created whitelist, obtaining a whitelist test result. If the whitelist test result indicates a pass, the code to be submitted is submitted for the target program. If the blacklist test result contains a first test case that has passed the test, the blacklist and whitelist are updated based on the blacklist test result to obtain updated blacklists and whitelists. In this way, the code indicated by the code submission request is automatically tested using the test cases in the blacklist and whitelist, respectively, which can improve testing efficiency. At the same time, each time a code submission request is requested, the blacklist and whitelist are updated accordingly, allowing the user to accurately determine the test cases that the target program currently failed to test based on the updated blacklist. Since a test case is used to test only one function of a program, the test cases that the target program currently failed to test can indicate that the target program does not yet have a function or has a function that has problems. In this way, the user can carry out subsequent development of the target program in accordance with the functions represented by the test cases that have not passed the test, thereby improving the efficiency of subsequent development to a certain extent. Based on the whitelist, the present application can accurately know the test cases that the target program has passed the test. Accordingly, after submitting the code for the target program, if it can still pass the test of all the second test cases in the whitelist, the submitted code will not cause the target program to fail the test cases that have passed the test before, that is, the submitted code is credible, thereby avoiding introducing new problems for the target program after submitting the code, and ensuring the stability of the target program code.

[0034] Optionally, in the embodiment of the present invention, the step of testing the code to be submitted indicated by the code submission request to obtain a blacklist test result may specifically include:

[0035] Step 1011: For any first test case currently recorded in the blacklist, the code to be submitted is tested according to the first test case to obtain a first test result; the first test case indicates a test case in which the target program fails the test.

[0036] Step 1012: Generate the blacklist test result based on the number of first test cases whose corresponding first test results are successful and the case identifiers.

[0037] Among them, the first test case is a test case in which the code of the target program has not yet passed the test. For any first test case, the code to be submitted can be put online to the test environment, and then the target program can be tested in the test environment according to the first test case. Specifically, the test script can be called to operate the target program according to the operating steps defined in the first test case to obtain the actual result. The actual result is then compared with the expected result of the first test case. If the actual result is consistent with the expected result, a first test result representing the success of the test can be generated, for example, "Success". If the actual result is inconsistent with the expected result, for example, the expected result is that the target program fails to execute, but the actual result is that the target program executes successfully, a first test result representing the failure of the test can be generated, for example, "failure". The first test result corresponding to the first test case refers to the test result obtained by using the first test case to test the code to be submitted.

[0038] For example, let's assume the target program is an image processing program. This program receives an image, converts it to a JPG format, and outputs it. The code to be submitted implements a new feature: reducing the converted image to 0.5 times its original size. A first test case a exists in the blacklist. First test case a defines the following: test input: a preset image in PNG format; expected result: a preset image in JPG format that is 0.5 times the original size; and operating steps: input the preset image, obtain the output image as the actual result, compare the actual result with the expected result, and generate a test result. Accordingly, after the code to be submitted is put online in the test environment, the test script can be called. When run, the test script inputs the test input defined in first test case a: a preset image in PNG format. The test script then obtains the image output by the image processing program as the actual result. Next, the actual result image is tested to see if it meets the expected result: a preset image in JPG format that is 0.5 times the original size. If so, the actual result is determined to be consistent with the expected result, and a first test result is generated, indicating a successful test. Otherwise, the test fails. Furthermore, since the first test result corresponding to the first test case a is a successful test, it can be determined that the target program has passed the test for the first test case a. The first test case a is updated to the second test case and added to the whitelist.

[0039] Furthermore, for each first test case, if the first test result corresponding to the first test case is a successful test, the use case identifier of the first test case can be obtained, and the number of all first test cases whose corresponding first test results are successful tests can be counted to obtain the number of use cases. The counted number of use cases and the use case identifier are used as the blacklist test result. Exemplarily, the blacklist test result may include the number of use cases: 3 and the use case identifier: the use case identifier of the first test case a. The use case identifier may be an identifier that can uniquely indicate a test case. Exemplarily, the use case identifier may be the name, number, etc. of the test case.

[0040] In an embodiment of the present invention, for any first test case currently recorded in the blacklist, the code to be submitted is tested according to the first test case to obtain a first test result. Then, based on the number of first test cases for which the corresponding first test results are successful and the case identifier, a blacklist test result is generated. In this way, based on the blacklist test result, it is possible to accurately determine whether any first test cases have passed the test, as well as which test cases have passed the test, thereby facilitating subsequent updates to the blacklist and whitelist.

[0041] Optionally, in the embodiment of the present invention, the step of testing the code to be submitted to obtain a whitelist test result may specifically include:

[0042] Step 1021: When the number of the second test cases is not 0, the code to be submitted is tested according to the second test cases to obtain a second test result; the second test cases represent test cases that the target program has passed the test.

[0043] Step 1022: Generate the whitelist test result based on the number of second test cases whose corresponding second test results are test failures.

[0044] In an embodiment of the present invention, when the number of second test cases currently recorded in the whitelist is 0, a whitelist test result is generated based on a preset value. The preset value is a value used to characterize that the test has passed. In the initial state, the whitelist is empty, that is, the number of second test cases currently recorded in the whitelist is 0. Accordingly, in this case, the number of cases of the second test examples characterizing test failure included in the whitelist test result can be set to a preset value. In this way, it can be ensured that the code to be submitted can be submitted smoothly. The preset value can be a pre-set fixed value, and illustratively, the preset value can be 0. When the developer requests to submit the code for the first time, the whitelist is empty. In an embodiment of the present invention, when the number of second test cases currently recorded in the whitelist is 0, the number of cases included in the whitelist test result is set to the preset value, so that the whitelist test result characterizes that the test has passed, so that the code requested to be submitted for the first time can be submitted smoothly.

[0045] If the code submitted in a particular instance passes a test case recorded in the blacklist, the target program's code can be considered to have passed that test case. In other words, the test cases recorded in the whitelist are the test cases that the target program's code has already passed. For the code submitted in this request, if it still passes all the test cases currently recorded in the whitelist, the code submitted can be considered trustworthy. The second test result corresponding to the second test case refers to the test result obtained by testing the code submitted using that second test case. Accordingly, if the number of second test cases currently recorded in the whitelist is not zero, for any second test case, the code submitted in this request can be tested according to that second test case. Specifically, the code submitted can be put online in a test environment, and then the target program can be tested in that test environment according to the second test case. Specifically, a test script can be called and the steps defined in the second test case can be executed to obtain the actual result. The actual result can then be compared with the expected result of the second test case. If the actual result matches the expected result, a second test result (e.g., "Success") can be generated, indicating a successful test. If the actual result is inconsistent with the expected result—for example, if the expected result is a failure of the target program execution, but the actual result is a success—a second test result, such as "failure," can be generated to indicate a test failure. Assume that a second test case b exists in the whitelist. Second test case b defines the following: test input: a preset image in PNG format; expected result: a preset image in JPG format; and steps: input the preset image, obtain the output image as the actual result, and compare the actual result with the expected result to generate the test result. Accordingly, after the code to be submitted is put online in the test environment, a test script can be called. During runtime, the test script inputs the test input defined in second test case b: a preset image in PNG format. The output image of the image processing program is then obtained as the actual result. The actual result image is then checked to see if it matches the expected result: a preset image in JPG format. If so, the actual result is determined to be consistent with the expected result, and a second test result, "Success," is generated to indicate a successful test.

[0046] Furthermore, the number of second test cases whose corresponding second test results are test failures can be counted. A whitelist test result is generated based on the number of use cases. Specifically, the number of use cases can be directly used as the whitelist test result, or the whitelist test result can also include other information, for example, the number of use cases and the use case identifiers of the second test cases whose corresponding second test results are test failures are used as the whitelist test result.

[0047] In an embodiment of the present invention, if the number of second test cases currently recorded in the whitelist is not zero, the code to be submitted is tested according to the second test case to obtain a second test result. A whitelist test result is generated based on the number of second test cases for which the corresponding second test results indicate a failed test. In this way, based on the whitelist test result, it is possible to accurately and conveniently determine whether any second test cases have failed the test, thereby facilitating subsequent decisions on whether to submit the code.

[0048] Optionally, in an embodiment of the present invention, the blacklist test result includes the number of first test cases that succeeded in the test and the case identifiers, and the whitelist test result includes the number of second test cases that failed in the test.

[0049] Correspondingly, if the whitelist test result indicates that the test has passed, the step of submitting the code to be submitted to the target program may specifically include: step 1031, if the number of use cases included in the whitelist test result is 0, merging the code to be submitted into the original code of the target program to achieve submission.

[0050] Specifically, if the number of test cases included in the whitelist test result is 0, it indicates that there is no second test case with a corresponding second test result of test failure. The code to be submitted passed the whitelist test, and the whitelist test result indicates that the test passed, and the code to be submitted is trustworthy. Therefore, the code to be submitted can be merged into the original code of the target program to achieve submission. In an embodiment of the present invention, after the code to be submitted passes all test cases in the whitelist, the code to be submitted can be submitted. This improves the quality and efficiency of rapid regression testing. Rapid regression testing refers to testing that verifies whether the changes have negatively impacted the program after the program code is modified or updated. If the number of test cases included in the whitelist test result is not 0, it indicates that there is a second test case that the code to be submitted failed this time. The code to be submitted did not pass the whitelist test and is untrustworthy. Therefore, the code to be submitted is not merged into the original code of the target program to ensure the correctness of the final submitted code. In an embodiment of the present invention, the whitelist is a list of test cases that have passed the test. The expected values ​​of the test cases recorded in the whitelist can be considered as expected passes. The blacklist is a list of test cases that have not passed the test. The expected values ​​of the test cases recorded in the blacklist can be considered as expected failures. Furthermore, if the code to be submitted passes the test of a test case recorded in the blacklist, the expected value of the test case can be considered as exceeding expectations. These test cases that exceed expectations can be added to the whitelist and removed from the blacklist, thereby realizing automated screening and iteration of test cases. If there are no unexpected failures, it can be considered that the whitelist test has passed and the code submitted in this request is correct.

[0051] If the code to be submitted fails the test of a test case recorded in the whitelist, the expected value of the test case can be regarded as an unexpected failure. Assume that B1 represents a test case that is expected to fail, B2 represents a test case that fails beyond expectations, A1 represents a test case that passes beyond expectations, and A2 represents a test case that passes as expected. Then B1 includes all the first test cases currently recorded in the blacklist, B2 includes the second test cases in which the code failed the test this time, A1 includes the first test cases in which the code passed the test this time, and A2 includes all the second test cases currently recorded in the whitelist. If the whitelist test result is 0, that is, B2 is empty, then the code submitted in this request is trustworthy and can be merged into the original code of the target program. If the whitelist test result is not 0, that is, B2 is not empty, then the code submitted in this request is not trustworthy and cannot be merged into the original code of the target program.

[0052] The original code of the target program can be stored in a code repository. In an embodiment of the present invention, in response to a user's code submission request, the electronic device can call a code processing service through a code management tool to execute, through the code processing service, the operation of testing the code to be submitted indicated by the code submission request based on the first test case currently recorded in the pre-created blacklist to obtain a blacklist test result; and testing the code to be submitted based on the second test case currently recorded in the pre-created whitelist to obtain a whitelist test result. Furthermore, if the whitelist test result indicates that the test passes, the code processing service can send a first notification message to the code management tool. Upon receiving the first notification message, the code management tool submits the code to be submitted to the code repository. After the code is submitted to the code repository, it is put online to the real production line environment. Among them, the production line environment refers to the environment in which the software or system formally provides services to the outside world. The production line environment includes the original code of the target program. If the whitelist test result indicates that the code test has failed, the code processing service can send a second notification message to the code management tool. When the code management tool receives the second notification message, it does not submit the code to be submitted, and the code to be submitted will not be put online to the real production line environment. Furthermore, when the whitelist test result indicates that the test has passed and the blacklist test result indicates that there is a first test case that succeeded in this test, the code processing service updates the test cases recorded in the blacklist and whitelist to obtain an updated blacklist and whitelist. If the whitelist test result indicates that the test has failed, even if the blacklist test result indicates that there is a first test case that succeeded in this test, the test cases recorded in the blacklist and whitelist are not updated. The code management tool can be a code repository management tool. Exemplarily, the code repository management tool can be a GitLab tool. Accordingly, merging the code into the original code of the target program can be that the code management tool merges the code to be submitted in this request into the original code of the target program in the code repository.

[0053] The above-mentioned step of updating the blacklist and the whitelist respectively according to the blacklist test result may specifically include:

[0054] Step 1032: When the number of use cases included in the blacklist test result is greater than 0, remove the test case indicated by the use case identifier from the blacklist and add it to the whitelist.

[0055] Specifically, if the number of test cases included in the blacklist test result is greater than 0, it means that there is a first test case that succeeded in this test, and the test cases recorded in the blacklist and whitelist need to be updated this time. If the number of test cases included in the blacklist test result is not greater than 0, it means that there is no first test case that succeeded in this test, and the test cases recorded in the blacklist and whitelist do not need to be updated this time.

[0056] Specifically, the test case indicated by the use case identifier included in the blacklist test result currently recorded in the blacklist can be moved to the whitelist as the second test case, and the test case indicated by the use case identifier included in the blacklist test result can be removed from the blacklist.

[0057] Assume that there are 100 test cases in total. When the developer requests to submit the code for the first time, these 100 test cases are recorded in the blacklist, and the whitelist is empty. The 100 test cases recorded in the blacklist can be used to test the code submitted for the first time, and the first test case that passes the test of the code submitted for the first time is removed from the blacklist and added to the whitelist. In an embodiment of the present invention, there are no duplicate test cases recorded in the blacklist and the whitelist. Specifically, A1 includes the test cases indicated by the use case identifier included in the blacklist test result. Assuming that A1 includes 10 test cases in the blacklist, and B2 is empty, then it can be considered that the code submitted in this request is credible, and the 10 test cases included in A1 can be moved to the whitelist, and these 10 test cases can be deleted from the blacklist to complete one iteration of the integrity test.

[0058] In this embodiment of the present invention, only when the number of test cases included in the blacklist test result is greater than 0 is the test case indicated by the test case identifier included in the blacklist test result removed from the blacklist and added to the whitelist. This avoids unnecessary update operations and ensures that there are no duplicate test cases between the blacklist and the whitelist, thereby ensuring the reliability of the code testing method.

[0059] Optionally, the embodiment of the present invention may further include the following steps: Step S21, when it is detected that the blacklist is empty, outputting preset prompt information to the user; the preset prompt information is used to indicate that the target program has passed the integrity test.

[0060] Specifically, after removing the test case indicated by the use case identifier included in the blacklist test result from the blacklist, or according to a preset period, the number of test cases currently recorded in the blacklist is checked. If the number is not 0, it can be determined that the blacklist is not empty. If the number is 0, it can be determined that the blacklist is empty. Furthermore, if the blacklist is empty, it means that the whitelist has converged. Assuming that there are 100 test cases in total, these 100 test cases are now recorded in the whitelist. In this embodiment of the present invention, the test cases recorded in the blacklist and whitelist are automatically updated to drive the development of the target program and simultaneously integrate access control testing. The access control testing refers to submitting the code only if the requested code passes the whitelist test, and not submitting the code if it fails the whitelist test. This implements access control protection and avoids introducing new problems into the target program after code submission. In the early stages of development, the blacklist can play a role in driver development and program integrity testing, while the whitelist can play a role in home access control protection. In this case, it is equivalent to performing both integrity testing and access control testing simultaneously. Completeness testing refers to checking whether the blacklist is empty after the blacklist and whitelist are updated. If so, it is determined that the target program has passed the completeness test. Otherwise, it is determined that the target program has not passed the completeness test. For example, L1 represents the blacklist and L2 represents the whitelist. Assume that the number of use cases in L1 is 5 and the number of use cases in L1 is 95. After testing L1 and L1 respectively, the test cases indicated by the use case identifier in the blacklist test result are removed from L1 and added to L2. Assuming that the blacklist test result includes the use case identifiers of these 5 test cases, it can be determined that the target program has passed the completeness test.

[0061] Specifically, when the blacklist is empty and all test cases are recorded in the whitelist, the target program can be considered to have functional completeness, that is, the target program meets the basic functional requirements, the target program's completeness test is completed, and the target program has passed the completeness test. Accordingly, a preset prompt message indicating that the target program has passed the completeness test can be output to the user, so that the user can promptly know that the target program has passed the completeness test. Exemplarily, the preset prompt message can be sent to the user in the form of a notification message, and the preset prompt message can be displayed to the user in the form of a pop-up window.

[0062] Furthermore, if the blacklist is empty, the target program has passed the integrity test, and the integrity test concludes. Entering the full access control testing phase, the only thing left to do is test whether the requested code passes the whitelist test. If so, the code is submitted. This way, the whitelist alone serves as a protective barrier for access control, ensuring that the submitted code does not introduce new issues or adversely affect existing code, thus ensuring the development quality of the target program.

[0063] Exemplarily, the blacklist and the whitelist can be stored in memory using an array data structure. The use case identifier of a test case can be an element in the array. The test case can be stored using a structure or class data structure. The test case includes fields for representing the test input, expected results, and operation steps. Assume that the blacklist and the whitelist are stored in the form of an array, the blacklist is recorded as array1, and the whitelist is recorded as array2. Assume that array1 only includes the use case representation of the first test case a, and array2 only includes the use case identifier of the second test case b.

[0064] The first test case a is:

[0065] Input: pic 0, format = PNG, size = m; (This means the test input is a preset image in PNG format marked as pic0 and of size m)

[0066] Expected results: pic 0, format = JPG, size = 0.5*m; (The expected result is a preset picture that is 0.5 times the original size and in JPG format)

[0067] STEP: Input pic 0, obtain the output image as the actual result, compare the actual result with the expected result, and generate the test result.

[0068] The second test case b is:

[0069] Input: pic 0, format = PNG; (indicates that the test input is a preset image in PNG format)

[0070] Expected results: pic 0, format = JPG; (indicates that the expected result is a preset picture in JPG format)

[0071] STEP: Input pic0, obtain the output image as the actual result, compare the actual result with the expected result, and generate the test result.

[0072] After the code to be submitted is put online in the test environment, the pseudo code of the image processing program in the test environment is:

[0073] Receive:inputpic;

[0074] reduce 0.5*inputpic=new1-pic;

[0075] ConvertPNGToJPG(new1-pic);

[0076] OUTput:new2-pic;

[0077] inputpic represents the input of the image processing program, reduce 0.5*inputpic=new1-pic means reducing the size of the input image to 0.5 times the original size, and ConvertPNGToJPG(new1-pic) means converting the reduced image into a JPG format image to obtain the final output image new2-pic.

[0078] Accordingly, after the code to be submitted is put online in the test environment, the process of using the blacklist for testing is: read the use case identifier of the first test case a (represented by ID1) from array1, and obtain the first test case a based on ID1. Call the test script, use the first test case a as the input of the test script, and input fig0 defined in the first test case a for the image processing program during runtime. Then, obtain the image output by the image processing program as the actual result. Next, check whether the image of the actual result meets the expected result: fig0 with a size 0.5 times the original and in JPG format. If so, generate a test result "Success" indicating a successful test, and obtain the first test result. In this example, the corresponding first test result is that the first test case that was successfully tested includes 1, namely the first test case a. Therefore, the blacklist test result includes: number of use cases: 1, use case identifier: ID1.

[0079] The process of testing using a whitelist is: read the use case identifier of the second test case b from array2 (represented by ID2), and obtain the second test case b based on ID2. Call the test script, use the second test case b as the input of the test script, and the test script inputs fig0 defined in the second test case b for the image processing program during runtime. Then, obtain the picture output by the image processing program as the actual result. Next, check whether the picture of the actual result meets the expected result: fig0 in JPG format. If so, generate a test result "Success" indicating a successful test, and obtain the second test result. In this example, there is no corresponding second test result for the first test case that failed the test, so the whitelist test results include: Number of use cases: 0.

[0080] Furthermore, since the number of use cases included in the whitelist test result is 0 (i.e., the whitelist test result indicates that the test has passed), it can be determined that no new problems will be introduced into the target program after the code is submitted, the code to be submitted is credible, and the code to be submitted can be submitted. At the same time, since the number of use cases included in the blacklist test result is not 0 (the blacklist test result indicates that there is a first test case that has passed the test), the use case identifier ID1 included in the blacklist test result can be removed from array1 and added to array2. Exemplarily, the use case identifier ID1 and the identifier of array1 can be used as parameters of the remove instruction, and the remove instruction can be used to remove the use case identifier ID1 from array1. The use case identifier ID1 and the identifier of array2 can be used as parameters of the push instruction, and the push instruction can be used to add the use case identifier ID1 to array2. In an embodiment of the present invention, the blacklist and whitelist are updated until the blacklist is empty. When the blacklist is empty, a preset prompt message is output.

[0081] In one related technology, when manual testing is performed, it is necessary to manually screen test cases for the code and use the screened test cases to test the code. This manual testing method not only has low testing efficiency, but also has the problem of being difficult and time-consuming to manually implement. In another related technology, for open source community scenarios, the code is submitted directly when it passes all test cases. However, during the program development process, in the early stages of development, the code often cannot directly pass all test cases and needs to be gradually updated and optimized to eventually pass all test cases. Although this method can save time, it is not suitable for the program development process. In the embodiment of the present invention, automated testing can reduce the difficulty of manual implementation and save time. In the embodiment of the present invention, through gradual iteration of black and white lists, the test cases in the blacklist are gradually updated to the whitelist. The submitted code only needs to meet the test cases currently recorded in the whitelist, so it can be more adaptable to the program development process.

[0082] Optionally, the embodiment of the present invention may further include the following steps:

[0083] Step S31: When the blacklist is empty, the code to be submitted is tested directly based on the second test case currently recorded in the whitelist to obtain the whitelist test result.

[0084] Step S32: If the whitelist test result indicates that the test has passed, the code to be submitted is submitted.

[0085] Specifically, each time a user submits a code request, the system first checks whether the current blacklist is empty. If it is empty, it means that there are currently no test cases that the target program has failed to test, and the code can be directly tested using all the test cases recorded in the whitelist. If each test case is tested successfully, it can be determined that the code to be submitted is trustworthy and the code to be submitted is submitted. Conversely, if there is at least one test case that fails beyond expectations, it can be determined that the code to be submitted is untrustworthy and the code to be submitted can be not submitted.

[0086] In this embodiment of the present invention, if the blacklist is empty, the code to be submitted is directly tested based on the second test case currently recorded in the whitelist, obtaining a whitelist test result. If the whitelist test result indicates a pass, the code is submitted. This avoids unnecessary blacklist-based testing operations, thereby saving processing resources.

[0087] The following is an explanation of a user's code submission request. In response to the user's code submission request, the code management tool is triggered to call the code processing service. If the blacklist is empty and B2 is empty, the code processing service sends a first notification message to the code management tool, notifying the code management tool that the code submitted in this request is credible. Accordingly, the code management tool can merge the code into the original code of the target program. If the blacklist is not empty, B2 is empty, and A1 is not empty, the test cases recorded in the blacklist and whitelist are updated, and a first notification message is sent to the code management tool, notifying the code management tool that the code submitted in this request is credible. Accordingly, the code management tool can merge the code into the original code of the target program. For example, the updated whitelist = the whitelist before the update + A1, and the updated blacklist = the blacklist before the update - A1. If B2 is not empty, the code processing service sends a second notification message to the code management tool, notifying the code management tool that the code submitted in this request is not credible and will not be merged into the original code of the target program. By responding to subsequent code submission requests, the above process is repeated until the blacklist is empty and all test cases are updated to the whitelist. When the blacklist is empty and all test cases are recorded in the whitelist, the access control test is carried out only through the whitelist.

[0088] Reference Figure 2 , shows a block diagram of a code testing device provided by an embodiment of the present invention, such as Figure 2 As shown, the code testing device may specifically include:

[0089] The first testing module 201 is configured to respond to a code submission request of a target program and test the code to be submitted indicated by the code submission request based on a first test case currently recorded in a pre-created blacklist to obtain a blacklist test result;

[0090] A second testing module 202 is configured to test the code to be submitted based on a second test case currently recorded in a pre-created whitelist, and obtain a whitelist test result;

[0091] The first processing module 203 is used to submit the code to be submitted for the target program if the whitelist test result indicates that the test has passed, and if there is a first test case that has passed the test in the blacklist test result, the blacklist and the whitelist are updated respectively according to the blacklist test result to obtain the updated blacklist and the whitelist.

[0092] Optionally, the first testing module 201 is specifically configured to:

[0093] For any first test case currently recorded in the blacklist, the code to be submitted is tested according to the first test case to obtain a first test result; the first test case indicates a test case in which the target program fails the test;

[0094] The blacklist test result is generated based on the number of first test cases whose corresponding first test results are successful and the case identifiers.

[0095] Optionally, the second testing module 202 is specifically configured to:

[0096] If the number of the second test cases is not 0, the code to be submitted is tested according to the second test cases to obtain a second test result; the second test cases represent test cases that the target program has passed the test;

[0097] The whitelist test result is generated based on the number of second test cases whose corresponding second test results are test failures.

[0098] Optionally, the blacklist test result includes the number of first test cases that succeeded in the test and the case identifiers, and the whitelist test result includes the number of second test cases that failed in the test;

[0099] The first processing module 203 is specifically configured to: if the number of use cases included in the whitelist test result is 0, merge the code to be submitted into the original code of the target program to achieve submission;

[0100] When the number of use cases included in the blacklist test result is greater than 0, the test case indicated by the use case identifier is removed from the blacklist and added to the whitelist.

[0101] Optionally, the device further comprises:

[0102] The output module is used to output preset prompt information to the user when it is detected that the blacklist is empty; the preset prompt information is used to indicate that the target program has passed the integrity test.

[0103] Optionally, the device further comprises:

[0104] A third testing module is configured to test the code to be submitted directly based on the second test case currently recorded in the whitelist when the blacklist is empty, to obtain the whitelist test result;

[0105] The second processing module is configured to submit the code to be submitted if the whitelist test result indicates that the test has passed.

[0106] In summary, the code testing device provided in an embodiment of the present invention responds to a code submission request from a target program. Based on the first test case currently recorded in a pre-created blacklist, the code to be submitted indicated by the code submission request is tested to obtain a blacklist test result. Based on the second test case currently recorded in a pre-created whitelist, the code to be submitted is tested to obtain a whitelist test result. If the whitelist test result indicates a pass, the code to be submitted is submitted for the target program. If the blacklist test result contains a first test case that has passed the test, the blacklist and whitelist are updated based on the blacklist test result to obtain updated blacklists and whitelists. In this way, the code indicated by the code submission request is automatically tested using the test cases in the blacklist and whitelist, respectively, improving testing efficiency. Furthermore, each time a code submission request is requested, the blacklist and whitelist are updated accordingly, allowing the user to accurately determine the test cases that the target program currently failed to test based on the updated blacklist. Since a test case is used to test only one function of a program, the test cases that the target program currently failed to test can indicate that the target program does not yet have a function or has a function that has problems. In this way, the user can carry out subsequent development of the target program in accordance with the functions represented by the test cases that have not passed the test, thereby improving the efficiency of subsequent development to a certain extent. Based on the whitelist, the present application can accurately know the test cases that the target program has passed the test. Accordingly, after submitting the code for the target program, if it can still pass the test of all the second test cases in the whitelist, the submitted code will not cause the target program to fail the test cases that have passed the test before, that is, the submitted code is credible, thereby avoiding introducing new problems for the target program after submitting the code, and ensuring the stability of the target program code.

[0107] Reference Figure 3 , is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. Figure 3 As shown, the electronic device includes: a processor, a memory, a communication interface and a communication bus.

[0108] The processor, the memory, and the communication interface communicate with each other via the communication bus; the memory is used to store at least one executable instruction, which enables the processor to execute the code testing method of the above embodiment. The executable instructions can form a program.

[0109] An embodiment of the present invention provides a machine-readable medium having instructions stored thereon. When executed by one or more processors, the processors are enabled to execute the code testing method of the aforementioned embodiment.

[0110] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0111] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, apparatus, or computer program products. Thus, embodiments of the present invention may take the form of a fully hardware embodiment, a fully software embodiment, or an embodiment combining software and hardware. Furthermore, embodiments of the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0112] It should be noted that all actions of acquiring signals, information or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where they are located and with the authorization given by the owner of the corresponding device.

[0113] The embodiments of the present invention are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the process in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0114] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing terminal device to operate in a predictable manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0115] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 a process or multiple processes and / or boxes Figure 1A step that specifies a function in one or more boxes.

[0116] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they become aware of the basic creative concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0117] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are merely used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations.

[0118] Moreover, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or terminal device that includes a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or terminal device. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not preclude the presence of additional identical elements in the process, method, article, or terminal device that includes the element.

[0119] The above is a detailed introduction to a code testing method, a code testing device, an electronic device and one or more readable media provided by the present invention. Specific examples are used herein to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. At the same time, for those skilled in the art, according to the ideas of the present invention, there will be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be understood as limiting the present invention.

Claims

1. A code testing method, characterized in that: The method comprises: In response to a code submission request of a target program, based on a first test case currently recorded in a pre-created blacklist, the code to be submitted indicated by the code submission request is tested to obtain a blacklist test result; Testing the code to be submitted based on the second test case currently recorded in the pre-created whitelist to obtain a whitelist test result; If the whitelist test result indicates that the test has passed, the code to be submitted is submitted for the target program, and if there is a first test case that has passed the test in the blacklist test result, the blacklist and the whitelist are updated respectively according to the blacklist test result to obtain the updated blacklist and the whitelist.

2. The method according to claim 1, characterized in that The step of testing the code to be submitted indicated by the code submission request to obtain a blacklist test result includes: For any first test case currently recorded in the blacklist, the code to be submitted is tested according to the first test case to obtain a first test result; the first test case indicates a test case in which the target program fails the test; The blacklist test result is generated based on the number of first test cases whose corresponding first test results are successful and the case identifiers.

3. The method according to claim 1, characterized in that The testing of the code to be submitted to obtain a whitelist test result includes: If the number of the second test cases is not 0, the code to be submitted is tested according to the second test cases to obtain a second test result; the second test cases represent test cases that the target program has passed the test; The whitelist test result is generated based on the number of second test cases whose corresponding second test results are test failures.

4. The method according to any one of claims 1 to 3, characterized in that: The blacklist test result includes the number of first test cases that succeeded in the test and the case identifiers, and the whitelist test result includes the number of second test cases that failed in the test; If the whitelist test result indicates that the test has passed, submitting the code to be submitted for the target program includes: if the number of use cases included in the whitelist test result is 0, merging the code to be submitted into the original code of the target program to achieve submission; The updating of the blacklist and the whitelist according to the blacklist test result includes: when the number of use cases included in the blacklist test result is greater than 0, removing the test case indicated by the use case identifier from the blacklist and adding it to the whitelist.

5. The method according to claim 4, characterized in that The method further comprises: When it is detected that the blacklist is empty, a preset prompt message is output; the preset prompt message is used to indicate that the target program has passed the integrity test.

6. The method according to claim 1, characterized in that The method further comprises: When the blacklist is empty, directly testing the code to be submitted based on the second test case currently recorded in the whitelist to obtain the whitelist test result; If the whitelist test result indicates that the test is passed, the code to be submitted is submitted.

7. A code testing device, characterized in that: The device comprises: A first testing module is configured to respond to a code submission request of a target program and, based on a first test case currently recorded in a pre-created blacklist, test the code to be submitted indicated by the code submission request to obtain a blacklist test result; A second testing module is used to test the code to be submitted based on a second test case currently recorded in the pre-created whitelist to obtain a whitelist test result; The first processing module is used to submit the code to be submitted for the target program if the whitelist test result indicates that the test has passed, and if there is a first test case that has passed the test in the blacklist test result, the blacklist and the whitelist are updated respectively according to the blacklist test result to obtain the updated blacklist and whitelist.

8. The device according to claim 6, characterized in that The first test module is specifically used to: For any first test case currently recorded in the blacklist, testing the code to be submitted according to the first test case to obtain a first test result; The first test case represents a test case in which the target program fails the test; The blacklist test result is generated based on the number of first test cases whose corresponding first test results are successful and the case identifiers.

9. An electronic device, characterized in that: include: A processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; The memory is used to store executable instructions, and the executable instructions enable the processor to execute the method according to any one of claims 1 to 6.

10. One or more machine-readable media, characterized in that Instructions are stored thereon, which, when executed by one or more processors, cause the processors to perform the method according to any one of claims 1 to 6.

Images