Methods, apparatus, electronic devices and storage media of assisting testing

Abstract

This application discloses an auxiliary testing method, apparatus, electronic device, and storage medium, relating to the field of server testing technology. The method includes: constructing a demand relationship graph containing the relationship between test task packages and resource requirements, as well as usage periods, to locate task package-level risk points at each stage of the project; dividing the graph into multiple time windows to obtain subgraphs and detecting resource requirement conflicts in the subgraphs, generating risk identifiers containing the test task packages, resources, conflict types, and corresponding time windows involved in the conflicts, thus achieving proactive risk prevention; and generating resource adjustment schemes for risky task packages by matching pre-stored resource adjustment cases, providing targeted remedial solutions while covering the interaction relationships between multiple test task packages and multiple resources. This addresses resource competition conflicts in multi-project parallel scenarios and improves the adaptability of resource scheduling schemes.

Description

Technical Field

[0001] This application relates to the field of server testing technology, and in particular to a method, apparatus, electronic device and storage medium for auxiliary testing. Background Technology

[0002] Server testing is a crucial step in ensuring the stability and reliability of server products. However, current server testing technologies lack fine-grained testing for different project phases and adaptive resource scheduling solutions to address resource contention conflicts in multi-project parallel testing scenarios. Summary of the Invention

[0003] This application provides a method, apparatus, electronic device, and storage medium for auxiliary testing, to at least solve the problem of resource contention in related technologies that lack fine-grained testing for different stages of a project and in parallel testing scenarios.

[0004] This application provides a method for assisting testing, comprising: constructing a requirement relationship graph, which represents the requirement relationships between multiple test task packages and multiple resources, as well as the usage periods of the resources required by each test task package; dividing the requirement relationship graph into multiple time windows according to the usage periods, resulting in multiple subgraphs; detecting conflicts in the resource requirements of test task packages in the subgraphs, and generating risk identifiers based on the detected conflicts, wherein the risk identifiers include: the test task packages and resources involved in the conflict, the type of conflict, and the time window in which the subgraph is located; determining, from multiple pre-constructed resource adjustment cases, a resource adjustment case matching the risk identifier as a reference case, and generating a resource adjustment plan for the risk task package based on the reference case, wherein the risk task package is the test task package included in the risk identifier, and the resource adjustment plan is used to adjust the resource allocation of the risk task package.

[0005] This application also provides an auxiliary testing device, comprising: a risk location module for constructing a demand relationship graph, which represents the demand relationships between multiple test task packages and multiple resources, as well as the usage periods of the resources required by each test task package; dividing the demand relationship graph into multiple time windows according to the usage periods to obtain multiple subgraphs; detecting conflicts in the resource requirements of test task packages in the subgraphs, and generating risk identifiers based on the detected conflicts, wherein the risk identifiers include: the test task packages and resources involved in the conflict, the type of conflict, and the time window in which the subgraph is located; and a solution generation module for determining, from multiple pre-built resource adjustment cases, a resource adjustment case matching the risk identifier as a reference case, and generating a resource adjustment solution for the risk task package based on the reference case, wherein the risk task package is the test task package included in the risk identifier, and the resource adjustment solution is used to adjust the resource allocation of the risk task package.

[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described auxiliary testing methods.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described auxiliary testing methods.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described auxiliary testing methods.

[0009] This application achieves several key benefits. By constructing a demand relationship graph that includes the relationship between test task packages and resource requirements, as well as their usage periods, it satisfies the need to locate task package-level risk points at each stage of the project. Furthermore, by dividing the demand relationship graph into multiple time windows to obtain subgraphs and detecting resource requirement conflicts within these subgraphs, it generates risk indicators that include the test task packages, resources, conflict types, and corresponding time windows involved in the conflicts, thus enabling proactive risk prevention. Finally, by matching pre-stored resource adjustment cases to generate resource adjustment schemes for risky task packages, it provides targeted remedial solutions at the task package level. Simultaneously, it covers the interaction relationships between multiple test task packages and multiple resources, addressing resource competition conflicts in multi-project parallel scenarios and improving the adaptability of the resource scheduling scheme. Attached Figure Description

[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A flowchart of an auxiliary testing method according to an embodiment of this application is shown.

[0012] Figure 2 A block diagram illustrating the relationships between nodes and edges in a demand relationship graph according to an embodiment of this application is shown.

[0013] Figure 3 A flowchart of a conflict detection and risk point location method according to an embodiment of this application is shown.

[0014] Figure 4 A flowchart of a resource adjustment scheme generation method according to an embodiment of this application is shown.

[0015] Figure 5 A flowchart of a method for generating a comprehensive risk index according to an embodiment of this application is shown.

[0016] Figure 6 A flowchart of a risk warning method according to an embodiment of this application is shown.

[0017] Figure 7 A structural block diagram of an auxiliary testing apparatus according to an embodiment of this application is shown. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0019] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0020] For server testing, existing technologies lack fine-grained testing for different project phases and adaptive resource scheduling solutions for resource contention conflicts in multi-project parallel testing scenarios. In multi-project parallel scenarios, each project is divided into multiple phases, each containing several independent test task packages. Each task package relies on various resources such as manpower, machines, and materials. The cross-sharing of these resources easily leads to risks such as manpower fluctuations, material shortages, machine failures, schedule deviations, and delays in vulnerability patching. This can cause test task packages to be difficult to complete on time, thus affecting the overall project progress and resulting in additional consumption of human, material, and financial resources.

[0021] In one example, by acquiring project tasks, personnel attributes, and status, the urgency of tasks and the effectiveness of personnel execution are analyzed. A risk calculation engine trained with a large model is used for dynamic risk assessment, real-time monitoring, and risk warnings are issued. However, this method only performs a coarse-grained risk assessment for the entire project, without considering the resource contention dimension at the server test task package level, and lacks targeted resource adjustment and remedial solutions.

[0022] In one example, automated, centralized management and real-time monitoring of the server are achieved through multi-dimensional data collection and analysis, including multiple comparative analyses of metrics such as memory utilization, CPU utilization, and thread status. Its focus is on the multi-dimensional collection and real-time monitoring and comparison of the server's own operational metrics (CPU / memory / thread status, etc.), without addressing resource allocation planning, conflict detection, dynamic adjustment logic at the test task package level in multi-project parallel scenarios, or any proactive risk prevention measures.

[0023] In view of this, embodiments of this application provide a method, apparatus, electronic device, and storage medium for assisting testing. The method includes: constructing a demand relationship graph, which represents the demand relationships between multiple test task packages and multiple resources, as well as the usage periods of the resources required by each test task package; dividing the demand relationship graph into multiple time windows according to the usage periods to obtain multiple subgraphs; detecting conflicts in the resource requirements of test task packages in the subgraphs, and generating risk identifiers based on the detected conflicts, wherein the risk identifiers include: the test task packages and resources involved in the conflict, the type of conflict, and the time window in which the subgraph is located; determining a resource adjustment case matching the risk identifier from multiple pre-constructed resource adjustment cases as a reference case, and generating a resource adjustment scheme for the risky task package based on the reference case, wherein the risky task package is a test task package included in the risk identifier, and the resource adjustment scheme is used to adjust the resource allocation of the risky task package.

[0024] According to the embodiments of this application, by constructing a demand relationship graph that includes the relationship between test task packages and resource requirements and the usage period, the location of task package-level risk points at each stage of the project is satisfied; by dividing the demand relationship graph into multiple time windows to obtain subgraphs and detecting resource requirement conflicts in the subgraphs, risk identifiers containing the test task packages, resources, conflict types, and corresponding time windows involved in the conflicts are generated, thus achieving proactive risk prevention and control; by matching pre-stored resource adjustment cases to generate resource adjustment schemes for risky task packages, targeted remedial solutions at the task package level are provided, while covering the interaction relationship between multiple test task packages and multiple resources, which can cope with resource competition conflicts in multi-project parallel scenarios and improve the adaptability of resource scheduling schemes.

[0025] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0026] The specific application environment architecture or specific hardware architecture on which the execution of the auxiliary testing methods depends is described here.

[0027] The embodiments of this application provide a method for auxiliary testing, and the method is described in detail below in conjunction with the execution flow of the auxiliary testing method.

[0028] Figure 1 A flowchart of an auxiliary testing method according to an embodiment of this application is shown.

[0029] like Figure 1 As shown, the auxiliary testing method of this embodiment includes operations S110 to S140.

[0030] In operation S110, a requirement relationship graph is constructed. The requirement relationship graph represents the requirement relationships between multiple test task packages and multiple resources, as well as the usage periods of the resources required by each test task package.

[0031] In embodiments of this application, the demand relationship graph can be a relationship graph composed of test task packages and resources as nodes, used to show the resources required by a test task package and the time periods during which those resources are required in a multi-project parallel scenario. Resources may include human resources, material resources, and equipment resources.

[0032] In operation S120, the demand relationship graph is divided into multiple time windows according to the usage period, resulting in multiple sub-graphs.

