Code cleaning method and device, equipment and medium

Abstract

The embodiment of the invention provides a code cleaning method and device, equipment and a medium. A specific embodiment of the method comprises the steps of running a target test case, obtaining metadata of a target class through reflection of the target class in byte codes called in the target test case, and determining a dependency relationship among members contained in the target class according to the metadata; on the basis of operation of the target test case, true values of members associated with the dependency relationship are determined; according to the true value, determining useless branches in a judgment structure included in the target class; and deleting the corresponding statement of the useless branch from the source code corresponding to the target class. Through the method, the real useless code can be identified more accurately by combining the byte code element data analysis result and the real operation value of the class member.

Description

Technical Field

[0001] The embodiments of the present disclosure relate to the field of code cleaning technology, and more particularly to a code cleaning method, apparatus, device, and medium. Background Art

[0002] Existing code cleaning solutions usually include dynamic code cleaning solutions and static code cleaning solutions. Among them, the dynamic code cleaning solution mainly determines the useless code in the code based on whether the various statements included in the code are executed during the actual operation of the code. The static code cleaning solution mainly performs code cleaning based on the results of grammatical analysis of the code statements without running the code. For example, the grammatical pattern is matched for the statements in the code, and the useless code therein is determined based on the matching results. However, the existing dynamic code cleaning solutions usually have the problem that it is usually impossible to traverse the branches that may take effect during the actual operation of the code, and thus it is difficult to accurately determine the useless code. The existing static code cleaning solutions often have the problem that in actual production scenarios, the writing style of the code development user is often difficult to completely match the code template, which limits the scope of application of the static code cleaning solution.

[0003] Therefore, a new approach to code cleanup is needed. Summary of the Invention

[0004] The embodiments of the present disclosure describe a code cleaning method, apparatus, device, and medium.

[0005] According to a first aspect, a code cleaning method is provided, comprising:

[0006] Running a target test case, obtaining metadata of the target class by reflecting a target class in a target bytecode called in the target test case, and determining dependencies between members included in the target class based on the metadata; and determining true values ​​of the members associated with the dependencies based on the running of the target test case;

[0007] Determine useless branches in the target class according to the true value; and delete statements corresponding to the useless branches from source code corresponding to the target class.

[0008] According to a second aspect, a code cleaning device is provided, comprising:

[0009] The running unit is configured to run a target test case, obtain metadata of the target class by reflecting a target class in a target bytecode called in the target test case, determine dependencies between members included in the target class based on the metadata, and determine true values ​​of the members associated with the dependencies based on the running of the target test case;

[0010] The cleaning unit is configured to determine, based on the true value, useless branches in the judgment structure included in the target class; and delete statements corresponding to the useless branches from the source code corresponding to the target class.

[0011] According to a third aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to execute the method of the first aspect.

[0012] According to a fourth aspect, an electronic device is provided, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method of the first aspect is implemented.

[0013] According to an embodiment of the present disclosure, a code cleaning method, apparatus, device, and medium are provided. First, a target test case can be run, and metadata of the target class can be obtained by reflecting the target class in the target bytecode called in the target test case. The dependency relationship between the members included in the target class is determined based on the metadata; based on the running of the target test case, the true value of the member associated with the dependency relationship is determined. Then, based on the true value, the useless branches in the judgment structure included in the target class are determined; and the corresponding statements of the useless branches are deleted from the source code corresponding to the target class. Through this method, the bytecode metadata analysis results and the true running values ​​of the class members can be combined to more accurately identify the real useless code. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 A schematic diagram of a static code cleaning solution is shown;

[0015] Figure 2 A schematic diagram of a dynamic code cleanup solution is shown;

[0016] Figure 3 A schematic diagram of a code cleaning method according to an embodiment of the present disclosure is shown;

[0017] Figure 4 A schematic diagram of a code cleaning method according to an embodiment of the present disclosure is shown;

[0018] Figure 5 A schematic diagram showing metadata of a class according to an embodiment of the present disclosure is shown;

[0019] Figure 6 A schematic diagram of a class member dependency diagram according to an embodiment of the present disclosure is shown;

[0020] Figure 7 A schematic block diagram of a code cleaning device according to an embodiment of the present disclosure is shown;

[0021] Figure 8 A schematic structural diagram of an electronic device suitable for implementing the embodiments of the present disclosure is shown;

[0022] Figure 9 A schematic diagram of the structure of a storage medium suitable for implementing the embodiments of the present disclosure is shown. DETAILED DESCRIPTION

