Test method and device based on historical risk matching test cases

Abstract

This application provides a testing method and apparatus based on historical risk matching test cases, including: generating a product risk library based on historical production problems and typical test defects; extracting test concerns from the product risk library to generate test guidelines; during the testing phase of any software under test, matching keywords in the product risk library with the test intent of test cases to identify historical risks matching the software under test, thereby obtaining matching results; wherein, test cases are obtained based on test guidelines; retrieving mitigation test cases associated with historical risks from the product risk library based on the matching results, and merging the mitigation test cases with the test cases to form an enhanced test case set, and testing the software under test based on the enhanced test case set. Through one embodiment of this application, at least the problem of low testing efficiency in related technologies is solved, thereby improving the efficiency of software testing.

Description

Technical Field

[0001] This application relates to the technical field of software testing, and more specifically, to a testing method and apparatus based on historical risk matching test cases. Background Technology

[0002] The number of historical production problems and typical test defects continues to increase as projects are built. Although these problems are analyzed and reviewed during the testing phase, there is no effective consensus on how to efficiently reuse these lessons learned and feed them back into subsequent projects. Instead, the focus is more on the experience and sense of responsibility of project members, which fails to maximize the value of historical lessons learned.

[0003] In recent years, many institutions have been exploring the construction of risk testing systems. However, due to factors such as the low freshness of product risks, the lack of inclusion in standard testing processes, and the low identification capability of automatic risk matching databases for projects, the workload of referencing historical risks is large and the standards are inconsistent. The benefits of risk identification and referencing are low, and the important value of historical test assets has not been fully utilized, resulting in low testing efficiency. Summary of the Invention

[0004] This application provides a testing method and apparatus based on historical risk matching test cases, which at least solves the problem of low testing efficiency in related technologies.

[0005] According to one embodiment of this application, a testing method based on historical risk matching test cases is provided, comprising:

[0006] A product risk database is generated based on historical production issues and typical testing defects.

[0007] Test concerns are extracted from the product risk database to generate test guidelines;

[0008] During the testing phase of any software under test, keywords in the product risk database are matched with the testing intent of the test cases to identify historical risks that match the software under test, thereby obtaining matching results; wherein, the test cases are obtained based on the testing guidelines;

[0009] Based on the matching results, the system retrieves mitigation test cases associated with the historical risks from the product risk database, and merges the mitigation test cases with the test cases to form an enhanced test case set, which is then used to test the software under test.

[0010] In one implementation, the step of generating a product risk database based on historical production problems and typical test defects includes:

[0011] Obtain typical defects during the testing phase, program defects added during the acceptance phase, and events occurring in the production environment as data sources;

[0012] Defect cause analysis and root cause analysis are performed on the data source to extract risk description, keywords, scope of impact, and frequency of occurrence information to form risk items to be included in the database;

[0013] Based on the matrix analysis model, risk impact analysis and risk probability analysis are performed on each of the risk items to be included in the database to determine the risk level.

[0014] Based on the review results of the risk level, the risk items to be added to the product risk database are added to the product risk database to update and maintain the product risk database.

[0015] In one implementation, the step of performing risk impact analysis and risk probability analysis on each of the risk items to be included in the database based on a matrix analysis model to determine the risk level includes:

[0016] The risk impact analysis results are determined based on risk characteristic information; wherein, the risk impact analysis results include: historical usage frequency, severity of consequences caused by the risk, and size of the affected group;

[0017] The risk probability analysis results are determined based on risk characteristic information; wherein, the risk probability analysis results include: whether the occurrence has occurred in the production environment, and the frequency of similar defects occurring during the testing process; wherein, the risk characteristic information is the characteristic information of historical risks matched with the software under test;

[0018] The results of the risk impact analysis and the results of the risk probability analysis are input into the matrix analysis model to determine the risk level based on the matrix analysis model.

[0019] In one implementation, the step of extracting testing concerns from the product risk database to generate testing guidelines includes:

[0020] Cluster analysis is performed on the risk items in the product risk database to extract keywords and descriptive information of common and common problems in order to obtain cluster analysis results;

[0021] The clustering analysis results are summarized to generate test focus points, and test guidelines are generated based on these test focus points.

[0022] In one implementation, before matching keywords in the product risk database with the test intent of test cases during the testing phase of any software under test, the method further includes:

[0023] When importing the test case, a prompt is generated confirming that the test case has been obtained based on the test guide;

[0024] If it is confirmed that the test case has been obtained based on the test guidelines, the import of the test case is permitted;

[0025] If the test case is confirmed to have not been obtained based on the test guidelines, and is forcibly imported, an alarm will be generated in each subsequent test phase.

[0026] In one implementation, the step of inputting the risk impact analysis results and the risk probability analysis results into a matrix analysis model to determine the risk level based on the matrix analysis model includes:

[0027] A risk score is calculated based on the risk impact analysis results and the risk probability analysis results using a comprehensive risk scoring algorithm, and the risk level is determined based on the risk score.

[0028] The comprehensive risk scoring algorithm is as follows:

[0029] ;

[0030] in, This is the result of the risk impact analysis. The results of the risk probability analysis, These are the risk items corresponding to the results of the risk impact analysis and the risk probability analysis. , , These are the weighting coefficients.

[0031] In one implementation, the step of adding the risk items to be added to the product risk database based on the review results of the risk level, in order to update and maintain the product risk database, includes:

[0032] The keywords and the test intent are vectorized to obtain keyword vectors and test intent vectors;

[0033] Calculate the cosine value between the keyword vector and the test intent vector, and determine the similarity between the keyword and the test intent based on the cosine value;

[0034] If the similarity is greater than or equal to a preset threshold, the match is confirmed to be successful, and the risk value and historical test cases corresponding to the keyword are displayed to supplement the product risk database as the risk items to be added to the database, so as to update and maintain the product risk database.

[0035] According to another embodiment of this application, a system based on historical risk matching test cases is provided, comprising:

[0036] The first generation module is used to generate a product risk library based on historical production problems and typical test defects.

[0037] The second generation module is used to extract test concerns from the product risk database to generate test guidelines;

