Defect finding method and apparatus for source code files

Abstract

The application discloses a defect finding method of a source code file. The method comprises the following steps: obtaining difference information of a to-be-tested source code file and a target source code file; determining a to-be-tested application program interface according to the difference information, wherein the to-be-tested application program interface comprises one or more; performing an interface test operation on each to-be-tested application program interface to obtain a test result; comparing the test result with an expected result corresponding to the performed interface test operation, and determining whether the to-be-tested application program interface has a defect according to a comparison result. The application can quickly find defects.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and apparatus for detecting defects in source code files. Background Technology

[0002] Currently, as API (Application Programming Interface) testing becomes increasingly granular, testing requires frequent verification of API entry and exit points, necessitating extensive combinations and verifications to ensure the legitimacy of entry points. With frequent business iterations, repetitive anomaly analysis and verification consume significant manpower and time. Summary of the Invention

[0003] The purpose of this application is to provide a method and system for discovering defects in source code files, which can solve the problem in the prior art that the repeated anomaly analysis and verification of APIs leads to a large amount of manpower and time costs.

[0004] One aspect of this application provides a method for discovering defects in source code files, including:

[0005] Obtain the difference information between the source code file to be tested and the target source code file;

[0006] The application interface to be tested is determined based on the difference information, and the application interface to be tested includes one or more.

[0007] For each application interface under test, perform interface testing operations and obtain test results;

[0008] The test results are compared with the expected results of the executed interface test operations, and the test results are used to determine whether the application interface under test has defects.

[0009] Optionally, the difference information includes changed file information and line number information of the changed code in the changed file, and the step of determining the application interface to be tested based on the difference information includes:

[0010] Based on the changed file information, filter out the application interface definition file from at least one changed file;

[0011] The application interface to be tested is determined based on the row number information and the application interface definition file.

[0012] Optionally, the step of filtering application interface definition files from at least one change file based on the change file information includes:

[0013] Based on the changed file information, a changed file with a preset file extension is selected from at least one changed file as the application interface definition file.

[0014] Optionally, after the step of comparing the test result with the expected result corresponding to the executed interface test operation, and determining whether the application interface under test has defects based on the comparison result, the method further includes:

[0015] When a defect is found in the interface of the application under test, a defect report is generated and pushed to a preset user.

[0016] Optionally, for each interface of the application under test, interface testing operations are performed, and the test results include:

[0017] Obtain the input parameter information of the application interface under test, and generate a test case set corresponding to the input parameters contained in the application interface under test based on the input parameter information;

[0018] Generate a combined test case set for testing the target application interface under test, and the expected results corresponding to the combined test case set, based on the test case set corresponding to all the input parameters contained in the application interface under test.

[0019] The test results are obtained by performing test operations on the interface of the application under test according to the combined test case set.

[0020] Optionally, the test case set includes a type validation set, a boundary validation set, and an exception validation set.

[0021] Optionally, the method further includes:

[0022] The code block file to be tested is determined based on the difference information;

[0023] Filter out the target code blocks associated with each of the application interfaces under test from the code block file to be tested;

[0024] The target code block is verified using a preset code block rule judgment algorithm, and the presence of defects in the target code block is determined based on the verification results.

[0025] Optionally, the code block rule determination algorithm includes basic syntax rules and basic syntax specifications. The step of using a preset code block rule determination algorithm to verify the target code block and determining whether the target code block has defects based on the verification result includes:

[0026] The target code block is verified using the basic syntax rules and the basic syntax specifications respectively, to obtain a first verification result and a second verification result;

[0027] The presence of defects in the target code block is determined based on the first verification result and the second verification result.

[0028] Optionally, the step of filtering out the target code blocks associated with each of the application interfaces under test from the code block file includes:

[0029] Find the method name associated with each of the application interfaces under test from the code block file under test;

[0030] The named code of the target code block is located according to the method name, and the code between the named code and the end symbol of the target code block in the code block file to be tested is taken as the target code block.

[0031] Optionally, the method further includes:

[0032] Based on the line number information, filter out the lines of code to be tested from the code block file to be tested that correspond to the line number information;

[0033] Determine whether the line of code to be tested belongs to the lines of code contained in the target code block;