[0033] The usage period can refer to the start and end timeframe during which the test task package is scheduled to consume resources. A sub-graph can be a partial view of the requirement relationship diagram within a specific time window.

[0034] In operation S130, conflicts in resource requirements of test task packages are detected in the subgraph, and risk indicators are generated based on the detected conflicts. The risk indicators include: the test task packages and resources involved in the conflict, the type of conflict, and the time window in which the subgraph is located.

[0035] Conflict detection refers to identifying when multiple test task packages simultaneously request and occupy the same resource in a subgraph. This is used to locate resource contention occurring at a specific time or time period, identifying whether the conflict is due to human resources, materials, or equipment. Risk identification transforms the abstract concept of risk into concrete coordinate information, used to identify which resource conflict occurred within which time window, thus achieving risk localization.

[0036] In operation S140, from a pool of pre-built resource adjustment cases, a resource adjustment case matching the risk identifier is selected as a reference case. Based on the reference case, a resource adjustment plan for the risk task package is generated. The risk task package is a test task package contained within the risk identifier, and the resource adjustment plan is used to adjust the resource allocation of the risk task package.

[0037] Resource adjustment cases can be information pairs consisting of risk characteristics and remedial measures stored in a case library. Reference cases can be historical cases retrieved from the case library using similarity algorithms (such as cosine similarity and time decay factor) that best match the current risk. Resource adjustment plans can be specific execution instructions for risk task packages, such as borrowing human resources, adjusting material quantities, or adjusting task start times.

[0038] For example, in a server testing project, test task package A (Basic Input / Output System verification) requires senior engineer Zhang San to perform exclusive operations on Wednesday. Simultaneously, test task package B (stress testing) also requires Zhang San to debug on the same day. The constructed requirement relationship graph shows that the resource node Zhang San connects test task package A and test task package B. Wednesday is thus divided into a time window W. A conflict is detected in the subgraph of time window W, generating a risk marker: [Test task package A, Zhang San, Time window W, Manpower conflict]. By searching for resource adjustment cases, reference cases matching the above risk marker of "insufficient manpower due to manpower conflict" are detected. These reference cases suggest "borrowing engineers of the same level and qualifications from idle project teams." Based on this, a resource adjustment plan is generated: "Borrow Li Si, who has Basic Input / Output System (BIOS) certification, from project X to test task package A for a period of 1 day."

[0039] For example, a certain testing phase includes test task package C and test task package D, both requiring a specific model of hard drive (material M). It is detected that within the Friday time window, the total demand for material M from test task packages C and D exceeds the current inventory of material resources. An overload conflict occurs at the node for material M in the demand relationship graph, generating a risk marker: [Test task package C, material M, Friday, material conflict]. Then, a reference case matching the risk marker is matched from multiple pre-built resource adjustment cases: "A project's testing is halted due to material shortages; this is resolved by allocating redundant materials from other projects." Based on this, a resource adjustment plan is generated: "Allocate 2 hard drives of the same model from project Y to test task package C, batch number SN002, expected to be delivered before Thursday."

[0040] By constructing a demand relationship graph and dividing it into multiple time windows, conflicts can be detected and risk markers can be generated in the subgraph, realizing "conflict detection and risk point location". Based on the conflict risk markers, cases are selected from pre-built cases to generate resource adjustment plans for adjusting the resource allocation of task packages, realizing "adaptive remedial plan generation". This can cope with resource competition conflicts in multi-project parallel scenarios and improve the adaptability of resource scheduling plans.

[0041] According to the embodiments of this application, by constructing a demand relationship graph that includes the relationship between test task packages and resource requirements and the usage period, the location of task package-level risk points at each stage of the project is satisfied; by dividing the demand relationship graph into multiple time windows to obtain subgraphs and detecting resource requirement conflicts in the subgraphs, risk identifiers containing the test task packages, resources, conflict types, and corresponding time windows involved in the conflicts are generated, thus achieving proactive risk prevention and control; by matching pre-stored resource adjustment cases to generate resource adjustment schemes for risky task packages, targeted remedial solutions at the task package level are provided, while covering the interaction relationship between multiple test task packages and multiple resources, which can cope with resource competition conflicts in multi-project parallel scenarios and improve the adaptability of resource scheduling schemes.

[0042] The above section has explained the overall technical solution for generating resource adjustment plans for risky task packages during server testing. The following section will further explain the requirement relationship graph.

[0043] According to an embodiment of this application, the demand relationship graph includes multiple first nodes, multiple second nodes, and multiple edges, wherein the first node represents a test task package, the second node represents a resource, the edge between the first node and the second node indicates that the test task package of the first node needs the resource of the second node, and the edge has a time label, which indicates the period during which the test task package uses the required resource.

[0044] In the embodiments of this application, the first node can be a core entity node in the demand relationship graph, representing an independently schedulable unit in the server testing process, and is the initiator of resource requests. The second node can be another type of entity node in the demand relationship graph, referring to the elements necessary for the execution of the test task, which is the resource being requested and also the object of operation of the resource adjustment scheme.

[0045] An edge can be a line connecting the first node and the second node, representing a dependency relationship between a specific test task package and a specific resource, used to construct a topological mapping between tasks and resources, and to associate discrete test task packages and resources into a whole network.

[0046] Figure 2 A block diagram illustrating the relationships between nodes and edges in a demand relationship graph according to an embodiment of this application is shown.

[0047] like Figure 2 As shown, all currently ongoing test task packages 210, such as test task package T1, test task package T2, test task package T3, ..., test task package Tn, are mapped to human resources 221, material resources 222, and equipment resources 223 in resources 220 respectively, to construct a bipartite graph, which serves as a demand relationship graph.

[0048] Human resources 221 may include human resources R11, human resources R12, ..., human resources R1n. Material resources 222 may include material resources R21, material resources R22, ..., material resources R2n. Equipment resources 223 may include equipment resources R31, equipment resources R32, ..., equipment resources R3n.

[0049] The requirement relationship 230 (edge) between test task package 210 and required resource 220 is accompanied by a time label. , ].

[0050] A bipartite graph can be denoted as G=( ∪ ,E), It can be a collection of test task package nodes (first node). It can be a set of resource nodes (secondary nodes). E can represent the requirement relationship (edge) between the test task package and the required resource entity.

[0051] According to embodiments of this application, by constructing a demand relationship graph, the structure of the graph facilitates accurate conflict identification and conflict marker construction, making implicit resource requirements explicit into a visible topological structure. This improves the visibility of complex multi-project resource dependencies and reduces management complexity. Time tags can identify resource occupancy in future time periods, elevating risk management from static inventory checks to dynamic scheduling conflict detection, preventing test stalls caused by time mismatches.

[0052] According to an embodiment of this application, the demand relationship graph is divided into multiple time windows based on the usage period to obtain multiple subgraphs, including: for each time window in the multiple time windows, determining the edge whose time label falls into the time window among the multiple edges of the demand relationship graph, and using it as the edge in the subgraph; in the demand relationship graph, connecting the first node and the second node of the edge whose time label falls into the time window, and using them as the first node and the second node in the subgraph.

[0053] In the embodiments of this application, the time window can be multiple discrete time periods obtained by dividing a continuous usage period according to a preset granularity (e.g., 0.5 days or 1 day).

[0054] The determination of edges and the mapping of nodes can be achieved through filtering and reconstruction mechanisms. For example, each edge in the demand relationship graph can be detected, and edges whose time tags fall within the "time window" can be filtered out. Then, the "first node" and "second node" connected at both ends of these edges can be extracted to form the entities of the subgraph.

[0055] For example, based on multiple preset continuous time windows, the bipartite graph is split into multiple continuous time windows. , ,… Multiple subgraphs of ) Each time window's subgraph includes the edges that fall within the time window and their corresponding task package nodes and resource entity nodes.

[0056] For example, the time window granularity is set to 0.5 days. Within the "Week 1 Mon AM" time window, it is detected that the first node "Test Task Package C" is connected to the second node "Insulation Box X" via an edge, and the time label of this edge covers the morning period. At the same time, another first node "Test Task Package D" is also connected to "Insulation Box X" via an edge, and its time label is also for the morning period. This generates a subgraph for "Week 1 Mon AM", which includes the two test task packages, one device, and two edges.

[0057] Considering that without slicing the entire continuous time period, complex dynamic programming would be required across the entire time period, the embodiments of this application generate subgraphs to decompose the complex demand relationship graph into multiple subgraphs. This improves the efficiency of the conflict detection algorithm and adapts to the real-time computing needs of high-frequency changes in server testing. Simultaneously, by employing time tags, the demand relationship graph can be divided into subgraphs according to resource usage periods, which is beneficial for subsequent risk localization. Through time window division and subgraph reconstruction, conflict detection is accurate to specific moments, solving the detection blind spot where there is sufficient total resources but local paralysis due to time mismatch.