[0023] The technical solutions provided in this specification are further described in detail below in conjunction with the accompanying drawings and embodiments. It will be understood that the specific embodiments described herein are merely for explaining the relevant inventions and are not intended to limit the inventions. It should also be noted that, for ease of description, only the portions relevant to the relevant inventions are shown in the accompanying drawings. It should be noted that, unless there is a conflict, the embodiments of the present disclosure and the features therein may be combined with each other.

[0024] In the description of the implementations of the present disclosure, the term "including" and similar terms should be understood as open inclusion, i.e., "including but not limited to." The term "based on" should be understood as "based at least in part on." The term "one / an implementation" or "the implementation" should be understood as "at least one / an implementation." The term "some implementations" should be understood as "at least some implementations." Other explicit and implicit definitions may be included below.

[0025] As mentioned above, existing code cleaning solutions generally include dynamic code cleaning solutions and static code cleaning solutions. Among them, the static code cleaning solution mainly cleans the code based on the results of grammatical analysis of code statements without running the code. For example, the syntax pattern of the statements in the code is matched, and the useless code is determined based on the matching results. The dynamic code cleaning solution mainly determines the useless code in the code based on whether the various statements included in the code are executed during the actual running of the code. For example, Figure 1 A schematic diagram of a static code cleaning solution is shown. Figure 1As shown, the code to be tested can be converted into an abstract syntax tree. Then, according to pre-configured syntax rules, it is matched with the syntax tree. According to the matching results, the syntax elements in the syntax tree are replaced. Then, based on the syntax tree after the element replacement, the cleaned code is generated, that is, the updated code after the useless code is removed from the code to be tested. However, the problem with this solution is that, on the one hand, in actual production scenarios, the pre-configured syntax rules are often difficult to fully match the writing styles of different code developers, and code with different writing styles is not necessarily useless code, which limits the scope of application of static code cleaning solutions. On the other hand, static code cleaning solutions usually rely on source code analysis. For example, the analysis of source code of different language types often relies on different pre-work such as header file inclusion or code module import, project structure adaptation, etc., making it difficult to perform universal code cleaning. Thirdly, because static code cleaning solutions do not rely on code execution but only on code structure analysis, not only does the analysis process have high computational complexity, but it is also prone to the problem that the analysis results (for example, the class member values ​​used to determine branch execution) are inconsistent with the actual operation.

[0026] For example, an existing dynamic code cleaning solution runs the code being tested and inserts additional statements after the execution statements of each conditional branch in the judgment structure to detect whether these execution statements are actually executed. The advantage of this solution is that it can perform code proxy based on the actual running status of the code. Figure 2 A schematic diagram of a dynamic code cleaning solution is shown, Figure 2 As shown, for example, the code under test includes an if statement. Additional statements can be added after the execution statements of each conditional branch of the statement. For example, after the execution statement logic1 for the a=1 conditional branch, add the execution statement log.("1 branch executed"); after the execution statement logic2 for the a=2 conditional branch, add the execution statement log.("2 branch executed"). This detects and records whether logic1 and logic2 are executed. Based on these records, the unused code that was not covered during execution can then be determined. However, this approach has a drawback: in actual production scenarios, many statements in the executed code, while not executed, are still useful code that cannot be deleted. For example, some code may only be executed under specific time conditions (e.g., on certain holidays). This code will not be covered during execution at other times, but it is actually impossible to delete. Especially for large-scale software, due to the high complexity of the execution conditions of the code statements included, code cleanup using this dynamic cleanup approach is often difficult.