[0034] If the line of code to be tested does not belong to the line of code contained in the target code block, the code block rule judgment algorithm is used to verify the line of code to be tested, and the verification result is used to determine whether the line of code to be tested has a defect.

[0035] One aspect of this application also provides a defect detection device for source code files, including:

[0036] The acquisition module is used to obtain the difference information between the source code file to be tested and the target source code file;

[0037] A determination module is used to determine the application interface to be tested based on the difference information, wherein the application interface to be tested includes one or more;

[0038] The testing module is used to perform interface testing operations for each application interface under test and obtain test results;

[0039] The comparison module is used to compare the test results with the expected results corresponding to the executed interface test operations, and determine whether the application interface under test has defects based on the comparison results.

[0040] This application also provides a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0041] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0042] The defect detection method for source code files provided in this application involves obtaining difference information between the source code file to be tested and the target source code file; determining the application interface to be tested based on the difference information, wherein the application interface to be tested includes one or more; performing interface testing operations for each application interface to be tested to obtain test results; comparing the test results with the expected results corresponding to the performed interface testing operations, and determining whether the application interface to be tested has defects based on the comparison results. This achieves testing only on application interfaces that have changed, without needing to repeat testing on application interfaces that have already been tested, thus saving testing time and shortening the testing cycle. Furthermore, since the defect detection method in this application only requires application interface testing in non-business scenarios, it can more quickly detect defects in application interfaces compared to existing technologies that require application interface testing in business scenarios. Attached Figure Description

[0043] Figure 1 This is an environmental diagram illustrating the defect detection method for source code files in an embodiment of this application.

[0044] Figure 2 A flowchart illustrating one embodiment of the defect detection method for source code files described in this application;

[0045] Figure 3 This is a detailed flowchart illustrating the steps of determining the application interface to be tested based on the difference information in one embodiment of this application.

[0046] Figure 4 A flowchart illustrating another embodiment of the defect detection method for source code files described in this application;

[0047] Figure 5 This is a detailed flowchart illustrating the steps of selecting target code blocks associated with each application interface under test from the code block file to be tested, according to one embodiment of this application.

[0048] Figure 6 This is a detailed flowchart illustrating the steps of using a preset code block rule judgment algorithm to verify the target code block and determining whether the target code block has defects based on the verification results in one embodiment of this application.

[0049] Figure 7 A flowchart illustrating another embodiment of the defect detection method for source code files described in this application;

[0050] Figure 8This is a program module diagram of one embodiment of the defect detection device for source code files described in this application;

[0051] Figure 9 A schematic diagram of the hardware structure of a computer device for a defect detection method for executing source code files provided in an embodiment of this application. Detailed Implementation

[0052] The advantages of this application are further illustrated below with reference to the accompanying drawings and specific embodiments.

[0053] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0054] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the listed items.

[0055] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0056] In the description of this application, it should be understood that the numerical labels before the steps do not indicate the order of the steps, but are only used to facilitate the description of this application and to distinguish each step, and therefore should not be construed as a limitation of this application.

[0057] Figure 1 This illustration shows an application scenario provided by an embodiment of this application, which includes: a source code file storage system 10 and a source code file defect detection terminal 20, wherein:

[0058] The source code file storage system 10 is used to store source code files of various versions, including source code files to be tested and target source code files, and to compare source code files to be tested and target source code files to obtain difference information between source code files to be tested and target source code files.

[0059] Among them, the source code file storage system 10 can be GitLab, which is a repository management system generally used to manage information such as code branches and versions.

[0060] The defect discovery terminal 20 for source code files can be a tablet computer, laptop computer, desktop computer, rack server, blade server, tower server, or cabinet server (including standalone servers or server clusters composed of servers), etc.

[0061] See Figure 2 This is a flowchart illustrating a method for discovering defects in source code files according to an embodiment of this application. It is understood that the flowchart in this method embodiment is not intended to limit the order of execution steps. As can be seen from the figure, the method for discovering defects in source code files provided in this embodiment includes:

[0062] Step S20: Obtain the difference information between the source code file to be tested and the target source code file.

[0063] Specifically, the source code file to be tested is the source code file for which defects need to be discovered, such as the latest version of the developed application (APP) code file. The target source code file is a historical version of the application code file, which can be the code file of the version before the current version, or any other historical version of the application code file.

