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

Abstract

The invention discloses a test case detection method and device, a storage medium and electronic equipment, and relates to the technical field of computers, and the method comprises the steps: analyzing a user operation behavior based on a behavior log and an interface call log, and obtaining a block behavior relationship network according to an association relationship among functional blocks and interfaces; identifying a code updating position of the current test case version, analyzing an influence range of the code updating position based on the block behavior relation network, and determining a target interface set contained in the influence range; selecting test cases corresponding to the target interface set from the current test case version and performing expansion processing to obtain a plurality of target test cases, and performing importance level evaluation on the plurality of target test cases from a plurality of dimensions to obtain importance levels of the plurality of target test cases; and determining a detection sequence of the plurality of target test cases according to the importance levels from high to low, and performing fault detection on the plurality of target test cases in sequence based on the detection sequence. The detection efficiency can be improved.

Description

Technical Field

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

[0002] In today's software development cycle, test case testing is a critical step in ensuring software quality. Test cases are designed to verify that software functionality, performance, security, and other key features meet expectations. This is crucial for discovering and fixing potential defects, helping to improve the stability of the final product and user experience.

[0003] At present, manual testing is widely used in related technologies to test test cases. That is, relying on the professional knowledge and experience of test engineers or experts in related fields, the integrity, accuracy, effectiveness and operability of test cases are comprehensively tested, and manual adjustments are made accordingly.

[0004] However, this approach relies heavily on the expertise of professionals. As the number of test cases increases, the time and human resources required for review and modification also increase dramatically, resulting in a significant labor cost burden. Furthermore, the subjectivity of manual testing can affect the accuracy and timeliness of test results, making it difficult to provide timely and accurate adjustment suggestions to optimize test plans. Manual testing also carries the risk of missing critical information, further reducing the accuracy and effectiveness of corrections. Summary of the Invention

[0005] In view of this, the present application provides a test case detection method, device, storage medium, and electronic device, the main purpose of which is to improve the current existing technology, which relies heavily on the professional experience of professionals. As the number of test cases increases, the time and human resources required for review and modification also increase dramatically, resulting in a significant labor cost burden. In addition, the manual detection process has a certain degree of subjectivity, which may affect the accuracy and timeliness of the test results, making it difficult to provide accurate adjustment suggestions in a timely manner to optimize the test plan. There is also a risk of missing key information during the manual detection process, further reducing the accuracy and effectiveness of the correction.

[0006] In a first aspect, the present application provides a method for detecting a test case, comprising: Obtaining the user's behavior log and interface call log, and analyzing the association between the user's operation behavior, functional blocks, and interfaces based on the behavior log and the interface call log to obtain a block behavior relationship network; Identify the code update location of the current test case version, analyze the impact range of the code update location based on the block behavior relationship network, and determine the target interface set included in the impact range; Selecting and expanding test cases corresponding to the target interface set from the current test case version to obtain a plurality of target test cases, and evaluating the importance levels of the plurality of target test cases from multiple dimensions to obtain importance levels of the plurality of target test cases; A detection order of the multiple target test cases is determined from high to low according to the importance levels, and fault detection is performed on the multiple target test cases in sequence based on the detection order.

[0007] In a second aspect, the present application provides a test case detection device, comprising: an acquisition module configured to acquire a user's behavior log and an interface call log, and analyze the association between the user's operation behavior, the functional blocks, and the interfaces 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 location of a current test case version, analyze an impact range of the code update location based on the block behavior relationship network, and determine a target interface set included in the impact 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 to evaluate the importance levels of the plurality of target test cases from a plurality of dimensions to obtain importance levels of the plurality of target test cases; The detection module is configured to determine a detection order of the multiple target test cases according to the importance levels from high to low, and perform fault detection on the multiple target test cases in sequence based on the detection order.

[0008] In a third aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the test case detection method described in the first aspect.

[0009] 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 implements the test case detection method described in the first aspect when executing the computer program.

[0010] By means of the above technical solution, the present application provides a test case detection method, device, storage medium and electronic device. Compared with the current existing technology, the present application obtains the user's behavior log and interface call log, and analyzes the relationship between the user's operation behavior, functional blocks and interfaces based on the behavior log and interface call log to obtain a block behavior relationship network. Based on the block behavior relationship network, the relationship between the operation behavior, functional blocks and interfaces can be accurately determined. By identifying the code update position of the current test case version, analyzing the impact range of the code update position based on the block behavior relationship network, and determining the target interface set included in the impact range, the present application can quickly and accurately analyze the impact range of the code update position based on the block behavior relationship network, and then determine the affected interface set of the code update position; by In the previous test case version, the test cases corresponding to the target interface set are selected and expanded to obtain multiple target test cases, and the importance levels of the multiple target test cases are evaluated from multiple dimensions to obtain the importance levels of the multiple target test cases, and then the detection order of the multiple target test cases is determined from high to low according to the importance levels, and fault detection is performed on the multiple target test cases in sequence based on the detection order. This allows the present application to give priority to testing test cases with higher importance, and can quickly detect whether important test cases have faults, and then can promptly discover and handle faults. Expanding the test cases and then performing detection can also enable the detection method of the present application to fully and comprehensively detect all test cases, avoid missed detections and false detections, improve detection efficiency, and ensure the accuracy and effectiveness of detection. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0012] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0013] Figure 1 A flow chart showing a method for detecting a test case provided in an embodiment of the present application is shown; Figure 2 A flow chart showing a method for detecting a test case provided in an embodiment of the present application is shown; Figure 3 A flow chart showing a method for detecting a test case provided in an embodiment of the present application is shown; Figure 4A flow chart showing a method for detecting a test case provided in an embodiment of the present application is shown; Figure 5 A flow chart showing a method for detecting a test case provided in an embodiment of the present application is shown; Figure 6 A schematic diagram of an example process provided by an embodiment of the present application is shown; Figure 7 A schematic diagram of the structure of a detection device for a test case provided in an embodiment of the present application is shown; Figure 8 A schematic structural diagram of an electronic device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0014] The embodiments of the present application will be described in more detail below with reference to the accompanying drawings. It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other.

