Performance regression testing method, device, electronic device and storage medium

Abstract

The embodiment of the present application provides a performance regression test method, device, electronic device and storage medium. The method includes: determining the environment change information of the software according to the current environment snapshot of the software at the current time and the most recent historical environment snapshot of the software from the current time; analyzing the use case execution result obtained by executing the patrol inspection test case of the software to obtain the current patrol inspection result; generating the current patrol inspection feature label according to the current patrol inspection result; updating the result analysis rule tree according to the current patrol inspection result, the historical patrol inspection result and the environment change information, the result analysis rule tree is a tree structure with the use case failure cause as the root node and the feature label corresponding to the use case failure cause as the leaf node; matching the current patrol inspection feature label with the feature label on the updated result analysis rule tree to obtain the patrol inspection failure cause of the current patrol inspection failure.

Description

Technical Field

[0001] The present application relates to the field of software development technology, and in particular to a performance regression testing method, device, electronic device and storage medium. Background Art

[0002] Performance testing plays an important role in software development. It can help identify performance bottlenecks in the system, discover and solve system performance problems, and is an important means to ensure efficient and stable operation of the system. It is extremely important for improving user experience and reducing operational risks and costs. For services that have undergone version changes, corresponding performance regression tests should be performed on their core interfaces after the changes to ensure that there will be no performance degradation or even production accidents.

[0003] However, due to the extensive and in-depth application of agile development ideas in daily development work, services are iterating rapidly and at high frequency every day, resulting in a surge in the demand for performance regression testing. Faced with a large number of indicator checks and a large number of failure result analyses, regression verification cannot be performed solely by manpower. Summary of the invention

[0004] The technical problem to be solved by the embodiments of the present application is to provide a performance regression testing method, device, electronic device and storage medium to implement performance regression testing without human intervention, so as to achieve the purpose of improving the efficiency and accuracy of performance regression testing.

[0005] In a first aspect, an embodiment of the present application provides a performance regression testing method, the method comprising:

[0006] Determine the environment change information of the software according to the current environment snapshot of the software at the current time and the most recent historical environment snapshot of the software from the current time;

[0007] Analyze the use case execution results obtained by executing the patrol inspection test case of the software to obtain the patrol inspection verification result;

[0008] If the inspection verification result indicates that there are failed test cases in the inspection, a feature tag for the inspection is generated according to the inspection verification result;

[0009] According to the inspection and verification result of this time, the historical inspection and verification result corresponding to the historical environment snapshot and the environment change information, the result analysis rule tree is updated, wherein the result analysis rule tree is a tree structure with the use case failure cause as the root node and the feature label corresponding to the use case failure cause as the leaf node;

[0010] The inspection feature tag of this time is matched with the feature tag on the updated result analysis rule tree to obtain the inspection failure reason of this inspection failure.

[0011] In a second aspect, an embodiment of the present application provides a performance regression testing device, the device comprising:

[0012] An environment change information determination module, used to determine the environment change information of the software according to the current environment snapshot of the software at the current time and the most recent historical environment snapshot of the software from the current time;

[0013] The inspection and verification result acquisition module is used to analyze the use case execution results obtained by executing the inspection and verification test case of the software to obtain the inspection and verification results of this time;

[0014] An inspection feature label generation module, used to generate a current inspection feature label according to the current inspection verification result when the current inspection verification result indicates that there is a failed test case in the current inspection;

[0015] An analysis rule tree updating module, used to update a result analysis rule tree according to the inspection and verification result of this inspection and verification, the historical inspection and verification result corresponding to the historical environment snapshot, and the environment change information, wherein the result analysis rule tree is a tree structure with the use case failure cause as the root node and the feature label corresponding to the use case failure cause as the leaf node;

[0016] The inspection failure reason acquisition module is used to match the inspection feature tag of this inspection with the feature tag on the updated result analysis rule tree to obtain the inspection failure reason of this inspection failure.

[0017] In a third aspect, an embodiment of the present application provides an electronic device, including:

[0018] A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor implements any of the above-mentioned performance regression testing methods when executing the program.

[0019] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium. When the instructions in the storage medium are executed by a processor of an electronic device, the electronic device can execute any of the performance regression testing methods described above.

[0020] Compared with the prior art, the embodiments of the present application have the following advantages:

[0021] In the embodiment of the present application, the environment change information of the software is determined according to the current environment snapshot of the software at the current time and the historical environment snapshot of the software at the most recent time. The use case execution result obtained by executing the patrol test case of the software is analyzed to obtain the inspection verification result of this patrol. In the case where the inspection verification result of this patrol indicates that there is a failed test case in this patrol, the feature label of this patrol is generated according to the inspection verification result of this patrol. According to the inspection verification result of this patrol, the historical inspection verification result corresponding to the historical environment snapshot and the environment change information, the result analysis rule tree is updated. The result analysis rule tree is a tree structure with the failure cause of the use case as the root node and the feature label corresponding to the failure cause of the use case as the leaf node. The inspection feature label of this patrol is matched with the feature label on the updated result analysis rule tree to obtain the inspection failure reason of this patrol failure. The embodiment of the present application generates a feature label for each performance patrol use case according to the generated environment snapshot, automatic verification of performance indicators and persistent storage of patrol records, and then combines the result analysis rule tree to obtain the corresponding failure reason, completes the automatic analysis of the performance patrol failure use case, effectively improves the analysis quality and analysis efficiency, and reduces the investment of manpower cost. At the same time, the result analysis rule tree can be self-updated according to historical execution records and environmental changes without human intervention, further reducing the investment in labor costs and achieving the goal of more accurate and efficient testing.

[0022] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 A flowchart of a performance regression testing method provided in an embodiment of the present application;

[0024] Figure 2 A flowchart of a method for determining environmental change information provided in an embodiment of the present application;

[0025] Figure 3 A flowchart of a method for obtaining inspection and verification results provided in an embodiment of the present application;

[0026] Figure 4 A flowchart of a method for generating inspection feature labels provided in an embodiment of the present application;