[0064] The difference information refers to information used to record changes in the source code file under test relative to the target code file. The difference information may include information such as changed file information, line number information of changed code in the changed file, and the person who made the change.

[0065] The modified file information may include the file extension of the modified code file and the source code of the modified code file. The line number information of the modified code in the modified file refers to the specific line number of the modified code in the modified file. For example, if the line number information is 4, it means that the 4th line of code in the modified file has been modified.

[0066] In one implementation, the difference information between the source code file to be tested and the target source code file can be obtained by calling the API interface provided by GitLab for handling diff capabilities.

[0067] Understandably, when obtaining the difference information by calling the API provided by GitLab for processing diffs, the user needs to upload the source code file to be tested and the target source code file to GitLab in advance.

[0068] GitLab is a repository management system typically used to manage code branches and versions. Besides providing standard branch upload and download, project management, and other functionalities, GitLab also offers a diff function with each commit. This function compares the code files of two specified commits. If no target commit is specified for comparison, the master commit is used as the comparison object.

[0069] GitLab's diff capability provides an API interface that can be used. In addition to returning information such as the file, differences, and who made the changes, diff also includes the specific line number of the changes.

[0070] Step S21: Determine the application interface to be tested based on the difference information. The application interface to be tested includes one or more.

[0071] Specifically, the application interface to be tested is an application interface (API) that has undergone code changes. There may be only one API or multiple APIs to be tested, and the specific number is determined based on the difference information.

[0072] In one exemplary implementation, when the difference information includes change file information and line number information of the change code in the change file, refer to... Figure 3 The step of determining the application interface to be tested based on the difference information includes:

[0073] Step S30: Select the application interface definition file from at least one change file based on the change file information.

[0074] Specifically, since an application's source code files typically consist of multiple types of code files, such as configuration code files, API interface definition code files, and ordinary code block files, and the change file information contains information about all the changed files, once the change file information is obtained, the application interface definition file can be selected from at least one change file based on this change file information.

[0075] Among them, the modified file refers to the file whose code has been changed relative to the corresponding file in the target source code file.

[0076] In one exemplary embodiment, the step of selecting the application interface definition file from at least one change file based on the change file information includes: selecting a change file with a preset file extension from at least one change file as the application interface definition file based on the change file information.

[0077] Specifically, because the application programming interface (API) definition file has a different file extension than other types of code files in the source code file under test, and it has a unique file extension, in this embodiment, during the screening of the API definition file, the file extensions of all modified files can be directly matched. When a file with the specified file extension is found, that file can be used as the API definition file.

[0078] The application programming interface (API) definition file is a file used to define the APIs included in the app. It includes the structure of input parameters and output parameters, as well as the types of the input and output parameter fields. This API definition file has a preset file extension.

[0079] It should be noted that the application programming interface (API) definition files of the source code files to be tested, which are developed in different languages, generally have different file extensions. For example, the application programming interface (API) definition files of the source code files to be tested developed in Go have the extension .pb.

[0080] In one exemplary implementation, the application interface definition file can also be found by first locating the code block file to be tested (the search method has been described in detail below and will not be repeated here).

[0081] Specifically, after locating the code block file to be tested, the nearest set of files in the same path can be found (the application interface definition file and the actual code file (i.e., the code block file to be tested) will be in a folder in the same path, i.e., a set of files), and the application interface definition file can be found from the set of files.

[0082] Step S31: Determine the application interface to be tested based on the row number information and the application interface definition file.

[0083] Specifically, since the line number information records which line in the application programming interface (API) definition file the changed code belongs to, once the API definition file is obtained, the corresponding line of code can be found within the API definition file based on the line number information. Since the line of code must belong to a specific API, once the line of code is found, the associated API can be located through that line.

[0084] Step S22: For each application interface under test, perform interface testing operations and obtain test results.

[0085] Specifically, by performing interface testing on each application interface to be tested, defects in all application interfaces in the source code file to be tested are identified, thus achieving full API testing.

[0086] For each application interface under test, interface testing is performed, and the test results include:

[0087] Step A: Obtain the input parameter information of the application interface under test, and generate a test case set corresponding to the input parameters contained in the application interface under test based on the input parameter information.

