Black box code analysis and test case generation method and device and storage medium

Abstract

The invention relates to a black box code analysis and test case generation method and device and a storage medium, which are applied to the technical field of software testing, and the method comprises the following steps: transparentizing an originally invisible internal logic state by non-intrusively obtaining a variable change track and an execution path in a black box code; therefore, testers can accurately position intermediate logic errors, and the problem that the internal state cannot be observed in a traditional black box test is solved. And secondly, by systematically restoring the logic structure and the execution path of the code, the uncovered logic branches can be accurately identified, and the complementary test case can be intelligently and reversely deduced and generated, so that the defects that the traditional black box test depends on experience and is incomplete in coverage are overcome, and the test depth and efficiency are remarkably improved. And thirdly, a system tracking interface is adopted for monitoring, byte codes of target codes do not need to be modified, and the possible influence of an intrusive method on the program performance and stability is avoided.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software testing, in particular to a black box code analysis and test case generation method and device and storage medium. BACKGROUND

[0002] In the process of software development and maintenance, black box testing is an important testing method for verifying the correctness of the function of a program only through its input and output. However, for a program that has been compiled and has no source code, such as a compiled file of Python language, such traditional black box testing method has significant limitations. Testers cannot observe the internal state of the program during runtime, such as the change of variable value, function call flow and execution of conditional branch. This makes it difficult to locate the specific intermediate logic link once an error occurs in the program; at the same time, the design of test cases depends heavily on the experience of testers, and it is difficult to systematically ensure effective coverage of the internal complex logic and boundary conditions of the program. SUMMARY

[0003] Therefore, the purpose of the present application is to provide a black box code analysis and test case generation method and device and storage medium, which aims to solve the technical problem that the prior art cannot effectively obtain the internal variable change trajectory and runtime logic structure of the compiled black box code without invading the target code and significantly affecting its performance, thereby causing blind test case design, difficulty in locating intermediate logic errors and inability to guarantee test coverage.

[0004] According to a first aspect of an embodiment of the present application, a black box code analysis and test case generation method is provided, the method comprising: registering a trace function through a preset sys.settrace interface, non-invasively monitoring the execution process of the black box code through the trace function, the trace function being called when a preset event is triggered, and used to obtain variable information of the related preset event; establishing a variable trajectory mapping relationship according to the change of variable values of different variable names in the variable information of the related preset event along with the execution time sequence and the corresponding bytecode offset; associating the variable trajectory mapping relationship to the pre-acquired black box pseudo code line through the instruction mapping function of a preset decompilation tool, to realize understandable display of the variable trajectory; obtaining variable boundary values according to the distribution of variable values in the variable trajectory and the branch paths in the pre-acquired black box pseudo code line; for a branch path that has not been covered, reversely deducing the input variable combination that triggers the execution of the path according to the variable boundary values and the variable trajectory, and generating a supplementary test case based on the input variable combination.

[0005] Preferably, The tracking function is called when a preset event is triggered, and variable information of the relevant preset event is obtained. When a preset event is triggered, the tracking function extracts runtime context data from the current execution stack frame, and the context data includes local variables, global variables, and variable type information.

[0006] Preferably, The preset event at least includes: function call event, code line execution event and function return event.

[0007] Preferably, it also includes: The tracking configuration is configured by setting a decorator at the target function call entry, and the extracted variable information of the relevant preset event is filtered through the tracking configuration to reduce redundant information and optimize tracking performance. The tracking configuration includes rules for filtering by at least one of variable scope, data type, or specified key variable name.

[0008] Preferably, The acquisition of the black box pseudo code line includes: The function call event and the function return event obtained by the tracking function record the function call relationship; According to the function call relationship and the entry function of the target function marked by the decorator, a function call tree is generated; According to the execution selection result of the conditional judgment, a path fingerprint is generated, which represents an identified branch path; by comparing the path fingerprint sets generated when executing test cases corresponding to different inputs, an uncovered branch path is identified, and all identified branch paths are obtained. The function call tree and all identified branch paths are converted into a visual structure of AST, and the pseudo code line of the black box is obtained.