[0038] The matching module is used to match keywords in the product risk database with the test intent of test cases during the testing phase of any software under test, identify historical risks that match the software under test, and obtain matching results; wherein, the test cases are obtained based on the test guidelines;

[0039] The execution module is used to retrieve mitigation test cases associated with the historical risks from the product risk database based on the matching results, and merge the mitigation test cases with the test cases to form an enhanced test case set, so as to test the software under test based on the enhanced test case set.

[0040] According to yet another embodiment of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, and the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0041] According to yet another embodiment of this application, an electronic device is also provided, 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 method embodiments.

[0042] According to yet another embodiment of this application, a computer program product is also provided, including computer instructions that, when executed by a processor, implement the steps in any of the above method embodiments.

[0043] In one embodiment of this application, a product risk library is first generated based on historical production issues and typical test defects. Then, test concerns are extracted from this product risk library to generate test guidelines. During the testing phase of the software under test, keywords in the product risk library are matched with the test intent of test cases to identify historical risks matching the software under test. Based on the matching results, mitigation test cases associated with these risks are retrieved from the product risk library. These mitigation test cases are then merged with test cases obtained based on the test guidelines to form an enhanced test case set. Finally, tests are executed based on this enhanced test case set. Therefore, efficient automatic matching and reuse of historical risks are achieved, reducing the workload of manual screening and adaptation, unifying reference standards, and significantly improving software testing efficiency. This solves the problems of inefficient reuse of historical lessons learned, high cost and inconsistent standards for referencing historical risks, and difficulty in releasing the value of historical test assets, which lead to low testing efficiency in related technologies. It effectively revitalizes historical test assets, reduces the workload of risk identification and case reuse, and improves software testing efficiency. Attached Figure Description

[0044] The accompanying drawings, which are included to provide a further understanding of the embodiments of this application and constitute a part of the embodiments of this application, illustrate exemplary embodiments of this application and, together with their descriptions, serve to explain the embodiments of this application and do not constitute an improper limitation of the embodiments of this application. In the drawings:

[0045] Figure 1 This is a hardware structure block diagram of the test method based on historical risk matching test cases according to an embodiment of this application;

[0046] Figure 2 This is a flowchart of a test method based on historical risk matching test cases according to an embodiment of this application;

[0047] Figure 3 This is a flowchart of the method for generating a product risk library based on historical production problems and typical test defects according to the embodiments of this application;

[0048] Figure 4 This is a flowchart of a method for updating and maintaining the product risk database by supplementing the risk items to be added to the product risk database based on the review results of the risk level, according to an embodiment of this application.

[0049] Figure 5 This is a flowchart of a method for determining the risk level by performing risk impact analysis and risk probability analysis on each of the risk items to be included in the database based on the matrix analysis model described in the embodiments of this application;

[0050] Figure 6This is a flowchart of a method for extracting test concerns from the product risk database to generate test guidelines, according to an embodiment of this application.

[0051] Figure 7 This is a flowchart of a method for generating alarm prompts according to an embodiment of this application;

[0052] Figure 8 This is a structural block diagram of a system based on historical risk matching test cases according to an embodiment of this application;

[0053] Figure 9 This is a structural block diagram of the first generation module according to an embodiment of this application;

[0054] Figure 10 This is a structural block diagram of the operation and maintenance unit according to an embodiment of this application;

[0055] Figure 11 This is a structural block diagram of the matrix analysis model according to an embodiment of this application;

[0056] Figure 12 This is a structural block diagram of the output execution unit according to an embodiment of this application;

[0057] Figure 13 This is a structural block diagram of the second generation module according to an embodiment of this application;

[0058] Figure 14 This is a structural block diagram of another system based on historical risk matching test cases according to an embodiment of this application. Detailed Implementation

[0059] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of this application can be combined with each other.

[0060] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of the embodiments of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0061] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of the technical solutions in the embodiments of this application. However, it does not mean that the applicant has used or necessarily used such solutions.

[0062] The methods and embodiments provided in this application can be executed on a mobile terminal, a computer terminal, or a similar computing device. Taking running on a computer terminal as an example, Figure 1This is a hardware structure block diagram of the testing method based on historical risk matching test cases according to an embodiment of this application, as shown below. Figure 1 As shown, a hardware board may include one or more ( Figure 1 Only one is shown in the diagram. A processor 12 (which may include, but is not limited to, a microprocessor MCU or programmable logic device, etc.) and a memory 14 for storing data are also shown. The computer terminal may further include a transmission device 16 for communication functions and an input / output device 18. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the computer terminal described above. For example, the computer terminal may also include components that are more complex than those described above. Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0063] The memory 14 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the test method based on historical risk matching test cases in this embodiment. The processor 12 executes various functional applications and implements the above-described methods by running the computer programs stored in the memory 14. The memory 14 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 14 may further include memory remotely located relative to the processor 12, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0064] The transmission device 16 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a telecommunications provider. In one example, the transmission device 16 includes a Network Interface Controller (NIC), which can connect to other network devices via a gateway to communicate with the Internet. In another example, the transmission device 16 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0065] This application provides a testing method based on historical risk matching test cases. Figure 2 This is a flowchart of a test method based on historical risk matching test cases according to an embodiment of this application, as shown below. Figure 2 As shown, the process includes the following steps:

[0066] Step S201: Generate a product risk database based on historical production problems and typical test defects;

[0067] In one exemplary implementation, historical production issues and typical test defects can be collected, sorted, and standardized to form a product risk database containing risk information, keywords, and related test resources. Therefore, scattered historical issues and defects can be transformed into test assets that can be managed uniformly and reused, providing a stable and reliable risk data foundation for subsequent testing phases.

[0068] Step S202: Extract test concerns from the product risk database to generate test guidelines;

[0069] In one exemplary implementation, risk information from a product risk database can be summarized and refined to determine the key areas and directions to focus on during testing, thus forming standardized and executable testing guidelines. This provides a clear basis for test case design, standardizes test design practices, and enhances the relevance and completeness of test cases.

[0070] Step S203: During the testing phase of any software under test, the keywords in the product risk database are matched with the testing intent of the test cases to identify historical risks that match the software under test, so as to obtain matching results; wherein, the test cases are obtained based on the test guidelines;