[0088] Specifically, the input parameter information includes the name and type of the input parameter. Generally, each application interface under test includes multiple input parameters. Therefore, when generating test case sets based on the input parameter information, a corresponding test case set will be generated for each input parameter. Assuming the application interface under test contains 3 input parameters, 3 test case sets need to be generated, with one test case set corresponding to each input parameter.

[0089] In one exemplary implementation, in order to achieve comprehensive testing of the application interface under test, the test case set may include a type validation set, a boundary validation set, and an exception validation set.

[0090] The type validation set is a set of test cases used to validate the type of input parameters. For example, if the type of an input parameter is string, then data of type string, type int, type float, etc. need to be generated as a type validation set.

[0091] The boundary validation set is a set of test cases used to validate the boundary values ​​of input parameters. For example, if the type of an input parameter is int, then data containing 0, negative numbers, the maximum value of int, etc., needs to be generated as the boundary validation set.

[0092] The exception check set is a set of test cases used to check for abnormal situations of input parameters. For example, if the value of a certain input parameter contains multiple numbers, then it is necessary to generate data that includes cases where the value is not passed, or cases where the input parameter value is passed too much or too little, as an exception check set.

[0093] In one embodiment, the test case set may further include a business value verification set, which is a set of test cases used to verify business scenarios.

[0094] In this embodiment, the specific method for generating a test case set corresponding to the input parameters contained in the interface of the application under test based on the input parameter information can refer to the test case set generation method in the prior art. The specific implementation method will not be described in this embodiment.

[0095] Step B: Generate a combined test case set for testing the target application interface under test, and the expected results corresponding to the combined test case set, based on the test case sets corresponding to all the input parameters contained in the application interface under test.

[0096] Specifically, the values ​​of the input parameters contained in the test case set corresponding to all input parameters are exhaustively combined, and each exhaustive combination is a combined test case. All combined test cases constitute the combined test case set.

[0097] As an example, the application interface under test includes input parameter 'a' and input parameter 'b'. Input parameter 'a' contains 2 data points in its type validation set, 2 data points in its boundary validation set, and 2 data points in its exception validation set. Input parameter 'b' contains 2 data points in its type validation set, 2 data points in its boundary validation set, and 2 data points in its exception validation set. When generating the combined test case set, the 2 data points in the type validation set of input parameter 'a' can be combined sequentially with each of the 2 data points in the type validation set of input parameter 'b', combined with each of the 2 data points in the boundary validation set, and combined with each of the 2 data points in the exception validation set, resulting in 12 test cases. Similarly, the 2 data points in the boundary validation set of input parameter 'a' can be combined sequentially with each of the 2 data points in the type validation set of input parameter 'b', combined with each of the 2 data points in the boundary validation set, and combined with each of the 2 data points in the exception validation set, resulting in 12 test cases. Similarly, the two data points contained in the constant validation set of input parameter a can be combined sequentially with each of the two data points contained in the type validation set of input parameter b, with each of the two data points contained in the boundary validation set, and with each of the two data points contained in the exception validation set, resulting in 12 test cases. These are then combined into 36 test cases, which form the combined test case set.

[0098] In this embodiment, each combined test case will have a corresponding expected result, which is the expected value of the return value of the application interface. For example, if the API input parameters are all of type string and the return value is a dictionary structure, then the combination of types that meet the requirements, and the value fields are not special, not boundary, and not exception, will have an expected return value status of 0, and the expected return value structure will be a dictionary format.

[0099] Step C: Perform test operations on the application interface under test according to the combined test case set, and obtain the test results.

[0100] Specifically, for each test case in the combined test case set, a test operation is performed on the application interface under test to obtain a test result. During the test operation, each combined test case can refer to the API definition to make a request to the application interface under test, thereby obtaining the request result, i.e., obtaining the test result.

[0101] As an example, if the combined test case set contains 10 combined test cases, then 10 test results can be obtained in the end.

[0102] Step S23: Compare the test results with the expected results corresponding to the executed interface test operation, and determine whether the application interface under test has defects based on the comparison results.

[0103] Specifically, after performing the test operation, each test result is compared with the corresponding expected result so that the test application interface may have defects based on the comparison result.