[0027] Figure 5 A flowchart of the steps of a result analysis rule tree updating method provided in an embodiment of the present application;

[0028] Figure 6 A flowchart of a method for acquiring a feature group provided in an embodiment of the present application;

[0029] Figure 7 A schematic diagram of the structure of a performance regression testing device provided in an embodiment of the present application;

[0030] Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0031] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, the present application is further described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0032] The terms used in the embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to limit the present application. The singular forms "a", "said" and "the" used in the embodiments of the present application and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings.

[0033] Reference Figure 1 , shows a flow chart of the steps of a performance regression testing method provided by an embodiment of the present application, such as Figure 1 As shown, the performance regression testing method may include: step 101, step 102, step 103, step 104 and step 105.

[0034] Step 101: Determine the environment change information of the software according to the current environment snapshot of the software at the current time and the most recent historical environment snapshot of the software from the current time.

[0035] The embodiments of the present application can be applied to a scenario in which an environment snapshot generated at the current time and an environment snapshot generated most recently are used to update a result analysis rule tree, and the cause of inspection failure is analyzed according to the updated result analysis rule tree and the results of this inspection test.

[0036] Software services, in a broad sense, refer to various support and functions related to the software, which are designed to ensure that the software can operate normally, meet user needs, and continue to provide value.

[0037] The current environment snapshot refers to a snapshot of the software's operating environment, such as services, components, scripts, and baselines associated with the software's operation, created at the current time.

[0038] A historical environment snapshot refers to the most recent snapshot of the software created at the current time.

[0039] In some examples, the software's environmental snapshots may be created periodically, that is, a period for creating the software's environmental snapshots may be pre-set, such as 30 minutes, 1 hour, 3 hours, etc. When the set snapshot creation period is reached, the software's operating environment information may be automatically obtained to create the software's environmental snapshot, etc.

[0040] In some examples, the software environment snapshot may be an environment snapshot created when a service of the software changes. For example, when a service monitoring thread detects a change in one or more services of the software, the software's operating environment information may be obtained to create an environment snapshot of the software.

[0041] It can be understood that the above examples are only examples listed for better understanding of the technical solutions of the embodiments of the present application, and the present embodiment does not limit the timing of creating the environment snapshot of the software.

[0042] When the software environment snapshot creation condition is reached at the current time (such as reaching the software environment snapshot creation cycle or the software service changes, etc.), the current environment snapshot of the software at the current time can be generated, and the software environment change information can be determined based on the current environment snapshot and the most recent historical environment snapshot generated from the current time. The environment change information can be used to indicate changes in the software operating environment. Of course, if the current environment snapshot has not changed from the most recent historical environment snapshot generated from the current time, the software environment change information is empty.

[0043] The implementation process of determining the software environment change information based on the current environment snapshot and the historical environment snapshot can be combined Figure 2 This is described in detail as follows.

[0044] Reference Figure 2 , shows a flow chart of the steps of a method for determining environmental change information provided by an embodiment of the present application. Figure 2 As shown, the method for determining environment change information may include: step 201, step 202, step 203, step 204, step 205 and step 206.

[0045] Step 201: Obtain service deployment information and service operation information of all services of the software at the current time, component deployment information and component operation information of all components, and script information and baseline information of the software.

[0046] In this embodiment, service deployment information refers to the configuration and deployment status of a software service in a specific environment (such as a production environment, a test environment, etc.) The service deployment information may include: deployment version, startup parameters, number of nodes, node resource configuration, and other information.

[0047] Service operation information refers to the status and performance data of software services during operation. Service operation information includes: current resource utilization, service monitoring level, node IP, exception log and other information.

[0048] Component deployment information refers to the configuration and deployment status of each component in the software service (such as database, middleware, third-party library, etc.). Component deployment information may include: component version, specifications, and other information.

[0049] Component operation information refers to the status and performance data of each component in the software service during operation. Component operation information can include: component resource usage, component specific data, etc. Among them, the specific data information varies according to the component type. For example, MySQL is the data table structure and data table order of magnitude. Kafka is the topic list, consumption, production rate, etc.

[0050] Script information refers to the script files and their contents used for automated deployment, configuration, monitoring and management of software services. Script information may include: the name and path of the script file, the purpose and function description of the script, the execution steps and logical flow of the script, other scripts or tools that the script depends on, and other information.

[0051] Baseline information refers to the initial reference standard or snapshot of the interface called and its performance indicator data when a certain operation or scenario (such as adding a shopping cart) is executed under specific conditions. Taking performance inspection as an example, there is a script that verifies the results of a certain scenario (such as adding a shopping cart, etc.). Adding a shopping cart is an action. The interfaces called by this action and the performance indicator data of the interfaces are called the baseline of the script. Of course, it is not limited to this. The script baseline can also be the performance indicators of the services and components associated with the interface during the execution of the interface. These two types of indicators are incremental performance change indicators, such as a 20% increase in CPU. When performing subsequent service and component indicator verification, the snapshot data can be used as the basis to check whether the increase in resource consumption after this execution exceeds the baseline floating threshold for judgment.

[0052] When the software environment snapshot creation conditions are met, service deployment information and service operation information of all services of the software, component deployment information and component operation information of all components, and script information and baseline information of the software can be obtained.

[0053] After obtaining the service deployment information and service operation information of all services of the software, the component deployment information and component operation information of all components, and the script information and baseline information of the software, step 202, step 203 and step 204 are executed.

[0054] Step 202: Create a service operation snapshot according to the service deployment information and the service operation information.

[0055] After obtaining the service deployment information and service operation information, a service operation snapshot can be created based on the service deployment information and service operation information. Specifically, the service deployment information: deployment version, startup parameters, number of nodes, node resource configuration and other information. Service operation information: current resource usage rate, service monitoring level, node IP, exception log and other information can be recorded and saved to generate a service operation snapshot. The service operation snapshot can reflect the service operation information when the software service changes at the current time.

[0056] Step 203: Create a component operation snapshot according to the component deployment information and the component operation information.