[0015] To improve existing technologies, professional experience of professionals is relied upon to a great extent. As the number of test cases increases, the time and human resources required for review and modification also increase dramatically, resulting in a significant burden on human costs. In addition, the manual inspection process is subjective to a certain extent, which may affect the accuracy and timeliness of the test results, making it difficult to provide accurate adjustment suggestions in a timely manner to optimize the test plan. There is also a risk of missing key information during the manual inspection process, which further reduces the accuracy and effectiveness of the correction. This embodiment provides a method for detecting test cases, such as Figure 1 As shown, the method includes: Step 101: Obtain the user's behavior log and interface call log, and analyze the association between the user's operation behavior, functional blocks and interfaces based on the behavior log and interface call log to obtain a block behavior relationship network.

[0016] In the embodiments of the present application, user behavior logs refer to logs that record the interactive operations performed by users in the client (such as Web / H5 / APP), which are usually collected through tracking points; correspondingly, interface call logs are used to record HTTP request information between back-end services, or between the front-end and back-end, and are usually collected uniformly by gateways, middleware or AOP aspects.

[0017] In some examples, user actions on the front-end interface, such as button clicks, swipes, and input, are typically collected through tracking. A module (or block) can be a functional area on a page, such as the "homepage recommendation" section or the "shopping cart checkout button," used to granularly describe the location of user actions. An API interface can be an HTTP interface provided by the backend, which is called by the front-end or other microservices to complete tasks such as data requests and status updates.

[0018] For example, the relationship between user operation behavior, functional blocks, and interfaces can correspond to: the user clicks the "Add to Cart" button (operation behavior); the button belongs to the "Product Details Page - Shopping Cart Function Block" (functional block); after clicking, the / api / cart / add interface call is triggered (interface).

[0019] Step 102: Identify the code update location of the current test case version, analyze the impact range of the code update location based on the block behavior relationship network, and determine the target interface set included in the impact range.

[0020] In this embodiment of the present application, the code update location of the current test case version can be the source code related to the test case, including the specific files and code line numbers that have changed between different versions. These changes may directly affect the behavior or expected results of the test case, and are therefore particularly important in regression testing or impact analysis.

[0021] Step 103: Select and expand the test cases corresponding to the target interface set from the current test case version to obtain multiple target test cases, and evaluate the importance levels of the multiple target test cases from multiple dimensions to obtain the importance levels of the multiple target test cases.

[0022] In an embodiment of the present application, test case expansion can be performed based on a control flow graph and a data dependency graph. A control flow graph is a directed graph structure that represents the control transfer relationship between basic blocks in a program. A node represents a "basic block," i.e., a section of sequentially executed code without branches. An edge represents the transfer of control flow from one basic block to another. Correspondingly, a data dependency graph describes the dependency relationship between variable definitions and uses in a program. A node represents the definition or use of a variable, and an edge indicates that the use of a variable depends on a definition.

[0023] In some examples, the multiple dimensions may include a business impact dimension, a historical failure dimension, a behavior heat dimension, and a risk level dimension.

[0024] Step 104 : Determine a detection order for the multiple target test cases according to their importance levels from high to low, and perform fault detection on the multiple target test cases in sequence based on the detection order.

[0025] Compared with the current existing technology, this embodiment obtains the user's behavior log and interface call log, analyzes the relationship between the user's operation behavior, functional blocks and interfaces based on the behavior log and interface call log to obtain a block behavior relationship network. Based on the block behavior relationship network, the relationship between the operation behavior, functional blocks and interfaces can be accurately determined. By identifying the code update position of the current test case version, analyzing the impact range of the code update position based on the block behavior relationship network, and determining the target interface set included in the impact range, this embodiment can quickly and accurately analyze the impact range of the code update position based on the block behavior relationship network, and then determine the affected interface set of the code update position; by converting the test corresponding to the target interface set from the current test case version to the test Use cases are selected and expanded to obtain multiple target test cases, and the importance levels of the multiple target test cases are evaluated from multiple dimensions to obtain the importance levels of the multiple target test cases, and then the detection order of the multiple target test cases is determined from high to low according to the importance levels, and fault detection is performed on the multiple target test cases in sequence based on the detection order. This allows the present embodiment to give priority to the detection of test cases with higher importance, and can quickly detect whether important test cases have faults, and then can promptly discover and handle the faults. Expanding the test cases for further detection can also enable the detection method of this embodiment to fully and comprehensively detect all test cases, avoid missed detections and false detections, improve detection efficiency, and ensure the accuracy and effectiveness of detection.

[0026] As a refinement and extension of the above embodiment, when obtaining the user's behavior log and interface call log, and analyzing the relationship between the user's operation behavior, functional blocks and interfaces based on the behavior log and interface call log to obtain the block behavior relationship network, the following methods can be used but are not limited to: Figure 2 As shown, the method includes: Step 201: Capture the interface call log through the business interface log collection platform, and obtain the behavior log sent by the client.

[0027] Among them, the behavior log is obtained by the client based on the user behavior log collection platform.