[0104] The defect detection method for source code files provided in this application involves obtaining difference information between the source code file to be tested and the target source code file; determining the application interface to be tested based on the difference information, wherein the application interface to be tested includes one or more; performing interface testing operations for each application interface to be tested to obtain test results; comparing the test results with the expected results corresponding to the performed interface testing operations, and determining whether the application interface to be tested has defects based on the comparison results. This achieves testing only on application interfaces that have changed, without needing to repeat testing on application interfaces that have already been tested, thus saving testing time and shortening the testing cycle. Furthermore, since the defect detection method in this application only requires application interface testing in non-business scenarios, it can more quickly detect defects in application interfaces compared to existing technologies that require application interface testing in business scenarios.

[0105] In one exemplary embodiment, to enable users to promptly address defects in the application interface, after the step of comparing the test results with the expected results corresponding to the executed interface test operation, and determining whether the application interface under test has defects based on the comparison results, the method further includes:

[0106] When a defect is found in the interface of the application under test, a defect report is generated and pushed to a preset user.

[0107] Specifically, when a defect is identified in a test application interface, a defect report can be generated. This defect report may include the application interface name, details of the defect, etc.

[0108] In one implementation, a defect report can be automatically generated using the report upload API provided by Jira, and then pushed to a preset user. The preset user is a user pre-defined to receive the defect report.

[0109] It should be noted that Jira is a code defect management tool. Generally, when a new defect is created and associated with a corresponding person, Jira will send a corresponding push message to the associated person.

[0110] In one exemplary implementation, to improve defect detection coverage, see [reference needed]. Figure 4 The method further includes:

[0111] Step S40: Determine the code block file to be tested based on the difference information.

[0112] Specifically, the code block file to be tested is a regular code file that has undergone code changes.

[0113] It should be noted that the ordinary code file is a file used to record the code that actually performs calculations and processes on the requests of the application interface.

[0114] In one implementation, files with specific file extensions can be selected as the code block files to be tested based on the changed file information contained in the difference information. Generally, the code block files to be tested are developed using different languages, and therefore have different specific file extensions. For example, the file extension for Go is .go, and for Python it is .py.

[0115] Step S41: Select the target code blocks associated with each application interface under test from the code block file to be tested.

[0116] Specifically, each application programming interface (API) has a block of target code that implements the functionality of that API. Therefore, after locating the code block to be tested, the target code blocks associated with the API to be tested can be selected from that block.

[0117] In one exemplary implementation, see [reference] Figure 5 The step of filtering out the target code blocks associated with each of the application interfaces under test from the code block file to be tested includes:

[0118] Step S50: Locate the method name associated with each of the application interfaces under test from the code block file under test.

[0119] Specifically, in the code specification, each application interface is uniquely assigned a method to implement the functionality of that application interface. Therefore, in this embodiment, the target code block can be located by searching for the method name associated with the application interface under test in the code block file to be tested.

[0120] As an example, if the application interface A specifies method a, then method a can be found in the code block file to be tested to locate the target code block.

[0121] Step S51: Locate the named code of the target code block according to the method name, and take the code between the named code and the end symbol of the target code block in the code block file to be tested as the target code block.

[0122] Specifically, after finding the method name, the naming code used to name the target code block can be located through the method name, that is, the code that names the method. At the same time, the end symbol of the target code block can also be found in each line of code through the method name.

[0123] Once the code with the given name and the code with the end symbol are found, all the code between them can be used as the target code block.

[0124] Step S42: The target code block is verified using a preset code block rule judgment algorithm, and the target code block is determined to have defects based on the verification results.

[0125] Specifically, the code block rule determination algorithm is an algorithm used to determine whether there are defects in the code.

[0126] In one exemplary implementation, the code block rule determination algorithm includes basic syntax rules and basic syntax specifications. The basic syntax rules are used to determine whether the syntax of the code is correct. For example, a code block symbol "{}" must appear in pairs, and only one of an if or else statement can have a return value. The basic syntax specifications are rules for determining whether the code conforms to standards. For example, for time formatting in code, it must be in the format of **year****month****day**, and for keywords that require uppercase letters, they must be uppercase and cannot be lowercase.