[0027] In order to solve the above technical problems, an embodiment of the present disclosure provides a code cleaning method. Figure 3 FIG. 1 shows a schematic diagram of a code cleaning method according to an embodiment of the present disclosure. Figure 3 As shown, in some embodiments, for example, a test case can be run, and reflection can be performed on the target class in the bytecode called during execution to obtain metadata for the target class. The dependencies between the members of the target class can then be determined based on the metadata. Furthermore, based on the execution of the target test case, the true values ​​of the class members associated with the dependencies can be determined. Furthermore, based on the true values ​​of the obtained class members, useless branches in the judgment structure of the target class can be determined. Alternatively, the target class metadata can be used to obtain the storage path of the source code corresponding to the target class, and the corresponding statements of the useless branches can be deleted from the source code. This method has the advantages of: first, analyzing the class metadata during code execution to obtain the member dependencies of the calling class. Furthermore, through actual code execution, the true values ​​of each member in the member dependencies can be obtained. Furthermore, based on these true values, useless branches in the code can be determined. In other words, this method obtains the class member dependencies typically obtained through static code analysis during code execution. Furthermore, the true values ​​of the members in the class member dependencies obtained during code execution can be used to determine useless branches. Compared to conventional static code cleanup solutions that rely solely on code analysis, this method determines unused branches based on the actual member values ​​within class member dependencies during execution, resulting in a more accurate identification of truly unused code. Compared to conventional dynamic code cleanup solutions that rely solely on code execution, this method uses class member dependencies as a basis to determine the associated member values, allowing for accurate location and acquisition of critical member values ​​that determine the outcome. This is a performance unattainable by dynamic code cleanup solutions that don't analyze dependencies. Furthermore, this solution also offers a level of accuracy in determining unused code that conventional dynamic code cleanup solutions cannot achieve. Furthermore, because class member dependencies are derived from metadata obtained by reflecting on the called classes during test case execution, conventional static code analysis, such as header file inclusion, module import, and project structure adaptation, is unnecessary. Therefore, compared to conventional static code cleanup solutions, this method provides a simpler and more versatile code cleanup solution. Thirdly, compared to conventional static code cleanup solutions, the actual member values ​​can be obtained based on code execution, eliminating the need for complex analysis to obtain predicted values. Therefore, not only are the code cleanup results more accurate, but the execution process is also more convenient and more efficient.

[0028] The detailed process of this method is further described below.

[0029] Figure 4FIG. 1 shows a flow chart of a code cleaning method according to an embodiment of the present disclosure. Figure 4 As shown, the method comprises at least the following steps:

[0030] Step S401: Run a target test case, obtain metadata of the target class by reflecting the target class in the target bytecode called in the target test case, determine dependencies between members included in the target class based on the metadata, and determine the true values ​​of the members associated with the dependencies based on the execution of the target test case.

[0031] Step S403: determining useless branches in the judgment structure included in the target class according to the true value; and deleting statements corresponding to the useless branches from the source code corresponding to the target class.

[0032] First, in step S401, a target test case is run. Metadata for the target class is obtained by reflecting on the target class in the target bytecode called in the target test case. Dependencies between members of the target class are determined based on the metadata. In this step, a test case (e.g., the target test case) can be run and the target class in the bytecode called in the test case can be reflected on to obtain metadata for the target class.

[0033] A test case refers to a test task performed on a specific program (such as a target program) to verify whether the target program meets specific test expectations. In different embodiments, the target program targeted by the target program may be a program for different specific businesses or purposes, and this specification does not limit this. In different embodiments, the test case may also be a test case of different specific types. For example, in one embodiment, the target test case may include one or more of: a unit test case, a functional test case, and a control experiment test case.

[0034] The target bytecode may be the bytecode of the target program targeted by the target test case. Bytecode is an intermediate code that is converted from the source code during the compilation process. It is usually more abstract than the source code and can therefore be more easily optimized and converted. Bytecode provides a platform-independent code representation so that the code can run on different platforms without recompilation. Class members refer to elements in a class, such as data members (variables or properties) and member functions (methods). Therefore, in one embodiment, the members contained in the target class may include: one or more of the variables, methods, and properties included in the target class.

[0035] Reflection is a technology that interacts with classes or objects at runtime. Through reflection, the metadata of a class can be dynamically obtained at runtime. In different embodiments, the reflection of the target class in the bytecode called in the target test case can be achieved in different specific ways. In one embodiment, it can be based on the bytecode control framework ASM, and the target class in the bytecode corresponding to the target code called in the target test case is reflected. The metadata of a class refers to the data that describes the class. As mentioned above, the metadata of a class can be obtained through reflection. In different specific embodiments, the specific information included in the metadata can be different. Figure 5 Schematic diagram of metadata of a class according to an embodiment of the present disclosure is shown. Figure 5 In the example shown, the obtained metadata of the class may include, for example, methods and properties included in the class, calls between methods or properties, and the loading path of the class.

[0036] According to the metadata, the dependency relationships between the members contained in the target class can be determined. Specifically, the dependency relationships between the members of the class can be determined based on the calls between them. In one embodiment, the metadata of multiple target classes can also be obtained by reflecting the multiple target classes (classes) in the target bytecode called in the target test case. Furthermore, according to the metadata of the multiple target classes, the dependency relationships between the members of the same target class in the multiple target classes, as well as the dependency relationships between the members of different target classes in the multiple target classes are determined. In different specific embodiments, depending on the different target test cases, the multiple target classes in the target bytecode called in the target test case can be different specific classes, and this specification does not limit this. In the above manner, it is convenient to identify the member dependencies within the target class in the target bytecode, as well as the member dependencies between the target classes, thereby forming a complete dependency relationship of the target class members.