[0028] In the embodiment of the present application, the user behavior log can be used to collect user historical behavior data through the user behavior log collection platform, including the activity behavior data generated by the user using the APP or front-end page. In some examples, the standard definition of tracking logs may include: 1. Unified log format requirements: Each log must contain user ID, operation timestamp, page name, function block name, operation location, 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. The log format can be specifically expressed as follows:

[0029] (Formula 1) In formula 1: Represents each log; uuId represents a distributed unique identifier with a time component; Indicates the user ID (using the user primary key in the database); sessionId represents a continuous operation session, which facilitates the reconstruction of the user behavior path; For timestamps, use ISO-8601 with time zone to ensure cross-system parsing consistency, millisecond-level accuracy, and monotonically increasing values. Unique identifier for the application; A page that uniquely identifies an application; A functional block that uniquely identifies a page; Uniquely identifies an operation location of an application.

[0030] For example, in a real business scenario, user behavior can be represented by a hierarchical recording caliber. For example, the SPM data used to record the location of user behavior on the client usually has a recording caliber with gradually finer granularity from top to bottom, such as site, page, functional block, and location. For example, assuming that a site has an average of L pages, a page has an average of M functional blocks, and a functional block has an average of N locations, then a user's behavior can be schematically represented as a vector like this: (i, j, k), where i is the i-th page in the L pages, j is the j-th functional block in the M functional blocks, and k is the k-th position in the N positions.

[0031] For example, three corresponding dictionary tables can be established for page, function block, and operation position, for example: Page: Homepage = A1, Product Page = A2, Shopping Cart Page = A3; Function Block: Jacket Function Block = M1, Shoe Function Block = M2, Mobile Phone Function Block = M3; Operation Position: First Position in Sequence = L1 For this embodiment, log preprocessing and session reconstruction are performed, specifically: obtaining multiple consecutive actions of the first user, wherein the time interval between two consecutive actions in the multiple actions is less than a predetermined time length. (Initially set at 30 minutes) is considered as continuous behavior and has a high correlation On the contrary, if it exceeds, it is considered to be two unrelated behaviors, that is, different functional blocks, for example, ,in:

[0032] Step 202: De-duplicate the behavior log and the interface call log to obtain the function block triggered by the user operation behavior, and extract the operation trigger position in the function block to obtain the user's interface execution path.

[0033] Optionally, capture business log records through the business interface log collection platform. The initial log content includes: ; Then, the unique function block (module) name is determined by deduplication and filtering through the traceID+SpanId unique key. Under the function block (module), each interfaceUrl path (i.e., the interface execution path in the embodiment of the present application) will be printed based on the user-triggered location (i.e., the operation trigger location in the embodiment of the present application). Each interfaceUrl is recorded as I, and there is a sequence. Therefore, based on this, the interface list corresponding to the function block (module) can be generated interfaceUrlList-module=[I1, I2, I3...].

[0034] Step 203: Analyze the user operation behavior, the association relationship between the function block and the interface based on the interface execution path and the function block to obtain a block behavior relationship network.

[0035] In some examples, the above operation will filter out the interface list that is not related to the current operation. Therefore, it is necessary to perform a secondary intersection filter based on the timestamp parameter interfaceUrlList-module-timestamp = [It1, It2, It3...], and then output the complete user block behavior function interface association log, as shown in the following formula 2:

[0036] (Formula 2) At this point, the user's block information behavior interface relationship network G is formed, as shown in Table 1 below: Table 1

[0037] Furthermore, when identifying the code update location of the current test case version, analyzing the impact range of the code update location based on the block behavior relationship network, and determining the target interface set included in the impact range, the following steps may be adopted but are not limited to: Figure 3 Shown, including: Step 301: Obtain a current version test case and a previous version test case, identify code differences between the current version test case and the previous version test case, and obtain a code update location.

[0038] Among them, the current version test case is updated based on the previous version test case.

[0039] In an embodiment of the present application, code difference identification between the current version test case and the previous 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.

[0040] For example, two versions of the code base can be entered , ; via git diff , Extract the changed files of the two versions With line number .

[0041] Step 302: parse the code of the current test case version, 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.

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

[0043] For example, let the set of grammatical elements of program P be E, then AST is a tree ; is a set of nodes, corresponding to the set of grammatical elements E; It is a set of directed edges, representing the parent-child relationship, and is based on the change files of two versions. With line number Get the changed position set .

[0044] 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.

[0045] 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.

[0046] 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).

[0047] 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: (Formula 3) In formula 3, It represents the reachable node set from the node set S on the dependency graph G, and performs BFS breadth-first calculation to obtain the full impact set:

[0048] Step 304: Determine the impact interface set as the target interface set.

[0049] Optionally, when selecting and expanding the test cases corresponding to the target interface set from the current test case version to obtain multiple target test cases, the following methods may be used but are not limited to: Figure 4 As shown, the method includes: 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.

[0050] In this embodiment, dynamic time warping (DTW) can be used to match typical user operation paths, identify user behavior sequences, and identify specific use cases. Dynamic Time Warping (DTW) is an algorithm used to measure the similarity between two time series. It is particularly suitable for comparing time series data of varying lengths or speeds, such as in speech recognition and gesture recognition.

[0051] Step 402: Match the similarity between the operation behavior sequence and the operation behavior sequence set to obtain a plurality of candidate operation behavior sequences having similarity greater than or equal to a predetermined similarity threshold.

[0052] For this embodiment, determining the set of operation behavior sequences corresponding to the current test case version may include, but is not limited to, the following steps: Step 1: Number the user's historical behavior sequence Define 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 ; Functional block: Possible values are ; Position: Possible values are .