[0057] After obtaining the component deployment information and the component operation information, a component operation snapshot can be created based on the component deployment information and the component operation information. Specifically, the component deployment information: component version, specification, etc. and the component operation information: component resource usage, component specific data, etc. can be recorded and saved to generate a component operation snapshot. The component operation snapshot can reflect the operation status information of the component when the software service changes at the current time.

[0058] Step 204: Create a script and a baseline snapshot according to the script information and the baseline information.

[0059] After obtaining the script information and baseline information, you can create a script and baseline snapshot based on the script information and baseline information. The script and baseline snapshot can reflect information on services, configurations, scripts, baselines, etc. when software services change.

[0060] Step 205: The service operation snapshot, the component operation snapshot, the script and the baseline snapshot are taken together as the current environment snapshot.

[0061] After obtaining the service operation snapshot, component operation snapshot, script and baseline snapshot, the service operation snapshot, component operation snapshot, script and baseline snapshot can be used together as the current environment snapshot of the software at the current time.

[0062] Step 206: Compare the current environment snapshot with the historical environment snapshot to obtain the environment change information.

[0063] After obtaining the current environment snapshot, you can compare the current environment snapshot with the most recent historical environment snapshot to obtain the software environment change information. For example, by comparing with the previous snapshot, you can get all the changes, for example, service A: version changes from V1.0 to V2.0, the amount of data in the user_info table in the t_user database changes from 3 million to 5 million, the 1001 script is updated, and the number of concurrent operations is adjusted from 100 to 500, etc.

[0064] It can be understood that the above examples are merely examples listed for a better understanding of the technical solutions of the embodiments of the present application, and are not intended to be the sole limitation to the embodiments.

[0065] The embodiment of the present application proposes a multi-dimensional environment snapshot solution, which covers service operation status snapshots, component operation status snapshots, scripts and baseline status snapshots, so that environmental changes can be clearly seen, and effectively provides data support for problem location and troubleshooting.

[0066] After determining the environment change information of the software based on the current environment snapshot of the software at the current time and the most recent historical environment snapshot of the software from the current time, step 102 is executed.

[0067] Step 102: Analyze the use case execution results obtained by executing the patrol inspection test case of the software to obtain the patrol inspection verification result.

[0068] After obtaining the current environment snapshot of the software at the current time, you can obtain the software's patrol test cases, execute the patrol test cases, and obtain the use case execution results. Then, you can analyze the use case execution results to obtain the results of this patrol verification. Specifically, you can pre-set the patrol execution mode, and filter out patrol test cases from the software's test cases according to the patrol execution mode, and execute the scripts of the patrol test cases to obtain the use case execution results and the monitoring indicator information during the execution process. Furthermore, you can analyze the use case execution results and monitoring indicator information according to the preset verification rules to obtain the patrol verification results. This implementation process can be combined with Figure 3 This is described in detail as follows.

[0069] Reference Figure 3 , shows a flowchart of the steps of a method for obtaining inspection and verification results provided by an embodiment of the present application. Figure 3 As shown, the inspection and verification result acquisition method may include: step 301, step 302 and step 303.

[0070] Step 301: Determine the patrol inspection trial case according to the environment change information and the preset patrol inspection execution mode.

[0071] In this embodiment, a batch of performance inspection use cases are maintained in advance during software development. Each performance inspection use case corresponds to a script and contains multiple types of baseline data, which may specifically include the following three categories:

[0072] 1. Performance indicator baseline:

[0073] Interface performance indicators: tps, rt, exception rate, etc.

[0074] Service performance indicators: indicator information of related services, resource usage, GC (Garbage Collection) status (i.e. the number of garbage collections per unit time), etc.

[0075] Component performance indicators: indicator information of related components, resource usage, GC status, etc.

[0076] 2. Script situation baseline:

[0077] Script content: request definition, request URL (Uniform Resource Locator), request parameters, etc. in the script.

[0078] Script execution configuration: number of concurrent calls, execution time, rate limiter, etc.

[0079] 3. Baseline of association:

[0080] Related service information: which services are related, how to call them, the version of the related services, configuration parameters, number of nodes, etc.

[0081] Related component information: which components are associated, the version of the associated service, configuration parameters, number of nodes, etc.

[0082] After obtaining the environment change information by comparing the current environment snapshot with the historical environment snapshot, the patrol inspection trial case can be determined according to the environment change information and the preset patrol execution mode.

[0083] In this embodiment, when the inspection execution mode is the incremental execution mode, the inspection test case with changes in the test case can be determined based on the environment change information, the association between the software test case and the software services and components.

[0084] When the inspection execution mode is the full execution mode, all test cases of the software can be used as inspection test cases.

[0085] It is understandable that when there is no change between the current environment snapshot and the historical environment snapshot, that is, the environment change information of the software is empty, the full execution mode can be adopted at this time, and all test cases of the software can be inspected as inspection test cases.

[0086] After the patrol inspection trial case is determined according to the environment change information and the preset patrol inspection execution mode, step 302 is executed.

[0087] Step 302: Execute the script of the patrol inspection test case to obtain the execution result of the test case and the monitoring indicator information of the patrol inspection test case during the execution process.

[0088] After determining the patrol inspection trial case according to the environment change information and the pre-set patrol execution mode, the script of the patrol inspection trial case can be executed to obtain the use case execution result and the monitoring indicator information of the patrol inspection trial case during the execution process. Specifically, an execution plan can be generated according to the patrol inspection trial case, and the scripts in the execution plan can be traversed and executed in sequence, and the script execution results can be collected to obtain the use case execution result. At the same time, the monitoring indicator information during the script execution process can include: throughput, response time, resource utilization (such as memory occupancy, CPU utilization, etc.), network bandwidth, etc.

[0089] After executing the script of the patrol detection test case to obtain the use case execution result and the monitoring indicator information of the patrol detection test case during the execution process, step 303 is executed.

[0090] Step 303: Analyze the use case execution results and the monitoring indicator information based on the preset verification rules to obtain the inspection verification results of this inspection, which include: application programming interface performance indicators, service performance indicators, component performance indicators and abnormal log detection results.