[0071] In one exemplary implementation, historical risks applicable to the currently tested software can be automatically identified by comparing and matching keywords in the product risk database with the testing intent of test cases, resulting in accurate matching results. Therefore, it enables rapid and accurate mapping between historical risks and the current test object, reducing the workload of manual identification and screening, and improving the efficiency of risk location.

[0072] Step S204: Based on the matching result, retrieve the mitigation test cases associated with the historical risks from the product risk database, and merge the mitigation test cases with the test cases to form an enhanced test case set, so as to test the software under test based on the enhanced test case set.

[0073] In one exemplary implementation, corresponding mitigation test cases can be retrieved based on the matched historical risks, and integrated with the original test cases to form a more comprehensive enhanced test case set, which is then used for testing. Therefore, mature and effective risk control testing solutions can be directly reused, improving the risk coverage of test cases and the effectiveness of test execution, thus ensuring test quality.

[0074] Through steps S201 to S204, a product risk library is first generated based on historical production issues and typical test defects. Then, test concerns are extracted from this library to generate test guidelines. During the testing phase of the software under test, keywords in the product risk library are matched with the test intent of test cases to identify historical risks matching the software under test. Based on the matching results, mitigation test cases associated with these risks are retrieved from the product risk library. These mitigation test cases are then merged with test cases obtained based on the test guidelines to form an enhanced test case set. Finally, testing is performed based on this enhanced test case set. Therefore, efficient and automatic matching and reuse of historical risks are achieved, reducing the workload of manual screening and adaptation, unifying reference standards, and significantly improving software testing efficiency. This solves the problems of inefficient reuse of historical lessons learned, high cost and inconsistent standards for referencing historical risks, and difficulty in releasing the value of historical test assets, which lead to low testing efficiency. It effectively revitalizes historical test assets, reduces the workload of risk identification and case reuse, and improves software testing efficiency.

[0075] Figure 3 This is a flowchart of the method for generating a product risk library based on historical production problems and typical test defects according to the embodiments of this application, such as... Figure 3 As shown, in one embodiment, generating a product risk database based on historical production problems and typical test defects includes:

[0076] Step S301: Obtain typical defects from the testing phase, program defects supplemented during the acceptance phase, and events occurring in the production environment as data sources;

[0077] In one exemplary implementation, defect and problem data can be comprehensively collected from multiple stages, including testing, acceptance, and production deployment, forming a data source covering the entire software lifecycle. This ensures the completeness and comprehensiveness of risk sources, providing a reliable and sufficient data foundation for subsequent risk analysis and data entry.

[0078] Step S302: Perform defect cause analysis and root cause analysis on the data source to extract risk description, keywords, scope of impact, and frequency of occurrence information to form risk items to be entered into the database;

[0079] In one exemplary implementation, for example, root cause analysis is performed on the collected defects and problems to extract structured risk information and form standardized risk items to be included in the database. Therefore, raw problem data can be transformed into identifiable, categorizable, and reusable risk items, improving the standardization of risk information.

[0080] Step S303: Based on the matrix analysis model, perform risk impact analysis and risk probability analysis on each of the risk items to be included in the warehouse to determine the risk level;

[0081] In one exemplary implementation, for example, a matrix analysis model is used to quantitatively assess risk items from two dimensions: the degree of impact and the probability of occurrence, thereby determining the corresponding risk level. Therefore, it is possible to achieve scientific classification and reasonable prioritization of risks, providing an objective basis for risk management and resource allocation.

[0082] Step S304: Based on the review results of the risk level, the risk items to be added to the product risk database are added to the product risk database to update and maintain the product risk database.

[0083] In one exemplary implementation, for example, compliant and valid risk items are added to the risk database based on the risk level review conclusion, enabling dynamic supplementation and continuous maintenance of the product risk database. Therefore, the accuracy, effectiveness, and timeliness of the risk database content can be guaranteed, enhancing the overall usability of the risk database.

[0084] Through steps S301 to S304, raw data is collected from multiple dimensions, structured risk information is extracted through root cause analysis, risk level assessment is completed through a matrix analysis model, and finally, the risk database is updated and maintained according to the audit results. This forms a full-process risk database construction mechanism from data collection, risk extraction, level assessment to database maintenance. It can systematically, standardizedly, and efficiently build and maintain the product risk database, fully integrate historical testing and production experience, improve the availability and reliability of risk assets, and provide solid support for subsequent risk matching, test guide generation, and test case optimization.

[0085] Figure 4 This is a flowchart illustrating the method for updating and maintaining the product risk database by adding the risk items to be added to the product risk database based on the review results of the risk level, as described in the embodiments of this application. Figure 4 As shown, in one implementation, the step of adding the risk items to be added to the product risk database based on the review results of the risk level, in order to update and maintain the product risk database, includes:

[0086] Step S401: Vectorize the keywords and the test intent to obtain keyword vectors and test intent vectors;

[0087] In one exemplary implementation, for example, the following is performed within the execution body: operate.

[0088] Step S402: Calculate the cosine value between the keyword vector and the test intent vector to determine the similarity between the keyword and the test intent based on the cosine value;

[0089] In one exemplary implementation, for example, the following is performed within the execution body: operate.

[0090] Step S403: If the similarity is greater than or equal to a preset threshold, the matching is confirmed to be successful, and the risk value and historical test cases corresponding to the keyword are displayed to supplement the product risk database as the risk items to be added to the database, so as to update and maintain the product risk database.

[0091] In one exemplary implementation, for example, the preset threshold is... Preset threshold The methods for determining the threshold include, but are not limited to: (1) statistical analysis based on historical matching results (F1, ROC optimal threshold); (2) dynamic adaptive threshold. (3) Project-level configuration: Set high-security projects to 0.75, rapid iteration projects to 0.55, and recommended projects to 0.65. The current preset threshold is the similarity judgment threshold before the update. This value can be determined based on historical matching results, project configuration, or the results after the last adaptive adjustment. η is the learning rate, used to control the step size of each adjustment. Its value range is usually (0,1]. The larger η is, the more drastic the response of the threshold to the matching result feedback, and vice versa. This represents the number of valid matching attempts that were rejected by the system (i.e., failed to match) due to similarity being below the threshold during the most recent evaluation period. The number of valid matching attempts that are accepted by the system (i.e., successful matching) due to similarity reaching or exceeding the threshold within the same evaluation period; To evaluate the total number of matching attempts within the period.

