Test case detection method and device, storage medium and electronic equipment

Abstract

The application discloses a test case detection method and device, a storage medium and an electronic device, and relates to the technical field of computers, which comprises the following steps: obtaining a block behavior relationship network by analyzing user operation behaviors, functional block areas and the association relationship between interfaces based on behavior logs and interface call logs; identifying the code update position of the current test case version, analyzing the influence range of the code update position based on the block behavior relationship network, and determining a target interface set contained in the influence range; selecting and expanding the test cases corresponding to the target interface set from the current test case version to obtain a plurality of target test cases, and performing important level evaluation on the plurality of target test cases from multiple dimensions to obtain the important levels of the plurality of target test cases; determining the detection order of the plurality of target test cases from high to low according to the important levels, and sequentially performing fault detection on the plurality of target test cases based on the detection order. The application can improve the detection efficiency.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and in particular to a test case detection method and device, a storage medium and an electronic device. BACKGROUND

[0002] In the current software development cycle, test case detection is a key link to ensure software quality. Test cases aim to verify whether the functions, performance, security and other key characteristics of the software meet expectations. This is crucial for discovering and fixing potential defects, helping to improve the stability and user experience of the final product.

[0003] Currently, the detection of test cases in the related art is widely carried out by manual detection, that is, relying on the professional knowledge and experience of test engineers or experts in the relevant field to comprehensively detect the integrity, accuracy, effectiveness and operability of test cases, and to manually adjust accordingly.

[0004] However, this method relies heavily on the professional experience of professionals, and as the number of test cases increases, the required review and modification time and human resources also increase dramatically, resulting in significant human cost burden. Moreover, the manual detection process has a certain subjectivity, which may affect the accuracy and timeliness of the detection results, making it difficult to provide accurate adjustment suggestions to optimize the test plan, and there is a risk of missing critical information in the manual detection process, further reducing the accuracy and effectiveness of the correction. SUMMARY

[0005] Therefore, the present application provides a test case detection method and device, a storage medium and an electronic device, which mainly aims to solve the technical problem that the current prior art relies heavily on the professional experience of professionals, and as the number of test cases increases, the required review and modification time and human resources also increase dramatically, resulting in significant human cost burden. Moreover, the manual detection process has a certain subjectivity, which may affect the accuracy and timeliness of the detection results, making it difficult to provide accurate adjustment suggestions to optimize the test plan, and there is a risk of missing critical information in the manual detection process, further reducing the accuracy and effectiveness of the correction.

[0006] In a first aspect, the present application provides a test case detection method, comprising:

[0007] Obtaining a user's behavior log and interface call log, analyzing the user's operation behavior, functional block and the association between interfaces based on the behavior log and the interface call log to obtain a block behavior relationship network;

[0008] identify a code update position of a current test case version, analyze an influence range of the code update position based on the block behavior relationship network, and determine a target interface set contained in the influence range;

[0009] select test cases corresponding to the target interface set from the current test case version, perform expansion processing on the test cases, obtain a plurality of target test cases, and perform important level evaluation on the plurality of target test cases from a plurality of dimensions to obtain important levels of the plurality of target test cases;

[0010] determine a detection order of the plurality of target test cases according to the important levels from high to low, and perform fault detection on the plurality of target test cases in sequence based on the detection order.

[0011] In a second aspect, the present application provides a test case detection device, comprising:

[0012] an acquisition module configured to acquire a behavior log and an interface call log of a user, analyze a user operation behavior, a functional block, and an association relationship between interfaces based on the behavior log and the interface call log to obtain a block behavior relationship network;

[0013] an identification module configured to identify a code update position of a current test case version, analyze an influence range of the code update position based on the block behavior relationship network, and determine a target interface set contained in the influence range;

[0014] an evaluation module configured to select test cases corresponding to the target interface set from the current test case version, perform expansion processing on the test cases, obtain a plurality of target test cases, and perform important level evaluation on the plurality of target test cases from a plurality of dimensions to obtain important levels of the plurality of target test cases;

[0015] a detection module configured to determine a detection order of the plurality of target test cases according to the important levels from high to low, and perform fault detection on the plurality of target test cases in sequence based on the detection order.

[0016] In a third aspect, the present application provides a computer readable storage medium having a computer program stored thereon, wherein the computer program is executed by a processor to implement the test case detection method of the first aspect.

[0017] In a fourth aspect, the present application provides an electronic device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the computer program to implement the test case detection method of the first aspect.

[0018] By the technical solutions, the test case detection method, device, storage medium and electronic equipment provided by the application can accurately determine the association relationship between the operation behavior, function block and interface based on the block behavior relationship network obtained by analyzing the user operation behavior, function block and association relationship between interfaces based on the behavior log and interface call log, analyze the influence range of the code update position based on the block behavior relationship network by identifying the code update position of the current test case version, and determine the target interface set contained in the influence range. The application can quickly and accurately analyze the influence range of the code update position based on the block behavior relationship network, and then determine the influence interface set of the code update position. The application can select and expand the test cases corresponding to the target interface set from the current test case version to obtain a plurality of target test cases, and evaluate the importance level of the plurality of target test cases from multiple dimensions to obtain the importance level of the plurality of target test cases. Then, the detection order of the plurality of target test cases is determined from high to low according to the importance level, and the plurality of target test cases are sequentially detected based on the detection order. The application can detect the test cases with higher importance first, and can quickly detect whether the important test cases have faults. In this way, the application can timely find and process faults, and the expanded test cases can be detected again. The detection method of the application can fully and comprehensively detect all test cases, avoid missing detection and false detection, improve detection efficiency, and ensure the accuracy and effectiveness of detection. BRIEF DESCRIPTION OF DRAWINGS

[0019] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the application and, together with the specification, serve to explain the principles of the application.

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, those skilled in the art can obtain other drawings from these drawings without creative labor.

[0021] Figure 1 A flowchart of a test case detection method provided by an embodiment of the application is shown;

[0022] Figure 2 A flowchart of a test case detection method provided by an embodiment of the application is shown;

[0023] Figure 3 A flowchart of a test case detection method provided by an embodiment of the application is shown;

[0024] Figure 4 A flowchart of a test case detection method provided by an embodiment of the application is shown.

[0025] Figure 5 A flowchart of a test case detection method provided by an embodiment of the application is shown.

[0026] Figure 6 A flowchart of an example provided by an embodiment of the application is shown.

[0027] Figure 7 A structural diagram of a test case detection device provided by an embodiment of the application is shown.

[0028] Figure 8 A structural diagram of an electronic device provided by an embodiment of the application is shown. DETAILED DESCRIPTION

[0029] Embodiments of the application will be described in more detail below with reference to the accompanying drawings. It should be noted that the embodiments in the application and the features in the embodiments can be combined with each other without conflict.

[0030] To improve the fact that the prior art largely relies on the professional experience of professionals, as the number of test cases increases, the required review and modification time and human resources also increase dramatically, resulting in significant human cost burden. And the manual detection process has a certain subjectivity, which may affect the accuracy and timeliness of the detection results, making it difficult to provide accurate adjustment suggestions to optimize the test scheme, and there is a risk of missing key information in the manual detection process, further reducing the accuracy and effectiveness of the correction. The embodiment provides a test case detection method, as shown in Figure 1 The method comprises the following steps.