[0037] In one example, a class member dependency graph can be used to represent the complete dependency relationships of target class members, wherein nodes represent class members and directed edges between nodes represent the dependency relationships between members. Figure 6 A schematic diagram of a class member dependency diagram according to an embodiment of the present disclosure is shown. Figure 6As shown, for example, during the execution of the target test case, classes C1, C2, and C3 are called directly or indirectly (through the call of an intermediate class). Node F represents the return value of method F2 of class C2, and the execution of F2 calls attribute A2 (node ​​D) of class C2. Therefore, node F depends on node D, or in other words, the value of node F depends on the value of node D. In addition, the calculation of attribute A2 calls the return value of method F1 of class C2 (node ​​A) and attribute A1 of class C1 (node ​​B). Therefore, node D depends on nodes A and B. Similarly, node C (the return value of method F4 of class C1) depends on node E (the return value of method F3 of class C3), and node E depends on node C (attribute A3 of class C3).

[0038] After determining the dependencies between the members contained in the target class, the true values ​​of the class members associated with the dependencies can be determined based on the execution of the target test case. Specifically, during the execution of the target test case, the actual values ​​of the various class members with dependencies in the classes directly or indirectly called by the test case can be read. For method members, the return value of the method can be used as the member value. Therefore, in one embodiment, the true value of the member associated with the dependency can include: the return value of the method. For example, Figure 6 In the example shown, during the execution of the target test case, the values ​​of the members represented by each node can be read after the member is called. This method allows you to easily obtain the actual values ​​of class members associated with dependencies without complex code analysis.

[0039] In one embodiment, a target operating environment can be constructed by an environment simulator; based on the operation of the target test case under the target operating environment, the true value of the member associated with the dependency is determined. In different embodiments, environment simulators in different specific software or hardware forms can be used. In different specific embodiments, the specific method of constructing the target operating environment can also be different. In a specific embodiment, one or more of a simulated network environment, a simulated storage environment, an environment input value or environment configuration value for the target test case, and an updated value of the member associated with the dependency can be constructed. In the above manner, by simulating the real operating environment under different scenarios, the true value of the class member in the execution of the target test case under the real operating environment under various different scenarios can be more accurately obtained. Furthermore, in subsequent steps, useless code can be identified more accurately based on the true value of the class member under various different scenarios.

[0040] Then, in step S403, the useless branches in the judgment structure included in the target class can be determined based on the true value of the class member obtained in step S401. In different embodiments, the specific form of the judgment structure included in the target class may be different. In one embodiment, for example, it may include one or more of an If judgment structure, a switch judgment structure, and a case judgment structure. In different embodiments, the specific calculation method of the judgment structure based on the class member value to determine which branch is executed, and the specific class member value used to determine which branch is executed may be different, and this specification does not limit this. In one example, for example Figure 6 As shown, the attribute A2(D) in the class member dependency is used in the If judgment structure to determine which if branch or branches are executed. Thus, the useful branches and useless branches in the if branch can be determined based on the true value of the attribute A2 obtained in step S401.

[0041] In different embodiments, the specific method of determining useless branches may also be different. In one embodiment, an abstract syntax tree corresponding to the target class can be generated based on the source code corresponding to the target class; based on the true value and the abstract syntax tree (AST), the useless branches in the judgment structure included in the target class are determined. Specifically, for example, the source code can be converted into an abstract syntax tree, and then the syntax nodes corresponding to the above-mentioned useless branches in the abstract syntax tree are determined based on the true value. In one embodiment, the source code corresponding to the target class can be obtained in the following manner: based on the metadata of the target class, the loading path of the target class is determined; based on the loading path of the target class and the preset correspondence between the loading path of the target class and the saving path of the source code of the target class, the saving path of the source code of the target class is obtained; based on the saving path, the source code is obtained. In the above manner, useless branches can be quickly determined based on the abstract syntax tree.

[0042] As described above, in different embodiments, the specific form of the judgment structure and the true value of the member used for judgment may be different. Furthermore, in different embodiments, the specific useless branches determined may also be different, and this specification does not limit this.