[0092] Through steps S401 to S403, keywords and test intentions are vectorized separately, and cosine values ​​are calculated to determine similarity. When the similarity reaches a preset threshold, a successful match is automatically confirmed. The corresponding risk values ​​and historical test cases are then added to the product risk database as risk items to be added, thus achieving intelligent and automated updates and maintenance of the product risk database. This process utilizes vectorization and cosine similarity calculation to accurately quantify the matching degree between keywords and test intentions. Combined with preset thresholds (which can be flexibly determined based on historical statistics, dynamic adaptation, or project-level configuration), it effectively avoids the subjectivity and inefficiency of manual review, while ensuring the relevance and accuracy of the added risk items. This significantly reduces the labor costs of maintaining the product risk database and improves the reuse efficiency of risk assets and the automation level of test preparation.

[0093] Figure 5 This is a flowchart illustrating a method for determining a risk level by performing risk impact analysis and risk probability analysis on each of the risk items to be included in the database, based on a matrix analysis model as described in the embodiments of this application. Figure 5 As shown, in one implementation, the step of performing risk impact analysis and risk probability analysis on each of the risk items to be included in the database based on a matrix analysis model to determine the risk level includes:

[0094] Step S501: Determine the risk impact analysis results based on risk characteristic information; wherein, the risk impact analysis results include: historical usage frequency, severity of consequences caused by the risk, and size of the affected group;

[0095] In one exemplary implementation, for example, by combining risk characteristic information, the degree of risk impact is comprehensively assessed from multiple dimensions such as historical usage frequency, severity of consequences, and size of the affected group, resulting in an objective and comprehensive risk impact analysis. Therefore, it can accurately reflect the magnitude of the impact on the product and its users after the risk occurs, providing a reliable basis for risk level determination.

[0096] Step S502: Determine the risk probability analysis results based on risk characteristic information; wherein, the risk probability analysis results include: whether the occurrence has occurred in the production environment, and the frequency of similar defects occurring during the testing process; wherein, the risk characteristic information is the characteristic information of historical risks matching the software under test;

[0097] In one exemplary implementation, for example, the risk probability analysis results are determined based on risk characteristic information, combined with the frequency of similar defects occurring in production environment records and the testing phase. Therefore, this accurately reflects the probability of the risk actually occurring, providing a reliable basis for risk level determination.

[0098] Step S503: Input the risk impact analysis results and the risk probability analysis results into the matrix analysis model to determine the risk level based on the matrix analysis model.

[0099] In one exemplary implementation, for example, the results of the analysis of both impact and probability are input into a matrix analysis model for comprehensive calculation and judgment to obtain a standardized risk level. Therefore, it is possible to achieve standardized and quantitative assessment of risk levels, avoiding the subjectivity and variability caused by manual judgment.

[0100] Through steps S501 to S503, risk quantification analysis is first completed from the impact dimension and the possibility dimension, respectively. Then, the results of the two types of analysis are input into the matrix analysis model for comprehensive processing to determine the risk level. This forms a multi-dimensional, standardized, and quantitative risk level assessment process, which can scientifically, objectively, and uniformly complete risk classification, improve the accuracy and consistency of risk assessment, and provide a solid judgment basis for subsequent risk entry, risk matching, and test resource allocation.

[0101] In one implementation, the step of inputting the risk impact analysis results and the risk probability analysis results into a matrix analysis model to determine the risk level based on the matrix analysis model includes:

[0102] A risk score is calculated based on the risk impact analysis results and the risk probability analysis results using a comprehensive risk scoring algorithm, and the risk level is determined based on the risk score.

[0103] The comprehensive risk scoring algorithm is as follows:

[0104] ;

[0105] in, This is the result of the risk impact analysis. The results of the risk probability analysis, These are the risk items corresponding to the results of the risk impact analysis and the risk probability analysis. , , These are the weighting coefficients.

[0106] In one exemplary implementation, for example, Specifically, the weighting coefficient , , The determination methods include, but are not limited to: (1) expert calibration method; (2) data-driven training method: training the optimal weights based on historical data through least squares method or machine learning; (3) adaptive adjustment mechanism: dynamically adjusting by incremental learning or Bayesian update according to project risk feedback.

[0107] Among them, it can be based on , Build 5 A 5th-order risk level matrix M.

[0108] For example, the risk level matrix M is shown in the table below:

[0109]

[0110] Therefore, this comprehensive risk scoring algorithm introduces weighting coefficients. , , Results of risk impact analysis and risk probability analysis results Nonlinear combination calculations can flexibly adjust the contribution of each dimension to the final risk score, thereby achieving adaptive risk assessment for different project types, safety levels, or iteration rhythms. Based on the calculated risk score, it can be further mapped to a standardized risk level matrix (such as a 5×5 matrix), transforming qualitative impact and probability analysis into quantitative risk level output. This significantly reduces the bias and inconsistency caused by subjective human judgment, improves the scientificity, accuracy, and repeatability of risk classification, and provides an objective and quantifiable decision-making basis for the automated updating of the product risk library, the rational allocation of testing resources, and the priority handling of high-risk items.

[0111] Figure 6 This is a flowchart illustrating the method for extracting test concerns from the product risk database to generate test guidelines, as described in the embodiments of this application. Figure 6 As shown, in one embodiment, the step of extracting test concerns from the product risk database to generate test guidelines includes:

[0112] Step S601: Perform cluster analysis on the risk items in the product risk database to extract keywords and descriptive information of common and common problems to obtain cluster analysis results;

[0113] In one exemplary implementation, for example, by performing cluster analysis on all risk items in the product risk database, common and high-frequency issues can be identified and extracted, along with their corresponding keywords and descriptive information, resulting in a structured cluster analysis. Therefore, dispersed and diverse risk information can be categorized and integrated, clearly presenting risk distribution patterns and key issues.

[0114] Step S602: Summarize the clustering analysis results to generate test focus points, and generate test guidelines based on the test focus points.