[0091] After executing the script of the patrol inspection test case to obtain the use case execution result and the monitoring indicator information of the patrol inspection test case during the execution process, the use case execution result and the monitoring indicator information can be analyzed based on the preset verification rules to obtain the patrol inspection verification result.

[0092] Preset verification rules refer to pre-set rules for analyzing the test case execution results to determine whether they meet expectations. In this example, rules can be set separately for each indicator, and multiple types of rules can be set, such as floating coefficients (for some performance indicators, they may be allowed to fluctuate within a certain range, for example, the response time of the API may be allowed to have a floating range of ±10%, etc.), at most or at least (for some performance indicators, a clear upper or lower limit may be set, for example, the response time of the service may be required to be no more than 200 milliseconds, and the CPU utilization of the system may be required to be at least kept below 50% to avoid idle resources, etc.), etc., based on the data contained in the performance indicator baseline (pre-defined performance indicator data, used as a reference standard during the test process) for verification.

[0093] The inspection results may include: Application Program Interface (API) performance indicators, service performance indicators, component performance indicators, and abnormal log detection results.

[0094] The embodiment of the present application can significantly reduce the time and labor cost of manual inspections by executing inspection trials through automated scripts. The preset inspection execution mode and verification rules can ensure the consistency and accuracy of each inspection. The collection and analysis of monitoring indicator information can provide more detailed and comprehensive system status information, which helps to discover potential problems.

[0095] After analyzing the use case execution results obtained from the patrol inspection test case of the execution software to obtain the patrol inspection result, step 103 is executed.

[0096] Step 103: When the inspection verification result indicates that there are failed test cases in the inspection, a feature tag for the inspection is generated according to the inspection verification result.

[0097] After analyzing the test case execution results obtained by executing the pre-set software inspection test case according to the preset verification rules to obtain the inspection verification results of this inspection, it can be determined whether there are failed test cases in the inspection verification results of this inspection. In the case where the inspection verification results of this inspection indicate that there are failed test cases in this inspection, the inspection feature labels of this inspection can be generated according to the inspection verification results of this inspection. Among them, the inspection feature labels of this inspection refer to a set of labels used to describe and identify key features and states in the inspection process.

[0098] The implementation process of generating the inspection feature label can be combined with Figure 4 This is described in detail as follows.

[0099] Reference Figure 4 , shows a flowchart of the steps of a method for generating inspection feature labels provided by an embodiment of the present application. Figure 4 As shown, the inspection feature tag generation method may include: step 401 and step 402.

[0100] Step 401: perform data cleaning on the inspection and verification results of this time to obtain processed inspection and verification results.

[0101] In this embodiment, after obtaining the inspection and verification results, the inspection and verification results can be cleaned to obtain processed inspection and verification results. Specifically, the data in the inspection and verification results can be sorted according to a predetermined format to remove redundant information to ensure the accuracy and consistency of the data.

[0102] After data cleaning is performed on the inspection and verification results of this inspection and verification to obtain processed inspection and verification results, step 402 is executed.

[0103] Step 402: Classify the inspection results by feature labels to obtain the inspection feature labels for this inspection.

[0104] After data cleaning is performed on the inspection and verification results of this inspection and verification to obtain processed inspection and verification results, feature label classification can be performed on the processed inspection and verification results to obtain feature labels of this inspection.

[0105] In this example, the inspection feature tags may include: an environment change tag, an execution result tag, and a history record tag.

[0106] Among them, the environmental change label refers to the conversion of changes related to the current patrol inspection trial into relevant feature labels, such as service version changes, increase in the amount of associated data, changes in the script request interface, increase in the number of script concurrency, etc.

[0107] The execution result label refers to the relevant feature label obtained by converting the four types of verification results of this inspection (namely, API performance indicators, service performance indicators, component performance indicators, and abnormal log detection).

[0108] Historical record labeling refers to converting the historical execution information of patrol inspection test cases into relevant feature labels, such as the number of recent consecutive failures and associated defects to be resolved.

[0109] After generating the inspection feature tag according to the inspection verification result, step 104 is executed.

[0110] Step 104: Update the result analysis rule tree based on the inspection and verification results of this time, the historical inspection and verification results corresponding to the historical environment snapshot, and the environment change information. The result analysis rule tree is a tree structure with the use case failure cause as the root node and the feature label corresponding to the use case failure cause as the leaf node.

[0111] After obtaining the inspection results and environment change information of this inspection, the result analysis rule tree can be updated according to the inspection results of this inspection, the historical inspection results corresponding to the historical environment snapshot (i.e., the results obtained by executing the script of the test case when the historical environment snapshot was generated), and the environment change information. The result analysis rule tree is a tree structure with the failure cause of the test case as the root node and the feature label corresponding to the failure cause of the test case as the leaf node.

[0112] In this embodiment, the result analysis rule tree is a rule tree generated in the initial software testing phase. In the subsequent software continuous testing process, the result analysis rule tree can be continuously updated.

[0113] For this result analysis, the update process of the rule tree can be combined with Figure 5 This is described in detail as follows.

[0114] Reference Figure 5 , shows a flowchart of the steps of a result analysis rule tree update method provided by an embodiment of the present application. Figure 5 As shown, the result analysis rule tree updating method may include: step 501, step 502, step 503 and step 504.

[0115] Step 501: Based on the current inspection and verification results, the historical inspection and verification results and the environment change information, analyze and obtain the use case failure reasons corresponding to the inspection use cases that failed to execute in the historical inspection and verification results; the use case failure reasons include: at least one of code defect reasons, script change reasons, environment change reasons and system jitter reasons.

[0116] In this embodiment, after obtaining the inspection verification results of this inspection and the environment change information, the use case failure reasons corresponding to the inspection use cases that failed to execute in the historical inspection verification results can be analyzed based on the inspection verification results of this inspection, the historical inspection verification results and the environment change information. Specifically, the inspection verification results of this inspection can be compared and analyzed with the historical inspection verification results to find out the common points and differences. If similar use cases fail in this inspection and the failure mode is the same as the historical failure, it may indicate that there is a persistence problem. Then, combined with the environment change information, it can be analyzed whether the environment change may be the cause of the use case failure.