[0043] After determining the useless branch, the corresponding statement of the useless branch can be deleted from the source code corresponding to the target class. In different embodiments, the specific method of deleting the corresponding statement of the useless branch may be different. In a specific embodiment, after determining the syntax node corresponding to the useless branch through the abstract syntax tree, the syntax node can be deleted from the abstract syntax tree, and an updated source code can be generated based on the abstract syntax tree after deleting the syntax node corresponding to the useless branch. The effect is to delete the corresponding statement of the useless branch from the original source code. In the above manner, the corresponding statement of the useless branch can be efficiently deleted from the source code based on the abstract syntax tree.

[0044] Figure 7 A schematic block diagram of a code cleaning device according to an embodiment of the present disclosure is shown. The device is used to perform the following Figure 4 As shown in the method. Figure 7 As shown, the apparatus 700 includes:

[0045] The running unit 701 is configured to run a target test case, obtain metadata of the target class by reflecting the target class in the target bytecode called in the target test case, determine dependencies between members included in the target class based on the metadata, and determine the true values ​​of the members associated with the dependencies based on the running of the target test case.

[0046] The cleaning unit 702 is configured to determine, according to the true value, useless branches in the judgment structure included in the target class; and delete statements corresponding to the useless branches from the source code corresponding to the target class.

[0047] The embodiment of the present disclosure also provides an electronic device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the following is achieved: Figure 4 The method shown.

[0048] You can also refer to the following Figure 8 , which shows a structural diagram of an electronic device 800 suitable for implementing an embodiment of the present application. Figure 8 The electronic device 800 shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0049] like Figure 8As shown, the electronic device 800 may include a processing device (such as a central processing unit, a graphics processing unit, etc.) 801. The above-mentioned processing device 801 can be a general-purpose processor, a digital signal processor (DSP), a microprocessor or a microcontroller, and may further include an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 802 or the program loaded from the storage device 808 into the random access memory (RAM) 803. In RAM803, various programs and data required for the operation of the electronic device 800 are also stored. The processing device 801, ROM802 and RAM803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0050] Typically, the following devices may be connected to the I / O interface 805: an input device 806 including, for example, a touch screen, a touchpad, a keyboard, a mouse, etc.; an output device 807 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 808 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 809. The communication device 809 may allow the electronic device 800 to communicate with other devices wirelessly or by wire to exchange data. Figure 8 The electronic device 800 is shown with various devices, but it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed instead. Figure 8 Each block shown in the figure may represent one device, or may represent multiple devices as needed.

[0051] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network via the communication device 809, or installed from the storage device 808, or installed from the ROM 802. When the computer program is executed by the processing device 801, the above-mentioned functions defined in the code cleaning method provided in the embodiment of the present application are executed.

[0052] The present disclosure also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the following steps provided in the present disclosure: Figure 4 The code cleanup method shown in . Figure 9 A schematic diagram of a storage medium for implementing an embodiment of the present application. Figure 8 As shown, the storage medium 900 can be a non-transitory computer-readable storage medium for storing non-transitory computer-executable instructions 901. When the non-transitory computer-executable instructions 901 are executed by the processor, the code cleaning method provided in the embodiment of the present application can be implemented. For example, when the non-transitory computer-executable instructions 901 are executed by the processor, one or more steps in the code cleaning method provided in the embodiment of the present application can be executed. For example, the storage medium 900 can be applied to the above-mentioned electronic device. For example, the storage medium 900 may include a memory in the electronic device. For the description of the storage medium 900, reference can be made to the description of the memory in the embodiment of the electronic device, and the repeated parts will not be repeated here. The specific functions and technical effects of the storage medium 900 can be referred to the description of the code cleaning method provided in the embodiment of the present application, and will not be repeated here.

[0053] It should be noted that the computer-readable medium of the embodiments of the present disclosure may be a computer-readable signal medium or a computer-readable storage medium or any combination of the two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or component, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a memory card of a smart phone, a storage component of a tablet computer, a portable computer disk, a hard disk of a personal computer, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the embodiments of the present disclosure, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or device. In the embodiments of the present disclosure, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries a computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any suitable medium, including but not limited to wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0054] The computer-readable medium may be included in the electronic device, or may exist independently without being incorporated into the electronic device. The computer-readable medium carries one or more programs, and when the one or more programs are executed by the server, the electronic device implements the code cleaning method provided in the embodiments of the present application.

[0055] Computer program code for performing the operations of the embodiments of the present disclosure may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0056] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of the systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the boxes may occur in an order different from that marked in the accompanying drawings. For example, two boxes shown in succession may actually be executed substantially in parallel, or they may sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, as well as the combination of boxes in the block diagram and / or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or may be implemented using a combination of dedicated hardware and computer instructions. The units involved in the embodiments described in the present disclosure may be implemented using software or hardware. The name of the unit does not, in some cases, constitute a limitation on the unit itself. The functions described above in this document may be performed at least in part by one or more hardware logic components. For example, and without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on a chip (SOCs), complex programmable logic devices (CPLDs), and the like.