[0053] Encoding representation: For each feature, define a one-hot encoding function , as shown in the following formula 4: (Formula 4) 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: (Formula 5) Step 2: Generate behavior sequence vector representation 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 .

[0054] Step 3: Generate user historical behavior sequence: 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: (Formula 6) 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) 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.

[0055] In the embodiments of this application, a control flow graph is a directed graph structure that represents the control transfer relationship between basic blocks in a program. A node represents a "basic block," that is, a section of sequentially executed code without branches. An edge represents the transfer of control flow from one basic block to another. Correspondingly, a data dependency graph describes the dependency relationship between variable definitions and uses in a program. A node represents a variable definition or use, and an edge indicates that the use of a variable depends on a certain definition.

[0056] Expanding multiple candidate operation behavior sequences based on a preset control flow graph and a preset data dependency graph to obtain multiple target test cases can be performed by, but is not limited to, the following steps: Step 1. Construct a control flow graph (CFG): CFG is the fundamental structure used for static analysis. Each node in the CFG is a BasicBlock. The CFG shows the execution paths between basic blocks in a program, helping to understand the execution order of the program. CFG is a directed graph CFG = (B, E), where B is the set of BasicBlocks and E is the control flow edges between BasicBlocks. A BasicBlock is a continuous, longest 3AC instruction sequence with the following properties: 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. (A 3AC instruction sequence refers to an instruction that can contain at most three types of addresses: variable names (such as a, b, c), constants (such as the number 3), and compiler-generated temporary variables (such as temp1). Each instruction must have at most one operator on its right side.) Step 2: Build a data dependency graph (DDG): This graph is used to show the dependency paths between basic blocks, helping to understand the execution order and data flow of the program.

[0057] Extracting basic block set B: Control flow graphs can be generated through existing tools, such as Android and backend code, and all basic blocks BasicBlock of the method to be analyzed can be extracted using the compiled Java source file through Soot.

[0058] Build a data flow table (DFT): a table that records variable definitions and usage relationships, helping to identify the variable life cycle and dependencies.

[0059] Module analysis: Extract the basic block set (BasicBlocks) in the module and initialize an empty data dependency graph set for each basic block Initialize data flow tracking: Initialize the data flow tracking set DFT to record data flow dependencies.

[0060] Basic block iteration: For each basic block in the module, extract the set of instructions it contains Instruction value extraction and data flow tracking: For each instruction, determine whether it is a defined instruction. If the instruction is a defined instruction, extract its defined value val and initialize the empty data flow tracking set DFTval of the value. General instruction processing: If the instruction is of a general type, its value val and operand ops are extracted again, and the data flow relationship is inserted into the data flow tracking set DFT.

[0061] Usage query and dependency update: For each use of an instruction, query the data flow trace set DFT to obtain the definition instruction def and identify the basic block to which it belongs, as shown in Table 2 below: Table 2

[0062] Step 3: Construct a Data Dependency Graph (DDG): After identifying the definition and usage locations of variables in the program (DFT), a data dependency graph (DDG) can be constructed. Nodes in the DDG represent variables or expressions in the program, and edges represent dependencies 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.

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

[0064] In Table 3, B1 is the starting node because a=1 has no dependency; 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.

[0065] Step 4: Build the control dependency graph CDG: 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 start 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.

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

[0067] Construct the dominator tree of the reverse graph: Construct the dominator tree of G', where the root node of the dominator tree corresponds to the exit node of G. Definition of dominance: In G', d dominates n if and only if all paths from the root node (the exit of the original CFG) to n must pass through d.

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

[0069] Construct a control dependency graph: Generate CDG edges. An edge x→y exists in CDG if and only if x∈DF_G'(y).

[0070] Step 4: Generate the program executable path to guide fuzz testing.

[0071] Record the constraints of the corresponding path: Identify conditional branches and record the constraints of the branches to trigger specific output behaviors of some program links. This allows for targeted test case generation, triggering some complex data or control dependencies, and thus deriving test cases. The expanded complete test case set is S, which can be shown in Table 4 as an example: Table 4

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

[0073] However, in complex scenarios, this approach may become difficult. In these cases, you can combine a large model to generate test cases that meet the constraints. Alternatively, you can manually generate test cases for this part using only the constraint set. I will not go into detail here.

[0074] Furthermore, when evaluating the importance levels of multiple target test cases from multiple dimensions to obtain the importance levels of multiple target test cases, the following steps may be adopted but are not limited to: Figure 5 Shown, including: Step 501: Obtain historical test case execution data and historical fault data within a preset time period, determine the number of executions of each target test case in the historical test case execution data, and evaluate the first score of each target test case in the business impact dimension based on the number of executions.

[0075] In the embodiment of the present application, the specific steps of evaluating the business impact dimension of the page function block may include: Step 1. Collect data: Pull the execution records of historical core process test cases (case ID, execution time, page to which it belongs, and functional block to which it belongs).

[0076] Step 2: Set the time window: Choose a reasonable period (e.g., the last 90 days) to ensure data timeliness. Use a sliding window mechanism for regular updates (e.g., automatically rolling over old data every week).

[0077] 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.

[0078] Step 4: Calculate the business impact of the page functional blocks using Formula 7 : Convert the number of page function block executions into 0-1 business impact , Formula 7 is as follows: (Formula 7) In Formula 7, Indicates the page functional block The business impact is in the range of [0, 1]. Indicates the number of times the corresponding function block is executed. Indicates the maximum number of execution times of all modules. Indicates the minimum number of execution times of all modules. Set the business impact level: Set the P0 level in the range [0.75,1]; Set the P1 level within the range of [0.25~0.75); Set the P2 level in the range of [0~0.25).