[0058] According to embodiments of this application, detecting resource demand conflicts for test task packages in a subgraph includes: if different test task packages in the subgraph require the same exclusive human resources, a conflict is detected, and the type of conflict is determined to be a human resource conflict; if different test task packages in the subgraph require the same exclusive equipment resources, a conflict is detected, and the type of conflict is determined to be an equipment conflict; if the sum of the material resource requirements of the test task packages in the subgraph is greater than the available material resource quantity within the corresponding time window of the subgraph, a material conflict is detected, and the type of conflict is determined to be a material conflict.

[0059] In the embodiments of this application, exclusive human resources can refer to personnel with specific scarce skills who can only serve one test task package within a specific time period, making it difficult to perform multiple tasks simultaneously. Exclusive equipment resources can refer to physically unique or limited-quantity test equipment. The sum of material resource demands refers to the cumulative total demand for a specific material from all active test task packages within the same time window. The available material resource quantity can refer to the actual inventory quantity of that material in the warehouse at the start of the time window.

[0060] For example, within each time window, three types of conflict detection are performed, including: manpower conflict detection, where if two task packages require the same person and that person's skill is "exclusive operation", then a conflict edge is marked. The conflict condition is the existence of a resource node r such that edges (T_a, r) ​​and (T_b, r) exist simultaneously within the time window.

[0061] Material conflict detection is used to calculate the cumulative consumption rate of materials within the current window. Let the total consumption of material m within window w be... ,in Let T_i be the single consumption amount of material m for task package T_i. > If so, mark the material conflict. This represents the inventory level at the start of the window. Device conflict detection: Similar to human conflict detection, if two test task packages require the same exclusive device, a conflict is flagged.

[0062] For example, in the subgraph "TimeWindow_Week1_Mon", two test task packages are detected: the first node "Test Task Package C" requires 5 units of material M (Solid State Drive); the other first node "Task Package D" requires 3 units of material M (Solid State Drive), with a total demand of 8 units. Checking the inventory reveals that only 6 units of material are available within this time window. Since the total demand of 8 > the available material resource of 6, a resource conflict is detected, and the conflict type is determined to be a material conflict.

[0063] For example, in the subgraph of "TimeWindow_Day2", it was detected that the first node "Task Package A (Firmware Verification)" and another first node "Task Package B (Stress Test)" are simultaneously connected to the second node "Engineer Li Si" via edges. By checking the resource attributes, it was confirmed that Li Si belongs to "Exclusive Human Resources" (possessing special certification qualifications and cannot do two things at the same time). Since the time labels of the two edges overlap on Day2, a resource conflict was detected, and the type of conflict was determined to be a human resources conflict.

[0064] For example, in a demand relationship graph, there is a first node "Test Task Package A (Firmware Verification)" and a second node "HR Engineer Zhang San". The edge connecting the first and second nodes has a time label "Day 3 09:00 - Day 3 18:00", indicating that Zhang San needs to serve this task for the entire third day. Meanwhile, another first node in the graph, "Test Task Package B (System Debugging)," is also connected to the second node "HR Engineer Zhang San" via an edge, with the same time label "Day 3 09:00 - Day 3 18:00". Since the two edges share the same HR node and their time labels completely overlap, the conflict type is identified as a HR conflict.

[0065] According to embodiments of this application, by distinguishing between exclusive human resources, exclusive equipment resources, and material resources, distinct remedial logic is generated for each type. This avoids the situation in traditional technologies where simply reporting resource insufficiency leads to unclear remedial directions and measures, thus improving the rationality of resource scheduling. Three conflict detection methods enable conflict detection and subsequent risk identification for various resource conflicts.

[0066] According to an embodiment of this application, generating a risk identifier based on a detected conflict includes: identifying the edge involved in the conflict as a conflict edge; generating a risk identifier for the conflict edge, the risk identifier including: a test task package corresponding to a first node connected to the conflict edge, resources corresponding to a second node connected to the conflict edge, the type of conflict corresponding to the conflict edge, and the time window in which the conflict edge falls; wherein, the test task package corresponding to the first node connected to the conflict edge is used as a risk task package, and the risk identifier generated for the conflict edge is used as the risk identifier of the risk task package.

[0067] In embodiments of this application, a conflict edge can refer to an edge in a subgraph of the demand relationship graph that points to the same second node (resource) and overlaps (causing resource contention) within the corresponding time window. A risk task package can refer to the first node directly connected to the conflict edge, and in a conflict scenario, it may involve one or more test task packages.

[0068] The following three types of conflicting edges can be detected in the subgraph: human resource conflict (there are connecting edges between the same human resource node and multiple test task package nodes), material resource conflict (the total consumption of material resources within the time window is greater than the inventory at the beginning of the window), and equipment resource conflict (there are connecting edges between the same equipment resource node and multiple task package nodes).

[0069] According to embodiments of this application, by generating risk identifiers (task + resource + time + type), the coordinate system and interpretability of risk descriptions are achieved, avoiding the time-consuming diagnostic costs of investigating specific problems in traditional technologies. By attaching risk identifiers to specific risk task packages, a reliable data foundation is provided for the subsequent generation of resource adjustment plans.

[0070] In one feasible embodiment, the auxiliary testing method further includes: if a first test task package depends on a second test task package among multiple test task packages, then a risk propagation factor for the first test task package is generated based on the comprehensive risk index of the second test task package and the dependency relationship between the first test task package and the second test task package.

[0071] For example, if test task package B depends on the output of test task package A, and test task package A has risks, then test task package B inherits and derives risks. Based on this, a risk propagation factor can be generated: the risk propagation factor of test task package B is generated based on the risks of test task package A and the pre-dependency relationship between test task package B and test task package A. Construct a directed graph of task package dependencies and determine the risk propagation factor as shown in the following formula (1):

[0072] (1);

[0073] in, To test the derived risk value of task package B. To test the inherent risk value of task package A. Let λ be the planned start time interval between test task package A and test task package B, and let λ be the decay factor (e.g., an empirical value of 0.2). A risk propagation factor is used to propagate derived risks to downstream task packages. This is the risk attenuation coefficient.

[0074] Considering the dependencies between different task packages, the embodiments of this application upgrade risk control from single-point defense to network-wide defense through a risk propagation factor. Using a decay model, risks that naturally dissipate due to excessive time intervals are automatically filtered out, concentrating limited resources on critical chain risks that truly paralyze the project due to dependencies. By tracing conflict nodes through conflict edges, the task packages, resources, conflict types, and conflict periods involved in the conflict are identified, and the constructed risk identifiers enable accurate risk point location.

[0075] Figure 3 A flowchart of a conflict detection and risk point location method according to an embodiment of this application is shown.

[0076] like Figure 3 As shown, the conflict detection and risk point location method in this application embodiment includes operations S301 to S312.

[0077] In operation S301, construct a demand relationship graph.

[0078] For example, it is possible to construct such as Figure 2 The bipartite graph shown serves as a demand relationship graph. It can be constructed using the obtained task package list, resource list, and edges representing the demand relationships between each task package and each resource.

[0079] In operation S302, multiple time windows can be set. For example, time slices can be made at a certain granularity (such as 0.5 days or 1 day) to obtain multiple consecutive time windows for fine-grained collision detection.

[0080] In operation S303, determine whether the time window has been traversed completely. If not, execute operation S304; if yes, execute operation S307.

[0081] In operation S304, conflict detection is performed for the next time window.

[0082] It can detect various types of conflicts within a time window, such as, but not limited to, human conflict detection, material conflict detection, and equipment conflict detection.

[0083] In operation S305, determine if there is a resource conflict. If not, return to operation S303; if yes, execute operation S306.

[0084] Taking the above three conflict types as examples, if different test task packages in the subgraph are detected to require the same exclusive human resources, then a conflict is detected and the conflict type is determined to be a human resources conflict; if different test task packages in the subgraph are detected to require the same exclusive equipment resources, then a conflict is detected and the conflict type is determined to be an equipment conflict; if the sum of the material resource requirements of the test task packages in the subgraph is detected to be greater than the available material resource quantity within the corresponding time window of the subgraph, then a material conflict is detected and the conflict type is determined to be a material conflict.

[0085] In operation S306, conflicting edges are marked, and operation S303 is returned. For example, if any of the above types of conflicts are detected in the subgraph, the edges involved in the conflict are identified as conflicting edges for each conflict. In some embodiments, conflict information may also be temporarily stored.

[0086] For example, in the "TimeWindow_03" (corresponding to Wednesday all day) check: the first node "Test Task Package A" and the first node "Test Task Package B" are both connected to the second node "Senior Engineer Zhang San", and Zhang San's skill is exclusive operation. Therefore, a conflict can be detected, and the type of conflict is a human conflict. The connection edges between the first nodes "Test Task Package A" and "Test Task Package B" and the second node "Senior Engineer Zhang San" are considered conflict edges.

[0087] In operation S307, reverse tracing is performed. Starting from the test task package where the conflict occurred, the process traverses in the reverse direction of the task dependencies to find upstream task packages that depend on this task package, or downstream task packages that caused this task package to be blocked. This operation is used to build dependencies in subsequent operations S309 to S312. If the method does not need to build dependencies, this operation can be omitted.