[0057] The various embodiments in this specification are described in a progressive manner. Similar portions between the various embodiments can be referenced to each other, and each embodiment focuses on the differences between the other embodiments. In particular, the storage medium and computing device embodiments are described briefly because they are generally similar to the method embodiments. For relevant portions, refer to the description of the method embodiments.

[0058] The above description is only a preferred embodiment of the present disclosure and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present disclosure is not limited to the technical solutions formed by the specific combination of the above-mentioned technical features, but should also cover other technical solutions formed by any combination of the above-mentioned technical features or their equivalent features without departing from the above-mentioned disclosed concepts. For example, the above-mentioned features are replaced with (but not limited to) technical features with similar functions disclosed in the present disclosure to form a technical solution. In addition, although the operations are described in a specific order, this should not be understood as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Certain features described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination.

[0059] The above specific implementation methods further describe in detail the purpose, technical solutions and beneficial effects of the embodiments of the present invention. Although the subject matter has been described in a language specific to structural features and / or method logical actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. On the contrary, the specific features and actions described above are merely example forms of implementing the claims. It should be understood that the above are only specific implementation methods of the embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made on the basis of the technical solution of the present invention should be included in the scope of protection of the present invention.

Claims

1. A code cleaning method, comprising: Running a target test case, obtaining metadata of the target class by reflecting a target class in a target bytecode called in the target test case, and determining dependencies between members of the target class based on the metadata; Determining the true value of the member associated with the dependency relationship based on the execution of the target test case; Determining, based on the true value, useless branches in the judgment structure included in the target class; Delete the corresponding statements of the useless branches from the source code corresponding to the target class.

2. The method according to claim 1, wherein Determining, according to the true value, useless branches in the judgment structure included in the target class, comprising: Generate an abstract syntax tree corresponding to the target class according to the source code corresponding to the target class; Determine useless branches in the judgment structure included in the target class according to the true value and the abstract syntax tree.

3. The method according to claim 1, wherein Reflection of the target class in the bytecode called in the target test case, including: Based on the bytecode control framework ASM, the target class in the bytecode corresponding to the target code called in the target test case is reflected.

4. The method according to claim 1, wherein The members included in the target class include: one or more of the variables, methods, and properties included in the target class; The actual value of the member associated with the dependency relationship includes: the return value of the method.

5. The method according to claim 1, wherein Obtaining metadata of the target class by reflecting the target class in the target bytecode called in the target test case, including: Obtaining metadata of the multiple target classes by reflecting the multiple target classes in the bytecode called in the target test case; Determining dependencies between members included in the target class according to the metadata includes: Dependencies between members of the same target class in the multiple target classes and dependencies between members of different target classes in the multiple target classes are determined based on the metadata of the multiple target classes.

6. The method according to claim 1, wherein The source code of the target class is obtained by: Determining a loading path for the target class according to the metadata of the target class; Obtaining a saving path of the source code of the target class according to the loading path of the target class and a preset correspondence between the loading path of the target class and the saving path of the source code of the target class; The source code is obtained according to the saving path.

7. The method according to claim 1, wherein Determining the true value of the member associated with the dependency relationship based on the execution of the target test case includes: Build the target operating environment through the environment simulator; Based on the execution of the target test case in the target execution environment, a true value of the member associated with the dependency is determined.

8. The method according to claim 1, wherein Build the target operating environment, including: Construct one or more of a simulated network environment, a simulated storage environment, an environment input value or an environment configuration value for the target test case, and an updated value of the member associated with the dependency relationship.

9. The method according to claim 1, wherein: The target test cases include: one or more of unit test cases, functional test cases, and control experiment test cases.

10. A testing device for a mini-program, comprising: The running unit is configured to run a target test case, obtain metadata of the target class by reflecting the target class in the target bytecode called in the target test case, and determine dependencies between members included in the target class based on the metadata; Determining the true value of the member associated with the dependency relationship based on the execution of the target test case; a cleaning unit configured to determine, based on the true value, useless branches in the judgment structure included in the target class; Delete the corresponding statements of the useless branches from the source code corresponding to the target class.

11. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to any one of claims 1 to 9.

12. An electronic device comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 9 is implemented.

Images