[0079] Step 502: Analyze the historical fault data to obtain multiple fault indicator data corresponding to each target test case, and evaluate the second score of each target test case in the historical fault dimension based on the multiple fault indicator data.

[0080] The multiple fault indicator data include at least one or more of function impact range, fault duration, user impact scale and number of faults.

[0081] 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: 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.).

[0082] 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

[0083] 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).

[0084] Step 4: Calculate the historical fault score of the page functional block based on Formula 8. Formula 8 is as follows: = *20%+ *30%+ *50% (Formula 8) 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.

[0085] 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); Set the P2 level in the range of [0~0.25).

[0086] Step 503: Evaluate the third score of each target test case in the behavior heat dimension based on the user's function block usage frequency, path conversion rate, and function block call frequency in the behavior log, and evaluate the fourth score of each target test case in the risk level dimension based on the preset risk level corresponding to the function block.

[0087] User behavior popularity of page function blocks: Analyze function access patterns in tracking logs and calculate real-time user path conversion rate and function call frequency (sliding window statistics) For example, configure the window mechanism: set up multi-level time windows: short window (5 minutes): real-time monitoring of burst traffic; medium window (1 hour): observe trend changes; long window (24 hours): establish a baseline; use a sliding step size = 50% of the window length (e.g., a 5-minute window slides every 2.5 minutes); calculate the core indicator: the number of visits to functional block i Determine the path conversion rate using Formula 9: Predefine key conversion paths (e.g., registration process: startup page -> phone verification -> complete information -> completion); Use a state machine model to track user path completion Conversion rate = Number of users who completed the path / Number of users who entered the first node (Formula 9) Furthermore, the user behavior heat of the page function block is calculated by Formula 10, which is as follows: (Formula 10) in: Indicates page function module The usage frequency is in the range [0, 1]. Indicates functional blocks Number of visits, Indicates functional blocks conversion rate.

[0088] Furthermore, set the user behavior heat level of the page function block: Set the P0 level in the range [0.75,1]; Set the P1 level within the range of [0.25~0.75); Set the P2 level in the range of [0~0.25).

[0089] In the embodiments of the present application, the preset risk level can be determined based on the functional risk level setting rules, including: High Risk P0: Use cases involving security, data integrity, and financial transactions (such as password encryption and payment amount verification) are given the highest priority. Medium Risk P1: Functions that are branches within the core process are set to a medium risk level. Low Risk P2: Interface style and text that does not affect functionality are set to a low risk level.

[0090] Step 504 : Evaluate the importance level of each target test case 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.

[0091] In some examples, the business impact , user behavior heat , Historical Faults , risk level To dynamically calculate the priority score of each function and then evaluate the importance level of each target test case, the following steps may be involved: Step 1: Implicit relationship table (priority baseline) Based on business experience, we define the reasonable relationship between indicators as the basis for priority adjustment, as shown in Table 5 below: Table 5

[0092] Step 2: Dynamically adjust priorities (overlay other indicators) - verify the basic priority, usage frequency, and historical failures to adjust the priority. Step 2.1: Correlation analysis between basic priority and historical fault counts: Statistical method: Group by basic priority and calculate the average number of failures in each group using Formula 11. Formula 11 is as follows: (Formula 11) Expected results: If the failure rate of use cases with a base priority of P2 is significantly higher than that of P1 / P0, it means that relying solely on the base priority is unreasonable, as shown in Table 6 below: Table 6

[0093] Conclusion: P2 use cases have the highest average failure rate, indicating that basic prioritization alone cannot effectively identify high-risk use cases.

[0094] Step 2.2: Correlation analysis between usage frequency and failure count: Hierarchical statistics: Under the frequency level (P0 / P1 / P2), the failure rate of each group is calculated using Formula 12, which is as follows: (Formula 12) Expected results: The failure rate of use cases with high frequency (P0) should be significantly higher than that of use cases with low frequency (P2), as shown in Table 7 below: Table 7

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

[0096] Step 2.3, priority adjustment rules, where the rule adjustment calculation formula is shown in Formula 13 below. The basic priority can be (P_{\text{base}}}: P0=3, P1=2, P2=1: The usage frequency correction value is calculated by Formula 14 , calculate the historical fault correction value through formula 15, (Formula 13) (Formula 14) (Formula 15) Step 2.4: Final priority mapping, as shown in Table 8 below: Table 8

[0097] Step 3: Rules for eliminating abnormal use cases 3.1. Abnormal types that are directly eliminated: The following combinations are considered invalid or contradictory data and are directly eliminated or required to be re-evaluated, as shown in Table 9 below: Table 9

[0098] Step 3.2: Exception types that require manual review are shown in Table 10 below: Table 10

[0099] Optionally, after executing "determining the detection order of multiple target test cases in descending order of importance, and performing fault detection on the multiple target test cases in sequence based on the detection order", the following steps can be adopted but are not limited to: in response to detecting the presence of a faulty test case among the multiple target test cases, replacing the faulty test case in the current test case version to update the current test case version to the next test case version.

[0100] Exemplarily, automated test case execution can construct a standardized MCP prompt based on a knowledge base, which may include the following steps: Step 1 (Input): Affected test cases with full priority, including a sequence of operation steps (i.e., multiple target test cases in the embodiment of this application) ; Step 2 (Knowledge Base): Contains the mapping relationship between standardized operation templates and MCP protocol command words, such as common operation templates such as "click button" and "enter text", as well as the correspondence rules between interface elements and MCP command formats.