[0009] Preferably, it also includes: When the compiled code of the current black box changes due to version update, the branch path tracking is retriggered, and the visual structure corresponding to the updated black box is obtained.

[0010] Preferably, it also includes: For the updated black box code, a new version of visual structure is generated; Compare the visual structure views of the new and old versions to identify structural differences; And according to the structural differences, new supplementary test cases are generated.

[0011] Preferably, it also includes: The decorator is used to automatically check whether the tracked variable value is consistent with the preset variable value during execution of the test case, thereby verifying the intermediate logic.

[0012] According to a second aspect of the embodiments of the present application, a black-box code analysis and test case generation device is provided, and the device comprises: The variable information acquisition module is configured to register a tracking function through a preset sys.settrace interface, perform non-invasive monitoring on the execution process of the black-box code through the tracking function, and call the tracking function when a preset event is triggered to acquire variable information of the related preset event. The variable trajectory acquisition module is configured to establish a variable trajectory mapping relationship according to the variable values of different variable names and the corresponding bytecode offsets in the variable information of the related preset event. The variable trajectory correlation module is configured to correlate the variable trajectory mapping relationship to the pre-acquired black-box pseudo code lines through an instruction mapping function of a preset decompilation tool, and realize understandable display of the variable trajectory. The variable boundary value acquisition module is configured to acquire variable boundary values according to the distribution of the variable values in the variable trajectory and the branch paths in the pre-acquired black-box pseudo code lines. The test case generation module is configured to, for a branch path that has not been covered, reversely deduce an input variable combination that triggers execution of the path according to the variable boundary values and the variable trajectory, and generate a supplementary test case based on the input variable combination.

[0013] According to a third aspect of the embodiments of the present application, a storage medium is provided, and the storage medium stores a computer program.

[0014] The technical solution provided by the embodiments of the present application can have the following beneficial effects: The present application can transparently make the internal logic state visible by non-invasively acquiring the variable change trajectory and execution path inside the black-box code, so that the tester can accurately locate the intermediate logic error, and solve the problem that the internal state cannot be observed in the traditional black-box test. Secondly, the present application can accurately identify the uncovered logic branch by systematically restoring the logic structure and execution path of the code, and intelligently reversely deduce and generate a supplementary test case, thereby overcoming the shortcomings of the traditional black-box test, such as dependence on experience and incomplete coverage, and significantly improving the depth and efficiency of the test. Thirdly, the present application uses a system tracking interface for monitoring, does not need to modify the bytecode of the target code, avoids the influence of the invasive method on the performance and stability of the program, and combines the configurable tracking granularity control to effectively reduce the performance loss caused by redundant tracking.

[0015] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application, as claimed. BRIEF DESCRIPTION OF DRAWINGS

[0016] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and serve to explain the principles of the application.

[0017] Figure 1 is a flowchart of a black box code analysis and test case generation method according to an exemplary embodiment; Figure 2 is a system diagram of a black box code analysis and test case generation device according to another exemplary embodiment; In the drawings: 1 - variable information acquisition module, 2 - variable trajectory acquisition module, 3 - variable trajectory association module, 4 - variable boundary value acquisition module, 5 - test case generation module. DETAILED DESCRIPTION

[0018] The exemplary embodiments will be described in detail herein with reference to the attached drawings; figures, wherein like reference numerals refer to like elements throughout. The following detailed description is made in connection with the accompanying drawings. Like reference numerals identify like elements throughout the description. The following description is presented for the purpose of describing exemplary embodiments consistent with the present application, and is not intended to limit the scope of the application, as claimed.