[0031] In step 101, the behavior log and the interface call log of the user are obtained, and the association relationship between the user operation behavior, the function block and the interface is analyzed based on the behavior log and the interface call log to obtain a block behavior relationship network.

[0032] In the embodiment of the application, the user behavior log refers to a log recording the interactive operation of the user in the client (such as Web / H5 / APP), which is usually collected by burying points; correspondingly, the interface call log is used to record the HTTP request information between the backend services or between the front and back ends, which is usually collected by the gateway, middleware or AOP aspect.

[0033] In some examples, the user operation behavior is the operation of the user on the front-end interface, such as clicking a button, sliding, inputting, etc., which is usually collected through burying points; a function block (Module / Block) can be a function area in a page, for example, a "home page recommendation position", a "shopping cart settlement button", etc., which is used to finely describe the position of the user behavior. An interface (API Interface) can be an HTTP interface provided by the back-end for the front-end or other microservices to call to complete data requests, state updates, etc.

[0034] For example, the association relationship between the user operation behavior, the function block and the interface can correspond to: the user clicks the "add to shopping cart" button (operation behavior); the button belongs to the "product detail page-shopping cart function block" (function block); and the / api / cart / add interface call (interface) is triggered after the button is clicked.

[0035] Step 102, identifying the code update position of the current test case version, analyzing the influence range of the code update position based on the block behavior relationship network, and determining a target interface set contained in the influence range.

[0036] In the embodiment of the application, the code update position of the current test case version can be the source code related to the test case, and the specific file and code line number changed between different versions. These changes can directly affect the behavior or expected result of the test case, and therefore are particularly important in regression testing or impact analysis.

[0037] Step 103, selecting and expanding the test cases corresponding to the target interface set from the current test case version to obtain a plurality of target test cases, and performing important level evaluation on the plurality of target test cases from a plurality of dimensions to obtain important levels of the plurality of target test cases.

[0038] In the embodiment of the application, the test cases can be expanded based on a control flow graph and a data dependency graph, wherein the control flow graph is a directed graph structure representing the control transfer relationship between basic blocks in the program, a node (Node) represents a "basic block", that is, a piece of sequential code without branching. An edge (Edge) represents the control flow from one basic block to another basic block; correspondingly, the data dependency graph describes the dependency relationship between variable definitions and uses in the program; a node (Node) represents the definition or use of a variable; and an edge (Edge) represents that the use of a variable depends on a definition.

[0039] In some examples, the plurality of dimensions can include a business impact dimension, a historical fault dimension, a behavior heat dimension and a risk level dimension.

[0040] Step 104, determine the detection order of the plurality of target test cases from high to low according to the importance level, and perform fault detection on the plurality of target test cases in turn based on the detection order.

[0041] Compared with the prior art, the embodiment can accurately determine the association relationship between the operation behavior, the functional block and the interface based on the block behavior relationship network obtained by analyzing the association relationship between the operation behavior, the functional block and the interface based on the behavior log and the interface calling log, analyze the influence range of the code update position based on the block behavior relationship network by identifying the code update position of the current test case version, and determine the target interface set contained in the influence range, so that the embodiment can quickly and accurately analyze the influence range of the code update position based on the block behavior relationship network, and further determine the influence interface set of the code update position. The test cases corresponding to the target interface set are selected from the current test case version and expanded, a plurality of target test cases are obtained, the importance level of the plurality of target test cases is evaluated from multiple dimensions, and the detection order of the plurality of target test cases is determined from high to low according to the importance level, and the plurality of target test cases are detected in turn based on the detection order, so that the embodiment can preferentially detect the test cases with higher importance, can quickly detect whether the important test cases have faults, and can further discover and process faults in time. Expanding the test cases and then detecting can make the detection method of the embodiment fully and comprehensively detect all the test cases, avoid missing detection and wrong detection, improve the detection efficiency, and further ensure the accuracy and effectiveness of the detection.

[0042] As a refinement and extension of the above embodiment, when performing the steps of obtaining the behavior log and the interface calling log of the user, and analyzing the association relationship between the operation behavior, the functional block and the interface based on the behavior log and the interface calling log to obtain the block behavior relationship network, the following methods can be used, but are not limited to the following methods, such as Figure 2 As shown in the figure, the method comprises the following steps:

[0043] Step 201, grabbing the interface calling log through the business interface log collection platform, and obtaining the behavior log sent by the client.

[0044] The behavior log is obtained by the client based on the user behavior log collection platform.

[0045] In the embodiment of the application, the user behavior log can be collected by the user behavior log collection platform, including the activity behavior data generated by the user when using the APP or the front-end page

[0046] In some examples, the embedded log specification definition can include: 1, unified log format requirement: each log must contain user identification, operation timestamp, page name, function block name, operation position, and event type (such as button click, page jump, etc.). 2, collection and reporting of user behavior logs, each element represents a field in the log, and the log format can be shown by formula one as follows:

[0047]

[0048] (Formula one)

[0049] In formula one: represents each log; uuId represents a distributed unique identification with time component; represents user identification (using user primary key in the database); sessionId represents a continuous operation session, which is convenient for reconstructing user behavior path; is a timestamp, which uses ISO-8601 with time zone to ensure consistent cross-system analysis and millisecond-level precision and monotonicity; is an application unique identification; is a unique identification of a page of an application; is a unique identification of a function block of a page; is a unique identification of an operation position of an application.

[0050] Exemplarily, in a real business scenario, user behavior can be represented by a record caliber with a hierarchical structure. For example, SPM data for recording user behavior position on the client usually has a record caliber with gradually refined granularity from top to bottom, such as site, page, function block, and position. For example, assuming that a site has L pages on average, a page has M function blocks on average, and a function block has N positions on average, a user behavior can be represented as a vector (i, j, k), where i is the i-th page in the L pages, j is the j-th function block in the M function blocks, and k is the k-th position in the N positions.

[0051] Exemplarily, three corresponding dictionary tables can be established for the page, function block, and operation position, for example: page: home page=A1, product page=A2, shopping cart page=A3; function block: coat function block=M1, shoe function block=M2, mobile phone function block=M3; operation position: first position in sequence=L1

[0052] For this embodiment, log preprocessing and session reconstruction can be performed, which can specifically include: obtaining a plurality of behaviors continuously performed by a first user, wherein the time interval between two continuous behaviors in the plurality of behaviors is less than a predetermined time length. The first user is reconstructed between adjacent event intervals (Initial setting 30 minutes) Considered as continuous behavior and has a greater relevance Conversely, if it exceeds, it is considered as two unrelated behaviors, i.e. different functional functional blocks, for example, Wherein:

[0053] Step 202, the behavior log and interface call log are de-duplicated and screened to obtain the functional block triggered by the user operation behavior, and the operation trigger position in the functional block is extracted to obtain the interface execution path of the user.

[0054] Optionally, the log records of the business are captured through the business interface log collection platform, and the initial log content includes: ; and the unique function block (module) name is determined through traceID+SpanId unique key de-duplication screening, and each interfaceUrl path (interface execution path in the embodiment of the application) is printed based on the location (operation trigger position in the embodiment of the application) triggered by the user under the function block (module). Each interfaceUrl is recorded as I, and there is a sequence, so the interface list interfaceUrlList-module corresponding to the function block (module) can be output based on this, [I1, I2, I3…].