[0101] Step 3 (Processing): The system traverses each operation sequence, retrieves the corresponding command template from the knowledge base based on the operation type, and fills in the specific element identifiers or operation parameters to generate a standardized MCP protocol prompt. For example, for operations such as clicking a button and entering text, a prompt format that conforms to the MCP protocol specification is constructed to ensure that the subsequently generated command statements are standardized and parseable.

[0102] Step 4 (output): The standardized MCP protocol prompt text generated by Formula 16 describes the complete test execution task and serves as the input for the AI large model to generate the MCP instruction sequence. Formula 16 is as follows: (Formula 16) In formula 16, It is a knowledge base mapping, including operation templates and element metadata. Fill in the function for the template, and convert each operation step into The "operation type" and "target element" in the are mapped to the corresponding placeholders.

[0103] Furthermore, calling the LLM-AI large model to generate MCP instruction arrangement can include the following steps: Step 1 (Input): Standardized MCP protocol prompt text , model parameter set (Including configurations such as model type, temperature, etc.).

[0104] Step 2 (Knowledge Base): Define the relationship between the MCP server and the operation, and load it into the AI model through the embedded model. For example: Open the browser and call the playwright MCP service, and the terminal and call the shell MCP service.

[0105] Step 3 (Processing): The system calls the connected LLM-AI large model interface, submits the constructed prompt to the model for execution, and obtains the model's output. By specifying the task flow and instruction format requirements in the prompt, the model returns an instruction sequence (JSON format) that complies with the MCP protocol.

[0106] Step 4 (output): The MCP instruction sequence generated by Formula 17 contains each instruction and its parameters in the execution order for use by the automated test execution module.

[0107] (Formula 17) In formula 17, Indicates the large model generation function, and Prompt Convert to MCP instruction sequence , get the MCP instruction sequence In JSON format, each instruction contains fields such as "command", "target", and "parameters".

[0108] Furthermore, performing automated simulation testing using existing MCP services and collecting logs and reports can include the following steps: Step 1 (Input): MCP instruction sequence generated by the AI model .

[0109] Step 2 (Processing): The system sends the instruction sequence to the existing MCP automated testing service, which executes each instruction on the test device. The MCP service is responsible for completing operations such as application launch, page navigation, element positioning, control clicks, and text input. During test execution, the system collects device logs, application return results, and execution status in real time, and records and provides feedback on the execution results of each instruction.

[0110] Step 3 (Output): Test execution logs and reports, including the execution status of each instruction (success or failure), error messages, application screenshots, etc., provide data basis for test result analysis.

[0111] Step 4 (Input): Automated test execution results and logs.

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

[0113] It should be noted that if Figure 6 The figure shows an example flowchart provided by an embodiment of the present application. After executing "determining the detection order of multiple target test cases according to the importance level from high to low, and performing fault detection on the multiple target test cases in turn based on the detection order", the functional coverage of the multiple target test cases can also be detected. If the functional coverage of the multiple target test cases is comprehensive, automated testing can be performed. If the functional coverage of the multiple target test cases is not comprehensive, test cases can be supplemented based on the multiple target test cases, and then testing can be performed based on the supplemented test cases.

[0114] Compared with the current existing technology, this embodiment obtains the user's behavior log and interface call log, analyzes the relationship between the user's operation behavior, functional blocks and interfaces based on the behavior log and interface call log to obtain a block behavior relationship network. Based on the block behavior relationship network, the relationship between the operation behavior, functional blocks and interfaces can be accurately determined. By identifying the code update position of the current test case version, analyzing the impact range of the code update position based on the block behavior relationship network, and determining the target interface set included in the impact range, this embodiment can quickly and accurately analyze the impact range of the code update position based on the block behavior relationship network, and then determine the affected interface set of the code update position; by converting the test corresponding to the target interface set from the current test case version to the test Use cases are selected and expanded to obtain multiple target test cases, and the importance levels of the multiple target test cases are evaluated from multiple dimensions to obtain the importance levels of the multiple target test cases, and then the detection order of the multiple target test cases is determined from high to low according to the importance levels, and fault detection is performed on the multiple target test cases in sequence based on the detection order. This allows the present embodiment to give priority to the detection of test cases with higher importance, and can quickly detect whether important test cases have faults, and then can promptly discover and handle the faults. Expanding the test cases for further detection can also enable the detection method of this embodiment to fully and comprehensively detect all test cases, avoid missed detections and false detections, improve detection efficiency, and ensure the accuracy and effectiveness of detection.

[0115] Further, as Figures 1 to 6 The specific implementation of the method shown in this embodiment provides a detection device for a test case, such as Figure 7 As shown, the device includes: an acquisition module 61 , an identification module 62 , an evaluation module 63 and a detection module 64 .

[0116] An acquisition module 61 is configured to acquire a user's behavior log and an interface call log, and analyze the association between the user's operation behavior, the functional blocks, and the interfaces based on the behavior log and the interface call log to obtain a block behavior relationship network; Identification module 62 is configured to identify the code update location of the current test case version, analyze the impact range of the code update location based on the block behavior relationship network, and determine the target interface set included in the impact range; An evaluation module 63 is 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 to evaluate the importance levels of the plurality of target test cases from multiple dimensions to obtain importance levels of the plurality of target test cases; The detection module 64 is configured to determine a detection order of the multiple target test cases according to the importance levels from high to low, and perform fault detection on the multiple target test cases in sequence based on the detection order.