[0019] Embodiment One Figure 1 is a flowchart of a black box code analysis and test case generation method according to an exemplary embodiment, as shown in Figure 1 the method comprises: S1, registering a trace function through a preset sys.settrace interface, non-invasively monitoring the execution process of the black box code through the trace function, the trace function being called at a preset event trigger, and being used to acquire variable information of the related preset event; S2, establishing a variable trajectory mapping relationship according to the variable values of different variable names in the variable information of the related preset event and the corresponding bytecode offsets along with the execution time sequence; S3, associating the variable trajectory mapping relationship to the pre-acquired black box pseudo code lines through the instruction mapping function of a preset decompilation tool, and realizing understandable display of the variable trajectory; S4, acquiring variable boundary values according to the distribution of the variable values in the variable trajectory and the branch paths in the pre-acquired black box pseudo code lines; S5, for a branch path that has not been covered, reversely deducing an input variable combination triggering execution of the path according to the variable boundary value and the variable trajectory, and generating a supplementary test case based on the input variable combination; It can be understood that the compiled Python code (such as.pyc) cannot obtain variable information through source code analysis, and traditional black box testing can only observe input and output. In this embodiment, the underlying tracing capability of sys.settrace is used to realize the full-process tracking of variables from definition, assignment to destruction without modifying the target code bytecode. Specifically, it includes: By registering a tracing function through sys.settrace, when events such as call (function call), line (line execution), return (return) of code execution are triggered, the local variables (f_locals) in the current stack frame (frame object), global variables (f_globals) and variable type information are extracted through the tracing function; Wherein, frame represents the current execution stack frame (stack frame), which contains the context information of the executed code, such as the current function name, line number, etc. Local variables and their values: By accessing the local variable set in the execution stack frame object (for example, frame.f_locals in CPython), a dictionary containing all local variable names and their current values in the current scope can be obtained.

[0020] Global variables and their values: Similarly, by accessing the global variable set in the execution stack frame object (for example, frame.f_globals), the variable state in the global scope can be obtained.

[0021] Bytecode offset: By accessing the current bytecode offset recorded in the execution stack frame object (for example, frame.f_lasti), an integer that accurately points to the location of the executing bytecode instruction in the function code object can be obtained.

[0022] According to the variable values of different variable names in the variable information of different preset events (call, line, return) obtained above and their corresponding bytecode offsets, a variable trajectory mapping relationship is established, which is represented as variable name - value change - bytecode offset. For example, in the tracking of def func(a): b = a*2;return b, the input value of a is associated with the intermediate value of b at the bytecode level. In view of the problem that.pyc files have no source line numbers, by mapping the bytecode offset (f_lasti) and the instruction of the decompilation tool (such as uncompyle6), the variable trajectory is associated with the equivalent "pseudo code line", so that the variable trajectory can be displayed. It is worth emphasizing that the above "pseudo-code line" acquisition includes: The call and return events obtained by the trace function registered by sys.settrace record the function call relationship (such as A() → B() → C()), combined with the entry function marked by the decorator (such as @trace_entry), to generate a function call tree; The execution results of conditional judgments (such as if x>0) (entering if or else branch) generate "path fingerprints" (such as 0→1→0 representing the selection results of three branch judgments); through the comparison of fingerprints of multiple test cases, identify the uncovered branches, which specifically include: During execution, whenever a conditional branch instruction (such as POP_JUMP_IF_FALSE) is encountered, the trace function will record the actual jump selection (i.e. the result of the conditional judgment is true or false). For a complete execution, all the conditional branches and their selections constitute a unique execution path. In order to identify the path, a unique path fingerprint can be generated according to the branch identifier and the selection result sequence, for example, the bytecode offset of the branch and the boolean selection result are serialized and the hash value is calculated. For the execution of target_func(200), since x>100 is true, a path fingerprint representing the "if branch" (called "Path-A") will be generated and stored in the set of covered paths; Through static analysis of the pseudo code, all possible branch paths in the target function are identified, in the example of target_func, there are if path and else path two paths, then all known paths are compared with the recorded covered path fingerprint set, after the initial execution of target_func(200), only "Path-A" is in the set, therefore, the path corresponding to the else branch (called "Path-B") has not been covered can be identified; Convert the function call tree and all identified branch paths into a visual structure of AST (Abstract Syntax Tree), for example: func_A() ├─ Branch 1 (x>0) → Call func_B() │└─ Loop (i=0→5) └─ Branch 2 (x≤0) → Directly return; The above visual structure is the "pseudo-code line"; It is worth mentioning that when the compiled code changes due to version update, the path tracking is automatically triggered again, the visual structure view is updated, and the manual maintenance cost is avoided.