[0115] In one exemplary implementation, for example, the common information and key content obtained from cluster analysis are systematically summarized to form test concerns for test execution, and standardized, implementable test guidelines are further developed based on these test concerns. Therefore, risk analysis results can be transformed into a direct basis for test design, providing a clear direction for test case development and test execution.

[0116] Through steps S601 to S602, cluster analysis is first performed on the risk database information to extract common key content. Then, the analysis results are summarized to form test focus points and generate test guidelines, thus constructing a complete transformation process from risk data to test guidance documents. Therefore, it can efficiently and systematically transform historical risk assets into unified and usable test standards, improving the relevance, completeness, and standardization of test design.

[0117] Figure 7 This is a flowchart of a method for generating alarm prompts according to an embodiment of this application, such as... Figure 7 As shown, in one embodiment, before matching keywords in the product risk database with the test intent of the test case during the testing phase of any software under test, the method further includes:

[0118] Step S701: When importing the test case, generate a prompt confirming that the test case has been obtained based on the test guide;

[0119] In one exemplary implementation, a compliance confirmation prompt is proactively triggered during the test case import phase to clearly communicate the verification requirements to operators. Therefore, a standardized verification node can be established at the entry point of the testing process, ensuring that the test case design aligns with the testing guidelines.

[0120] Step S702: If it is confirmed that the test case has been obtained based on the test guide, allow the import of the test case;

[0121] In one exemplary implementation, for example, a normal import operation is performed on test cases that meet the testing guidelines. Therefore, while ensuring the compliance of test cases, the testing process can proceed smoothly, improving the standardization of the test import stage.

[0122] Step S703: If it is confirmed that the test case was not obtained based on the test guide, and the test case is forcibly imported, an alarm prompt will be generated in each subsequent test stage.

[0123] In one exemplary implementation, for example, continuous alerts are issued for non-compliant forced import behavior. Therefore, operators are constantly reminded to pay attention to the compliance of test cases, avoiding test oversights or insufficient risk coverage due to deviations from testing guidelines.

[0124] Through steps S701 to S703 above, a full-process control mechanism is established in the test case import stage, which includes prompt confirmation, compliance release, and continuous alerts for violations. The test guidelines are used as a pre-verification standard for test case import, which can effectively standardize test case import behavior, strengthen the quality control of the test process, improve the compliance and risk coverage of test design, and ensure the reliability of subsequent test execution.

[0125] In one implementation, the method further includes: establishing standard indicators for each stage of the project's entire lifecycle, and implementing stage risk monitoring through a stage risk matrix monitoring algorithm.

[0126] The phase risk matrix monitoring algorithm includes: a preset project lifecycle comprising n phases, each phase defining a standard vector: Cstd=[Rstd,Tstd,Dstd,Bstd]. Here, n is a natural number greater than or equal to 1.

[0127] Where: Rstd is the risk pre-assessment pass rate (e.g., ≥85% is required to meet the requirement); Tstd is the schedule deviation (e.g., ≤10% is required to meet the requirement); Dstd is the defect density standard; Bstd is the defect re-opening rate standard.

[0128] Real-time acquisition of actual vectors (Cactual);

[0129] Calculate the deviation: Δj = Cstd – Cactual;

[0130] Specifically, if Δj < 0, an early warning will be automatically triggered; if Δj ≥ 0, an early warning will not be triggered.

[0131] By adopting the above technical solution, a standard indicator system for each stage of the project's entire lifecycle is established (including risk pre-assessment pass rate, schedule deviation, defect density standard, and defect re-opening rate). A stage risk matrix monitoring algorithm is used to collect actual risk vectors in real time and calculate deviations from the standard vectors. An early warning is automatically triggered when any indicator deviation is negative, achieving quantitative monitoring and automated early warning of project risks. Furthermore, it can promptly detect anomalies in risk pre-assessment, schedule deviation, defect density, and defect re-opening rate at each stage, effectively avoiding the subjectivity and lag of manual monitoring, significantly improving the controllability of the project process and the speed of risk response, thereby ensuring quality and schedule management throughout the entire testing and development process.

[0132] In summary, this application's embodiments integrate a risk-based testing process throughout the entire testing cycle. Through data analysis and machine learning models, testing concerns can be automatically identified and testing guidelines generated. Simultaneously, by automatically matching project test cases with the product risk database, risk sets for subsequent projects are formed. Based on a matrix analysis model, test risks are prioritized, and test risks, solutions, and mitigation cases are pushed to each project. By efficiently utilizing testing assets, the timeliness, accuracy, and efficiency of risk identification in subsequent projects are improved. Furthermore, by associating product risks with test cases, a closed-loop tracking system is formed, enhancing overall testing quality. Specific advantages are as follows:

[0133] 1. Improved the automation and accuracy of risk identification. The system automatically analyzes, classifies, rates, and stores historical defects and production problems, reducing manual intervention and avoiding risk omissions or misjudgments due to differences in experience.

[0134] 2. Improved the reuse efficiency of historical test assets. By building a unified product risk database, typical defects and production problems scattered across various projects were systematically integrated, forming a reusable and evolving test knowledge system.

[0135] 3. Enhanced the standardization and controllability of the testing process. The testing guidelines, serving as a "checkpoint" in the project testing process, mandate that test managers complete a completeness check before importing test cases, thereby improving the quality of test design.

[0136] 4. Enabled dynamic monitoring of risks throughout their entire lifecycle. A risk matrix standard was constructed, encompassing multiple dimensions such as risk pre-assessment pass rate, schedule, and defect density. The system automatically monitors project execution status and provides real-time alerts for abnormal situations.

[0137] 5. Improved the completeness and risk coverage of test cases. The system automatically recommends historical risks and their mitigation cases that match the current project, allowing test managers to evaluate and add them to the test cases, thereby improving test coverage.

[0138] 6. It facilitated closed-loop feedback between the testing and business acceptance phases. During the business acceptance testing phase, the system automatically identified program issues and provided feedback to system testers, supporting continuous optimization of system test scenarios and improving overall testing maturity.

[0139] 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 adding necessary general-purpose hardware platforms through software. Of course, they can also be implemented through hardware, but in many cases, the former is a better implementation method. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the embodiments of this application.