[0117] In some examples of this embodiment, the acquisition module 61 is specifically configured to capture the interface call log through the business interface log collection platform, and obtain the behavior log sent by the client, where the behavior log is obtained by the client based on the user behavior log collection platform; deduplicate the behavior log and the interface call log to obtain the functional block triggered by the user operation behavior, and extract the operation trigger position in the functional block to obtain the interface execution path of the user; based on the interface execution path and the functional block, analyze the association between the user operation behavior, the functional block and the interface to obtain a block behavior relationship network.

[0118] In some examples of this embodiment, the identification 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, where the current version test case is updated 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 the code update node corresponding to the code update position in the target abstract syntax tree; 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; determine the impact interface set as the target interface set.

[0119] In some examples of this embodiment, the identification module 62 is further configured to analyze the directly affected node set of the code update node from the target abstract syntax tree, traverse and filter the directly affected node set in the target abstract syntax tree through a preset query function, and select nodes that meet the predetermined filtering conditions to form a target directly affected node set; analyze the node dependencies in the target abstract syntax tree based on the block behavior relationship network, obtain the influence range of the code update node according to the node dependencies, and determine the target indirectly affected node set of the code update node based on the influence range; and form the target directly affected node set and the target indirectly affected node set into the affected node set.

[0120] In some examples of this embodiment, the evaluation module 63 is specifically configured to determine the operation behavior sequence corresponding to the target interface set and the operation behavior sequence set corresponding to the current test case version; match the similarity between the operation behavior sequence and the operation behavior sequence set to match multiple candidate operation behavior sequences whose similarity is greater than or equal to a predetermined similarity threshold; expand the multiple candidate operation behavior sequences based on a preset control flow graph and a preset data dependency graph to obtain the multiple target test cases.

[0121] In some examples of this embodiment, the evaluation module 63 is further configured to obtain historical test case execution data and historical fault data within a preset time period, determine the number of executions 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 number of executions; analyze multiple 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 multiple fault indicator data, wherein the multiple fault indicator data include at least one or more of functional impact range, fault duration, user impact scale, and number of faults; evaluate a third score of each target test case in a behavior heat dimension based on the user's function block usage frequency, path conversion rate, and function block call frequency in the behavior log, and evaluate a fourth score of each target test case in a risk level dimension based on a preset risk level corresponding to the function block; and evaluate the importance level of each target test case 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.

[0122] In some examples of this embodiment, the detection module 64 is further configured to, in response to detecting that there is a faulty test case in the multiple target test cases, replace the faulty test case in the current test case version to update the current test case version to the next test case version.

[0123] It should be noted that for other corresponding descriptions of the functional units involved in the detection device of a test case provided in this embodiment, please refer to Figures 1 to 6 The corresponding description in will not be repeated here.

[0124] Based on the above Figures 1 to 6 The method shown in FIG. 1 is a method for performing the above-mentioned steps. Accordingly, this embodiment further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the computer program can realize the above-mentioned steps. Figures 1 to 6 The method shown.

[0125] Based on this 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, USB flash drive, mobile hard disk, etc.), and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of the present application.

[0126] like Figure 8 FIG. 1 is a schematic diagram of the hardware structure of an electronic device of the present invention, comprising: at least one processor 701; and, A memory 702 in communication with at least one of the processors 701; wherein, The memory 702 stores instructions that can be executed by at least one of the processors. The instructions are executed by at least one of the processors to enable the at least one processor to perform the test case detection method as described above.

[0127] Figure 8 A processor 701 is taken as an example.

[0128] The electronic device may further include an input device 703 and a display device 704 .

[0129] The processor 701, the memory 702, the input device 703 and the display device 704 may be connected via a bus or other means. Figure 8 The bus connection is taken as an example.

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

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

[0132] The input device 703 can receive user clicks and generate signal inputs related to user settings of the test case detection method and function control. The display device 704 can include a display device such as a display screen.

[0133] The one or more modules are stored in the memory 702 and, when executed by the one or more processors 701 , execute the test case detection method in any of the above method embodiments.

[0134] Optionally, the physical device may also 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 may include a display screen and an input unit such as a keyboard. Optional user interfaces may also include a USB interface and a card reader interface. Optionally, the network interface may include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0135] Those skilled in the art will understand that the above-mentioned physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or a combination of certain components, or different component arrangements.

[0136] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the physical device, supporting the execution of information processing programs and other software and / or programs. The network communication module is used to enable communication between components within the storage medium, as well as with other hardware and software within the physical information processing device.

[0137] Through the description of the above implementation methods, those skilled in the art can clearly understand that the present application can be implemented by means of software plus a necessary general hardware platform, or by hardware. By applying the solution of this embodiment, compared with the current existing technology, this embodiment obtains the user's behavior log and interface call log, and analyzes the relationship between the user's operation behavior, functional blocks and interfaces based on the behavior log and interface call log to obtain a block behavior relationship network. Based on the block behavior relationship network, the relationship between the operation behavior, functional blocks and interfaces can be accurately determined. By identifying the code update position of the current test case version, analyzing the impact range of the code update position based on the block behavior relationship network, and determining the target interface set included in the impact range, this embodiment can quickly and accurately analyze the impact range of the code update position based on the block behavior relationship network, and then determine the affected interface set of the code update position; by removing the target interface set from the current test case version, the code update position can be quickly and accurately analyzed based on the block behavior relationship network, and then the affected interface set of the code update position can be determined. Corresponding test cases are selected and expanded to obtain multiple target test cases, and the importance levels of the multiple target test cases are evaluated from multiple dimensions to obtain the importance levels of the multiple target test cases, and then the detection order of the multiple target test cases is determined from high to low according to the importance levels, and fault detection is performed on the multiple target test cases in sequence based on the detection order. This allows the present embodiment to give priority to the detection of test cases with higher importance, and can quickly detect whether important test cases have faults, and then can promptly discover and handle the faults. Expanding the test cases for further detection can also enable the detection method of this embodiment to fully and comprehensively detect all test cases, avoid missed detection and false detection, improve detection efficiency, and ensure the accuracy and effectiveness of detection.