[0117] In this example, the use case failure reason may include at least one of the following failure reasons: code defect reason, script change reason, environment change reason, system jitter reason, etc.

[0118] Specifically, if a new associated defect is added to the baseline, it is classified as a code defect.

[0119] If script-related changes occur, such as script content changes, script configuration changes, performance indicator adjustments, etc., they are classified as script reasons.

[0120] If an environment-related change occurs, such as a service version change, an adjustment in the number of service replicas, a change in the amount of component data, etc., but there are no associated defects, it is classified as an environment anomaly.

[0121] If no changes occur and the execution result is passed, it is classified as system jitter. In this example, system jitter can be the time consumption fluctuation caused by accidental network jitter, or it can be the fluctuation caused by triggering disk cleanup, service garbage cleanup, etc.

[0122] After analyzing the failure reasons of the inspection cases corresponding to the inspection cases that failed to be executed in the historical inspection results based on the current inspection results, the historical inspection results and the environment change information, step 502 is executed.

[0123] Step 502: Group the failed inspection cases according to the failure reasons of the cases to obtain grouped inspection cases.

[0124] After analyzing the failure reasons of the inspection cases corresponding to the inspection cases that failed to be executed in the historical inspection results according to the inspection results of this inspection, the historical inspection results and the environment change information, the inspection cases that failed to be executed can be grouped according to the failure reasons to obtain grouped inspection cases. That is, the inspection cases that failed to be executed are assigned to the above four categories of failure reasons, and each failure reason includes multiple test cases that failed to be executed.

[0125] After the failed inspection cases are grouped according to the reasons for the failure of the cases to obtain grouped inspection cases, step 503 is executed.

[0126] Step 503: extracting features of the execution script of each of the group inspection use cases according to a preset feature adoption coefficient to obtain a feature group of each of the group inspection use cases.

[0127] After grouping the failed inspection cases according to the reasons for the failure of the cases to obtain the grouped inspection cases, the features of the execution script of each grouped inspection case can be extracted according to the preset feature adoption coefficient to obtain the feature group of each grouped inspection case. Figure 6 This is described in detail as follows.

[0128] Reference Figure 6 , shows a flow chart of the steps of a feature group acquisition method provided by an embodiment of the present application. Figure 6 As shown, the feature group acquisition method may include: step 601, step 602, step 603 and step 604.

[0129] Step 601: extract the features of the execution script of each of the group inspection use cases to obtain a feature set corresponding to each of the group inspection use cases.

[0130] In this embodiment, after obtaining the group inspection use case, the features of the execution script of each group inspection use case can be extracted to obtain the feature set corresponding to each group inspection use case. Specifically, the script of each group inspection use case can be traversed, and the features contained in each script can be taken as the union to obtain the feature set of each group inspection use case.

[0131] After extracting the features of the execution script of each group inspection case to obtain a feature set corresponding to each group inspection case, step 602 is executed.

[0132] Step 602: Obtain a feature proportion parameter of each feature in the feature set.

[0133] After extracting the features of the execution script of each group inspection case to obtain the feature set corresponding to each group inspection case, the feature proportion parameter of each feature in the feature set can be obtained. Specifically, each feature in the feature set can be traversed one by one to calculate the proportion of the feature value in the entire set, that is, the feature proportion parameter.

[0134] After obtaining the feature proportion parameter of each feature in the feature set, step 603 is executed.

[0135] Step 603: According to the preset necessary feature adoption coefficient, optional feature adoption coefficient and the feature proportion parameter, the features in the feature set corresponding to each of the group inspection use cases are marked as necessary features and optional features.

[0136] After obtaining the feature proportion parameters of each feature in the feature set, the features in the feature set corresponding to each group inspection use case can be marked as necessary features and optional features according to the pre-set necessary feature adoption coefficient, optional feature adoption coefficient and feature proportion parameters. Specifically, the necessary feature adoption coefficient and the optional feature adoption coefficient can be pre-set, and the features of each group inspection use case can be marked according to these two coefficients. For example, there are a total of 10 inspection use cases, of which 8 use cases have a service change status of no change, accounting for 80%, and in 5 use cases, the script change status is a script content change, then "service change status-no change" is adopted as a necessary feature, and "script change status-script content change" is adopted as an optional feature, etc.

[0137] It can be understood that the above examples are merely examples listed for a better understanding of the technical solutions of the embodiments of the present application, and are not intended to be the sole limitation to the embodiments.

[0138] After marking the features in the feature set corresponding to each group inspection case as necessary features and optional features according to the preset necessary feature adoption coefficient, optional feature adoption coefficient and feature proportion parameter, step 604 is executed.

[0139] Step 604: traverse the necessary features and optional features marked in the features of the execution script of each of the group inspection use cases to obtain a feature group corresponding to the execution script of each of the group inspection use cases.

[0140] After completing the above feature marking, the necessary features and optional features marked in the features of the execution script of each group inspection case can be traversed to obtain the feature group corresponding to the execution script of each group inspection case. Specifically, traverse the scripts one by one, extract the necessary features and optional features contained therein, and obtain a set of feature groups corresponding to specific abnormal reasons (i.e., reasons for use case failure) for each script. For example, inspection results that meet the following characteristics can be identified as script problems:

[0141] (1) Service change status: No change has occurred.

[0142] (2) Script content: Changes have occurred.

[0143] (3) Component resource status: No change has occurred.

[0144] (4) API performance indicator: tps (Transactions Per Second) drops below the threshold.

[0145] It can be understood that the above examples are merely examples listed for a better understanding of the technical solutions of the embodiments of the present application, and are not intended to be the sole limitation to the embodiments.

[0146] After extracting the features of the execution script of each group inspection case according to the preset feature adoption coefficient to obtain the feature group of each group inspection case, step 504 is executed.