[0140] This application also provides a system based on historical risk matching test cases, which is used to implement the above embodiments and preferred embodiments, and will not be repeated hereafter. The term "module" as used below can refer to a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0141] Figure 8 This is a structural block diagram of a system based on historical risk matching test cases according to an embodiment of this application, such as... Figure 8 As shown, the system includes:

[0142] The first generation module 81 is used to generate a product risk library based on historical production problems and typical test defects.

[0143] The second generation module 82 is used to extract test concerns from the product risk database to generate test guidelines;

[0144] The matching module 83 is used to match keywords in the product risk database with the test intent of test cases during the testing phase of any software under test, identify historical risks that match the software under test, and obtain matching results; wherein, the test cases are obtained based on the test guidelines;

[0145] The execution module 84 is used to retrieve the mitigation test cases associated with the historical risks from the product risk database based on the matching results, and merge the mitigation test cases with the test cases to form an enhanced test case set, so as to test the software under test based on the enhanced test case set.

[0146] By adopting the above technical solution, the first generation module 81 first generates a product risk library based on historical production problems and typical test defects. Then, the second generation module 82 extracts test concerns from the product risk library to generate test guidelines. During the testing phase of the software under test, the matching module 83 matches keywords in the product risk library with the test intent of test cases obtained based on the test guidelines, thereby identifying historical risks matching the software under test and obtaining matching results. Finally, the execution module 84 retrieves mitigation test cases associated with historical risks from the product risk library based on the matching results, merges these mitigation test cases with the test cases to form an enhanced test case set, and executes tests based on this enhanced test case set. Therefore, efficient automatic matching and reuse of historical risks is achieved, reducing the workload of manual screening and adaptation, unifying reference standards, and significantly improving software testing efficiency. It solves the problems of inefficient reuse of historical lessons learned, high cost and inconsistent standards for referencing historical risks, and difficulty in releasing the value of historical test assets, which lead to low testing efficiency. This effectively revitalizes historical test assets, reduces the workload of risk identification and case reuse, and improves software testing efficiency.

[0147] Figure 9 This is a structural block diagram of the first generation module according to an embodiment of this application, such as... Figure 9 As shown, in one embodiment, the first generation module 81 includes:

[0148] The acquisition unit 811 is used to acquire typical defects in the testing phase, program defects supplemented in the acceptance phase, and events occurring in the production environment as data sources.

[0149] Analysis unit 812 is used to perform defect cause analysis and root cause analysis on the data source to extract risk description, keywords, scope of impact, and frequency of occurrence information to form risk items to be entered into the database.

[0150] Matrix analysis model 813 is used to perform risk impact analysis and risk probability analysis on each of the risk items to be included in the warehouse, so as to determine the risk level;

[0151] The operation and maintenance unit 814 is used to add the risk items to be added to the product risk database based on the review results of the risk level, so as to update and maintain the product risk database.

[0152] By adopting the above technical solution, the acquisition unit 811 comprehensively collects typical defects, program defects, and production events from multiple stages such as testing, acceptance, and production, ensuring the integrity of the data source and full lifecycle coverage; the analysis unit 812 performs defect cause analysis and root cause analysis on the collected raw data, extracting structured information such as risk description, keywords, scope of impact, and frequency of occurrence, forming standardized risk items to be included in the database, transforming scattered problem data into identifiable and reusable risk entries; the matrix analysis model 813 performs risk impact analysis and risk probability analysis on each risk item to be included in the database, and conducts quantitative evaluation. The system determines scientific risk levels to provide an objective basis for risk prioritization and resource allocation. Based on the risk level review results, the operations and maintenance unit 814 adds compliant and valid risk items to the product risk database, enabling dynamic updates and continuous maintenance of the database. The collaboration of these units forms a comprehensive risk database construction mechanism, encompassing data collection, risk extraction, level assessment, and database maintenance. This mechanism systematically, efficiently, and effectively builds and maintains the product risk database, fully integrating historical testing and production experience to improve the availability and reliability of risk assets, and providing solid support for subsequent risk matching, test guide generation, and test case optimization.

[0153] Figure 10 This is a structural block diagram of the operation and maintenance unit according to an embodiment of this application, such as... Figure 10 As shown, in one embodiment, the operation and maintenance unit 814 includes:

[0154] The vectorization subunit 8141 is used to vectorize the keywords and the test intent to obtain keyword vectors and test intent vectors;

[0155] The calculation subunit 8142 is used to calculate the cosine value between the keyword vector and the test intent vector, so as to determine the similarity between the keyword and the test intent based on the cosine value;

[0156] Execution subunit 8143 confirms successful matching if the similarity is greater than or equal to a preset threshold, and displays the risk value and historical test cases corresponding to the keyword as supplementary risk items to be added to the product risk database, so as to update and maintain the product risk database.

[0157] By adopting the above technical solution, the vectorization subunit 8141 converts keywords and test intents into keyword vectors and test intent vectors, respectively. The calculation subunit 8142 calculates the similarity by calculating the cosine value between the two. The execution subunit 8143 automatically confirms a successful match when the similarity is greater than or equal to a preset threshold, and adds the corresponding risk value and historical test cases as risk items to be added to the product risk database. This achieves intelligent and automated updating and maintenance of the product risk database. This technical solution uses vectorization representation and cosine similarity calculation to accurately quantify the matching degree between keywords and test intents. Combined with preset thresholds that can be flexibly determined based on historical statistics, dynamic adaptation, or project-level configuration, it effectively avoids the subjectivity and inefficiency of manual review, ensures the relevance and accuracy of risk items added to the database, significantly reduces the labor cost of maintaining the product risk database, and improves the reuse efficiency of risk assets and the automation level of test preparation.

[0158] Figure 11 This is a structural block diagram of the matrix analysis model according to an embodiment of this application, such as... Figure 11 As shown, in one embodiment, the matrix analysis model 813 includes:

[0159] The first determining unit 8131 is used to determine the risk impact analysis results based on risk characteristic information; wherein, the risk impact analysis results include: historical usage frequency, severity of consequences caused by the risk, and size of the affected group;