[0138] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

[0139] The foregoing is merely a list of specific embodiments of the present application, intended to enable those skilled in the art to understand and implement the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application is not limited to the embodiments described herein, but is intended to conform to the broadest scope consistent with the principles and novel features of the present application.

Claims

1. A method for detecting a test case, characterized in that: include: Obtaining the user's behavior log and interface call log, and analyzing the association between the user's operation behavior, functional blocks, and interfaces based on the behavior log and the interface call log to obtain a block behavior relationship network; Identify the code update location of the current test case version, analyze the impact range of the code update location based on the block behavior relationship network, and determine the target interface set included in the impact range; Selecting and expanding test cases corresponding to the target interface set from the current test case version to obtain a plurality of target test cases, and evaluating the importance levels of the plurality of target test cases from a plurality of dimensions to obtain importance levels of the plurality of target test cases; A detection order of the multiple target test cases is determined from high to low according to the importance levels, and fault detection is performed on the multiple target test cases in sequence based on the detection order.

2. The method according to claim 1, characterized in that The obtaining of the user's behavior log and interface call log, and analyzing the association between the user's operation behavior, functional blocks, and interfaces based on the behavior log and the interface call log to obtain a block behavior relationship network, includes: Capturing the interface call logs through the business interface log collection platform, and obtaining the behavior logs sent by the client, the behavior logs being obtained by the client based on the user behavior log collection platform; Deduplication screening is performed on the behavior log and the interface call log to obtain the functional block triggered by the user's operation behavior, and the operation trigger position in the functional block is extracted to obtain the user's interface execution path; Based on the interface execution path and the functional blocks, the association relationship between the user operation behavior, the functional blocks and the interface is analyzed to obtain a block behavior relationship network.

3. The method according to claim 1, characterized in that The step of identifying the code update location of the current test case version, analyzing the impact range of the code update location based on the block behavior relationship network, and determining the target interface set included in the impact range includes: Obtaining a current version test case and a previous version test case, and identifying code differences between the current version test case and the previous version test case to obtain the code update location, wherein the current version test case is obtained by updating based on the previous version test case; Performing code parsing 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; Analyzing the impact range of the code update node from the target abstract syntax tree based on the block behavior relationship network, and determining the impact interface set corresponding to the impact node set; The impact interface set is determined as the target interface set.

4. The method according to claim 3, characterized in that Analyzing the impact scope of the code update node from the target abstract syntax tree based on the block behavior relationship network, and determining the impact node set included in the impact scope, includes: Analyzing a set of directly affected nodes of the code update node from the target abstract syntax tree, traversing and filtering the set of directly affected nodes in the target abstract syntax tree using a preset query function, and selecting nodes that meet a predetermined filtering condition to form a target directly affected node set; Analyzing node dependencies in the target abstract syntax tree based on the block behavior relationship network, obtaining an impact range of the code update node according to the node dependencies, and determining a target indirectly impacted node set of the code update node based on the impact range; The target directly affected node set and the target indirectly affected node set are combined into the affected node set.

5. The method according to claim 1, wherein Selecting test cases corresponding to the target interface set from the current test case version and performing expansion processing to obtain multiple target test cases, including: Determine the operation behavior sequence corresponding to the target interface set and the operation behavior sequence set corresponding to the current test case version; matching the similarity between the operation behavior sequence and the operation behavior sequence set to match a plurality of candidate operation behavior sequences having a similarity greater than or equal to a predetermined similarity threshold; The multiple candidate operation behavior sequences are expanded based on a preset control flow graph and a preset data dependency graph to obtain the multiple target test cases.

6. The method according to claim 1, characterized in that Evaluating the importance levels of the multiple target test cases from multiple dimensions to obtain the importance levels of the multiple target test cases includes: Obtaining historical test case execution data and historical fault data within a preset time period, determining the number of executions 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 number of executions; Analyzing the historical fault data to obtain a plurality of fault indicator data corresponding to each target test case, and evaluating a second score of each target test case in the historical fault dimension based on the plurality of fault indicator data, wherein the plurality of fault indicator data includes at least one or more of functional impact scope, fault duration, user impact scale, and number of faults; Evaluate a third score of each target test case in the behavior heat dimension based on the user's function block usage frequency, path conversion rate, and function block call frequency in the behavior log, and evaluate a fourth score of each target test case in the risk level dimension based on the preset risk level corresponding to the function block; 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.

7. The method according to claim 1, characterized in that After determining the detection order of the multiple target test cases from high to low according to the importance levels, and sequentially performing fault detection on the multiple target test cases based on the detection order, the method further includes: In response to detecting that a faulty test case exists in the multiple 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.

8. A test case detection device, characterized in that: include: an acquisition module configured to acquire a user's behavior log and an interface call log, and analyze the association between the user's operation behavior, the functional blocks, and the interfaces 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 location of a current test case version, analyze an impact range of the code update location based on the block behavior relationship network, and determine a target interface set included in the impact 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 to evaluate the importance levels of the plurality of target test cases from a plurality of dimensions to obtain importance levels of the plurality of target test cases; The detection module is configured to determine a detection order of the multiple target test cases according to the importance levels from high to low, and perform fault detection on the multiple target test cases in sequence based on the detection order.

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

10. An electronic device comprising a storage medium, a processor, and a computer program stored in the storage medium and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.

Images