[0088] In operation S308, a risk identifier is generated. The risk identifier may include the test task package corresponding to the first node connected to the conflicting edge, the resource corresponding to the second node connected to the conflicting edge, the type of conflict corresponding to the conflicting edge, and the time window in which the conflicting edge falls. In some embodiments, the risk identifier may be constructed as a four-tuple, for example, RiskCoordinate=[TaskID, ResourceID, TimeWindow, ConflictType]. TaskID represents the identifier of the test task package, ResourceID represents the resource identifier, TimeWindow represents the time window, and ConflictType represents the conflict type. In some embodiments, ConflictType ∈ {human conflict, material conflict, equipment conflict}.

[0089] Taking the edge connecting test task package A and Zhang San as an example, the nodes corresponding to this conflicting edge are task package A and Zhang San, the corresponding time window is TimeWindow_03, and the corresponding conflict type is human conflict. Based on this information, a risk identifier [Task_A, Zhang San, TimeWindow_03, Human Conflict] can be generated. Thus, a risk identifier has been generated for risky task package A. A similar method is used to generate risk identifiers for test task package B, which will not be elaborated upon here.

[0090] In some embodiments, a risk propagation factor may be further generated. For example, a risk propagation factor may be generated by performing the following operations: S309 to S312.

[0091] In operation S309, a directed dependency graph is constructed. Based on the dependencies between task packages, a directed dependency graph is built. For example, a finite dependency graph can be constructed, reflecting the following dependencies: test task package B depends on the output of test task package A, test task package C depends on the output of test task package B, and so on.

[0092] In operation S310, derived risk information is calculated. Based on the dependency graph and conflict information, the derived risk information (indirect impact) of the conflict on upstream and downstream tasks is calculated. For example, if test task package B depends on the output of test task package A, and test task package A has risks, then test task package B inherits the derived risks. Based on this, a risk propagation factor can be generated: the risk propagation factor of test task package B is generated based on the risks of test task package A and the pre-dependencies between test task package B and test task package A.

[0093] When operating S311, derived risk information is attached to the corresponding downstream task package, forming a complete risk propagation chain.

[0094] When operating S312, output the risk coordinate quadruple and the risk propagation chain.

[0095] According to embodiments of this application, a resource adjustment case includes a risk feature vector and an atomic operation corresponding to the risk feature vector. Determining a resource adjustment case matching a risk identifier as a reference case from a pre-constructed plurality of resource adjustment cases may include: generating a risk feature vector for a risk task package based on the risk identifier of the risk task package; determining, among the risk feature vectors of the plurality of resource adjustment cases, a risk feature vector whose similarity to the risk feature vector of the risk task package meets predetermined conditions, as a target feature vector; and using the resource adjustment case including the target feature vector as a reference case.

[0096] For example, a target atomic operation template can be generated based on the atomic operation template of a reference case; the target operation value can be calculated using mixed integer programming with the operation value of the reference case as the initial feasible solution; and the target operation value can be mapped to the target atomic operation template to obtain a resource adjustment scheme. In some embodiments, the reference case includes atomic operation templates and operation values. Generating a resource adjustment scheme for a risk task package based on the reference case includes: generating a target atomic operation template based on the atomic operation template of the reference case; calculating the target operation value using mixed integer programming with the operation value of the reference case as the initial feasible solution; and mapping the target operation value to the target atomic operation template to obtain a resource adjustment scheme.

[0097] The following will refer to Figure 4 This application describes a method for generating a resource adjustment scheme according to embodiments thereof.

[0098] Figure 4 A flowchart of a resource adjustment scheme generation method according to an embodiment of this application is shown.

[0099] like Figure 4 As shown, the resource adjustment scheme generation method in this embodiment includes operations S401 to S413.

[0100] In operation S401, a risk feature vector is generated based on the risk identifier.

[0101] In embodiments of this application, the risk feature vector can be a multidimensional numerical array that encodes risk identifiers (risk coordinate quadruples) and related contextual information (such as project level, resource scarcity, and task urgency). The target feature vector can be the top K risk feature vectors with the highest similarity selected from the case library.

[0102] The risk coordinate quadruple can be denoted as [TaskID, ResourceID, TimeWindow, ConflictType], and it serves as the initial trigger signal for generating resource adjustment schemes.

[0103] For example, a risk feature vector can be generated based on the risk coordinate quadruple. The feature vector can include multiple risk features, including but not limited to conflict type, conflict duration, task urgency, project level, resource scarcity, etc. The conflict type can be obtained based on the conflict type ConfilictType in the quadruple, the conflict duration can be calculated based on the time window, and other features can be obtained by querying the database based on the task package ID and resource ID, or by further analyzing and calculating the queried data.

[0104] For example, by using historical project data, a historical case library containing historical risk feature vectors and historical remedial measures can be constructed to obtain multiple pre-constructed resource adjustment cases. Thus, based on the similarity matching of case reasoning, it can be determined whether the similarity between the historical risk feature vector and the risk feature vector of the current risk task package meets the predetermined conditions.

[0105] In operation S402, the similarity with historical cases is calculated. Each historical case can contain a historical risk feature vector. And historical remedial atomic operations (remedial measures) Calculate the risk feature vector Compared with historical risk feature vector The mixture similarity Sim between them is shown in the following formula (2):

[0106] Sim = + (2);

[0107] Where cos is the cosine similarity, which measures the similarity between the risk feature vector and the historical risk feature vector; T is the current time. The more recent the historical case, the higher its weight. This is an indicator function; it takes a value of 1 if the current project and historical cases belong to the same customer line, and 0 otherwise. , , Let be the weighting coefficient, satisfying + =1. Recall the K most similar historical cases and use their remedial action sequences as reference cases.

[0108] It should be noted that the dimensions of the risk feature vector can be pre-fixed and uniform. The historical risk feature vectors of all historical cases and the risk feature vector of the current risk event can both adopt a predefined set of fixed dimensions. , ,..., }, where p is the number of predefined fixed dimensions (e.g., conflict type, conflict duration, task urgency, project level, resource scarcity, etc.).

[0109] For missing feature values ​​in certain historical cases, they are uniformly filled with 0. Similarity is calculated using the cosine similarity after zero-padding, weighted sum of time decay and product line parameters. In extreme cases of inconsistent dimensions, only the similarity of the common feature subspace can be calculated and multiplied by the proportion of common features.

[0110] In operation S403, historical similar cases with similarity scores meeting preset criteria are recalled. For example, the mixed similarity between the risk feature vector and historical risk feature vectors in the historical case library can be calculated, and the top K historical cases with the highest similarity scores are used as reference cases. For example, if a risk task package "BIOS verification" is detected to have a risk identifier: [BIOS verification, engineer Zhang San, Day 2, manpower conflict], features are extracted to generate a risk feature vector: [conflict type = manpower, resource skill = BIOS expert, project level = high, urgency = high]. Multiple resource adjustment cases are then retrieved, and the feature vector of historical case H23 is found to be [manpower, BIOS expert, high, high]. The similarity is calculated to be extremely high (meeting the preset conditions), and case H23 is thus identified as a reference case. Its atomic operation is "borrow Li Si (same level BIOS expert) from project Y for 3 days".

[0111] According to embodiments of this application, since cases are constructed as feature vectors and atomic operations, they can be effectively matched with risk identifiers, thereby finding cases with risks similar to the current task package. Through matching resource adjustment cases, multiple resource adjustment cases formed based on historical data ensure the stability and rationality of resource adjustment case decision quality, and shorten the decision-making time for risk emergency response.

[0112] In operation S404, historical remedial measures are extracted as the initial population.

[0113] In the embodiments of this application, the atomic operation template can be a predefined, structured operational logic framework, such as: "borrow [personnel Y] [Z] days from [project X]" or "allocate [material M] [N] pieces to [task package A]". The target atomic operation template can be an operational framework adapted from reference cases and applicable to the current scenario, based on the specific circumstances of the current risk task package. The target operation value can be the optimal numerical solution obtained through mixed integer programming, achieving the minimization of the objective function (overall cost) while satisfying all constraints (such as personnel hours and material inventory).

[0114] Extract the "historical remedies" used in the top K historical cases (reference cases) and use them as the initial population of the current optimization algorithm. This will help accelerate convergence by leveraging historical experience and avoid blindly searching from scratch.

[0115] In operation S405, define decision variables. Decision variables may include the number of personnel j borrowed from project i (integer variable), the number of materials l transferred from test task package k (integer variable), and the start time offset of test task package m (continuous variable, which can be negative to indicate early start), denoted as follows: , and .

[0116] For example, based on the type of atomic operation template in the atomic operation sequence of the reference case, multiple decision variables are defined. Based on the preset objective function and constraints, mixed integer programming is performed on the multiple decision variables to obtain the values ​​of the multiple decision variables, which are then used as the objective operation values.