[0160] The second determining unit 8132 is used to determine the risk probability analysis result based on risk characteristic information; wherein, the risk probability analysis result includes: whether the occurrence has occurred in the production environment, and the frequency of occurrence of similar defects during the testing process; wherein, the risk characteristic information is the characteristic information of historical risks matching the software under test;

[0161] The output execution unit 8133 is used to input the risk impact analysis results and the risk probability analysis results into the matrix analysis model to determine the risk level based on the matrix analysis model.

[0162] By adopting the above technical solution, the first determining unit 8131 comprehensively evaluates the risk impact analysis results based on risk characteristic information from three dimensions: historical usage frequency, severity of consequences, and scale of affected groups. The second determining unit 8132 derives the risk probability analysis results based on whether the production environment has experienced the issue and the frequency of similar defects occurring during testing. The output execution unit 8133 inputs both types of analysis results into a matrix analysis model to comprehensively determine the risk level, thus forming a multi-dimensional, standardized, and quantitative risk level assessment process. This technical solution can scientifically, objectively, and uniformly complete risk classification, effectively avoiding the subjectivity and variability caused by manual judgment, significantly improving the accuracy and consistency of risk assessment, and providing a solid judgment basis for subsequent risk entry, risk matching, and test resource allocation.

[0163] Figure 12 This is a structural block diagram of the output execution unit according to an embodiment of this application, such as... Figure 12 As shown, in one embodiment, the output execution unit 8133 includes:

[0164] The algorithm execution subunit 81331 is used to calculate a risk score based on the risk impact analysis results and the risk probability analysis results using a comprehensive risk scoring algorithm, so as to determine the risk level based on the risk score;

[0165] The comprehensive risk scoring algorithm is as follows:

[0166] ;

[0167] in, This is the result of the risk impact analysis. The results of the risk probability analysis, These are the risk items corresponding to the results of the risk impact analysis and the risk probability analysis. , , These are the weighting coefficients.

[0168] By adopting the above technical solution, the algorithm logic of the comprehensive risk scoring algorithm is pre-stored in the algorithm execution subunit 81331, and the comprehensive risk scoring algorithm is used by introducing weight coefficients. , , Results of risk impact analysis and risk probability analysis results Nonlinear combination calculations can flexibly adjust the contribution of each dimension to the final risk score, thereby achieving adaptive risk assessment for different project types, safety levels, or iteration rhythms. Based on the calculated risk score, it can be further mapped to a standardized risk level matrix (such as a 5×5 matrix), transforming qualitative impact and probability analysis into quantitative risk level output. This significantly reduces the bias and inconsistency caused by subjective human judgment, improves the scientificity, accuracy, and repeatability of risk classification, and provides an objective and quantifiable decision-making basis for the automated updating of the product risk library, the rational allocation of testing resources, and the priority handling of high-risk items.

[0169] Figure 13 This is a structural block diagram of the second generation module according to an embodiment of this application, such as... Figure 13 As shown, in one embodiment, the second generation module 82 includes:

[0170] Cluster analysis unit 821 is used to perform cluster analysis on risk items in the product risk library to extract keywords and descriptive information of common problems and common problems to obtain cluster analysis results;

[0171] The summarization unit 822 is used to summarize the clustering analysis results to generate test focus points, and to generate test guidelines based on the test focus points.

[0172] By adopting the above technical solution, the clustering analysis unit 821 performs clustering analysis on risk items in the product risk database, extracts keywords and descriptive information of common and frequently occurring problems, and thus classifies and integrates scattered and diverse risk information into structured clustering analysis results, clearly presenting the risk distribution patterns and key issues. The summarization unit 822 systematically summarizes the clustering analysis results, generates standardized test focus points, and further forms implementable test guidelines, constructing a complete transformation process from risk data to test guidance documents. Therefore, it can efficiently and systematically transform historical risk assets into unified and usable test standards, significantly improving the relevance, completeness, and standardization of test design.

[0173] Figure 14 This is a structural block diagram of another system based on historical risk matching test cases according to an embodiment of this application, such as... Figure 14 As shown, in one embodiment, the system further includes:

[0174] The prompt module 85 is used to generate a prompt confirming that the test case has been obtained based on the test guide when the test case is imported;

[0175] The judgment module 86 is used to allow the import of the test case if it is confirmed that the test case has been obtained based on the test guide.

[0176] The alarm module 87 generates an alarm prompt in each subsequent test stage if the test case is forcibly imported if it is confirmed that the test case was not obtained based on the test guidelines.

[0177] By adopting the above technical solutions, the prompting module 85 proactively generates compliance confirmation prompts when importing test cases, establishing a standardized verification node at the entry point of the test process; the judgment module 86 allows normal import if it confirms that the test cases have been obtained based on the test guidelines, ensuring both compliance and smooth process; the alarm module 87 continuously generates alarm prompts in each subsequent test stage when test cases are forcibly imported without being obtained based on the test guidelines, reminding operators to pay attention to compliance risks throughout the process; the above modules work together to build a full-process control mechanism from prompt confirmation and compliance release to continuous alarms for violations, using the test guidelines as a pre-verification standard for test case import, effectively standardizing test case import behavior, strengthening quality control of the test process, significantly improving the compliance and risk coverage completeness of test design, thereby ensuring the reliability of subsequent test execution.

[0178] In one embodiment, the system further includes a monitoring module for establishing standard indicators for each stage of the project's entire lifecycle and implementing stage risk monitoring through a stage risk matrix monitoring algorithm.

[0179] The phase risk matrix monitoring algorithm includes: a preset project lifecycle comprising n phases, each phase defining a standard vector: Cstd=[Rstd,Tstd,Dstd,Bstd]. Here, n is a natural number greater than or equal to 1.

[0180] Where: Rstd is the risk pre-assessment pass rate (e.g., ≥85% is required to meet the requirement); Tstd is the schedule deviation (e.g., ≤10% is required to meet the requirement); Dstd is the defect density standard; Bstd is the defect re-opening rate standard.

[0181] Real-time acquisition of actual vectors (Cactual);

[0182] Calculate the deviation: Δj = Cstd – Cactual;

[0183] Specifically, if Δj < 0, an early warning will be automatically triggered; if Δj ≥ 0, an early warning will not be triggered.