[0055] Step 203, based on the interface execution path and the functional block, the association relationship between the user operation behavior, the functional block and the interface is analyzed to obtain the block behavior relationship network.

[0056] In some examples, the above operation will screen out the interface list of the non-current operation. Therefore, it is necessary to make a second intersection screening interfaceUrlList-module-timestamp=[It1, It2, It3…] according to the timestamp parameter, and then the complete user block behavior function interface association log can be output, as shown in Equation Two:

[0057] (Equation Two)

[0058] At this point, the user's block information behavior interface relationship network G is formed, as shown in Table 1:

[0059] Table 1

[0060]

[0061] Further, in the step of identifying the code update location of the current test case version, analyzing the influence range of the code update location based on the block behavior relationship network, and determining the target interface set contained in the influence range, the following steps can be adopted, but are not limited to, such as Figure 3 As shown in the following steps:

[0062] Step 301, obtaining the current version test case and the last version test case, and performing code difference identification on the current version test case and the last version test case to obtain the code update location.

[0063] The current version test case is obtained based on the last version test case.

[0064] In the embodiments of the present application, the code difference identification on the current version test case and the last version test case can be performed based on the code version control tool (git diff). Git diff is one of the most commonly used commands in the Git version control system, which is used to view the differences between the code in different states.

[0065] For example, two versions of the code library can be input , The change files of the two versions can be extracted by git diff , and line numbers .

[0066] Step 302, code parsing is performed on the current test case version to generate a target abstract syntax tree corresponding to the current test case version, and a code update node corresponding to the code update location in the target abstract syntax tree is determined.

[0067] In the embodiments of the present application, the code parsing on the current test case version to generate the target abstract syntax tree corresponding to the current test case version can be specifically structural analysis of the source code, including: using a static analysis tool to parse the source code to generate an abstract syntax tree (AST) AST is a tree representation of program structure, which can help identify syntax elements in the program and identify syntax level relationships.

[0068] For example, the syntax element set of the program P can be E, and the AST is a tree ; is a node set corresponding to the syntax element set E; is a directed edge set representing the parent-child relationship, and based on the change files and line numbers of the two versions, a change location set is obtained. ​

[0069] Step 303: Analyze the impact range of the code update node from the target abstract syntax tree based on the block behavior relationship network, and determine the impact interface set corresponding to the impact node set.

[0070] Optionally, when executing step 303, the following steps may be adopted but are not limited to: analyzing the directly affected node set of the code update node from the target abstract syntax tree, traversing and filtering the directly affected node set in the target abstract syntax tree through a preset query function, and selecting nodes that meet the predetermined filtering conditions to form a target directly affected node set; analyzing the node dependencies in the target abstract syntax tree based on the block behavior relationship network, obtaining the influence range of the code update node according to the node dependencies, and determining the target indirectly affected node set of the code update node based on the influence range; and forming the target directly affected node set and the target indirectly affected node set into an affected node set.

[0071] In the embodiment of the present application, identifying the impact interface set may include performing two aspects: direct impact surface identification and indirect impact surface identification. The direct impact surface identification may include: locating the change node: for each difference position , find the corresponding (AST) Locate node n and get the affected node set (ie, the directly affected node set in the embodiment of the present application); traverse the node set . Call the Ancestor query function Locate the closest to the root but meeting the "type" The set of ancestor nodes of the target type, such as function, class, route; determines when to terminate the recursion Through the function Mapping directly affected interface & page identifiers (That is, the target in the embodiment of the present application directly affects the node set).

[0072] Exemplarily, indirect impact surface identification may include: providing existing dependencies between applications or between front-end and back-end, scanning whether there are dependencies between them, identifying the parts of the interfaces or pages of their modules that call the modified functions: identifying interfaces and interaction points between modules, such as function calls, API interfaces, message queues, etc.; generating the final front-end functional block impact range (i.e., the target indirect impact node set in the embodiment of the present application) based on the constructed cross-module relationship network G (i.e., the block behavior relationship network in the embodiment of the present application); if it is a back-end code change, then based on the calling relationship between the front-end page and the back-end interface, the indirect impact on the front-end (i.e., the target indirect impact node set in the embodiment of the present application) is determined by formula three. Formula three is specifically as follows:

[0073] (Formula Three)

[0074] In Formula Three, denotes the breadth-first search calculation from the set of reachable nodes S on the dependency graph G, and then the full-impact set is obtained:

[0075] Step 304, determine the impact interface set as the target interface set.

[0076] Optionally, when performing the operation of selecting and expanding the test cases corresponding to the target interface set from the current test case version to obtain a plurality of target test cases, the following method can be used, but is not limited to the following method, as shown in the following formula: Figure 4 The method comprises the following steps:

[0077] Step 401, determine the operation behavior sequence corresponding to the target interface set, and the operation behavior sequence set corresponding to the current test case version.

[0078] In the embodiment of the present application, the user behavior operation sequence can be obtained by matching the user's typical operation route by dynamic time warping (DTW), which is an algorithm for measuring the similarity between two time series. It is particularly suitable for comparing time series data of different lengths or speeds, such as speech recognition, gesture recognition, etc.

[0079] Step 402, match the similarity between the operation behavior sequence and the operation behavior sequence set to match a plurality of candidate operation behavior sequences with a similarity greater than or equal to a predetermined similarity threshold.

[0080] For the present embodiment, determining the operation behavior sequence set corresponding to the current test case version can include the following steps, but is not limited thereto:

[0081] Step 1: Represent the user historical behavior sequence number as

[0082] Define the feature space: select three features: page P, function block M and operation position L. The possible value range of each feature is as follows: page: possible value ; function block: possible value ; position: possible value .

[0083] Encoding representation: for each feature, define a one-hot encoding function , as shown in the following formula four:

[0084] (Formula Four)

[0085] In formula 4, is the value of the feature, is the number of possible values ​​of the feature, and the function returns a length of vector, It can be determined by the following formula 5:

[0086] (Formula 5)

[0087] Step 2: Generate behavior sequence vector representation

[0088] For user operation behavior location ,in , , , the one-hot encoding is represented as: page one-hot encoding , one-hot encoding of functional blocks , position one-hot encoding ; Combine the one-hot encoding vectors of each feature into a complete behavior representation vector .

[0089] Step 3: Generate user historical behavior sequence:

[0090] Generate affected user behavior sequence: Arrange the collected behaviors in chronological order to obtain the user behavior sequence , according to the full impact set , filter to get the affected behavior sequence : Preliminary screening of the optimal test case set ; Through DTW time series. Analyze the affected user behavior sequence through formula 6 and test case operation path collection The similarity of , formula six is ​​as follows:

[0091] (Formula 6)

[0092] In Formula 6, is the maximum acceptable distance threshold set; A test case set (i.e., multiple candidate operation behavior sequences in the embodiment of this application)

[0093] Step 403: Expand multiple candidate operation behavior sequences based on a preset control flow graph and a preset data dependency graph to obtain multiple target test cases.