[0147] Step 504: Update the result analysis rule tree based on the feature group of each group inspection use case.

[0148] After extracting the features of the execution script of each group inspection case according to the preset feature adoption coefficient to obtain the feature group of each group inspection case, the result analysis rule tree can be updated based on the feature group of each group inspection case. Specifically, the feature groups obtained above can be deduplicated, the number of occurrences can be calculated, and after removing the feature groups that are repeated or are subsets of other rule groups, the final analysis result rule tree can be obtained, and the priority order of the rule tree is positively correlated with the number of repetitions.

[0149] Of course, when using the feature group to update the result analysis rule tree, the feature group used needs to be a feature group that contains all necessary features before it is adopted as the feature group for updating the rule tree. If it does not completely contain all the necessary features, it is considered that the judgment scenario is insufficient and needs to be ignored.

[0150] In this embodiment, the analysis result rule tree is equivalent to an analysis result rule set, which includes feature tags and the use case failure reasons under each feature tag.

[0151] The automatically updated and iterated abnormal result analysis rule tree proposed in the embodiment of the present application has changed from the traditional reliance on manual maintenance of rules to the automatic generation of all rules. While greatly reducing manpower input, it also effectively improves the quality of the rule tree. Since it no longer relies on the personal experience of maintenance personnel for maintenance, it completely relies on the actual situation of each inspection, avoiding problems such as human errors and rule deviations caused by individuals, and ensuring the real-time, effectiveness and reliability of the rule tree. At the same time, this embodiment realizes automatic analysis of abnormal results through the solution of combining three types of label features with the rule tree, which can effectively filter out use cases that fail due to environmental jitter, service anomalies, etc., instead of manually eliminating some failed use cases that do not require intervention analysis. At the same time, it can also provide corresponding analysis ideas for other failed use cases, allowing testers to focus on key issues, effectively improving analysis efficiency and reducing manpower input.

[0152] After the result analysis rule tree is updated according to the current inspection and verification result, the historical inspection and verification result corresponding to the historical environment snapshot, and the environment change information, step 105 is executed.

[0153] Step 105: Match the inspection feature tag of this time with the feature tag on the updated result analysis rule tree to obtain the inspection failure reason of this inspection failure.

[0154] After updating the result analysis rule tree according to the inspection results of this inspection, the historical inspection results corresponding to the historical environment snapshot, and the environment change information, the feature tags of this inspection can be matched with the feature tags on the updated result analysis rule tree to obtain the inspection failure reason of this inspection failure. That is, traverse the execution results of this inspection use case, use the inspection tags in the above steps and the rules in the result analysis rule tree, match them one by one, and if the match is successful, summarize the failure reason as the corresponding reason.

[0155] The embodiment of the present application implements a fully automatic and self-updating performance regression testing solution, which achieves the effect of automatic verification of inspection results and automatic analysis of inspection failures, effectively avoids problems such as incomplete coverage of performance regression testing and relatively lagging regression testing, effectively reduces manpower investment, greatly improves the efficiency and value of performance regression testing, and effectively ensures version quality.

[0156] The performance regression test method provided by the embodiment of the present application determines the environment change information of the software according to the current environment snapshot of the software at the current time and the historical environment snapshot of the software at the most recent time. The use case execution result obtained by executing the patrol test case of the software is analyzed to obtain the patrol verification result of this patrol. In the case where the patrol verification result of this patrol indicates that there is a failed test case in this patrol, the feature label of this patrol is generated according to the patrol verification result of this patrol. According to the patrol verification result of this patrol, the historical patrol verification result corresponding to the historical environment snapshot and the environment change information, the result analysis rule tree is updated. The result analysis rule tree is a tree structure with the failure cause of the use case as the root node and the feature label corresponding to the failure cause of the use case as the leaf node. The feature label of this patrol is matched with the feature label on the updated result analysis rule tree to obtain the patrol failure reason of this patrol failure. The embodiment of the present application generates a feature label for each performance patrol use case according to the generated environment snapshot, automatic verification of performance indicators and persistent storage of patrol records, and then combines the result analysis rule tree to obtain the corresponding failure reason, completes the automatic analysis of the performance patrol failure use case, effectively improves the analysis quality and analysis efficiency, and reduces the investment of manpower cost. At the same time, the result analysis rule tree can be self-updated according to historical execution records and environmental changes without human intervention, further reducing the investment in labor costs and achieving the goal of more accurate and efficient testing.

[0157] Reference Figure 7 , which shows a schematic diagram of the structure of a performance regression testing device provided in an embodiment of the present application, such as Figure 7 As shown, the performance regression testing device 700 may include the following modules:

[0158] An environment change information determination module 710, configured to determine the environment change information of the software according to the current environment snapshot of the software at the current time and the most recent historical environment snapshot of the software from the current time;

[0159] The inspection and verification result acquisition module 720 is used to analyze the use case execution result obtained by executing the inspection and verification test case of the software to obtain the inspection and verification result of this time;

[0160] The inspection feature label generation module 730 is used to generate the inspection feature label according to the inspection result when the inspection verification result indicates that there are failed test cases in the inspection;

[0161] An analysis rule tree updating module 740 is used to update a result analysis rule tree according to the inspection result of this inspection, the historical inspection result corresponding to the historical environment snapshot, and the environment change information. The result analysis rule tree is a tree structure with the use case failure cause as the root node and the feature label corresponding to the use case failure cause as the leaf node;

[0162] The inspection failure reason acquisition module 750 is used to match the inspection feature tag of this inspection with the feature tag on the updated result analysis rule tree to obtain the inspection failure reason of this inspection failure.

[0163] Optionally, the environment change information determination module includes:

[0164] A software information acquisition unit, used to acquire service deployment information and service operation information of all services of the software at the current time, component deployment information and component operation information of all components, and script information and baseline information of the software;

[0165] A service operation snapshot creation unit, configured to create a service operation snapshot according to the service deployment information and the service operation information;

[0166] A component operation snapshot creation unit, used to create a component operation snapshot according to the component deployment information and the component operation information;