[0184] By adopting the above technical solution, a standard indicator system for each stage of the project's entire lifecycle (including risk pre-assessment pass rate, schedule deviation, defect density standard, and defect re-opening rate) is established based on the monitoring module. A stage risk matrix monitoring algorithm is used to collect actual vectors in real time and calculate deviations from the standard vectors. An early warning is automatically triggered when any indicator deviation is negative, achieving quantitative monitoring and automated early warning of project risks. Furthermore, it can promptly detect anomalies in risk pre-assessment, schedule deviation, defect density, and defect re-opening rate at each stage, effectively avoiding the subjectivity and lag of manual monitoring, significantly improving the controllability of the project process and the speed of risk response, thereby ensuring quality and schedule management throughout the testing and development process.

[0185] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0186] This application also provides a computer-readable storage medium storing a computer program configured to execute the steps in any of the above method embodiments when running.

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

[0188] This application also provides 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 method embodiments.

[0189] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0190] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0191] Specific examples in the embodiments of this application can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0192] Obviously, those skilled in the art should understand that the modules or steps of the embodiments of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be executed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the embodiments of this application are not limited to any particular combination of hardware and software.

[0193] The above description is merely a preferred embodiment of the present application and is not intended to limit the embodiments of the present application. For those skilled in the art, various modifications and variations can be made to the embodiments of the present application. Any modifications, equivalent substitutions, improvements, etc., made within the principles of the embodiments of the present application should be included within the protection scope of the embodiments of the present application.

Claims

1. A test method for matching test cases based on historical risks, characterized by, include: A product risk database is generated based on historical production issues and typical testing defects. Test concerns are extracted from the product risk database to generate test guidelines; During the testing phase of any software under test, keywords in the product risk database are matched with the testing intent of the test cases to identify historical risks that match the software under test, thereby obtaining matching results; wherein, the test cases are obtained based on the testing guidelines; Based on the matching results, the system retrieves mitigation test cases associated with the historical risks from the product risk database, and merges the mitigation test cases with the test cases to form an enhanced test case set, which is then used to test the software under test.

2. The method of claim 1, wherein, The product risk database generated based on historical production issues and typical testing defects includes: Obtain typical defects during the testing phase, program defects added during the acceptance phase, and events occurring in the production environment as data sources; Defect cause analysis and root cause analysis are performed on the data source to extract risk description, keywords, scope of impact, and frequency of occurrence information to form risk items to be included in the database; Based on the matrix analysis model, risk impact analysis and risk probability analysis are performed on each of the risk items to be included in the database to determine the risk level. Based on the review results of the risk level, the risk items to be added to the product risk database are added to the product risk database to update and maintain the product risk database.

3. The method of claim 2, wherein, The matrix analysis model is used to perform risk impact analysis and risk probability analysis on each of the risk items to be included in the database, in order to determine the risk level, including: The risk impact analysis results are determined based on risk characteristic information; wherein, the risk impact analysis results include: historical usage frequency, severity of consequences caused by the risk, and size of the affected group; The risk probability analysis results are determined based on risk characteristic information; wherein, the risk probability analysis results include: whether the occurrence has occurred in the production environment, and the frequency of similar defects occurring during the testing process; wherein, the risk characteristic information is the characteristic information of historical risks matched with the software under test; The results of the risk impact analysis and the results of the risk probability analysis are input into the matrix analysis model to determine the risk level based on the matrix analysis model.

4. The method of claim 1, wherein, The step of extracting testing concerns from the product risk database to generate testing guidelines includes: Cluster analysis is performed on the risk items in the product risk database to extract keywords and descriptive information of common and common problems in order to obtain cluster analysis results; The clustering analysis results are summarized to generate test focus points, and test guidelines are generated based on these test focus points.

5. The method of claim 1, wherein, Before matching keywords in the product risk database with the test intent of test cases during the testing phase of any software under test, the method further includes: When importing the test case, a prompt is generated confirming that the test case has been obtained based on the test guide; If it is confirmed that the test case has been obtained based on the test guidelines, the import of the test case is permitted; If the test case is confirmed to have not been obtained based on the test guidelines, and is forcibly imported, an alarm will be generated in each subsequent test phase.

6. The method of claim 3, wherein, The step of inputting the risk impact analysis results and the risk probability analysis results into a matrix analysis model to determine the risk level based on the matrix analysis model includes: A risk score is calculated based on the risk impact analysis results and the risk probability analysis results using a comprehensive risk scoring algorithm, and the risk level is determined based on the risk score. The comprehensive risk scoring algorithm is as follows: ; wherein, is a risk impact analysis result, is a risk likelihood analysis result, is a risk item corresponding to the risk impact analysis result, the risk likelihood analysis result, , , is a weight coefficient.

7. The method of claim 2, wherein, The step of adding the risk items to be added to the product risk database based on the review results of the risk level, in order to update and maintain the product risk database, includes: The keywords and the test intent are vectorized to obtain keyword vectors and test intent vectors; Calculate the cosine value between the keyword vector and the test intent vector, and determine the similarity between the keyword and the test intent based on the cosine value; If the similarity is greater than or equal to a preset threshold, the match is confirmed to be successful, and the risk value and historical test cases corresponding to the keyword are displayed to supplement the product risk database as the risk items to be added to the database, so as to update and maintain the product risk database.

8. A system for matching test cases based on historical risks, the system comprising: include: The first generation module is used to generate a product risk library based on historical production problems and typical test defects. The second generation module is used to extract test concerns from the product risk database to generate test guidelines; The matching module is used to match keywords in the product risk database with the test intent of test cases during the testing phase of any software under test, identify historical risks that match the software under test, and obtain matching results; wherein, the test cases are obtained based on the test guidelines; The execution module is used to retrieve mitigation test cases associated with the historical risks from the product risk database based on the matching results, and merge the mitigation test cases with the test cases to form an enhanced test case set, so as to test the software under test based on the enhanced test case set.

9. A computer readable storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is executed by a processor to perform the method described in any one of claims 1 to 7. 10.An electronic device comprising a memory and a processor, the electronic device characterized by, The memory stores a computer program, and the processor is configured to run the computer program to perform the method of any one of claims 1 to 7.

11. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the method of any one of claims 1 to 7.

Images