[0094] In the embodiments of the present application, the control flow graph is a directed graph structure representing the control transfer relationship between basic blocks in the program, a node (Node) represents a "basic block", that is, a piece of sequential code without branching. The edge (Edge) represents the control flow from one basic block to another basic block; accordingly, the data dependency graph describes the dependency relationship between variable definitions and uses in the program; the node (Node) represents the definition or use of a variable; and the edge (Edge) represents that the use of a certain variable depends on a certain definition.

[0095] The expansion processing of the plurality of candidate operation behavior sequences based on the preset control flow graph and the preset data dependency graph can be performed through the following steps, but is not limited thereto:

[0096] Step 1, constructing a control flow graph (CFG): CFG is a basic structure for static analysis. Each node of CFG is a basic block BasicBlock. CFG shows the execution paths between each basic block in the program, helping to understand the execution order of the program. CFG is a directed graph CFG= (B, E), where B is a set of basic blocks BasicBlock, and E is the control flow edge between basic blocks; BasicBlock refers to a continuous and longest 3AC instruction sequence, which has the following characteristics: control flow can only enter from the start instruction of the sequence, and control flow can only exit from the last instruction of the sequence; (3AC instruction sequence: refers to that the instructions can contain at most three addresses: variable name (such as a, b, c), constant (such as the number 3), and temporary variable generated by the compiler (such as temp1), and requires that there is at most one operator on the right side of an instruction.)

[0097] Step 2, constructing a data dependency graph DDG: used to show the dependency paths between basic blocks BasicBlock, helping to understand the execution order and data flow of the program.

[0098] Extracting a basic block set B: the control flow graph can be generated by existing tools, such as Android and backend code, using the compiled java source file through Soot to extract all basic blocks BasicBlock of the method to be analyzed.

[0099] Building a data flow table (DFT): a table recording the variable definition and use relationship, helping to identify the lifetime and dependency relationship of variables.

[0100] Module analysis: extracting the basic block set (BasicBlocks) in the module, and initializing an empty data dependency graph set for each basic block

[0101] Initializing data flow tracking: initializing the data flow tracking set DFT for recording data flow dependency relationship.

[0102] Basic block iteration: For each basic block in the module, extract the set of instructions it contains

[0103] Instruction value extraction and data flow tracking: For each instruction, determine if it is a definition instruction. If the instruction is a definition instruction, extract the value val it defines and initialize an empty data flow tracking set DFTval for this value.

[0104] General instruction processing: If the instruction is of a general type, extract its value val and operands ops again and insert the data flow relationship into the data flow tracking set DFT.

[0105] Use and dependence relationship update: For each use of the instruction, query the data flow tracking set DFT to get the definition instruction def and identify the basic block it belongs to, as shown in Table 2 below:

[0106] Table 2

[0107]

[0108] Step 3, Build the data dependence graph DDG: After identifying the representation DFT of the definition and use positions of variables in the program, the data dependence graph DDG can be constructed. The nodes in the DDG represent variables or expressions in the program, and the edges represent the dependence relationship between variables. For example, if the value of variable b depends on variable a, there will be an edge from a to b in the DDG.

[0109] Build the DDG directed graph: D = (V, ED), where V is the set of variables and expressions, and ED is the set of dependence relationships. For each variable v ∈ V, if the value of v depends on variable u, there is an edge (u, v) ∈ ED, as shown in Table 3 below:

[0110] Table 3

[0111]

[0112] In Table 3, B1 is the starting node because a = 1 has no dependence; B2 depends on B1 because b = a + 2 depends on a; B3 depends on B2 because c = b * 3 depends on b; B4 depends on B3 because d = c - 4 depends on c.

[0113] Step 4, Build the control dependence graph CDG:

[0114] Add entry and exit nodes: Add a new entry node r to the control flow graph CFG, and create an edge r→s pointing to the starting node s, indicating that the program may enter G. Add an edge r→exit pointing to the exit node exit, indicating that the program may not execute G.

[0115] Constructing the reverse control flow graph G': create a reverse control flow graph G', where G' has an edge y→x whenever G has an edge x→y. The start node of G' corresponds to the exit node of G.

[0116] Constructing the dominator tree of the reverse graph: construct the dominator tree of G', whose root node corresponds to the exit node of G. Definition of domination: in G', d dominates n if and only if all paths from the root node (exit of the original CFG) to n must pass through d.

[0117] Calculate the dominator frontier DF_G'(y): determine those nodes that are dominated by the predecessors of y but not by y itself, and add them to the set.

[0118] Constructing the control dependence graph: generate CDG edges, there is an edge x→y in CDG if and only if x∈DF_G'(y).

[0119] Step 4, generate program executable paths to guide fuzz testing.

[0120] Recording the constraint conditions corresponding to the path: identifying conditional branches, recording the constraint conditions of the branch, and triggering the specific output behavior of the part of the program. Thus, we can generate test cases to trigger some complex data or control dependence relationships, and thus obtain test cases. The expanded complete test case set is S, which is shown in Table 4 as an example:

[0121] Table 4

[0122]

[0123] In some scenarios, we can quickly generate test cases by providing constraint conditions and using constraint solving.

[0124] In complex scenarios, this method may become difficult. At this time, we can combine large models to generate test cases that meet the constraint conditions. Or only use the constraint condition set to manually generate test cases for this part. Here, we will not repeat it.

[0125] Further, when performing important level evaluation of multiple target test cases from multiple dimensions to obtain the important level of multiple target test cases, the following steps can be used, but are not limited to, as shown in Figure 5 , including:

[0126] Step 501, obtaining historical test case execution data and historical fault data in a preset time period, determining the execution times of each target test case in the historical test case execution data, and evaluating the first score of each target test case in the business impact dimension based on the execution times.

[0127] In the embodiments of the present application, the specific steps of the service impact dimension evaluation of the page function area block can include:

[0128] Step 1, collect data: pull the execution records of historical core process test cases (case ID, execution time, belonging page, belonging function area block).

[0129] Step 2, set time window: select a reasonable period (such as the last 90 days) to ensure data timeliness. Adopt sliding window mechanism to update regularly (such as automatic rolling coverage of old data every week).

[0130] Step 3, count the execution frequency of test cases: for each test case, count the number of executions within the time window. Aggregate by block, and count the total number of executions of all associated test cases.

[0131] Step 4, calculate the business impact of the page function area block by formula seven : convert the execution times of the page function area block to 0-1 business impact , formula seven is as follows:

[0132] (Formula seven)

[0133] In formula seven, represents the business impact of the page function area block , ranging from [0, 1]. represents the execution times of the corresponding function block, represents the maximum value of all module execution times, represents the minimum value of all module execution times. Set the business impact level: Set P0 level in the range of [0.75, 1]; Set P1 level in the range of [0.25~0.75); Set P2 level in the range of [0~0.25).

[0134] Step 502, analyze a plurality of fault indicator data corresponding to each target test case from historical fault data, and evaluate a second score of each target test case in the historical fault dimension based on the plurality of fault indicator data.

[0135] Among them, the plurality of fault indicator data at least includes one or more of the function impact range, the fault duration, the user impact scale and the fault times.

[0136] In some examples, the historical fault dimension evaluation of page functional blocks can specifically establish a three-dimensional assessment model for accident level (impact scope, duration, and user scale), and combine historical fault data to perform operation path risk prediction (linear) for evaluation. Specific steps may include:

[0137] Step 1. Data collection: Historical failure data: Record detailed indicator data for each failure event (affected page function block, accident time, number of affected users, accident end time, etc.).

[0138] Step 2: Data Indicators: Functional Impact : Quantify the extent of the fault impact, calculated as the number of affected modules / total number of system modules (value range 0~1, the larger the value, the wider the impact). : Measures the damage to business continuity caused by a fault, recording the time from the fault occurrence to repair (unit: hours, the larger the value, the higher the risk), calculated as (current repair time / maximum historical duration). User impact scale : Assess the damage to user experience, calculated as the number of active users at the time of failure / system historical peak DAU (value range 0~1, the larger the value, the more users are affected). Number of failures

[0139] Step 3. Weight allocation: Assign weights based on business priorities (e.g., 20% for functional impact range, 30% for fault duration, and 50% for user impact scale).

[0140] Step 4: Calculate the historical fault score of the page functional block based on Formula 8. Formula 8 is as follows:

[0141] = *20%+ *30%+ *50% (Formula 8)

[0142] In Formula 8: Indicates a page fault The historical fault score of the , range is [0,1]. Indicates a fault The functional impact range, Indicates the corresponding fault duration, Indicates the corresponding fault The scale of user impact.

[0143] Step 4: Set the historical fault level: Set the P0 level in the range [0.75,1]; Set the P1 level within the range of [0.25~0.75); P2 level is set in the range of [0~0.25).

[0144] In step 503, a third score of each target test case in the behavior heat dimension is evaluated based on the frequency of use of the functional area block of the user, the path conversion rate and the frequency of calling the functional area block in the behavior log, and a fourth score of each target test case in the risk level dimension is evaluated based on the preset risk level corresponding to the functional area block.

[0145] User behavior heat of the page functional area block: analyze the functional access mode in the buried point log, calculate the real-time user path conversion rate and the frequency of calling the function (sliding window statistics)

[0146] For example, the window mechanism is configured: a multi-level time window is set: a short window (5 minutes): real-time monitoring of sudden traffic; a medium window (1 hour): observing trend changes; a long window (24 hours): establishing a baseline; a sliding step = 50% of the window length (such as 5-minute window sliding every 2.5 minutes); core index calculation: access times of functional area block i ; determine the path conversion rate by formula nine: predefine the key conversion path (such as the registration process: start page->mobile verification->perfect data->complete); use the state machine model to track the user path completion

[0147] Conversion rate = number of users completing the path / number of users entering the first node (formula nine)

[0148] Further, the user behavior heat of the page functional area block is calculated by formula ten, and formula ten is specifically as follows:

[0149] (formula ten)

[0150] Wherein: represents the use frequency of the page functional module , ranging from 0 to 1. represents the access times of the functional area block , represents the conversion rate of the functional area block , and represents the conversion rate of the functional area block .

[0151] Further, the user behavior heat level of the page functional area block is set as follows: P0 level is set in the range of [0.75, 1]; P1 level is set in the range of [0.25~0.75); P2 level is set in the range of [0~0.25).

[0152] In the embodiments of the present application, the preset risk level can be determined based on a function risk level setting rule, including: high risk P0 level: the use case (such as password encryption, payment amount verification) involving security, data integrity, fund transaction and the like has the highest priority. Medium risk P1 level: the function in the core process and branch is set to the medium risk level. Low risk P2 level: the interface style and the text that does not affect the function are set to the low level.

[0153] Step 504, based on the first score of the business impact dimension, the second score of the historical failure dimension, the third score of the behavior heat dimension and the fourth score of the risk level dimension, the importance level of each target test case is evaluated.

[0154] In some examples, the priority score of each function can be dynamically calculated according to the business impact , user behavior heat , historical failure , risk level , and then the importance level of each target test case is evaluated, which can include the following steps:

[0155] Step 1, implicit relationship table (priority baseline)

[0156] According to the reasonable relationship between the indexes defined by business experience, the priority is adjusted as the baseline, which is shown in the following table 5:

[0157] Table 5

[0158]

[0159] Step 2, dynamically adjust the priority (superimpose other indexes) -- the basic priority, frequency of use and historical failure are verified with each other to adjust the priority

[0160] Step 2.1, correlation analysis of basic priority and historical failure times:

[0161] Statistical method: group by basic priority, calculate the average failure times of each group by formula eleven, and formula eleven is shown as follows:

[0162] (Formula eleven)

[0163] Expected result: if the failure rate of the use case with the basic priority P2 is significantly higher than that of P1 / P0, it means that it is unreasonable to rely on the basic priority only, for example, as shown in the following table 6:

[0164] Table 6

[0165]

[0166] Conclusion: P2 use cases have the highest average failure rate, indicating that base priority alone is not effective in identifying high-risk use cases.

[0167] Step 2.2, Correlation analysis between frequency of use and number of failures:

[0168] Hierarchical statistics: Under the frequency of use level (P0 / P1 / P2), calculate the failure rate of each group by Formula Twelve, which is shown as follows:

[0169] (Formula Twelve)

[0170] Expected results: High-frequency use (P0) use case failure rate should be significantly higher than low-frequency (P2), as shown in the following Table 7:

[0171] Table 7

[0172]

[0173] Conclusion: The higher the frequency of use, the higher the failure rate, which needs to be included in the priority model.

[0174] Step 2.3, Priority adjustment rules, where the rule adjustment calculation formula is shown as Formula Thirteen, and the base priority can be (P_{\text{base}}}: P0=3, P1=2, P2=1: Calculate the frequency of use correction value by Formula Fourteen , calculate the historical failure correction value by Formula Fifteen,

[0175] (Formula Thirteen)

[0176] (Formula Fourteen)

[0177] (Formula Fifteen)

[0178] Step 2.4, Final priority mapping, as shown in the following Table 8:

[0179] Table 8

[0180]

[0181] Step 3, Abnormal use case elimination rules

[0182] 3.1, Directly eliminate abnormal types, the following combinations are considered invalid or contradictory data, directly eliminated or require re-evaluation, as shown in the following Table 9:

[0183] Table 9

[0184]

[0185] Step 3.2, the type of abnormality that needs to be manually reviewed, such as shown in Table 10 below:

[0186] Table 10

[0187]

[0188] Optionally, after performing the "determining a detection order of a plurality of target test cases in descending order according to the importance level, and sequentially performing fault detection on the plurality of target test cases based on the detection order", the following steps, but not limited to, can be adopted, including: in response to detecting that there is a faulty test case in the plurality of target test cases, performing replacement processing on the faulty test case in the current test case version to update the current test case version to the next test case version.

[0189] For example, the automated test case execution can be based on a knowledge base to build a standardized MCP Prompt, which can include the following steps:

[0190] Step 1 (input): affected test cases with priority full-quantity containing operation step sequence (i.e. a plurality of target test cases in the embodiments of the present application) ;

[0191] Step 2 (knowledge base): mapping relationship containing standardized operation templates and MCP protocol command words, such as commonly used operation templates such as "click button", "input text", and corresponding rules of interface elements and MCP command format.