[0117] In operation S406, set constraints.

[0118] Constraints may include personnel hour constraints (e.g., each person's total daily working hours do not exceed 10 hours), material deadlock constraints (the remaining inventory after the original task package is transferred is not lower than the safety threshold), and task package dependency constraints (e.g., if task package B depends on task package A, then...). + + , start B This is the actual start time of task package B. This is the actual end time of task package A. It could be the time buffer size for task package B. These could include the time buffer for task package A, and resource availability constraints (e.g., seconded personnel must be available or available for secondment during the secondment period, and material allocation must not cause a disruption in the original task package's supply). By introducing business logic constraints as conditions, the generated solution is ensured to be executable. Constraints include personnel work hours, material deadlock, and dependencies between task packages.

[0119] In S407, set the target function.

[0120] For example, an objective function can be set to minimize the overall cost MinZ, as shown in the following formula (3):

[0121] MinZ= + + (3);

[0122] in, This indicates that the summation is performed on all task pairs (i,j) involving manpower allocation, where i refers to the resource-exporting party (such as other project teams) and j refers to the resource-receiving party (i.e., the task package currently facing risks). This indicates that the summation is performed on all supply chain nodes (k,l) involved in material allocation. This indicates that the summation is performed on all delayed test task packages m. , , These are the costs of seconding personnel, the costs of allocating materials, and the costs of penalties for delays. The costs of penalties for delays can be dynamically adjusted according to the project priority. This refers to the number of personnel transferred from node i to node j. This refers to the quantity of materials transferred from node k to node l. The delay time length refers to the delay time of task package m. max(0, z) m This ensures that penalty costs are only incurred when actual delays occur. By setting an objective function, the core optimization metric can be established: minimizing the total cost. Minimizing the total cost includes: the cost of project delays, the cost of resource borrowing, and the loss of customer satisfaction.

[0123] In operation S408, mixed-integer programming is invoked. Using the operation values ​​from the reference case as the initial feasible solution, the target operation value is calculated through mixed-integer programming.

[0124] For example, the values ​​of multiple decision variables can be assigned as target operation values ​​to the target atomic operation template to obtain a new sequence of atomic operations. This can be used as a resource adjustment scheme, including: calling a mixed integer programming solver (such as the branch and bound method) to solve the objective function in the above formula (3) to obtain the optimal solution. , , value.

[0125] In operation S409, atomic operation mapping maps the target operation value to the target atomic operation template.

[0126] For example, atomic operation instructions may include: a personnel secondment instruction: "Secure engineer Li Si from project A to project B, with the secondment period from [date] to [date]"; a material transfer instruction: "Transfer material batch number M20260213 from task package Task1 to Task2, quantity 2 pieces"; and a task rescheduling instruction: "Postpone the start time of task package Task3 by 12 hours".

[0127] Traditional solutions rely directly on historical experience data for remedial measures, which is not optimal. The embodiments of this application employ mixed-integer programming, combining reference cases with current real-time constraints for mathematical optimization. This results in resource adjustment schemes that are not only based on historical experience but also represent the optimal solution with the lowest current cost. The atomic operation templates of the resource adjustment scheme in this application are derived from similar cases, while the operation values ​​are the optimal solutions considering various constraints, meeting current requirements. Thus, similar operations can be performed under similar risk conditions, but the specific operation values ​​are calculated considering current needs. An effective trade-off is achieved between historical operations and the current environment.

[0128] In some embodiments, operations S410 to S413 may also be performed after operation S409.

[0129] In operation S410, determine whether the constraints are satisfied. For example, a comprehensive feasibility check can be performed on the atomic operations output by the solver to check for hidden conflicts or deadlocks. If not, execute operation S411; if yes, execute operation S412.

[0130] In operation S411, adjust the search space. Then return to operation S405.

[0131] During operation S412, executable recovery instructions are generated.

[0132] When operating S413, the remedial instructions are written into the scheme execution record.

[0133] These atomic operations will be combined into structured, readable "executable remediation instructions" and written into the "scheme execution log" for the scheduler to execute directly.

[0134] According to an embodiment of this application, the method for assisting testing further includes: for each test task package in multiple test task packages, dividing the indicators involved in the test task package into multiple indicator clusters according to multiple preset dimensions, normalizing the indicators in the indicator clusters, and weighting and summing the normalized indicators to obtain the risk index of the indicator clusters; and fusing the risk indices of multiple indicator clusters to obtain the comprehensive risk index of the test task package.

[0135] The following will refer to Figure 5 This application describes a method for generating a comprehensive risk index according to embodiments thereof.

[0136] Figure 5 A flowchart of a method for generating a comprehensive risk index according to an embodiment of this application is shown.

[0137] like Figure 5 As shown, the generation of the comprehensive risk index in this embodiment includes operations S501 to S508.

[0138] When operating S501, the initial parameters of the currently ongoing test task package are obtained from various data sources. These initial parameters include, but are not limited to, the planned task time, required manpower skills, bill of materials, equipment requirements, and current progress.

[0139] In operation S502, data cleaning, default value filling, and outlier correction are performed on the initial parameters.

[0140] When operating S503, divide it into multiple indicator clusters.

[0141] In the embodiments of this application, an indicator cluster is a set of indicators under a classification dimension. The indicators in an indicator cluster can be quantitative parameters used to describe the status of a test task package, and are parameters after preprocessing the initial parameters. Examples include test progress deviation rate, personnel skill matching degree, and machine configuration matching degree. The dimension of an indicator cluster can be a classification dimension (such as progress or manpower), and multiple dimensions can include a progress health cluster, a manpower load cluster, a material / equipment cluster, and a quality backtracking cluster.

[0142] The preprocessed parameters were divided into four indicator clusters according to multiple dimensions: a schedule health cluster for assessing whether a task deviates from the original plan; a manpower load cluster for assessing the workload of the team or key personnel; a material / equipment cluster for assessing the availability of key material inventory or equipment; and a quality backtracking cluster for assessing the density and severity of defects found in the early testing phase. The specific content of the indicator clusters / sets and the indicators included in each dimension are shown in Table 1 below.

[0143] Table 1

[0144]

[0145] Different membership functions can be used to map each indicator to the [0,1] risk range for different indicators.

[0146] In operation S504, the indicators in the indicator cluster are normalized and weighted and summed to obtain the risk index of the indicator cluster.

[0147] In the embodiments of this application, the risk index can refer to the risk value obtained by assigning weights to the normalized indicators within a cluster and summing them. The sub-indicators within each indicator cluster are weighted and summed to obtain the basic risk indicators for each indicator cluster.

[0148] For the indicators in the schedule health cluster, the S-shaped membership function can be used for normalization, which is suitable for the characteristics of task schedule deviation being insignificant in the early stage and increasing sharply near the deadline. Assuming the schedule deviation ΔP = (actual progress - planned progress) / planned progress, a positive deviation indicates ahead of schedule and a negative deviation indicates lag, as shown in the following formula (4):

[0149] (4);

[0150] in, The growth rate coefficient, This is a risk trigger threshold. When the hysteresis exceeds the threshold... At that time, the risks increased sharply.

[0151] For indicators within a material / equipment cluster, an inverted L-shaped function can be used to calculate the material resource risk index. If a material is a critical path exclusive that plays a decisive role in the successful delivery of the project and must be completed on time, a material scarcity coefficient is introduced. Material resource risk index The specific formula is shown in formula (5) below:

[0152] (5);

[0153] in, The minimum safety stock is, The current inventory, if the material is a critical path exclusive, then A value >1 (e.g., set to 1.5 or 2.0) is used to amplify the inventory risk weight, making the risk more easily triggered.

[0154] For metrics within the human resource workload cluster, the net loss rate (such as the percentage of overtime hours) can be calculated and normalized by incorporating return-to-delivery penalties (the closer to the delivery date, the higher the workload and the greater the penalty). For example, for the human resource risk index... The net loss rate of secondment can be introduced. = (Number of borrowers - Number of available borrowers) / Total project manpower, Human resource risk index The calculation method is shown in the following formula (6):