[0023] Analyze the distribution of values ​​in the variable trajectory (e.g., the value of x is concentrated in 0-100), combine it with the branch path (e.g., when x=100, a new branch is entered), and infer the boundary values ​​(e.g., 99, 100, 101). For uncovered branch path fingerprints, the required combinations of input variables are derived in reverse (e.g., by solving for input conditions where x>0 and yisNone), generating supplementary use cases, specifically including: To generate supplementary test cases for the uncovered path: Locate the key conditional branch leading to the uncovered path "Path-B", namely the else case of "if x>100", whose trigger condition is x<= 100. Utilize variable trajectory information, especially the type of the input variable x (e.g., inferring its numeric type from its initial value of 200), and use reverse derivation or a constraint solver to generate an input value that satisfies the condition x<= 100. A simple strategy is to choose a value some distance from the boundary, such as 50. Finally, based on the deduced input variable combination {x: 50}, generate a new, executable supplementary test case, namely target_func(50).

[0024] During test execution, decorators (such as @verify_case(expect_vars={"b": 20}) can be used to automatically verify whether the values ​​of the tracked variables meet expectations (without relying on the output), thus enabling the verification of intermediate logic. When the compiled code is updated, the structural differences between the old and new versions are compared (such as the addition of the function func_C). The test cases that cover the original structure are automatically retained, and test cases for the new structure are added.

[0025] Example 2 As an optional implementation, this embodiment, based on Embodiment 1, provides a variant scheme for fine-grained control of the tracing process. This aims to address the problem that comprehensive tracing may lead to excessive performance overhead and information redundancy in large and complex applications. The technical solution of this embodiment supports flexible configuration of the tracing range and granularity.

[0026] In real-world software testing scenarios, the target black-box code might be a massive system containing hundreds or even thousands of functions and variables. Collecting all local and global variables for every line of code execution would generate a massive amount of data, consuming enormous storage space, severely slowing down the target program's execution, and placing a huge computational burden on subsequent processes. It's important to note that testers typically only care about a few key variables relevant to specific functionalities or defects.

[0027] To solve this problem, embodiments of the present application introduce a tracing configuration and data filtering mechanism. As a preferred implementation, embodiments of the present application provide a method of receiving tracing configuration through a decorator. Decorators are a syntactic sugar supported by many high-level programming languages (such as Python) and can conveniently wrap or modify the behavior of functions or classes. Testers can use a predefined decorator to declare the tracing requirements of the current test in the test script that calls the target black-box code.

[0028] For example, assume that there is a call in the test script as follows: # Code in the test script from tracer_library import trace_vars @trace_vars(scope="local", types=(int, str), names=["result", "status_code"]) def run_complex_test(): import target_module # target_module.complex_func is a complex black-box function target_module.complex_func(initial_data) In this example, trace_vars is a configuration decorator provided by embodiments of the present application. It receives three parameters, which together constitute a set of tracing configuration rules: scope="local": the rule indicates that the tracing function only focuses on local-scope variables and ignores global variables.

[0029] types=(int, str): the rule further limits that, among the local variables, only variables of integer or string types are focused on.

[0030] names=["result", "status_code"]: the rule provides a more accurate limitation, requiring only variables with the variable names "result" or "status_code" to be traced.

[0031] ​Subsequently, when the run_complex_test function is executed and in turn calls the black-box function target_module.complex_func, the non-intrusive monitoring and data collection process described in Embodiment 1 is still triggered. It should be noted that a filtering step is added in this embodiment. After the tracing function extracts the complete set of local variables from the execution stack frame object at each code line execution event trigger, it does not immediately save all variable information, but rather filters according to the pre-configured rules.

[0032] The specific filtering logic is as follows: for each variable (key-value pair) taken from the local variable set, a series of checks are performed, including scope check, type check, and name check. For example, according to the scope configuration, it is determined whether to process the local variable set or the global variable set; the type check function (such as Python's isinstance) is used to determine whether the variable value type belongs to one of the configured type tuples (int, str); and it is determined whether the variable name exists in the configured name list ["result", "status_code"].

[0033] Only when a variable meets all the configured rules at the same time, its variable name, current value, and corresponding bytecode offset are recorded.

[0034] In this way, even if there are a large number of temporary variables, loop counters, different types of objects, etc. inside the complex black-box function, this embodiment will only collect and analyze the key variables explicitly specified by the test personnel. This scheme can greatly reduce the amount of data generated by tracking, reduce the consumption of storage and network resources; significantly reduce the performance burden of the target program, making the tracking process more lightweight. This fine-grained control capability enables the technical solution of the present application to comfortably cope with large, performance-sensitive black-box application testing, achieving the goal of optimizing tracking performance while ensuring tracking accuracy.

[0035] Embodiment Three This embodiment further provides a variant scheme that intelligently generates boundary value test cases in combination with variable trajectory analysis based on Embodiment 1. This scheme aims to solve potential defects related to boundary condition handling that are difficult to discover by relying solely on branch coverage, such as the classic "off-by-one error".

[0036] In embodiment 1, the system generates supplementary test cases by identifying uncovered branch paths, with the main goal of improving the structural coverage of the code. However, even if 100% branch coverage is achieved, the program can still have errors when dealing with specific boundary values. For example, a logic that should handle x <= 100 is mistakenly implemented as x < 100, then when the input is exactly 100, the program will exhibit unexpected behavior. Traditional black-box testing methods rely on the experience of testers to design boundary value cases, while this embodiment provides an automated method to discover and test boundary values.

[0037] The following still takes the target_func(x) function in embodiment 1 as an example. Assume that the system has executed two test cases in succession: target_func(200) and target_func(50) according to the process of embodiment 1. At this time, the complete data of the two executions has been recorded, including their variable trajectories and the respective paths covered (Path-A and Path-B), and the system knows that all branches have been covered.

[0038] At this time, the method of this embodiment will start a deeper analysis process. First, perform the boundary value analysis task. The specific steps are as follows: identify the path switching event, i.e., find that the execution path of the program has switched (from Path-A to Path-B) in the two executions. Then, it associates the path switching event with the code logic structure to locate the key conditional branch that causes the path switching, i.e., if x > 100 in the pseudo code, and analyzes the conditional expression to identify the variable x as the "key variable" that determines the branch direction. Then, extract and compare the trajectories of the key variable x in the two executions, and observe that when the input x is 200, the if branch is executed; when the input x is 50, the else branch is executed. Based on this, the system correlates and analyzes the value of the key variable with the branch condition x > 100, and infers that the switching of the path occurs when the value of x crosses the point 100. Therefore, this value is identified and marked as an important "boundary value". It should be noted that this boundary value may be a constant explicitly written in the code, or an implicit value calculated through multiple variables, and this method can effectively discover it.

[0039] After successfully inferring the boundary value, perform the generation task of the boundary value test case. Based on the boundary value analysis method in software testing theory, a set of representative test inputs is automatically generated around the identified boundary value. A typical generation strategy includes: Boundary point: generate an input equal to the boundary value, i.e., x = 100. This case is used to test whether the program behaves correctly at the boundary point itself.

[0040] Inside boundary point: generate a value that is immediately adjacent to the boundary and on the side where the condition does not hold, e.g. for integer type take x = 99.

[0041] Outside boundary point: generate a value that is immediately adjacent to the boundary and on the side where the condition holds, e.g. for integer type take x = 101.

[0042] Accordingly, three new supplementary test cases can be created: target_func(99), target_func(100) and target_func(101). These test cases are automatically added to the test suite and can be scheduled for execution. By running these precise boundary value test cases and verifying their outputs or internal states, the testing system can very effectively reveal program defects due to incorrect boundary condition judgment (e.g. misusing > as >=, or vice versa).

[0043] This embodiment greatly enhances the depth of testing and the ability to discover potential defects by automatically analyzing the relationship between variable trajectories and path switching to discover implicit boundaries in the code and generating high-quality boundary value test cases accordingly, making up for the shortcomings of testing methods that rely solely on branch coverage.

[0044] Embodiment Four: This embodiment provides a variant scheme for generating a code structure view and intelligently adapting regression testing using the view, which aims to provide testers with an intuitive understanding of the logic of black-box code and automate the maintenance of regression testing due to code updates.

[0045] In one aspect of this embodiment, the generation of a code logic structure view is involved. In Embodiment 1, detailed information about the function call chain and conditional branch path of the target black-box code has been internally constructed through analysis of runtime data. In order to convert these abstract data into a user-friendly form, this embodiment adds a function for generating a structure view. After completing the path analysis of the code, the reconstructed function call chain and all discovered logical branch paths are integrated to generate a visual code structure view. This view is conceptually similar to the abstract syntax tree of the source code, but it is obtained by reverse engineering through dynamic execution of the black-box code.

[0046] In the structure view, nodes represent functions, conditional statements, and executed statements, while directed edges represent control flow. For example, for `target_func` in Example 1, the view displays a root node "target_func(x)", which connects to a diamond-shaped branch node "if (x>100)". This branch node then leads to two rectangular leaf nodes "y = x * 2" and "y = x + 10", with labels such as "True" and "False" indicating the path selection. The generated code structure view can be presented to users, providing testers with a clear blueprint of the internal workings of black-box code. This allows them to quickly understand the core logic even without the source code, which is very helpful for manually designing more complex test scenarios or understanding the root causes of errors.

[0047] Another aspect of this embodiment relates to intelligent adaptation of regression testing. Software products are continuously iterated and updated throughout their lifecycle. When the black-box code is updated, efficiently performing regression testing to ensure that old functions are not broken and to verify new functions is a significant challenge. This embodiment provides an automated solution.

[0048] Suppose the target_func function is modified by the developers and a new version is released, whose logic is equivalent to target_func_v2: # New version of the target black-box function target_func_v2 def target_func_v2(x): if x>200: y = x * 3 elif x>100: y = x * 2 else: y = x + 10 return y The new version adds an if x>200 branch and moves the original if x>100 logic to the elif branch.

[0049] When the tester gets the new version of the black-box code file, they will use the system of the present application to analyze it again. First, the system will perform monitoring, collection and analysis on the new version of the code, and finally generate a new version of the code logic structure view corresponding to target_func_v2, and then compare the code structure views of the old and new versions, and automatically identify the structural differences through tree comparison or graph comparison algorithm. In this example, the system will find that: a top-level conditional branch if (x>200) and its corresponding execution body y = x * 3 are added; and the context of the original if (x>100) branch has changed, which has become an elif branch.

[0050] Preserve relevant use cases: The system analysis finds that the elif (x>100) and else branches in the new structure correspond to the logic of the if and else branches in the old structure, respectively. Therefore, the test cases generated earlier to cover these logics (e.g., target_func(150) and target_func(50)) are still valid and need to be preserved for regression testing.

[0051] Abandon or update use cases: If an old branch is completely deleted, the corresponding test case may be marked as obsolete.

[0052] Supplement new function use cases: Most importantly, the system identifies that the newly added if x>200 logic path is completely new and not covered by existing use cases, and then reversely deduces the input that can trigger this path, such as generating a new test case target_func_v2(250).

[0053] Embodiment five: Figure 2 is a system schematic diagram of a black-box code analysis and test case generation device according to another exemplary embodiment, the device comprising: Variable information acquisition module 1: for registering a trace function through a preset sys.settrace interface, performing non-intrusive monitoring on the execution process of the black-box code through the trace function, the trace function being called when a preset event is triggered, for acquiring variable information of the related preset event; Variable trajectory acquisition module 2: for establishing a variable trajectory mapping relationship according to the changes of variable values of different variable names in the variable information of the related preset event with execution time sequence and their corresponding bytecode offsets; Variable trajectory association module 3: for associating the variable trajectory mapping relationship to the pre-acquired black-box pseudo code lines through the instruction mapping function of a preset decompilation tool, realizing understandable display of the variable trajectory; The variable boundary value acquisition module 4 is configured to acquire the variable boundary value according to the distribution of the variable value in the variable trajectory and the pre-acquired branch path in the black-box pseudo code line; The test case generation module 5 is configured to, for a branch path that has not been covered, acquire the input variable combination triggering the execution of the path according to the variable boundary value and the variable trajectory, and generate a supplementary test case based on the input variable combination.

[0054] Embodiment six The embodiment provides a storage medium storing a computer program, and the computer program is executed by a host to implement each step in the above method. It can be understood that the storage medium mentioned above can be a read-only memory, a disk or an optical disk, etc.

[0055] It can be understood that the same or similar parts in the above embodiments can be mutually referred to, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0056] It should be noted that, in the description of the present application, the terms "first", "second", etc. are only for the purpose of description, and cannot be understood as indicating or implying relative importance. In addition, in the description of the present application, unless otherwise specified, the meaning of "a plurality of" is at least two.

[0057] Any process or method descriptions in flow charts or described herein otherwise can be understood as representing code modules, segments, or portions of code that include one or more executable instructions for implementing specific logic functions (or steps) in the process, and the various embodiments of the present application can include additional or fewer functions performed in the order shown or discussed, including functions performed in a substantially simultaneous manner or in a reverse order. This should be understood by those skilled in the art.

[0058] It should be understood that the parts of the present application can be realized by hardware, software, firmware or their combination. In the above embodiments, a plurality of steps or methods can be realized by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if realized by hardware, and as in another embodiment, it can be realized by any one or their combination of the following technologies known in the art: discrete logic circuit with logic gate circuit for implementing logic function on data signal, application specific integrated circuit with suitable combination logic gate circuit, programmable gate array (PGA), field programmable gate array (FPGA), etc.

[0059] Those skilled in the art can understand that all or part of the steps of the method carried out by the above-mentioned embodiments can be instructed by a program to the relevant hardware, and the program can be stored in a computer readable storage medium. When the program is executed, it includes one of the steps of the method embodiment or a combination thereof.

[0060] In addition, each functional unit in each embodiment of the present application can be integrated into one processing module, or each unit can exist physically independently, or two or more units can be integrated into one module. The integrated module can be realized in the form of hardware or in the form of a software functional module. When the integrated module is realized in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer readable storage medium.

[0061] The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc.

[0062] In the description of the present specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example" or "some examples" means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, the illustrative description of the above terms does not necessarily mean the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0063] Although the embodiments of the present application have been shown and described above, it can be understood that the above-mentioned embodiments are exemplary and cannot be understood as limiting the present application, and those skilled in the art can make changes, modifications, replacements and variations to the above-mentioned embodiments within the scope of the present application.

Claims

1. A black-box code analysis and test case generation method, characterized by, The method comprises: Registering a trace function through a preset sys.settrace interface, performing non-intrusive monitoring on the execution process of the black-box code through the trace function, the trace function being called at a preset event trigger, and being used to acquire variable information of the relevant preset event; According to the variable values of different variable names in the variable information of the relevant preset event and the corresponding bytecode offsets with the change of the execution time sequence, a variable trajectory mapping relationship is established; Through an instruction mapping function of a preset decompilation tool, the variable trajectory mapping relationship is associated to the pre-acquired black-box pseudo code line, and understandable display of the variable trajectory is realized; According to the distribution of the variable values in the variable trajectory and the branch paths in the pre-acquired black-box pseudo code line, variable boundary values are acquired; For a branch path that has not been covered, input variable combinations triggering the execution of the path are reversely deduced according to the variable boundary values and the variable trajectory, and a supplementary test case is generated based on the input variable combinations.

2. The method of claim 1, wherein the trace function is called at a preset event trigger, and the acquisition of the variable information of the relevant preset event comprises: at the preset event trigger, the trace function extracts runtime context data from a current execution stack frame, and the context data comprises local variables, global variables and variable type information.

3. The method of claim 2, wherein the preset event at least comprises a function call event, a code line execution event and a function return event.

4. The method of claim 3, wherein, Further comprising: a decorator is set at an entry of a target function call to perform tracking configuration, and the variable information of the relevant preset event extracted is filtered through the tracking configuration to reduce redundant information and optimize tracking performance; the tracking configuration comprises a rule of filtering at least one of a variable scope, a data type or a specified key variable name.

5. The method of claim 4, wherein the acquisition of the black-box pseudo code line comprises: the function call events and the function return events acquired through the trace function record function call relationships; a function call tree is generated according to the function call relationships and an entry function of the target function marked by the decorator; a path fingerprint is generated according to an execution selection result of a conditional judgment, the path fingerprint representing an identified branch path; by comparing path fingerprint sets generated when different inputs correspond to test cases, an uncovered branch path is identified, and all identified branch paths are obtained; the function call tree and all identified branch paths are converted into a visual structure of a class AST, and the pseudo code line of the black-box is obtained.

6. The method of claim 5, wherein, Further comprising: when the compiled code of the current black-box changes due to version update, branch path tracking is retriggered, and the visual structure corresponding to the updated black-box is acquired.

7. The method of claim 6, wherein, Further comprising: for the updated black-box code, a new version of the visual structure is generated; the visual structure views of the new and old versions are compared to identify structural differences; and according to the structural differences, a new supplementary test case is generated.

8. The method of claim 7, wherein, Further comprising: The decorator is used to automatically check whether the tracked variable value is consistent with the preset variable value during execution of the test case, thereby achieving verification of the intermediate logic.

9. A black-box code analysis and test case generation apparatus characterized by comprising: The device comprises: A variable information acquisition module is configured to register a tracking function through a preset sys.settrace interface, and to non-invasively monitor an execution process of the black-box code through the tracking function, the tracking function being called when a preset event is triggered, and being configured to acquire variable information of the related preset event; A variable track acquisition module is configured to establish a variable track mapping relationship according to variable values of different variable names in the variable information of the related preset event and corresponding bytecode offsets with execution time sequences; A variable track association module is configured to associate the variable track mapping relationship to pre-acquired black-box pseudo code lines through an instruction mapping function of a preset decompilation tool, and to achieve understandable display of the variable track; A variable boundary value acquisition module is configured to acquire variable boundary values according to a distribution of the variable values in the variable track and branch paths in the pre-acquired black-box pseudo code lines; A test case generation module is configured to, for a branch path that has not been covered, reversely deduce an input variable combination triggering execution of the path according to the variable boundary values and the variable track, and to generate a supplementary test case based on the input variable combination.

10. A storage medium, characterized by The storage medium stores a computer program, and when the computer program is executed by the host, each step of the high-energy-consumption industrial load mode recognition method according to any one of claims 1-8 is implemented.

Images