[0192] Step 3 (processing): the system traverses each operation sequence, obtains the corresponding command template from the knowledge base according to the operation type, and fills in the specific element identifier or operation parameter to generate a unified standard MCP protocol prompt word (Prompt). For example, for click button, input text and other operations, construct a prompt word format that conforms to the MCP protocol specification to ensure that the subsequent generated instruction statements are consistent and can be parsed.

[0193] Step 4 (output): the standardized MCP protocol Prompt text generated by Formula 16 describes the complete test execution task, which is used as the input of the AI large model to generate the MCP instruction sequence, and Formula 16 is as follows:

[0194] (Formula 16)

[0195] In Formula 16, is the knowledge base mapping, containing operation templates and element metadata, is the template filling function, which maps the "operation type" and "target element" in each operation step to the corresponding placeholders according to the MCP command template defined in the knowledge base.

[0196] Further, calling LLM-AI large model to generate MCP instruction arrangement can include the following steps:

[0197] Step 1 (input): standardized MCP protocol Prompt text , model parameter set (including model type, temperature, etc. Configuration).

[0198] Step 2 (knowledge base): define the correspondence between MCP server and operation, and load it into the AI model through the embedded model. For example: open the browser-call playwright MCP service, and the terminal operation calls the shell MCP service.

[0199] Step 3 (processing): the system calls the interface of the accessed LLM-AI large model, submits the constructed Prompt to the model for execution, and obtains the output result of the model. By specifying the task flow and instruction format requirements in the Prompt, the model returns the instruction sequence (JSON format) conforming to the MCP protocol.

[0200] Step 4 (output): the MCP instruction sequence generated by Formula Seventeen contains each instruction and its parameters according to the execution order, which is used by the automated test execution module.

[0201] (Formula Seventeen)

[0202] In Formula Seventeen, represents the large model generation function, which converts Prompt into MCP instruction sequence , and obtains MCP instruction sequence JSON format, each instruction contains "command", "target", "parameters" and other fields.

[0203] Further, through the existing MCP service to execute automated simulation test and collect logs and reports, the following steps can be included:

[0204] Step 1 (input): MCP instruction sequence generated by AI model .

[0205] Step 2 (processing): the system sends the instruction sequence to the existing MCP automated test service, and executes the instructions one by one on the test device through the service. The MCP service is responsible for completing the application startup, page navigation, element positioning, control clicking, text input, etc. During the test execution process, the system collects device logs, application return results and execution status in real time, and records and feeds back the execution result of each instruction.

[0206] Step 3 (output): Test execution log and report, including the execution status of each instruction (success or failure), error information, application screenshots, etc., to provide data basis for test result analysis.

[0207] Step 4 (input): Automated test execution results and logs.

[0208] Step 5 (processing): The system analyzes the log information of failed test cases and classifies them according to error types.

[0209] It should be noted that, as Figure 6 shown in a flowchart provided by an embodiment of the present application, after performing "determining the detection order of the plurality of target test cases in descending order of importance level, and sequentially performing fault detection on the plurality of target test cases based on the detection order", the functionality coverage detection can be performed on the plurality of target test cases. If the functionality coverage of the plurality of target test cases is comprehensive, the automatic testing can be performed. If the functionality coverage of the plurality of target test cases is not comprehensive, the test case supplement can be performed based on the plurality of target test cases, and then the detection can be performed based on the supplemented test cases.

[0210] Compared with the prior art, the embodiment can accurately determine the association relationship between the operation behavior, the functional block, and the interface based on the block behavior relationship network obtained by analyzing the user operation behavior, the functional block, and the interface based on the behavior log and the interface call log. The influence range of the code update position can be quickly and accurately analyzed based on the block behavior relationship network by identifying the code update position of the current test case version, determining the target interface set contained in the influence range based on the block behavior relationship network, and determining the influence interface set of the code update position. The target interface set corresponding to the test case in the current test case version can be selected and expanded to obtain a plurality of target test cases, and the importance level of the plurality of target test cases can be evaluated from multiple dimensions to obtain the importance level of the plurality of target test cases. Then, the detection order of the plurality of target test cases can be determined in descending order of importance level, and the fault detection can be sequentially performed on the plurality of target test cases based on the detection order. The test case with a higher importance level can be detected first in the embodiment, the important test case can be quickly detected for failure, and the fault can be found and processed in time. The detection of the expanded test case can also make the detection method of the embodiment fully and comprehensively detect the full amount of test cases, avoid missing detection and false detection, improve the detection efficiency, and also ensure the accuracy and effectiveness of the detection.

[0211] Further, as Figures 1 to 6 For a specific implementation of the method shown in the Figure 7 The device includes an acquisition module 61, an identification module 62, an evaluation module 63, and a detection module 64.

[0212] The acquisition module 61 is configured to acquire a behavior log and an interface call log of a user, analyze the association relationship between user operation behavior, function blocks, and interfaces based on the behavior log and the interface call log, and obtain a block behavior relationship network.

[0213] The identification module 62 is configured to identify a code update location of a current test case version, analyze the influence range of the code update location based on the block behavior relationship network, and determine a target interface set contained in the influence range.

[0214] The evaluation module 63 is configured to select and expand the test cases corresponding to the target interface set from the current test case version to obtain a plurality of target test cases, and perform important level evaluation on the plurality of target test cases from multiple dimensions to obtain the important levels of the plurality of target test cases.

[0215] The detection module 64 is configured to determine the detection order of the plurality of target test cases from high to low according to the important levels, and perform fault detection on the plurality of target test cases in sequence based on the detection order.

[0216] In some examples of the present embodiment, the acquisition module 61 is specifically configured to collect the interface call log through a business interface log collection platform, and acquire a behavior log sent by a client, the behavior log being acquired by the client based on a user behavior log collection platform; perform deduplication screening on the behavior log and the interface call log to obtain a function block triggered by user operation behavior, and extract an operation trigger location in the function block to obtain an interface execution path of the user; analyze the association relationship between user operation behavior, function blocks, and interfaces based on the interface execution path and the function block to obtain a block behavior relationship network.

[0217] In some examples of the present embodiment, the identifying module 62 is specifically configured to obtain a current version test case and a previous version test case, and perform code difference identification on the current version test case and the previous version test case to obtain the code update position, the current version test case being obtained based on the previous version test case; perform code parsing on the current test case version to generate a target abstract syntax tree corresponding to the current test case version, and determine a code update node corresponding to the code update position in the target abstract syntax tree; analyze the influence range of the code update node from the target abstract syntax tree based on the block behavior relationship network, and determine an influence interface set corresponding to the influence node set; and determine the influence interface set as the target interface set.

[0218] In some examples of the present embodiment, the identifying module 62 is specifically further configured to analyze a direct influence node set of the code update node from the target abstract syntax tree, perform traversal filtering on the direct influence node set in the target abstract syntax tree through a preset query function, and select nodes meeting a predetermined filtering condition to form a target direct influence node set; analyze a node dependency relationship in the target abstract syntax tree based on the block behavior relationship network, obtain an influence range of the code update node according to the node dependency relationship, determine a target indirect influence node set of the code update node based on the influence range; and form the influence node set by combining the target direct influence node set and the target indirect influence node set.