[0167] A script baseline snapshot creation unit, used to create a script and a baseline snapshot according to the script information and the baseline information;

[0168] A current environment snapshot acquisition unit, configured to use the service operation snapshot, the component operation snapshot, and the script and baseline snapshot together as the current environment snapshot;

[0169] The environment change information acquisition unit is used to compare the current environment snapshot with the historical environment snapshot to obtain the environment change information.

[0170] Optionally, the inspection and verification result acquisition module includes:

[0171] An inspection case determination unit, configured to determine the inspection case according to the environment change information and a preset inspection execution mode;

[0172] A monitoring indicator acquisition unit, used to execute the script of the patrol and detection trial case, obtain the use case execution result and the monitoring indicator information of the patrol and detection trial case during the execution process;

[0173] The inspection and verification result acquisition unit is used to analyze the use case execution results and the monitoring indicator information based on the preset verification rules to obtain the inspection and verification results of this time. The inspection and verification results of this time include: performance indicators of the application programming interface, service performance indicators, component performance indicators and abnormal log detection results.

[0174] Optionally, the inspection case determination unit includes:

[0175] A patrol test case determination subunit, configured to determine, when the patrol execution mode is an incremental execution mode, the patrol test case in which a change exists in the test case according to the environment change information, the association relationship between the test case of the software and the services and components of the software;

[0176] The inspection case acquisition subunit is used to use all the test cases of the software as the inspection test cases when the inspection execution mode is the full execution mode.

[0177] Optionally, the inspection feature label generation module includes:

[0178] The inspection processing result acquisition unit is used to perform data cleaning on the inspection verification result of this time to obtain the processed inspection verification result;

[0179] An inspection feature label acquisition unit is used to classify the inspection result by feature labels to obtain the inspection feature label of this inspection;

[0180] The inspection feature tags include: environment change tags, execution result tags and history record tags.

[0181] Optionally, the analysis rule tree updating module includes:

[0182] A use case failure reason acquisition unit is used to analyze and obtain the use case failure reason corresponding to the inspection use case that failed to execute in the historical inspection and verification results according to the current inspection and verification results, the historical inspection and verification results and the environment change information; the use case failure reason includes: at least one of a code defect reason, a script change reason, an environment change reason and a system jitter reason;

[0183] A group inspection case acquisition unit, used to group the failed inspection cases according to the failure reasons of the cases to obtain group inspection cases;

[0184] A use case feature group acquisition unit, used to extract features of the execution script of each of the group inspection use cases according to a preset feature adoption coefficient, to obtain a feature group of each of the group inspection use cases;

[0185] The analysis rule tree updating unit is used to update the result analysis rule tree based on the feature group of each group inspection use case.

[0186] Optionally, the use case feature group acquisition unit includes:

[0187] A feature set acquisition subunit is used to extract the features of the execution script of each of the group inspection use cases to obtain a feature set corresponding to each of the group inspection use cases;

[0188] A feature ratio acquisition subunit is used to obtain a feature ratio parameter of each feature in the feature set;

[0189] A feature marking subunit, used to mark the features in the feature set corresponding to each of the group inspection use cases as necessary features and optional features according to the preset necessary feature adoption coefficient, optional feature adoption coefficient and the feature proportion parameter;

[0190] The feature group acquisition subunit is used to traverse the necessary features and optional features marked in the features of the execution script of each group inspection case, and obtain the feature group corresponding to the execution script of each group inspection case.

[0191] The performance regression test device provided in the embodiment of the present application determines the environment change information of the software according to the current environment snapshot of the software at the current time and the historical environment snapshot of the software at the most recent time. The use case execution result obtained by executing the patrol test case of the software is analyzed to obtain the patrol verification result of this patrol. In the case where the patrol verification result of this patrol indicates that there is a failed test case in this patrol, the feature label of this patrol is generated according to the patrol verification result of this patrol. According to the patrol verification result of this patrol, the historical patrol verification result corresponding to the historical environment snapshot and the environment change information, the result analysis rule tree is updated. The result analysis rule tree is a tree structure with the failure cause of the use case as the root node and the feature label corresponding to the failure cause of the use case as the leaf node. The feature label of this patrol is matched with the feature label on the updated result analysis rule tree to obtain the patrol failure reason of this patrol failure. The embodiment of the present application generates a feature label for each performance patrol use case according to the generated environment snapshot, automatic verification of performance indicators and persistent storage of patrol records, and then combines the result analysis rule tree to obtain the corresponding failure reason, completes the automatic analysis of the performance patrol failure use case, effectively improves the analysis quality and analysis efficiency, and reduces the investment of manpower cost. At the same time, the result analysis rule tree can be self-updated according to historical execution records and environmental changes without human intervention, further reducing the investment in labor costs and achieving the goal of more accurate and efficient testing.

[0192] An embodiment of the present application also provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the above-mentioned performance regression testing method when executed by the processor.

[0193] Figure 8 FIG. 8 is a schematic diagram showing the structure of an electronic device 800 according to an embodiment of the present invention. Figure 8 As shown, the electronic device 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes according to computer program instructions stored in a read-only memory (ROM) 802 or computer program instructions loaded from a storage unit 808 into a random access memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the electronic device 800 can also be stored. The CPU 801, the ROM 802, and the RAM 803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0194] Multiple components in the electronic device 800 are connected to the I / O interface 805, including: an input unit 806, such as a keyboard, a mouse, a microphone, etc.; an output unit 807, such as various types of displays, speakers, etc.; a storage unit 808, such as a disk, an optical disk, etc.; and a communication unit 809, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 809 allows the electronic device 800 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0195] The various processes and processing described above may be performed by the processing unit 801. For example, the method of any of the above embodiments may be implemented as a computer software program, which is tangibly contained in a computer-readable medium, such as the storage unit 808. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 800 via the ROM 802 and / or the communication unit 809. When the computer program is loaded into the RAM 803 and executed by the CPU 801, one or more actions in the method described above may be performed.

[0196] In addition, an embodiment of the present application further provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the above-mentioned performance regression testing method is implemented.