[0127] See Figure 6 The step of using a preset code block rule judgment algorithm to verify the target code block and determining whether the target code block has defects based on the verification results includes: step S60, verifying the target code block using the basic syntax rules and the basic syntax specifications respectively to obtain a first verification result and a second verification result; step S61, determining whether the target code block has defects based on the first verification result and the second verification result.

[0128] Specifically, in the process of defect detection of the target code block, the target code block needs to be verified by both basic syntax rules and basic syntax specifications. Only when both verifications pass can it be determined that the target code block is free of defects. When at least one of the verification results fails, it can be determined that the target code block is defective.

[0129] In this embodiment, after determining that the target code block has a defect, a defect report can also be generated and pushed to the relevant person.

[0130] It should be noted that in this embodiment, the target code block is validated as a string, that is, each piece of code in the target code block is validated as a string.

[0131] In one exemplary implementation, see Figure 7 To improve the comprehensiveness of defect detection, the method further includes:

[0132] Step S70: Select the line of code to be tested from the code block file to be tested according to the line number information; Step S71: Determine whether the line of code to be tested belongs to the line of code contained in the target code block; Step S72: If the line of code to be tested does not belong to the line of code contained in the target code block, then use the code block rule judgment algorithm to verify the line of code to be tested, and determine whether the line of code to be tested has defects based on the verification result.

[0133] Specifically, since the line number information records the specific line number of the modified code within the code block file under test, the modified lines of code under test can be filtered out based on this information. After obtaining the lines of code under test, it can be determined whether they belong to the target code block. If they do, since the lines of code under test have already been verified during the detection of the target code block, there is no need to verify them again. Only when the lines of code under test do not belong to the target code block do they need to be verified using the code block rule determination algorithm, and the verification result is used to determine whether the lines of code under test have defects.

[0134] Understandably, once a defect is detected, a defect report can be generated and sent to the relevant personnel.

[0135] See Figure 8 The diagram shown is a program module diagram of an embodiment of the defect detection device 80 in the source code file of this application.

[0136] In this embodiment, the source code file defect detection device 80 includes a series of computer program instructions stored in a memory. When these computer program instructions are executed by a processor, they can implement the source code file defect detection function of various embodiments of this application. In some embodiments, based on the specific operations implemented by each part of the computer program instructions, the source code file defect detection device 80 can be divided into one or more modules. Specifically, the modules that can be divided are as follows:

[0137] Module 81 is used to obtain the difference information between the source code file to be tested and the target source code file;

[0138] The determination module 82 is used to determine the application interface to be tested based on the difference information, wherein the application interface to be tested includes one or more.

[0139] Test module 83 is used to perform interface testing operations for each application interface under test and obtain test results;

[0140] The comparison module 84 is used to compare the test results with the expected results corresponding to the executed interface test operation, and determine whether the application interface under test has defects based on the comparison results.

[0141] In one exemplary embodiment, the difference information includes change file information and line number information of the change code in the change file. The determining module 82 is further configured to filter out application interface definition files from at least one change file based on the change file information; and determine the application interface to be tested based on the line number information and the application interface definition file.

[0142] In one exemplary embodiment, the determining module 82 is further configured to select, based on the changed file information, a changed file with a preset suffix from at least one changed file as the application interface definition file.

[0143] In one exemplary embodiment, the defect detection device 80 for the source code file further includes a generation module:

[0144] The generation module is used to generate a defect report when it is determined that there is a defect in the interface of the application under test, and to push the defect report to a preset user.

[0145] In one exemplary implementation, for each application interface under test, an interface testing operation is performed, and the test results include:

[0146] Obtain the input parameter information of the application interface under test, and generate a test case set corresponding to the input parameters contained in the application interface under test based on the input parameter information;

[0147] Generate a combined test case set for testing the target application interface under test, and the expected results corresponding to the combined test case set, based on the test case set corresponding to all the input parameters contained in the application interface under test.

[0148] The test results are obtained by performing test operations on the interface of the application under test according to the combined test case set.

[0149] In one exemplary implementation, the test case set includes a type validation set, a boundary validation set, and an exception validation set.

[0150] In one exemplary embodiment, the defect detection device 80 for the source code file further includes a filtering module and a verification module.

[0151] The determining module 82 is further configured to determine the code block file to be tested based on the difference information;

[0152] The filtering module is used to filter out target code blocks associated with each application interface under test from the code block file to be tested.