[0219] In some examples of the present embodiment, the evaluating module 63 is specifically configured to determine an operation behavior sequence corresponding to the target interface set, and a set of operation behavior sequences corresponding to the current test case version; match the similarity between the operation behavior sequence and the set of operation behavior sequences to match a plurality of candidate operation behavior sequences with a similarity greater than or equal to a predetermined similarity threshold; and perform expansion processing on the plurality of candidate operation behavior sequences based on a preset control flow graph and a preset data dependency graph to obtain the plurality of target test cases.

[0220] In some examples of the present embodiment, the evaluation module 63 is further configured to obtain historical test case execution data and historical fault data in a preset time period, determine the execution times of each target test case in the historical test case execution data, and evaluate a first score of each target test case in a business impact dimension based on the execution times; analyze a plurality of fault indicator data corresponding to each target test case from the historical fault data, and evaluate a second score of each target test case in a historical fault dimension based on the plurality of fault indicator data, wherein the plurality of fault indicator data at least includes one or more of a function impact range, a fault duration, a user impact scale, and a fault frequency; evaluate a third score of each target test case in a behavior heat dimension based on the function block usage frequency, the path conversion rate, and the function block call frequency of the user in the behavior log, and evaluate a fourth score of each target test case in a risk level dimension based on the preset risk level corresponding to the function block; and evaluate an importance level of each target test case based on the first score in the business impact dimension, the second score in the historical fault dimension, the third score in the behavior heat dimension, and the fourth score in the risk level dimension.

[0221] In some examples of the present embodiment, the detection module 64 is further configured to, in response to detecting that there is a fault test case in the plurality of target test cases, perform replacement processing on the fault test case in the current test case version to update the current test case version to a next test case version.

[0222] It should be noted that other corresponding descriptions of the functions of the test case detection device provided in the present embodiment can be referred to the corresponding descriptions in the Figures 1 to 6 , which will not be described here in detail.

[0223] Based on the above method as shown in Figures 1 to 6 , accordingly, the present embodiment also provides a computer readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above method as shown in Figures 1 to 6 .

[0224] Based on such understanding, the technical solution of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a U disk, a mobile hard disk, etc.), and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods of various implementation scenarios of the present application.

[0225] As shown in Figure 8 , it is a hardware structure schematic diagram of an electronic device, which includes:

[0226] at least one processor 701; and

[0227] a memory 702 connected with the at least one processor 701; wherein

[0228] The memory 702 stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the test case detection method as described above.

[0229] Figure 8 In the foregoing embodiments, the processor 701 is taken as an example.

[0230] The electronic device can further include an input device 703 and a display device 704.

[0231] The processor 701, the memory 702, the input device 703, and the display device 704 can be connected through a bus or other means, Figure 8 In the foregoing embodiments, the connection through the bus is taken as an example.

[0232] The memory 702, as a non-volatile computer readable storage medium, can be used to store non-volatile software programs, non-volatile computer executable programs, and modules, such as program instructions / modules corresponding to the test case detection method in the embodiments of the present application, for example, Figures 1 to 6 The method flowchart shown. The processor 701 performs various functional applications and data processing by running the non-volatile software programs, instructions, and modules stored in the memory 702, that is, implements the test case detection method in the above embodiments.

[0233] The memory 702 can include a program storage area and a data storage area, wherein the program storage area can store an operating system and application programs required by at least one function; the data storage area can store data created according to the use of the test case detection method, etc. In addition, the memory 702 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other non-volatile solid-state memory device. In some embodiments, the memory 702 can optionally include a memory remotely arranged with respect to the processor 701, and these remote memories can be connected to the device performing the test case detection method through a network. Examples of the above network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0234] The input device 703 can receive input user clicks and generate signal inputs related to user settings and functional controls of the test case detection method. The display device 704 can include a display screen and other display devices.

[0235] When the one or more modules are stored in the memory 702, when executed by the one or more processors 701, perform the detection method of the test case in any of the above method embodiments.

[0236] Optionally, the above-mentioned entity device can further include a user interface, a network interface, a camera, a radio frequency (RF) circuit, a sensor, an audio circuit, a WI-FI module, and the like. The user interface can include a display screen (Display), an input unit such as a keyboard (Keyboard), and the like. Optionally, the user interface can further include a USB interface, a card reader interface, and the like. The network interface can optionally include a standard wired interface, a wireless interface (such as a WI-FI interface), and the like.

[0237] Those skilled in the art can understand that the above-mentioned entity device structure provided by the embodiment does not constitute a limitation on the entity device, and can include more or fewer components, or combine certain components, or different component arrangements.

[0238] The storage medium can further include an operating system, a network communication module. The operating system is a program for managing hardware and software resources of the above-mentioned entity device, supporting the running of information processing programs and other software and / or programs. The network communication module is used to realize the communication between the components in the storage medium, and the communication with other hardware and software in the information processing entity device.

[0239] Through the description of the above embodiments, those skilled in the art can clearly understand that the present application can be realized by means of software with a necessary general hardware platform, or by hardware. By applying the scheme of the present embodiment, compared with the prior art, the present embodiment can accurately determine the association relationship between the operation behavior, the functional block and the interface based on the block behavior relationship network obtained by acquiring the behavior log and the interface calling log of the user, analyzing the association relationship between the operation behavior, the functional block and the interface based on the block behavior relationship network, analyzing the influence range of the code update position based on the block behavior relationship network by identifying the code update position of the current test case version, and determining the target interface set contained in the influence range, so as to quickly and accurately analyze the influence range of the code update position based on the block behavior relationship network, and further determine the influence interface set of the code update position; by selecting and expanding the test cases corresponding to the target interface set from the current test case version to obtain a plurality of target test cases, and performing important level evaluation on the plurality of target test cases from multiple dimensions to obtain the important levels of the plurality of target test cases, and further determining the detection order of the plurality of target test cases in descending order of the important levels, and sequentially performing fault detection on the plurality of target test cases based on the detection order, the present embodiment can detect the test cases with higher importance first, can quickly detect whether the important test cases have faults, and further can timely find and process faults, and the expansion of the test cases before detection can make the detection manner of the present embodiment can fully and comprehensively detect all the test cases, avoid missing detection and wrong detection, improve the detection efficiency, and further can guarantee the accuracy and effectiveness of the detection.

[0240] It should be noted that, in this document, the terms such as "first" and "second" are merely used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between the entities or operations. Moreover, the terms "include", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the processes, methods, articles or devices including a series of elements not only include those elements, but also include other elements not explicitly listed or inherent to such processes, methods, articles or devices. Without more limitations, the element defined by the statement "including a" does not exclude the presence of another identical element in the process, method, article or device including the element.

[0241] The foregoing detailed description of the application has been presented for purposes of illustration and description. Various modifications and changes can be made to these embodiments without departing from the spirit and scope of the application. It is intended that the scope of the application should not be limited by the particular representative embodiments described above.

Claims