[0155] = ×(1+ (6);

[0156] in, The estimated return period is determined by the number of days; if the return date is far in the future, the risk amplification factor increases. It can be the time decay factor. k2 is the time sensitivity coefficient.

[0157] For metrics in other continuous metric clusters (such as the quality backtesting cluster), the deviation rate (the ratio of actual defects to expected defects) or the pass rate (test case pass rate) can be calculated and normalized. For other continuous metrics (such as the average execution time of each test case), a risk index can be used. Normalization (e.g., Min-Max) can be used to process it, as shown in the following formula (7):

[0158] (7);

[0159] Where x is the measured value of the current continuous index. It can be the minimum value of the current continuous indicator. It can be the maximum value of the current continuous indicator.

[0160] The fusion of risk indices from multiple indicator clusters can include: within each indicator cluster, performing a weighted sum of the normalized indicators to obtain the risk index for each indicator cluster. The specific formula is shown in formula (8) below:

[0161] (8);

[0162] in, Let i be the number of indices within the i-th cluster. Let be the initial weight of the j-th indicator within the i-th indicator cluster (which can be determined based on experience or the entropy weight method). It can be the normalized risk value of the j-th indicator within the i-th indicator cluster. Based on this, the risk indices of multiple indicator clusters are fused to obtain the comprehensive risk index of the test task package.

[0163] The embodiments of this application can identify complex scenarios where "although the progress is normal, the scarcity of key materials and conflicts with high-priority projects lead to high hidden risks" through the index cluster division and fusion mechanism; by using normalization processing and dynamic weight calibration based on historical data, the risk assessment process is standardized and quantified, so that the risk assessment results obtained from different assessment objects and different time points are consistent and comparable.

[0164] By operating S505, the risk indices of multiple indicator clusters are merged to obtain a comprehensive risk index.

[0165] For example, the risk indices of multiple indicator clusters are fused to obtain the comprehensive risk index of the test task package. This includes: determining the weight of each indicator cluster based on the historical risk data related to each indicator cluster; and weighting and summing the risk indices of multiple indicator clusters based on their weights to obtain the comprehensive risk index of the test task package.

[0166] In the embodiments of this application, the weight of an indicator cluster can represent the coefficient of a certain indicator cluster (e.g., schedule health cluster, manpower load cluster) to the degree of contribution of the task package to the final risk. Weighted summation can be achieved by multiplying the risk index of each indicator cluster by its corresponding weight and then adding them together, thus integrating multi-dimensional risks (schedule, manpower, materials, quality) into a unified scalar value. The weight of each indicator cluster can be determined based on historical data.

[0167] The comprehensive risk index is a risk value obtained by fusing risk indices from multiple indicator clusters, based on dynamic weights calibrated from historical data. Calculating the comprehensive risk index enables task-package-level risk assessment. This facilitates risk assessment by staff during testing, thereby assisting testers in improving testing efficiency.

[0168] For example, using historical data, we can statistically determine the conditional probability of a project actually experiencing delays or failures when a certain cluster of indicators is at a high risk. This probability is used as the dynamic weight of index cluster i. The specific formula is shown in formula (9) below:

[0169] (9);

[0170] in, This indicates an event where the risk value of the i-th indicator cluster exceeds a preset threshold; This represents the number of times the i-th indicator cluster exceeds the threshold in historical data; In the above In cases where this occurs, the number of times the final test task package is delayed (i.e., the failure event).

[0171] In determining the weights of index cluster i Subsequently, the risk indices of the four indicator clusters can be merged through weighted summation to obtain the comprehensive risk index of the task package. Using historical risk data to calibrate the credibility weights of each indicator improves the accuracy of the comprehensive risk index assessment results.

[0172] When operating S506, the comprehensive risk index is adjusted using the coupling coefficient.

[0173] For example, for the current test task package among multiple test task packages, after obtaining the comprehensive risk index of the current test task package, a coupling coefficient is generated based on the similarity between the resource requirements of the current test task package and the resource requirements of other test task packages among multiple test task packages; the coupling coefficient is then used to adjust the comprehensive risk index of the current test task package.

[0174] In the embodiments of this application, resource requirements refer to the amount of various resources (human skills, material types, equipment types) required by the test task package. The resource requirement vector is a multi-dimensional array quantified from these requirements. Similarity can be an indicator used to measure the closeness of resource requirements between two test task packages, and can be obtained by calculating Euclidean distance. The coupling coefficient can be an amplification factor calculated based on similarity, used to quantify the additional risks brought about by resource competition. The higher the similarity (the smaller the distance), the smaller the denominator, the larger the fractional value, and the larger the coupling coefficient, representing more intense competition. Adjusting the comprehensive risk index of the current test task package can refer to multiplying the initially calculated comprehensive risk index by the coupling coefficient.

[0175] For example, the higher the similarity in resource requirements between the current test task package and other concurrent test task packages, the greater the coupling risk. The coupling coefficient is obtained by calculating the average Euclidean distance between the current test task package and all concurrent test task packages. The specific formula is shown in formula (10):

[0176] (10);

[0177] in, This is the resource requirement vector for the current test task package. , respectively, represent the intensity of demand for resources (human skill type, material type, equipment model), and k is the index of the current test task package. This can be a resource requirement vector of other concurrent test task packages, where j is the index of the other concurrent test task package. n is the total number of concurrent test task packages. λ is an adjustment coefficient; the smaller the distance (the more similar the resource requirements), the higher the coupling risk.

[0178] An improved Dempster-Shafer evidence synthesis formula was used to fuse the risk indices of the four dimensions in Table 1, utilizing the coupling coefficient. Adjust the overall risk index of the current test task package to obtain the adjusted overall risk index of the test task package. The specific formula is shown in formula (11) below:

[0179] (11);

[0180] The overall risk index of the adjusted test task package can be calculated. The data is written into the task risk database and can serve as input data for subsequent conflict detection and risk point location. Intermediate calculation results for each indicator cluster are also stored for subsequent interpretability analysis. According to embodiments of this application, the resource requirement similarity between the current task package and other concurrent task packages is further considered during the evaluation, thereby further improving the accuracy of the comprehensive risk index assessment results.

[0181] In some embodiments, after operation S506, operations S507 to S508 may also be performed.

[0182] When operating S507, output the comprehensive risk index.

[0183] When operating S508, the comprehensive risk index is written into the task risk database.

[0184] In one embodiment, the method for assisting testing further includes: periodically acquiring ongoing test task packages as multiple test task packages; and / or, in response to detecting a preset trigger event, using test task packages related to the trigger event as multiple test task packages.

[0185] After determining the overall risk index of multiple test task packages, risk warnings were issued to relevant personnel.

[0186] For example, the risk level of a test task package is determined based on its comprehensive risk index; the risk warning method, target audience, and content are determined based on the risk level; and the risk warning content is sent to the target audience according to the determined risk warning method for each test task package.

[0187] In the embodiments of this application, the risk level can be a hierarchy based on a comprehensive risk index, such as high risk (Rtask ≥ 0.8), medium risk (0.5 ≤ Rtask < 0.8), and low risk (Rtask < 0.5). Determining the push strategy based on the differentiated risk levels ensures effective information delivery. The risk alert method can be a push channel selected according to the risk level. The risk alert recipient can be the responsible party to whom the risk information needs to be delivered, specifically the project manager of the test task package or the project manager of the conflicting resource. The risk alert content can refer to the specific information pushed, including the task package name, risk index, risk identifier (four-tuple: task ID, resource ID, time window, conflict type), and the generated resource adjustment plan.

[0188] The following will refer to Figure 6 This document describes a risk warning method according to embodiments of the present application.

[0189] like Figure 6 As shown, the risk warnings in this application embodiment include operations S601~S617.

[0190] When operating S601, test task packages related to triggering events are treated as multiple test task packages.

[0191] In the embodiments of this application, the preset triggering event can refer to a pre-configured business change event that can cause a change in risk status. For example, business change events from various data sources are monitored in real time, and test task packages related to the triggering event are treated as multiple test task packages. When a business change event occurs, such as approval / revocation of personnel leave application, activation / deactivation of personnel secondment, material issuance / inbound, change of task package status to blocked / completed, or test progress update, incremental calculation is immediately triggered.

[0192] In S602, identify the change type. Business change types triggered by events can include: approval / revocation of personnel leave applications, activation / deactivation of personnel secondments, material issuance / receipt, task package status changes to blocked / completed, test progress updates, etc.

[0193] When operating S603, mark the test task package related to the trigger event.

[0194] When operating S604, the affected task packages are pulled incrementally. For example, based on the change type, the test task packages directly affected by the change are pulled. Alternatively, in addition to pulling the directly affected test task packages, the test task packages indirectly affected are also pulled based on the dependency data between the task packages.

[0195] When operating S605, incrementally calculate the multidimensional risk index.

[0196] When operating S606, incremental conflict detection and risk point location are performed.

[0197] When operating S607, incrementally generate resource adjustment plans.

[0198] It should be noted that the incremental calculation of risk indices, conflict detection and risk point location, and generation of resource adjustment schemes can refer to the aforementioned methods. Figures 3 to 5 The corresponding text content will not be elaborated here.

[0199] In operation S608, the task's real-time risk snapshot table is stored. The calculation results are stored in the task's real-time risk snapshot table for subsequent risk status merging.

[0200] Incremental computation only recalculates the affected test task packages and their downstream dependencies, including: identifying the set of test task packages directly affected by the changes. (For example, a staff member's leave affects all the task packages that staff member is responsible for); recursively search for all indirectly affected test task packages using the task package dependency graph. Only for and The test task package is re-executed to generate multidimensional risk index, detect conflicts and locate risk points, and generate adaptive remedial solutions, avoiding a full rerun; the calculation results are stored in the task's real-time risk snapshot table and overwrite the corresponding task's timed snapshot.

[0201] In addition to determining the test task package based on preset trigger events, it is also possible to periodically obtain all ongoing test task packages as multiple test task packages.

[0202] In operation S609, ongoing test task packages are periodically retrieved as multiple test task packages. Periodically retrieving ongoing test task packages can refer to automatically pulling a set of currently active test task packages at preset fixed time intervals. For example, it could be set to trigger daily at 01:00 to perform a full calculation. It should be noted that the periodically retrieved test task packages are not restricted by the triggering event.

[0203] When operating S610, calculate the full multidimensional risk index.

[0204] When operating S611, perform full-scale conflict detection and risk point location.

[0205] When operating S612, a full resource adjustment plan is generated.

[0206] It should be noted that the full calculation of the risk index, conflict detection and risk point location, and generation of resource adjustment schemes can refer to the aforementioned methods. Figures 3 to 5 The corresponding text content will not be elaborated here.

[0207] In operation S613, save the daily risk snapshot table of the task.

[0208] In operation S614, risk status is merged. Data is received from both the real-time driving link and the timed driving link, and a merging strategy is applied: if a real-time result exists in the "Task Real-time Risk Snapshot Table", the real-time result takes precedence (overriding or taking priority); if no real-time result exists, the timed result in the "Task Daily Risk Snapshot Table" takes precedence.

[0209] In operation S615, determine the risk level of the test task package. Based on the merged risk status, determine the risk level of the current task package: high risk, medium risk, or low risk.

[0210] When operating S616, determine the risk warning method, target audience, and content for the test task package. Based on the risk level, issue risk warnings. Push notifications to different processing levels or channels: High risk: escalate the email to the superior, emphasizing urgency. Medium risk: send an email to the project manager. Low risk: send only an internal message within the system to minimize disruption.

[0211] For example, for the test task package "core switch firmware verification", its comprehensive risk index was calculated to be 0.92, which was determined to be a high-risk level. Therefore, the risk warning method was determined to be "email, and escalated to the superior person in charge". The risk warning recipients were: the project leader of the task package (Zhang San) and the project leader of the conflicting resource (senior engineer Li Si) (Wang Wu).

[0212] The risk warning includes the task package name "Core Switch Firmware Verification," a risk index of 0.92, a risk coordinate quadruple ([Task_SwitchFW, Engineer_Li, Day3_AM, Manpower Conflict]), and the generated remedial / resource adjustment plan: second engineer Zhao Liu of the same level from Project B to this task package for a period of 2 days. The risk warning containing the above content is then sent to Zhang San and Wang Wu via email. Depending on the risk level, different channels can be used to push the determined risk warning content to the identified risk warning recipients, as shown in Table 2 below.

[0213] Table 2

[0214]

[0215] It adopts a dual-drive architecture that combines event-driven and timed calculation. Daily full calculation ensures baseline accuracy, while real-time monitoring of change events such as personnel secondment and material inbound / outbound is performed. Incremental calculation of affected task packages enables second-level risk updates.

[0216] In some embodiments, operation S617 may also be performed after operation S616.

[0217] When operating S617, feedback loop and updates are performed.

[0218] In one feasible implementation, after receiving the push notification, the recipient of the risk alert can "accept" or "reject" the generated remedial solution. This feedback is recorded, and the weight of the corresponding case in the historical case library is updated: if accepted, the case's weight increases; if rejected, the case's weight decreases. Through long-term learning and accumulation, the case library will gradually converge to recommended solutions that better match the behavioral patterns of testing tasks.

[0219] Collect feedback from project leaders (acceptance or rejection of remedial measures) and write the feedback results into the system's feedback tag library. Based on the feedback tags, trigger the case library weight update mechanism.

[0220] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0221] Based on the above-described auxiliary testing method, this application also provides an auxiliary testing apparatus. The following will be combined with... Figure 7 The device is described in detail.

[0222] Figure 7 A structural block diagram of an auxiliary testing apparatus according to an embodiment of this application is shown.

[0223] like Figure 7 As shown, the auxiliary testing device 700 in this embodiment includes a risk positioning module 710 and a scheme generation module 720.

[0224] The risk location module 710 is used to construct a demand relationship graph, which represents the demand relationships between multiple test task packages and multiple resources, as well as the usage periods of the resources required by each test task package. Based on the usage periods, the demand relationship graph is divided into multiple time windows, resulting in multiple sub-graphs. Conflicts in resource requirements of test task packages are detected in the sub-graphs, and risk identifiers are generated based on the detected conflicts. The risk identifiers include: the test task package and resource involved in the conflict, the type of conflict, and the time window in which the sub-graph is located. In one embodiment, the risk location module 710 can be used to execute operations S210 to S230 described above, which will not be repeated here.

[0225] The scheme generation module 720 is used to determine, from a plurality of pre-built resource adjustment cases, a resource adjustment case matching the risk identifier as a reference case, and generate a resource adjustment scheme for a risk task package based on the reference case. The risk task package is a test task package included in the risk identifier, and the resource adjustment scheme is used to adjust the resource allocation of the risk task package. In one embodiment, the scheme generation module 720 can be used to perform the operation S270 described above, which will not be repeated here.

[0226] According to embodiments of this application, the risk location module 710 and the solution generation module 720 in the auxiliary testing device construct a demand relationship graph containing the relationship between test task packages and resource requirements and usage periods, thus satisfying the location of task package-level risk points at each stage of the project. By dividing the demand relationship graph into multiple time windows to obtain subgraphs and detecting resource requirement conflicts in the subgraphs, risk identifiers containing the test task packages, resources, conflict types, and corresponding time windows involved in the conflicts are generated, achieving proactive risk prevention and control. By matching pre-stored resource adjustment cases to generate resource adjustment schemes for risky task packages, targeted remedial solutions at the task package level are provided, while covering the interaction relationships between multiple test task packages and multiple resources. This can cope with resource competition conflicts in multi-project parallel scenarios and improve the adaptability of resource scheduling schemes.

[0227] According to an embodiment of this application, the demand relationship graph includes multiple first nodes, multiple second nodes, and multiple edges, wherein the first node represents a test task package, the second node represents a resource, the edge between the first node and the second node indicates that the test task package of the first node needs the resource of the second node, and the edge has a time label, which indicates the period during which the test task package uses the required resource.

[0228] According to an embodiment of this application, the risk location module 710 includes an edge determination submodule and a node determination submodule. The edge determination submodule is used to determine, for each time window in a plurality of time windows, the edges whose time tags fall within the time windows in the demand relationship graph, and to designate them as edges in the subgraph. The node determination submodule is used to connect the first node and the second node of the edges whose time tags fall within the time windows in the demand relationship graph, and to designate them as the first node and the second node in the subgraph.

[0229] According to an embodiment of this application, the risk location module 710 further includes: a conflict determination submodule and an identifier generation submodule. The conflict determination submodule is used to determine the edges involved in the conflict as conflict edges; the identifier generation submodule is used to generate risk identifiers for the conflict edges. The risk identifier includes: a test task package corresponding to a first node connected to the conflict edge, resources corresponding to a second node connected to the conflict edge, the type of conflict corresponding to the conflict edge, and the time window in which the conflict edge falls; wherein, the test task package corresponding to the first node connected to the conflict edge is used as a risk task package, and the risk identifier generated for the conflict edge is used as the risk identifier of the risk task package.

[0230] According to embodiments of this application, resource adjustment cases include risk feature vectors and atomic operations corresponding to the risk feature vectors; the scheme generation module 720 includes: a vector generation submodule, a vector determination submodule, and a case determination submodule. The vector generation submodule is used to generate risk feature vectors for a risk task package based on its risk identifier; the vector determination submodule is used to determine, among multiple resource adjustment case risk feature vectors, a risk feature vector whose similarity to the risk feature vector of the risk task package meets predetermined conditions, and uses it as the target feature vector; the case determination submodule is used to use resource adjustment cases including the target feature vector as reference cases.

[0231] According to an embodiment of this application, the reference case includes atomic operation templates and operation values. The scheme generation module 720 further includes a template generation submodule, a calculation submodule, and a mapping submodule. The template generation submodule is used to generate a target atomic operation template based on the atomic operation templates of the reference case. The calculation submodule is used to calculate the target operation value by using the operation value of the reference case as an initial feasible solution and solving it through mixed integer programming. The mapping submodule is used to map the target operation value to the target atomic operation template to obtain a resource adjustment scheme.

[0232] According to an embodiment of this application, the risk location module 710 further includes: a manpower conflict determination submodule, an equipment conflict determination submodule, and a material conflict determination submodule. The manpower conflict determination submodule is used to determine if a conflict has been detected if different test task packages in a subgraph require the same exclusive human resources, and to determine the type of conflict as a manpower conflict. The equipment conflict determination submodule is used to determine if a conflict has been detected if different test task packages in a subgraph require the same exclusive equipment resources, and to determine the type of conflict as an equipment conflict. The material conflict determination submodule is used to determine if a material conflict has been detected if the sum of the material resource requirements of the test task packages in the subgraph is greater than the available material resource quantity within the time window corresponding to the subgraph, and to determine the type of conflict as a material conflict.

[0233] According to embodiments of this application, the auxiliary testing apparatus further includes: a partitioning module, a summing module, and a fusion module. The partitioning module is used to divide the indicators involved in each of the multiple test task packages into multiple indicator clusters according to preset multiple dimensions. The summing module is used to normalize the indicators in the indicator clusters and perform a weighted summation of the normalized indicators to obtain a risk index for the indicator clusters. The fusion module is used to fuse the risk indices of the multiple indicator clusters to obtain a comprehensive risk index for the test task package.

[0234] According to an embodiment of this application, the fusion module includes a weight determination submodule and a weighting submodule. The weight determination submodule is used to determine the weight of each indicator cluster based on historical risk data related to each indicator cluster. The weighting submodule is used to perform a weighted summation of the risk indices of multiple indicator clusters based on their weights to obtain the comprehensive risk index of the test task package.

[0235] According to embodiments of this application, the auxiliary testing apparatus further includes a coefficient generation module and an adjustment module. The coefficient generation module is used to generate a coupling coefficient for the current test task package among multiple test task packages, after obtaining the comprehensive risk index of the current test task package, based on the similarity between the resource requirements of the current test task package and the resource requirements of other test task packages among the multiple test task packages; the adjustment module is used to adjust the comprehensive risk index of the current test task package using the coupling coefficient.

[0236] According to an embodiment of this application, the auxiliary testing apparatus further includes: a level determination module, a content determination module, and a sending module. The level determination module is used to determine the risk level of the test task package based on its comprehensive risk index; the content determination module is used to determine the risk warning method, risk warning recipients, and risk warning content of the test task package based on its risk level; and the sending module is used to send the determined risk warning content to the determined risk warning recipients according to the determined risk warning method for the test task package.

[0237] According to embodiments of this application, the auxiliary testing apparatus further includes: an acquisition module and a response module. The acquisition module is used to periodically acquire ongoing test task packages as multiple test task packages; and / or the response module is used to, in response to detecting a preset trigger event, allocate the test task packages related to the trigger event as multiple test task packages.

[0238] For a description of the features of the auxiliary testing device in the corresponding embodiment, please refer to the relevant description of the auxiliary testing method in the corresponding embodiment, which will not be repeated here.

[0239] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described methods for auxiliary testing.

[0240] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described auxiliary testing method embodiments when run.

[0241] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0242] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described auxiliary testing method embodiments.