[0153] The verification module is used to verify the target code block using a preset code block rule judgment algorithm, and to determine whether the target code block has defects based on the verification result.

[0154] In one exemplary embodiment, the code block rule determination algorithm includes basic syntax rules and basic syntax specifications. The verification module is further configured to verify the target code block using the basic syntax rules and the basic syntax specifications respectively, to obtain a first verification result and a second verification result; and to determine whether the target code block has defects based on the first verification result and the second verification result.

[0155] In one exemplary embodiment, the filtering module is further configured to find the method name associated with each application interface under test from the code block file under test; locate the named code of the target code block according to the method name, and take the code between the named code in the code block file under test and the end symbol of the target code block as the target code block.

[0156] In one exemplary embodiment, the defect detection device 80 for the source code file further includes a judgment module.

[0157] The filtering module is further configured to filter out the lines of code to be tested that correspond to the line number information from the code block file to be tested;

[0158] The judgment module is used to determine whether the code line to be tested belongs to the code lines contained in the target code block;

[0159] The verification module is further configured to, if the line of code to be tested does not belong to the line of code contained in the target code block, use the code block rule judgment algorithm to verify the line of code to be tested, and determine whether the line of code to be tested has defects based on the verification result.

[0160] Figure 9 This illustration schematically depicts the hardware architecture of a computer device 9 suitable for implementing a defect discovery method for source code files according to an embodiment of this application. In this embodiment, the computer device 9 is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. For example, it may be a tablet computer, laptop computer, desktop computer, rack server, blade server, tower server, or cabinet server (including standalone servers or server clusters), etc. Figure 9 As shown, the computer device 9 includes, but is not limited to, a memory 120, a processor 121, and a network interface 122 that can communicate with each other via a system bus. Wherein:

[0161] The memory 120 includes at least one type of computer-readable storage medium, which can be volatile or non-volatile. Specifically, the readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 120 may be an internal storage module of the computer device 9, such as the hard disk or memory of the computer device 9. In other embodiments, the memory 120 may also be an external storage device of the computer device 9, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 9. Of course, the memory 120 may also include both the internal storage module and the external storage device of the computer device 9. In this embodiment, the memory 120 is typically used to store the operating system and various application software installed on the computer device 9, such as program code for defect detection methods in source code files. In addition, the memory 120 can also be used to temporarily store various types of data that have been output or will be output.

[0162] In some embodiments, processor 121 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other source code defect detection chip. Processor 121 is typically used to control the overall operation of computer device 9, such as performing control and processing related to data interaction or communication with computer device 9. In this embodiment, processor 121 is used to run program code stored in memory 120 or process data.

[0163] Network interface 122 may include a wireless network interface or a wired network interface, which is typically used to establish a communication link between computer device 9 and other computer devices. For example, network interface 122 is used to connect computer device 9 to an external terminal via a network, establishing a data transmission channel and communication link between computer device 9 and the external terminal. The network may be an intranet, the Internet, Global System for Mobile Communication (GSM), Wideband Code Division Multiple Access (WCDMA), 4G network, 5G network, Bluetooth, Wi-Fi, or other wireless or wired networks.

[0164] It should be pointed out that, Figure 9 Only computer devices with components 120 to 122 are shown; however, it should be understood that it is not required to implement all of the shown components, and more or fewer components may be implemented instead.

[0165] In this embodiment, the defect discovery method of the source code file stored in the memory 120 can be divided into a program module and executed by a processor (processor 121 in this embodiment) to complete this application.

[0166] This application provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the steps of the defect detection method for source code files in the embodiment.

[0167] In this embodiment, the computer-readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the computer-readable storage medium can be an internal storage unit of a computer device, such as the hard disk or memory of the computer device. In other embodiments, the computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device. Of course, the computer-readable storage medium can also include both the internal storage unit and the external storage device of the computer device. In this embodiment, the computer-readable storage medium is typically used to store the operating system and various application software installed on the computer device, such as the program code of the defect detection method in the source code file of the embodiment. In addition, the computer-readable storage medium can also be used to temporarily store various types of data that have been output or will be output.

[0168] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across at least two network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the embodiments of this application. Those skilled in the art can understand and implement this without any creative effort.