[0197] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0198] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, devices, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0199] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, terminals (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0200] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing terminal to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0201] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal so that a series of operating steps are executed on the computer or other programmable terminal to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable terminal. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0202] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present application.

[0203] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal. In the absence of further restrictions, the elements defined by the statement "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or terminal including the elements.

[0204] The above is a detailed introduction to a performance regression testing method, a performance regression testing device, an electronic device and a computer-readable storage medium provided by the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for general technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A performance regression testing method, characterized in that: The method comprises: Determine the environment change information of the software according to the current environment snapshot of the software at the current time and the most recent historical environment snapshot of the software from the current time; Analyze the use case execution results obtained by executing the patrol inspection test case of the software to obtain the patrol inspection verification result; If the inspection verification result indicates that there are failed test cases in the inspection, a feature tag for the inspection is generated according to the inspection verification result; According to the inspection and verification result of this time, the historical inspection and verification result corresponding to the historical environment snapshot and the environment change information, the result analysis rule tree is updated, wherein the result analysis rule tree is a tree structure with the use case failure cause as the root node and the feature label corresponding to the use case failure cause as the leaf node; The inspection feature tag of this time is matched with the feature tag on the updated result analysis rule tree to obtain the inspection failure reason of this inspection failure.

2. The method according to claim 1, characterized in that Determining the environment change information of the software according to the current environment snapshot of the software at the current time and the most recent historical environment snapshot of the software from the current time includes: Obtaining service deployment information and service operation information of all services of the software at the current time, component deployment information and component operation information of all components, and script information and baseline information of the software; Creating a service operation snapshot according to the service deployment information and the service operation information; Creating a component operation snapshot according to the component deployment information and the component operation information; Creating a script and a baseline snapshot according to the script information and the baseline information; The service operation snapshot, the component operation snapshot, the script and the baseline snapshot are collectively used as the current environment snapshot; The current environment snapshot is compared with the historical environment snapshot to obtain the environment change information.

3. The method according to claim 1, characterized in that: The analysis of the use case execution results obtained by executing the patrol inspection trial case of the software to obtain the patrol inspection verification results includes: Determine the inspection test case according to the environment change information and the preset inspection execution mode; Execute the script of the patrol inspection trial case to obtain the use case execution result and the monitoring indicator information of the patrol inspection trial case during the execution process; Based on the preset verification rules, the use case execution results and the monitoring indicator information are analyzed to obtain the inspection verification results of this inspection, which include: application programming interface performance indicators, service performance indicators, component performance indicators and abnormal log detection results.

4. The method according to claim 3, characterized in that Determining the patrol inspection trial case according to the environment change information and the preset patrol inspection execution mode includes: In the case where the inspection execution mode is the incremental execution mode, determining the inspection test case in which the test case has been changed according to the environment change information, the association relationship between the test case of the software and the services and components of the software; When the inspection execution mode is the full execution mode, all test cases of the software are used as the inspection test cases.

5. The method according to claim 1, characterized in that The step of generating a feature tag for this inspection based on the inspection result includes: Performing data cleaning on the inspection and verification results of this time to obtain processed inspection and verification results; Classifying the processed inspection and verification results by feature labels to obtain the feature labels of this inspection; The inspection feature tags include: environment change tags, execution result tags and history record tags.

6. The method according to claim 1, characterized in that The updating of the result analysis rule tree according to the current inspection and verification result, the historical inspection and verification result corresponding to the historical environment snapshot and the environment change information includes: According to the inspection result of this time, the historical inspection results and the environment change information, analyze and obtain the use case failure reason corresponding to the inspection use case that failed to execute in the historical inspection results; the use case failure reason includes: at least one of a code defect reason, a script change reason, an environment change reason and a system jitter reason; The failed inspection use cases are grouped according to the failure reasons of the use cases to obtain grouped inspection use cases; Extracting features of the execution script of each of the group inspection use cases according to a preset feature adoption coefficient to obtain a feature group of each of the group inspection use cases; The result analysis rule tree is updated based on the feature group of each of the group inspection use cases.

7. The method according to claim 6, characterized in that The feature extraction of the execution script of each of the group inspection use cases according to the preset feature adoption coefficient to obtain the feature group of each of the group inspection use cases includes: Extracting features of the execution script of each of the group inspection use cases to obtain a feature set corresponding to each of the group inspection use cases; Obtain a feature ratio parameter of each feature in the feature set; According to the preset necessary feature adoption coefficient, optional feature adoption coefficient and the feature proportion parameter, the features in the feature set corresponding to each of the group inspection use cases are marked as necessary features and optional features; The necessary features and optional features marked in the features of the execution script of each of the group inspection use cases are traversed to obtain a feature group corresponding to the execution script of each of the group inspection use cases.

8. A performance regression testing device, characterized in that: The device comprises: An environment change information determination module, used to determine the environment change information of the software according to the current environment snapshot of the software at the current time and the most recent historical environment snapshot of the software from the current time; The inspection and verification result acquisition module is used to analyze the use case execution results obtained by executing the inspection and verification test case of the software to obtain the inspection and verification results of this time; An inspection feature label generation module, used to generate a current inspection feature label according to the current inspection verification result when the current inspection verification result indicates that there is a failed test case in the current inspection; An analysis rule tree updating module, used to update a result analysis rule tree according to the inspection and verification result of this inspection and verification, the historical inspection and verification result corresponding to the historical environment snapshot, and the environment change information, wherein the result analysis rule tree is a tree structure with the use case failure cause as the root node and the feature label corresponding to the use case failure cause as the leaf node; The inspection failure reason acquisition module is used to match the inspection feature tag of this inspection with the feature tag on the updated result analysis rule tree to obtain the inspection failure reason of this inspection failure.

9. An electronic device, characterized in that: include: A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor implements the performance regression testing method according to any one of claims 1 to 7 when executing the program.

10. A computer-readable storage medium, characterized in that: When the instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the performance regression testing method described in any one of claims 1 to 7.

Images