[0243] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described auxiliary testing method embodiments.

[0244] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0245] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0246] The foregoing has provided a detailed description of the auxiliary testing method, apparatus, electronic device, and storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method of aiding testing, characterized by, include: Construct a requirement relationship graph, which represents the requirement relationship between multiple test task packages and multiple resources, as well as the usage period of the resources required by each test task package; Based on the usage period, the demand relationship graph is divided into multiple time windows, resulting in multiple sub-graphs; Detect resource requirement conflicts of test task packages in the subgraph and generate risk labels based on the detected conflicts. The risk labels include: the test task package and resources involved in the conflict, the type of conflict, and the time window in which the subgraph is located. From a number of pre-built resource adjustment cases, a resource adjustment case that matches the risk identifier is selected as a reference case. Based on the reference case, a resource adjustment plan for the risk task package is generated. The risk task package is a test task package contained in the risk identifier. The resource adjustment plan is used to adjust the resource allocation of the risk task package.

2. The method of claim 1, wherein, The demand relationship graph includes multiple first nodes, multiple second nodes, and multiple edges. The first node represents a test task package, the second node represents a resource, and the edge between the first node and the second node indicates that the test task package of the first node needs the resource of the second node. The edge has a time label, which indicates the period during which the test task package uses the required resource.