[0169] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software and a general-purpose hardware platform, or of course, using hardware. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0170] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method of defect finding of a source code file, characterized by, The method includes: Obtain the difference information between the source code file to be tested and the target source code file; The application interface to be tested is determined based on the difference information, and the application interface to be tested includes one or more. For each application interface under test, perform interface testing operations and obtain test results; The test results are compared with the expected results corresponding to the executed interface test operations, and the test results are used to determine whether the interface of the application under test has defects. The method further includes: The code block file to be tested is determined based on the difference information; Filter out the target code blocks associated with each of the application interfaces under test from the code block file to be tested; The target code block is verified using a preset code block rule judgment algorithm, and the presence of defects in the target code block is determined based on the verification results.

2. The method of claim 1, wherein, The difference information includes changed file information and line number information of the changed code in the changed file. Determining the application interface to be tested based on the difference information includes: Based on the changed file information, filter out the application interface definition file from at least one changed file; The application interface to be tested is determined based on the row number information and the application interface definition file.

3. The method of claim 2, wherein, The step of filtering application interface definition files from at least one change file based on the change file information includes: Based on the changed file information, a changed file with a preset file extension is selected from at least one changed file as the application interface definition file.

4. The method of claim 1, wherein, After the step of comparing the test results with the expected results corresponding to the executed interface test operation, and determining whether the application interface under test has defects based on the comparison results, the method further includes: When a defect is found in the interface of the application under test, a defect report is generated and pushed to a preset user.

5. The method of claim 1, wherein, For each API interface of the application under test, perform API testing operations and obtain the following test results: Obtain the input parameter information of the application interface under test, and generate a test case set corresponding to the input parameters contained in the application interface under test based on the input parameter information; Generate a combined test case set for testing the application interface under test, and the expected results corresponding to the combined test case set, based on the test case set corresponding to all the input parameters contained in the application interface under test. The test results are obtained by performing test operations on the interface of the application under test according to the combined test case set.

6. The method of claim 5, wherein, The test case set includes a type validation set, a boundary validation set, and an exception validation set.

7. The method for detecting defects in source code files according to claim 1, characterized in that, The code block rule determination algorithm includes basic syntax rules and basic syntax specifications. The step of using a preset code block rule determination algorithm to verify the target code block and determining whether the target code block has defects based on the verification results includes: The target code block is verified using the basic syntax rules and the basic syntax specifications respectively, to obtain a first verification result and a second verification result; The presence of defects in the target code block is determined based on the first verification result and the second verification result.

8. The method for detecting defects in source code files according to claim 1, characterized in that, The step of filtering out the target code blocks associated with each of the application interfaces under test from the code block files to be tested includes: Find the method name associated with each of the application interfaces under test from the code block file under test; The named code of the target code block is located according to the method name, and the code between the named code and the end symbol of the target code block in the code block file to be tested is taken as the target code block.

9. The method for detecting defects in source code files according to claim 2, characterized in that, The method further includes: Based on the line number information, filter out the lines of code to be tested from the code block file to be tested that correspond to the line number information; Determine whether the line of code to be tested belongs to the lines of code contained in the target code block; If the line of code to be tested does not belong to the line of code contained in the target code block, the code block rule judgment algorithm is used to verify the line of code to be tested, and the verification result is used to determine whether the line of code to be tested has a defect.

10. A defect detection device for source code files, characterized in that, The defect detection device for the source code file includes: The acquisition module is used to obtain the difference information between the source code file to be tested and the target source code file; A determination module is used to determine the application interface to be tested based on the difference information, wherein the application interface to be tested includes one or more; The testing module is used to perform interface testing operations for each application interface under test and obtain test results; The comparison module is used to compare the test results with the expected results corresponding to the executed interface test operations, and determine whether the application interface under test has defects based on the comparison results. This also includes: The code block file to be tested is determined based on the difference information; Filter out the target code blocks associated with each of the application interfaces under test from the code block file to be tested; The target code block is verified using a preset code block rule judgment algorithm, and the presence of defects in the target code block is determined based on the verification results.

11. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the method according to any one of claims 1 to 9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

13. A computer program product comprising computer instructions, characterized in that, When executed by a processor, the computer instructions implement the steps of the method according to any one of claims 1 to 9.

Images