1. A method of detecting a test case, characterized by, The method comprises the following steps: obtaining a behavior log and an interface call log of a user, analyzing user operation behavior, a functional block and an association relationship between interfaces based on the behavior log and the interface call log to obtain a block behavior relationship network; identifying a code update position of a current test case version, analyzing an influence range of the code update position based on the block behavior relationship network, and determining a target interface set contained in the influence range; selecting and expanding a test case corresponding to the target interface set from the current test case version to obtain a plurality of target test cases, and performing important level evaluation on the plurality of target test cases from multiple dimensions to obtain important levels of the plurality of target test cases; determining a detection order of the plurality of target test cases from high to low according to the important levels, and sequentially performing fault detection on the plurality of target test cases based on the detection order; wherein the method of obtaining a behavior log and an interface call log of a user, analyzing user operation behavior, a functional block and an association relationship between interfaces based on the behavior log and the interface call log to obtain a block behavior relationship network comprises: collecting the interface call log through a business interface log collection platform, and obtaining a behavior log sent by a client, wherein the behavior log is obtained by the client based on a user behavior log collection platform, and the behavior log refers to a log recording interactive operations of a user in a client; performing deduplication screening on the behavior log and the interface call log to obtain a functional block triggered by user operation behavior, and extracting an operation trigger position in the functional block to obtain an interface execution path of the user; wherein the user operation behavior is an operation of a user on a front-end interface; the functional block is a functional area in a page, and is used for fine description of user behavior position; analyzing an association relationship between user operation behavior, a functional block and an interface based on the interface execution path and the functional block to obtain a block behavior relationship network; wherein the method of selecting and expanding a test case corresponding to the target interface set from the current test case version to obtain a plurality of target test cases comprises: determining an operation behavior sequence corresponding to the target interface set, and a set of operation behavior sequences corresponding to the current test case version; matching a similarity between the operation behavior sequence and the set of operation behavior sequences to match a plurality of candidate operation behavior sequences with a similarity greater than or equal to a predetermined similarity threshold; expanding the plurality of candidate operation behavior sequences based on a preset control flow graph and a preset data dependency graph to obtain the plurality of target test cases; wherein the control flow graph is a directed graph structure representing a control transfer relationship between each basic block in a program, and the data dependency graph describes a dependency relationship between variable definitions and uses in the program.

2. The method of claim 1, wherein, the method of identifying a code update position of a current test case version, analyzing an influence range of the code update position based on the block behavior relationship network, and determining a target interface set contained in the influence range comprises: Obtaining a current version test case and a previous version test case, and performing code difference identification on the current version test case and the previous version test case to obtain the code update position, the current version test case being obtained based on the previous version test case; Performing code analysis on the current test case version to generate a target abstract syntax tree corresponding to the current test case version, and determining a code update node corresponding to the code update position in the target abstract syntax tree; Based on the block behavior relationship network, the influence range of the code update node is analyzed from the target abstract syntax tree, and an influence node set corresponding to the influence interface set is determined; The influence interface set is determined as the target interface set.

3. The method of claim 2, wherein, Based on the block behavior relationship network, the influence range of the code update node is analyzed from the target abstract syntax tree, and an influence node set contained in the influence range is determined, comprising: The direct influence node set of the code update node is analyzed from the target abstract syntax tree, and the direct influence node set is traversed and filtered in the target abstract syntax tree through a preset query function, and nodes meeting a predetermined filtering condition are selected to form a target direct influence node set; Based on the block behavior relationship network, the node dependency relationship in the target abstract syntax tree is analyzed, and the influence range of the code update node is obtained according to the node dependency relationship, and a target indirect influence node set of the code update node is determined based on the influence range; The target direct influence node set and the target indirect influence node set form the influence node set.

4. The method of claim 1, wherein, The importance level of the plurality of target test cases is evaluated from multiple dimensions, comprising: Obtaining historical test case execution data and historical fault data in a preset time period, determining the execution times of each target test case in the historical test case execution data, and evaluating a first score of each target test case in a business impact dimension based on the execution times; From the historical fault data, a plurality of fault indicator data corresponding to each target test case is analyzed, and a second score of each target test case in a historical fault dimension is evaluated based on the plurality of fault indicator data, wherein the plurality of fault indicator data includes at least one or more of a function impact range, a fault duration, a user impact scale, and a fault frequency; Based on the function block usage frequency, path conversion rate and function block call frequency of the user in the behavior log, a third score of each target test case in a behavior heat dimension is evaluated, and a fourth score of each target test case in a risk level dimension is evaluated based on a preset risk level corresponding to the function block; Based on the first score of the business impact dimension, the second score of the historical fault dimension, the third score of the behavior heat dimension, and the fourth score of the risk level dimension, the importance level of each target test case is evaluated.

5. The method of claim 1, wherein, After the detection order of the plurality of target test cases is determined according to the importance levels from high to low, and the plurality of target test cases are sequentially detected based on the detection order, the method further comprises: In response to detecting that there is a faulty test case in the plurality of target test cases, the faulty test case is replaced in the current test case version to update the current test case version to a next test case version.

6. A test case detection apparatus characterized by comprising: Comprise: An acquisition module configured to acquire a behavior log and an interface call log of a user, analyze user operation behaviors, functional block and interface association relationships based on the behavior log and the interface call log to obtain a block behavior relationship network; An identification module configured to identify a code update position of a current test case version, analyze an influence range of the code update position based on the block behavior relationship network, and determine a target interface set contained in the influence range; An evaluation module configured to select and expand test cases corresponding to the target interface set from the current test case version to obtain a plurality of target test cases, and evaluate the plurality of target test cases from multiple dimensions to obtain importance levels of the plurality of target test cases; A detection module configured to determine a detection order of the plurality of target test cases according to the importance levels from high to low, and sequentially detect the plurality of target test cases based on the detection order; The acquisition of the behavior log and the interface call log of the user, the analysis of the user operation behaviors, the functional block and the interface association relationships based on the behavior log and the interface call log to obtain the block behavior relationship network comprises: The interface call log is grabbed through a business interface log collection platform, and a behavior log sent by a client is acquired, the behavior log being acquired by the client based on a user behavior log collection platform, the behavior log being a log recording interactive operations of a user in a client; The behavior log and the interface call log are de-duplicated and screened to obtain a functional block triggered by a user operation behavior, and a trigger position in the functional block is extracted to obtain an interface execution path of the user; wherein the user operation behavior is an operation of a user on a front-end interface; the functional block is a functional area in a page, used for fine description of a user behavior position; The block behavior relationship network is obtained based on the interface execution path and the functional block analysis of the user operation behaviors, the functional block and the interface association relationships; The selection and expansion of the test cases corresponding to the target interface set from the current test case version to obtain the plurality of target test cases comprises: A sequence of operation behaviors corresponding to the target interface set is determined, and a set of sequences of operation behaviors corresponding to the current test case version is determined; The similarity between the sequence of operation behaviors and the set of sequences of operation behaviors is matched to match a plurality of candidate sequences of operation behaviors with a similarity greater than or equal to a predetermined similarity threshold. The plurality of candidate operation behavior sequences are expanded based on a preset control flow graph and a preset data dependency graph to obtain the plurality of target test cases; wherein the control flow graph is a directed graph structure representing the control transfer relationship between each basic block in the program, and the data dependency graph describes the dependency relationship between variable definition and use in the program.

7. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program, when executed by a processor, implements the method of any one of claims 1 to 5.

8. An electronic device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, The processor, when executing the computer program, implements the method of any one of claims 1 to 5.

Images