3. The method of claim 2, wherein, Based on the usage period, the demand relationship graph is divided into multiple time windows, resulting in multiple sub-graphs, including: For each time window in multiple time windows, determine the edge whose time label falls into the time window from the multiple edges of the demand relationship graph, and use it as the edge in the subgraph; In the demand relationship graph, the first and second nodes connected by the edge where the time tag falls into the time window are used as the first and second nodes in the subgraph.

4. The method of claim 3, wherein, Risk identifiers are generated based on the detected conflicts, including: The edges involved in the conflict are identified as conflict edges; For conflict edges, risk identifiers are generated. The risk identifiers include: the test task package corresponding to the first node connected to the conflict edge, the resource corresponding to the second node connected to the conflict edge, the type of conflict corresponding to the conflict edge, and the time window in which the conflict edge falls. Specifically, the test task package corresponding to the first node connected to the conflict edge is used as the risk task package, and the risk identifier generated for the conflict edge is used as the risk identifier of the risk task package.

5. The method of claim 4, wherein, Resource adjustment cases include risk feature vectors and the atomic operations corresponding to the risk feature vectors; From a pool of pre-built resource adjustment cases, resource adjustment cases that match the risk indicators are selected as reference cases, including: Based on the risk identifier of the risk task package, generate the risk feature vector of the risk task package; Among the risk feature vectors of multiple resource adjustment cases, the risk feature vectors that have a similarity to the risk feature vectors of the risk task package that meet the predetermined conditions are identified as the target feature vectors. The resource adjustment case that includes the target feature vector is used as a reference case.

6. The method of claim 5, wherein, The reference cases include atomic operation templates and operation values. Based on these reference cases, resource adjustment plans for risk task packages are generated, including: Generate the target atomic operation template based on the atomic operation template of the reference case; Using the operation value of the reference case as the initial feasible solution, the target operation value is calculated by solving mixed integer programming. The target operation value is mapped to the target atomic operation template to obtain the resource adjustment scheme.

7. The method of claim 1, wherein, Detect resource requirement conflicts for test task packages in the subgraph, including: If different test task packages in a subgraph are detected to require the same exclusive human resources, then a conflict is detected, and the type of conflict is determined to be a human resources conflict. If different test task packages in a subgraph are detected to require the same exclusive device resource, it is determined that a conflict has been detected, and the type of conflict is determined to be a device conflict. If the sum of the material resource requirements of the test task packages in the subgraph is greater than the available material resource quantity in the corresponding time window of the subgraph, then a material conflict is detected and the type of conflict is determined to be a material conflict.

8. The method of claim 1, wherein, Also includes: For each test task package within multiple test task packages, The metrics involved in the test task package are divided into multiple metric clusters according to multiple preset dimensions; The indicators in the indicator cluster are normalized, and the normalized indicators are weighted and summed to obtain the risk index of the indicator cluster. The risk indices of multiple indicator clusters are fused to obtain the comprehensive risk index of the test task package.

9. The method according to claim 8, characterized in that, The risk indices of multiple indicator clusters are fused to obtain the comprehensive risk index of the test task package, including: For each indicator cluster within multiple indicator clusters, the weight of each indicator cluster is determined based on the historical risk data associated with that cluster. Based on the weights of multiple indicator clusters, the risk indices of the multiple indicator clusters are weighted and summed to obtain the comprehensive risk index of the test task package.

10. The method according to claim 9, characterized in that, Also includes: For the current test task package among multiple test task packages, After obtaining the comprehensive risk index of the current test task package, a coupling coefficient is generated based on the similarity between the resource requirements of the current test task package and the resource requirements of other test task packages in multiple test task packages. The coupling coefficient is used to adjust the overall risk index of the current test task package.

11. The method according to claim 8, characterized in that, Also includes: The risk level of the test task package is determined based on its comprehensive risk index. Based on the risk level of the test task package, determine the risk warning method, the target audience for the risk warning, and the content of the risk warning for the test task package; For each test task package, the determined risk warning content is sent to the designated risk warning recipients according to the determined risk warning method.

12. The method according to any one of claims 1 to 11, characterized in that, Also includes: Periodically acquire ongoing test task packages as the multiple test task packages; and / or In response to the detection of a preset trigger event, the test task package related to the trigger event is used as one of the multiple test task packages.

13. A device for auxiliary testing, characterized in that, include: The risk identification module is used to build a demand relationship graph, which represents the demand relationship between multiple test task packages and multiple resources, as well as the usage period of the resources required by each test task package. Based on the usage period, the demand relationship graph is divided into multiple time windows, resulting in multiple sub-graphs; Detect resource requirement conflicts of test task packages in the subgraph and generate risk labels based on the detected conflicts. The risk labels include: the test task packages and resources involved in the conflict, the type of conflict, and the time window in which the subgraph is located. The solution generation module is used to identify the resource adjustment case that matches the risk identifier from a number of pre-built resource adjustment cases as a reference case, and generate a resource adjustment solution for the risk task package based on the reference case. The risk task package is a test task package contained in the risk identifier, and the resource adjustment solution is used to adjust the resource allocation of the risk task package.

14. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the method as described in any one of claims 1 to 11.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the auxiliary testing method as described in any one of claims 1 to 11.

Images