Multi-factor-based software requirement risk index calculation and risk management and control method

Abstract

The embodiment of the present application relates to the technical field of demand risk management and control, in particular to a software demand risk index calculation and risk management and control method based on multiple factors, and the method provided by the embodiment of the present application obtains the use case data and defect data corresponding to the demand of the version, calculates the stability risk index of the demand according to the use case data and the defect data, determines the stability risk identification of the demand according to the stability risk index, and finally presents the stability risk identification, so that the stability of the function and performance of the demand can be monitored automatically and efficiently, the developer or tester can timely control the stability of the function and performance of the corresponding demand, the development progress is ensured to be affected as little as possible, and the software development quality is improved.

Description

Technical Field

[0001] This invention relates to the field of demand risk management technology, and in particular to a method for calculating and managing software demand risk index based on multiple factors. Background Technology

[0002] In software project management, a software project is typically divided into four phases: requirements analysis, functional development, functional testing, and software delivery. Each phase has a clearly defined start and end date and objectives. Starting and completing each phase on schedule is crucial for the entire software project. For developers, it is essential to regularly monitor the functionality and performance stability of the requirements or modules they are responsible for, adjusting their work strategies to meet the software project's quality requirements and ensure that the assigned requirements or modules fulfill the overall quality standards of the software project.

[0003] In related technologies, when it's necessary to manage the stability of the functionality and performance of requirements or modules, developers typically review and summarize requirement or module information, technical solutions, test documents, and historical weekly and monthly reports to determine the stability of the requirements or modules and infer whether their functionality and performance meet quality requirements. However, this method is time-consuming and labor-intensive, has low monitoring efficiency for the stability of requirements or modules, and poor readability. Failure to manage the stability of requirements or modules in a timely manner may lead to development delays, unmet quality expectations, or even the failure of the entire software project. Summary of the Invention

[0004] In view of this, one objective of the embodiments of the present invention is to provide a method for calculating and managing the software requirement risk index based on multiple factors, so as to solve the technical problems of low efficiency and poor readability in monitoring the stability of requirements functions and performance in related technologies.

[0005] To address the aforementioned technical problems, the embodiments of the present invention provide the following technical solutions:

[0006] In a first aspect, embodiments of the present invention provide a method for calculating and managing a software requirement risk index based on multiple factors, comprising:

[0007] Obtain at least one requirement for a target version, wherein the target version is a version in development among one or more versions of a software project;

[0008] Obtain test case data and defect data corresponding to candidate requirements. Candidate requirements are any one of at least one requirements. Test case data includes test cases and their status and level. Defect data includes defects and their status and level.

[0009] Based on use case data and defect data, the stability risk index of candidate requirements is calculated. The stability risk index is a parameter that characterizes the functional and performance stability of candidate requirements.

[0010] Based on the stability risk index, the stability risk level of candidate requirements is determined;

[0011] Based on the stability risk level, a stability risk identifier corresponding to the stability risk level is generated. The stability risk identifier is an identifier used to visually represent the stability risk level.

[0012] It displays a stability risk indicator.

[0013] The embodiments of the present invention have the following beneficial effects: Unlike existing technologies, the software requirement risk index calculation and risk management method based on multiple factors provided in the embodiments of the present invention includes: obtaining at least one requirement of a target version, where the target version is a version under development among one or more versions of a software project; obtaining use case data and defect data corresponding to candidate requirements, wherein the candidate requirement is any one of the at least one requirements; the use case data includes test cases and their status and level; the defect data includes defects and their status and level; based on the use case data and defect data, calculating the stability risk index of the candidate requirement, where the stability risk index is a parameter characterizing the functional and performance stability of the candidate requirement; based on the stability risk index, determining the stability risk level of the candidate requirement; based on the stability risk level, generating a stability risk identifier corresponding to the stability risk level, where the stability risk identifier is an identifier used to visually represent the stability risk level; and presenting the stability risk identifier.

[0014] This invention acquires use case data and defect data corresponding to the requirements in the version, calculates the stability risk index of the requirements based on the use case data and defect data, determines the stability risk identifier of the requirements based on the stability risk index, and finally presents the stability risk identifier. In this way, the stability of the functionality and performance of the requirements can be monitored automatically and efficiently, enabling developers or testers to manage the stability of the functionality and performance of the corresponding requirements in a timely manner, ensuring that the development progress is not affected as much as possible, and improving the quality of software development. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the prior art or embodiments will be briefly introduced below. Obviously, the drawings described below only show some embodiments of the present invention and should not be considered as limiting the scope of protection. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram illustrating the application scenario of the software requirement risk index calculation and risk management method based on multiple factors provided in some embodiments of the present invention;

[0017] Figure 2 This is a flowchart of the main steps in the method for calculating and managing software requirement risk index based on multiple factors provided in some embodiments of the present invention;

[0018] Figure 3 This is a flowchart illustrating the method for calculating and managing software requirement risk index based on multiple factors, provided in some embodiments of the present invention.

[0019] Figure 4 This is a schematic diagram of a set of test cases in some embodiments of the present invention;

[0020] Figure 5 This is a schematic diagram of the test case execution process in some embodiments of the present invention;

[0021] Figure 6 This is a schematic diagram of a defect set in some embodiments of the present invention;

[0022] Figure 7 This is a schematic diagram of the defect repair execution process in some embodiments of the present invention;

[0023] Figure 8 This is a schematic diagram of stability risk identification in some embodiments of the present invention. Detailed Implementation

[0024] To make the objectives and advantages of the embodiments of the present invention more readily understood, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. The detailed description of the embodiments of the present invention in the accompanying drawings is not intended to limit the scope of protection claimed by the present invention, but only to illustrate selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] It should be noted that, unless there is a conflict, the various technical features involved in the embodiments of the present invention described below can be combined with each other, and all are within the protection scope of the present invention. Furthermore, although functional modules are divided in the device or structural schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. In addition, the terms "first," "second," "third," and other similar expressions used herein do not limit the data or execution order, but are only for illustrative purposes and to distinguish identical or similar items with substantially the same function and effect, and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features.

[0026] Unless otherwise defined, the technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. It should be understood that the term "and / or" as used herein includes any and all combinations of one or more of the listed items.

[0027] Please see Figure 1 and Figure 2 , Figure 1 The illustrations depict application scenarios of the software requirement risk index calculation and risk management method based on multiple factors provided in some embodiments of the present invention. Figure 2 The flowchart illustrates the main steps of the multi-factor-based software requirement risk index calculation and risk management method provided in some embodiments of the present invention.

[0028] like Figure 1 As shown, the application scenario includes electronic device 100, first engine 10, second engine 20 and third engine 30. Electronic device 100 is connected to first engine 10, second engine 20 and third engine 30 through a communication network. It can be understood that the communication network includes, but is not limited to, the Internet, corporate intranet, local area network, mobile communication network and combinations thereof.

[0029] Specifically, in practical applications of software development management, the first engine 10 is used to collect and provide requirements. Users (such as project managers) can publish requirements on the first engine 10. The first engine 10 will collect multiple requirements for the same version of the same project to form a requirement set, and store the requirement set on local storage, cloud server, or other suitable media. In this embodiment of the invention, the first engine 10 can be the project management tool "Redmine" or other suitable systems, tools, or software, and this embodiment of the invention does not impose any limitations on this.

[0030] In some embodiments, the electronic device 100 obtains a set of requirements B from the first engine 10 in target version A, the set of requirements B including at least one requirement (such as... Figure 2 The requirements shown are B1, B2, B3, and B4. Target version A is one or more versions of the software project that are currently under development. In essence, a requirement describes the functionality that a software system needs to implement. For example, if the required functionality is to count the number of patents and patent applications, then the requirement could be to count the number of patents and patent applications within any given time period, and to be able to perform statistics based on various factors such as application type, application date, whether granted, and legal status.

[0031] It should be understood that the same target version of a project includes one or more requirements. A requirement can be divided into multiple detailed sub-requirements, and multiple sub-requirements correspond to the same requirement. For example, if the requirement is to implement a function to count the number of patents and patent applications, then the multiple sub-requirements may include patent entry requirements, patent information (including, for example, application time, application type, and whether it has been granted), and patent statistics requirements. Requirements are assigned to specific developers. When creating each requirement, the work hours for each requirement are preset, so that each requirement has a corresponding work time (i.e., the work time required for developers to solve each requirement). The work time of the requirements is used by project managers or managers to control and manage the resources of developers, as well as the project testing and delivery schedule, and to promote the software project development progress.

[0032] Specifically, the second engine 20 is used to aggregate and provide test cases. A test case is used to test the implementation status and defects of various functions in software development. Test cases are associated with requirements; that is, a test case is a test case specific to a particular requirement. Users can publish test cases on the second engine 20. The second engine 20 will aggregate test cases for the same requirement to form test case data and store the test case data in local storage, a cloud server, or other suitable media. The test case data includes test cases and their status and level. In some embodiments of this invention, the second engine 20 can be the software testing platform "MeterSphere" or other suitable systems, platforms, or software; this embodiment of the invention does not impose any limitations on this.

[0033] Specifically, the third engine 30 is used to collect and provide defects. A defect refers to a problem where the actual result does not match the expected requirement. Defects are associated with requirements; that is, a defect is a problem specific to a particular requirement. Users can publish defects on the third engine 30. The third engine 30 will collect defects targeting the same requirement, forming defect data, and store the defect data on local storage, a cloud server, or any other suitable medium. The defect data includes the defect itself, its status, and its level. In this embodiment of the invention, the third engine 30 can be the project management software "ZenTao" or any other suitable system, tool, or software; this embodiment of the invention does not impose any limitations on this.

[0034] In some embodiments, the electronic device 100 obtains use case data corresponding to candidate requirements from the second engine 20 and defect data corresponding to candidate requirements from the third engine 30, based on the obtained requirement set B. The candidate requirement is any one requirement in the requirement set B (e.g., candidate requirement B4).

[0035] For details, please refer to Figure 2 The electronic device 100 obtains the requirement set B of the target version A in the software project from the first engine 10. Requirement set B includes four requirements: B1, B2, B3, and B4. After selecting requirement B4 as a candidate requirement, the electronic device 100 obtains the data corresponding to requirement B4 from each engine, resulting in a data set C4. Specifically, it obtains use case data C41 corresponding to requirement B4 from the second engine 20 and defect data C42 corresponding to requirement B4 from the third engine 30. Based on the use case data C41 and defect data C42, the stability risk index of requirement B4 is calculated. For other requirements in requirement set B, the stability risk index of each requirement is calculated using the same method. After calculating the stability risk index of each requirement in requirement set B, the electronic device 100 determines the stability risk level of each requirement (i.e., requirement B1, requirement B2, requirement B3, and requirement B4) based on its stability risk index, and generates a stability risk identifier for each requirement based on its stability risk level. Finally, the stability risk identifier of each requirement is presented.

[0036] Through the above methods, the embodiments of the present invention can automatically and efficiently monitor the stability of the functionality and performance of the requirements, enabling developers or testers to manage the stability of the functionality and performance of the corresponding requirements in a timely manner, ensuring that the development progress is not affected as much as possible, and improving the quality of software development.

[0037] It should be understood that, Figure 1In the application scenario shown, the electronic device 100 is a laptop computer. This does not limit the structure, type, quantity, acquisition requirements, or the method of obtaining use case data and defect data corresponding to those requirements in other application scenarios or embodiments. For example, in some other application scenarios or embodiments, the electronic device can also be a desktop computer, tablet computer, microcontroller, microcontroller, or any other suitable type of device or apparatus. The use case data and defect data corresponding to the requirements are stored in the same storage medium. The electronic device directly obtains the use case data and defect data corresponding to the requirements from one storage medium, without having to obtain the use case data and defect data from multiple engines separately.

[0038] As can be understood from the above, the implementing entity of any of the multi-factor-based software requirement risk index calculation and risk management methods provided in the embodiments of the present invention can be any suitable type of electronic device with certain computing and control capabilities, such as the aforementioned electronic device 100. In some feasible implementations, any of the multi-factor-based software requirement risk index calculation and risk management methods provided in the embodiments of the present invention can be implemented by a processor executing computer program instructions stored in a memory.

[0039] The following will describe in detail the method for calculating and managing the software requirement risk index based on multiple factors provided in the embodiments of the present invention, using exemplary applications and implementations of the electronic devices provided in the embodiments of the present invention.

[0040] Please see Figure 3 , Figure 3 The illustration shows a flowchart of a method for calculating and managing software requirement risk index based on multiple factors, provided in some embodiments of the present invention.

[0041] Those skilled in the art will understand that the multi-factor-based software requirement risk index calculation and risk management method provided in this embodiment of the invention can be applied to the aforementioned electronic device (e.g., electronic device 100). Specifically, the execution entity of this multi-factor-based software requirement risk index calculation and risk management method is one or at least two processors of the electronic device.

[0042] like Figure 3 As shown, the method for calculating and managing the software demand risk index based on multiple factors includes, but is not limited to, the following steps S100-S600:

[0043] S100: Obtain at least one requirement for the target version.

[0044] In this embodiment of the invention, the target version is a version in the development stage of one or more versions of a software project.

[0045] For example, in embodiments of the present invention, the requirements set of the target version of a software project is obtained from the project management tool "Redmine" or any other suitable system, tool or software, and the requirements set includes at least one requirement, thereby obtaining at least one requirement of the target version.

[0046] S200: Obtain use case data and defect data corresponding to the candidate requirements.

[0047] Specifically, any one requirement from the requirement set is selected as a candidate requirement, that is, at least one requirement is selected as a candidate requirement. In this embodiment of the invention, test case data corresponding to the candidate requirements is obtained from the software testing platform "MeterSphere" or any other suitable system, platform, or software, and defect data corresponding to the candidate requirements is obtained from the project management software "ZenTao" or any other suitable system, tool, or software.

[0048] In this embodiment of the invention, the test case data includes test cases and their states and levels. The test case states include a pass state (P), a failure state (F), an obstacle state (B), and an unexecuted state (N). A pass state (P) indicates that the test case has been executed successfully. A failure state (F) indicates that the test case has been executed but failed, requiring problem fixing before execution. An obstacle state (B) indicates that there are obstacles to the execution of the test case (e.g., environment configuration problems), requiring resolution before execution. An unexecuted state (N) indicates that the test case has not been executed, requiring execution of the unexecuted test case. The test case levels include multiple levels, such as first level, second level, and third level, each representing the degree of influence of the test case on the risk index. For example, in some embodiments, the weights corresponding to the first, second, and third levels are 0.5, 0.3, and 0.2, respectively. Clearly, the first-level test case has a greater influence on the risk index than the second-level test case, and the second-level test case has a greater influence than the third-level test case.

[0049] In this embodiment of the invention, defect data includes defects and their states and levels. Defect states include New (N), Repair (R), Verification (V), Closed (C), and Invalid (I). New (N) indicates a defect has been created but not yet repaired. Repair (R) indicates a defect has been confirmed to exist and needs repair, requiring the corresponding developer to fix it. Verification (V) indicates a repaired defect requires verification by the corresponding tester to determine if the repair was successful. Closed (C) indicates a repaired defect has passed verification, and defects in Closed (C) are closed. Invalid (I) indicates a misjudgment during defect creation; the defect does not actually exist or does not need repair, and defects in Invalid (I) are closed. Defect levels include multiple levels, such as Level 1, Level 2, and Level 3, each representing the degree of impact of the defect on the risk index. In some embodiments, the weights corresponding to Level 1, Level 2, and Level 3 are 0.5, 0.3, and 0.2, respectively. Clearly, Level 1 defects have a greater impact on the risk index than Level 2 defects, and Level 2 defects have a greater impact than Level 3 defects.

[0050] S300: Calculates the stability risk index of candidate requirements based on use case data and defect data.

[0051] In this embodiment of the invention, the stability risk index is a parameter characterizing the functional and performance stability of candidate requirements. That is, the stability risk index reflects the stability of the functional and performance implementation of candidate requirements. Thus, through the stability risk index, the risks existing in the functional and performance implementation of candidate requirements can be accurately and promptly identified. The stability risk index mainly focuses on the completeness and quality of functional implementation. For each requirement in a version, two risk factors must be considered: test cases and defects. Test cases represent the expected scope of functional delivery and are the basis for software acceptance. Defects reflect the deviation between the actual results and the expected functions. Repairing defects ensures that the software delivery results meet the quality objectives. Test cases define the "standards to be achieved," defects expose the "actual gaps," and repairs achieve "standard alignment." Based on the two risk factors of test cases and defect repairs, the quality of the functional and performance implementation of each requirement can be well evaluated.

[0052] Specifically, based on the status and level of test cases in the test case data, the test case risk index of the candidate requirement is calculated. Similarly, based on the status and level of defects in the defect data, the defect risk index of the candidate requirement is calculated. Weighting coefficients for the test case risk index and the defect risk index are pre-set based on their respective impacts on the stability risk index. The weighting coefficients for both the test case risk index and the defect risk index are then obtained. Finally, the test case risk index and the defect risk index are weighted and summed to obtain the stability risk index of the candidate requirement.

[0053] In some embodiments, based on use case data and defect data, a stability risk index for candidate requirements is calculated, including but not limited to the following steps S310-S330:

[0054] S310: Calculate the use case risk index of candidate requirements based on use case data.

[0055] For example, the risk index is calculated based on the status and level of test cases. The risk index of candidate requirements is calculated based on the status, weight and number of first-level test cases for each status of first-level test cases, the status, weight and number of second-level test cases for each status of second-level test cases, and the status, weight and number of third-level test cases for each status of third-level test cases.

[0056] In some embodiments, based on use case data, a use case risk index for candidate requirements is calculated, including but not limited to the following steps S311-S315:

[0057] S311: Divide the test cases in the test case data into multiple test case sets according to the level of the test cases.

[0058] Specifically, based on the level of test cases in the test case data, test cases of the same level are grouped into the same set, resulting in multiple test case sets. Each test case set includes one or more test cases at a reference level. The execution status of test cases at each level has a different impact on the risk index. The reference level is any one of the preset test case levels (e.g., first level, second level, and third level). It is easy to understand that the level of test cases can also be represented in other ways, such as high level, medium level, low level, etc., and this embodiment of the invention does not impose any limitations on this.

[0059] For example, please see Figure 4 , Figure 4 This schematically illustrates one of the multiple test case sets. For example... Figure 4 As shown, the test case set U1 includes four test cases at the first level: test case N1, test case N2, test case N3, and test case N4. The status of test case N1 is Pass (P) and its number is KN8744; the status of test case N2 is Failure (F) and its number is KN8776; the status of test case N3 is Impeded (B) and its number is KN8733; and the status of test case N4 is Not Executed (N) and its number is KN8714.

[0060] S312: Calculate the first total workload based on the status of the test cases in the candidate test case set.

[0061] In this embodiment of the invention, the candidate test case set is any one of multiple test case sets.

[0062] Specifically, when a test case in the candidate test case set is in a certain state, the workload of each work item that has been executed when the test case is in a certain state is determined, the workload of each executed work item is calculated as the workload of the test case, and the workloads of all test cases in the candidate test case set are added together to obtain the first total workload.

[0063] Please see Figure 5 , Figure 5 The diagram illustrates the test case execution process. When a test case is in the pass state P, it means that the test case has been executed successfully. The first tasks that have been executed include identifying test case exeI and executing test case exeC. The workload of identifying test case exeI and executing test case exeC is calculated as the workload of the test case in the pass state P.

[0064] When a test case is in failure state F, it means that the test case was executed but failed and needs to be repaired before it can be executed again. The second task that has been executed at this time includes identifying test case exeI, executing test case exeC, and repairing the failed test case fixF. The workload of identifying test case exeI, executing test case exeC, and repairing the failed test case fixF is calculated as the workload of the test case in failure state F.

[0065] When a test case is in blocked state B, it means that the test case is being executed but there is an obstacle to the execution. The execution obstacle needs to be resolved before execution can be repeated. At this time, the third work item that has been executed includes identifying test case exeI, executing test case exeC, and resolving execution obstacle fixB. The workload of identifying test case exeI, executing test case exeC, and resolving execution obstacle fixB is calculated as the workload of the test case in blocked state B.

[0066] When a test case is in the unexecuted state N, it means that the test case has not yet been executed. At this time, the fourth work item that has been executed includes identifying the test case exeI and calculating the workload of identifying the test case exeI as the workload of the test case in the unexecuted state N.

[0067] Understandably, the workload of identifying test case exeI refers to the baseline workload of identifying a test case; the workload of executing test case exeC refers to the workload of executing a test case; the workload of fixing failed test case fixF refers to the additional workload of fixing a failed test case (including code fixing and regression testing); and the workload of resolving execution obstacles fixB refers to the workload of resolving an obstructing test case (i.e., a test case in obstructed state B) (including fixing environmental issues and regression testing). Designers pre-determine the workload for each task (including identifying test case exeI, executing test case exeC, fixing failed test case fixF, and resolving execution obstacles fixB) based on historical data, experience values, etc., with workload units including hours, days, etc.

[0068] In some embodiments, a first total workload is calculated based on the status of test cases in the candidate test case set, specifically including but not limited to the following steps S3121-S3124:

[0069] S3121: Select one or more test cases in the first candidate state from the candidate test case set as candidate test cases.

[0070] S3122: Based on the first candidate state, determine the first candidate workload corresponding to the first candidate state.

[0071] In this embodiment, the first candidate state is any one of the multiple states of a test case in the candidate test case set. That is, the first candidate state may be any one of the following states: pass state P, failure state F, obstacle state B, and non-execution state N. The first candidate workload represents the time required to execute all the work items of the first candidate work phase, and the first candidate work phase is the time period from the identification of the candidate test case to the candidate test case being in the first candidate state.

[0072] For example, one or more test cases in the first candidate state from the candidate test case set are selected as candidate test cases. The first candidate workload (i.e. the workload of the candidate test case) corresponding to the first candidate state is determined according to the first candidate state. That is, the workload of each work item that has been executed when the candidate test case is in the first candidate state is calculated as the first candidate workload.

[0073] In some embodiments, from the time period from the identification of candidate test cases to the time period when the candidate test cases are in the first candidate state (i.e., the first candidate work phase), all work items of the first candidate work phase are determined, and the time required to execute all work items of the first candidate work phase is determined as the first candidate workload (i.e. the workload of the candidate test cases).

[0074] For example, a test case in the pass state P is identified as a candidate test case. All work items in the first candidate work phase include identifying test case exeI and executing test case exeC. The time required to execute the identified test case exeI and the executed test case exeC (i.e., the workload of test case exeI and the execution of test case exeC) is determined as the first candidate workload (i.e., the workload of the candidate test case).

[0075] S3123: Multiply the number of candidate test cases by the workload of the first candidate to obtain the total workload of the candidate test cases.

[0076] S3124: Add up the total workload of all test cases in the candidate test case set to obtain the first total workload.

[0077] In this embodiment, the number of candidate test cases (i.e. test cases in the first candidate state) is counted, and the number of candidate test cases is multiplied by the first candidate workload to obtain the total workload of the candidate test cases.

[0078] Specifically, after calculating the total workload of test cases in each state in the candidate test case set, the total workload of all test cases in the candidate test case set is added together to obtain the first total workload.

[0079] S313: Based on the first total workload, determine the first standard workload of the standard test cases in the candidate test case set.

[0080] Here, the first standard state is the state among the multiple states of test cases in the candidate test case set that represents the test case's successful execution; that is, the first standard state is the pass state P. A standard test case is a test case in the candidate test case set that is in the first standard state, i.e., a test case in the pass state P.

[0081] Specifically, as mentioned earlier, the sum of the workloads of all test cases in the candidate test case set (i.e., the first total workload) has been calculated. Then, the first standard workload is selected from the first total workload to determine the standard test cases in the candidate test case set. Clearly, the number of standard test cases in the candidate test case set may be zero, one, or more.

[0082] In some embodiments, the correspondence between the status and workload of reference-level test cases in the test case set is shown in Table 1 below:

[0083] Table 1:

[0084]

[0085] As shown in Table 1, the first total workload is calculated based on the status of the test cases in the candidate test case set. Clearly, the first total workload... The first standard work volume for standard test cases is... .

[0086] It is understood that Table 1 above is merely an example. The correspondence between the status and workload of test cases at different levels may be the same or different. Designers design the correspondence between the status and workload of test cases at each level based on experience data, experimental data, etc. This embodiment of the invention does not impose any limitations on this.

[0087] S314: Based on the first total workload and the first standard total workload, determine the risk coefficient of the reference level test cases in the candidate test case set.

[0088] Specifically, based on the first total workload and the first standard total workload, the test progress value of the reference-level test cases is calculated. According to the correspondence table between the test progress value and the risk coefficient, the risk coefficient corresponding to the test progress value is determined as the risk coefficient of the reference-level test cases in the candidate test case set.

[0089] In some embodiments, the risk coefficient of reference-level test cases in the candidate test case set is determined based on the first total workload and the first standard total workload, specifically including but not limited to the following steps S3141-S3145:

[0090] S3141: Divide the total first standard workload by the total first workload to obtain the test progress value of the reference level test cases in the candidate test case set.

[0091] S3142: If the response test progress value is within the first test threshold range, the first test risk coefficient is determined as the risk coefficient of the test case at the reference level.

[0092] S3143: If the response test progress value is within the range of the second test threshold, the second test risk coefficient is determined as the risk coefficient of the test case at the reference level.

[0093] S3144: If the response test progress value is within the range of the third test threshold, the risk coefficient of the third test is determined as the risk coefficient of the test case at the reference level.

[0094] S3145: If the response test progress value is within the range of the fourth test threshold, the fourth test risk coefficient is determined as the risk coefficient of the test case at the reference level.

[0095] Specifically, after calculating the first standard workload and the first total workload, the first standard workload is divided by the first total workload to obtain the test progress value of the reference-level test cases in the candidate test case set. Based on a pre-defined correspondence table between test progress values ​​and risk coefficients, the risk coefficients corresponding to the test progress values ​​(i.e., the first test risk coefficient, the second test risk coefficient, the third test risk coefficient, or the fourth test risk coefficient) are determined as the risk coefficients of the reference-level test cases in the candidate test case set.

[0096] For example, the table below shows the correspondence between the test progress and risk coefficient of reference-level test cases in the test case set:

[0097] Table 2:

[0098]

[0099] As mentioned earlier, the first total workload is calculated based on the status of the test cases in the candidate test case set. The first standard work volume of standard test cases Then the test progress value of the reference level test cases According to Table 2 above, the test progress values ​​for reference-level test cases. Located within the first test threshold range , and the range of the first test threshold The corresponding risk coefficient for the first test is Then determine the risk coefficient of the first test. Risk coefficient for reference-level test cases.

[0100] Understandably, Table 2 above is merely an example. The correspondence between test progress and risk coefficient for different levels of test cases may be the same or different. Designers design the correspondence between test progress and risk coefficient for each level of test cases based on experience data, experimental data, etc. This embodiment of the invention does not impose any limitations on this.

[0101] S315: Calculate the test case risk index of candidate requirements based on the risk coefficients of reference-level test cases in all test case sets.

[0102] Specifically, obtain the weight coefficients corresponding to the reference-level test cases in all test case sets, and then weight and sum the risk coefficients of all reference-level test cases based on their weight coefficients to obtain the test case risk index of the candidate requirement.

[0103] For example, in some embodiments, the test case risk index of the candidate requirement is calculated based on the risk coefficient of the reference-level test cases in all test case sets, specifically including but not limited to the following steps S3151-S3153:

[0104] S3151: Obtain the reference weight coefficient corresponding to the reference level of the test cases in the test case set.

[0105] S3152: Multiply the risk coefficient of the reference-level test cases by the reference weight coefficient corresponding to the reference level to obtain the test case risk index of the reference-level test cases.

[0106] S3153: Sum the test case risk indices of all reference-level test cases to obtain the test case risk index of the candidate requirement.

[0107] Specifically, the impact of test cases at each level on the test case risk index varies. Based on the test case level, a weight coefficient corresponding to each level is pre-set; that is, a reference weight coefficient corresponding to the reference level of the test cases in the test case set is pre-set. When calculating the test case risk index of the candidate requirement, the reference weight coefficient corresponding to the reference level of the test cases in the test case set is obtained. The risk coefficient of each reference level test case is multiplied by its corresponding reference weight coefficient to obtain the test case risk index for each reference level. The test case risk indices of all reference levels are summed to obtain the test case risk index of the candidate requirement.

[0108] For example, suppose we divide the test cases into three sets: Level 1, Level 2, and Level 3 test cases. The risk coefficient and reference weight coefficient for the Level 1 test cases are as follows: and The risk coefficient and reference weight coefficient of the second-level test cases are respectively and The risk coefficient and reference weight coefficient of the third-level test cases are respectively and The risk coefficient of each level of test cases is multiplied by the reference weight coefficient of each level of test cases, and all the products are summed to calculate the test case risk index of the candidate requirement. .

[0109] S320: Calculate the defect risk index of candidate requirements based on defect data.

[0110] Specifically, the status and level of defects affect the calculation of the risk index. Based on the status, weight, and number of first-level defects in each status of the first-level defects, the status, weight, and number of second-level defects in each status of the second-level defects, and the status, weight, and number of third-level defects in each status of the third-level defects, the defect risk index of the candidate requirements is calculated.

[0111] In some embodiments, a defect risk index for candidate requirements is calculated based on defect data, including but not limited to the following steps S321-S325:

[0112] S321: Divide the defects in the use case data into multiple defect sets according to the defect level.

[0113] For example, based on the defect level in the defect data, defects of the same level are grouped into the same set, resulting in multiple defect sets. Each defect set includes one or more defects at a reference level, and the handling of defects at each level has a different impact on the risk index. The reference level is any one of the preset defect levels (e.g., first level, second level, and third level). It is readily understood that the defect level can also be represented in other ways, such as high level, medium level, low level, etc., and this embodiment of the invention does not impose any limitations on this.

[0114] For example, please see Figure 6 , Figure 6 This schematically illustrates one of the multiple defect sets. For example... Figure 6 As shown, the defect set H1 includes six defects at the second level. The six defects are defect M1, defect M2, defect M3, defect M4, defect M5 and defect M6. The status of defect M1 is New (N) and the number is KM6788. The status of defect M2 is Repair (R) and the number is KM6732. The status of defect M3 is Verify (V) and the number is KM6742. The status of defect M4 is Invalid (I) and the number is KM6751. The status of defect M5 is Closed (C) and the number is KM6722. The status of defect M6 is Closed (C) and the number is KM6774.

[0115] S322: Calculate the second total workload based on the state of the defects in the candidate defect set.

[0116] In this embodiment, the candidate defect set is any one of the multiple defect sets.

[0117] For example, when a defect in the candidate defect set is in a certain state, the workload of each work item that has been executed when the defect is in a certain state is determined, the workload of each executed work item is calculated as the workload of the defect, and the workloads of all defects in the candidate defect set are added together to obtain the second total workload.

[0118] Please see Figure 7 , Figure 7 The diagram illustrates the defect repair execution process. When a defect is in the "New" state N, it means the defect has just been created and it has not yet been confirmed whether it needs to be repaired. At this time, the fifth task already executed includes identifying defect bugI. The workload of identifying defect bugI is then calculated as the workload of the defect in the "New" state N.

[0119] When a defect is in the repair status R, it means that the defect has been identified and confirmed to need to be repaired, but the repair has not yet been performed and needs to be done by the developers; or the repair is in progress and has not yet been completed. At this time, the sixth work item that has been executed includes identifying defect bugI and confirming defect bugC. The workload of identifying defect bugI and confirming defect bugC is calculated as the workload of the defect in the repair status R.

[0120] When a defect is in verification state V, it means that the defect has been modified but has not yet been verified and needs to be verified by testers; or it is being verified but has not yet been completed. The seventh work item that has been executed at this time includes identifying defect bugI, confirming defect bugC, and fixing defect bugR. The workload of identifying defect bugI, confirming defect bugC, and fixing defect bugR is calculated as the workload of the defect in verification state V.

[0121] When a defect is in closed state C, it means that the defect has been repaired and verified. The eighth work item that has been executed at this time includes identifying defect bugI, confirming defect bugC, repairing defect bugR, and verifying defect bugV. The workload of identifying defect bugI, confirming defect bugC, repairing defect bugR, and verifying defect bugV is calculated as the workload of the defect in unexecuted state N.

[0122] When a defect is in invalid state I, it means that the defect does not exist or does not need to be fixed. It does not need to be fixed by the developers and can be closed directly. At this time, the ninth work item that has been executed includes identifying defect bugI and confirming defect bugC. The workload of identifying defect bugI and confirming defect bugC is calculated as the workload of the defect in invalid state I.

[0123] It's understandable that the workload for identifying defect bugI refers to the baseline workload for identifying a defect; the workload for confirming defect bugC refers to the baseline workload for confirming a defect (including confirming the specific content of the defect, its severity level, the personnel responsible for fixing it, and the preset repair time); the workload for fixing defect bugR refers to the additional workload for fixing a defect (including the workload of fixing the code); and the workload for verifying defect bugV refers to the workload for verifying a modified defect (including the workload of verification testing). It's easy to understand that designers pre-set the workload for each task (including identifying defect bugI, confirming defect bugC, fixing defect bugR, and verifying defect bugV) based on historical data, experience values, etc., with the workload unit being hours, days, etc.

[0124] For example, in some embodiments, a second total workload is calculated based on the state of defects in the candidate defect set, specifically including but not limited to the following steps S3221-S3224:

[0125] S3221: Select one or more defects in the second candidate state from the candidate defect set as candidate defects.

[0126] S3222: Based on the second candidate state, determine the second candidate workload corresponding to the second candidate state.

[0127] In this embodiment, the second candidate state is any one of the multiple states of a defect in the candidate defect set, that is, the second candidate state may be any one of the following states: new state N, repair state R, verification state V, closed state C, and invalid state I. The second candidate workload represents the time required to execute all the work items in the second candidate work stage, and the second candidate work stage is the time period from the identification of the candidate defect to the candidate defect being in the second candidate state.

[0128] Specifically, select one or more defects in the candidate defect set that are in the second candidate state as candidate defects, and determine the second candidate workload (i.e. the workload of the candidate defect) corresponding to the second candidate state based on the second candidate state. That is, calculate the workload of each work item that has been executed when the candidate defect is in the second candidate state as the second candidate workload.

[0129] In some embodiments of the present invention, during the time period from the identification of a candidate defect to the candidate defect being in a second candidate state (i.e., the second candidate work phase), all work items of the second candidate work phase are determined, and the working hours required to perform all work items of the second candidate work phase are determined as the second candidate workload (i.e. the workload of the candidate defect).

[0130] For example, if a defect in the closed state C is identified as a candidate defect, then all work items in the second candidate work phase, including identifying defect bugI, confirming defect bugC, fixing defect bugR, and verifying defect bugV, are determined to be the second candidate workload (i.e., the workload of identifying defect bugI, confirming defect bugC, fixing defect bugR, and verifying defect bugV).

[0131] S3223: Multiply the number of candidate defects by the second candidate workload to obtain the total workload of candidate defects.

[0132] S3224: Add up the total workload of all defects in the candidate defect set to obtain the second total workload.

[0133] In this embodiment, the number of candidate defects (i.e. defects in the second candidate state) is counted, and the number of candidate defects is multiplied by the second candidate workload to obtain the total workload of candidate defects.

[0134] Specifically, after calculating the total workload of defects in each state in the candidate defect set, the total workload of all defects in the candidate defect set is added together to obtain the second total workload.

[0135] S323: Determine the second standard workload of standard defects in the candidate defect set based on the second total workload.

[0136] In this invention, the second standard state is the state representing the closure of defect repair among multiple states of defects in the candidate defect set, i.e., the second standard state is the closed state C. The third standard state is the state representing the invalid closure of defects among multiple states of defects in the candidate defect set, i.e., the third standard state is the invalid state I. A standard defect is a defect in the candidate defect set that is in either the second or third standard state, i.e., a defect in either the closed state C or the invalid state I. For ease of understanding, this embodiment of the invention defines a defect in the closed state C as a first standard defect and a defect in the invalid state I as a second standard defect. Thus, standard defects include both first and second standard defects.

[0137] As mentioned earlier, the sum of the workloads of all defects in the candidate defect set (i.e., the second total workload) has been calculated. Then, the second total workload is used to filter out the standard defects (including the first standard defect and / or the second standard defect) in the candidate defect set from the second total workload. Understandably, the number of standard defects in the candidate defect set may be zero, one, or more.

[0138] For example, when there is a first standard defect and a second standard defect, the total workload of the first standard defect and the second standard defect in the candidate defect set is selected from the second total workload, and the total workload of the first standard defect is added to the total workload of the second standard defect to obtain the second standard workload of the standard defect.

[0139] For example, when there is a first standard defect and there is no second standard defect, the total workload of the first standard defect in the candidate defect set is selected from the second total workload, where the total workload of the first standard defect is the second standard workload of the standard defect.

[0140] For example, when there is no first standard defect but there is a second standard defect, the total workload of the second standard defects in the candidate defect set is selected from the total workload of the second standard defects, where the total workload of the second standard defects is the total workload of the second standard defects.

[0141] In some embodiments, the correspondence between the status of reference-level defects in the defect set and the workload is shown in Table 3 below:

[0142] Table 3:

[0143]

[0144] According to Table 3, the second total workload is calculated based on the status of the defects in the candidate defect set. The total workload for the second standard defect is [amount missing]. .

[0145] Understandably, Table 3 above is merely an example. The correspondence between the status of defects and workload at different levels may be the same or different. Designers design the correspondence between the status of defects and workload at each level based on experience data, experimental data, etc. This embodiment of the invention does not impose any limitations on this.

[0146] S324: Based on the second total workload and the second standard total workload, determine the risk coefficient of the reference level defects in the candidate defect set.

[0147] Specifically, based on the second total workload and the second standard total workload, the repair progress value of the reference level defect is calculated. According to the correspondence table between the repair progress value and the risk coefficient, the risk coefficient corresponding to the repair progress value is determined as the risk coefficient of the reference level defect in the candidate defect set.

[0148] In some embodiments, the risk coefficient of a reference-level defect in the candidate defect set is determined based on the second total workload and the second standard total workload, specifically including but not limited to the following steps S3241-S3245:

[0149] S3241: Divide the total amount of the second standard work by the sum of the second work to obtain the repair progress value of the reference level defects in the candidate defect set.

[0150] S3242: If the response repair progress value is within the range of the first repair threshold, the first repair risk coefficient is determined as the risk coefficient of the defect at the reference level.

[0151] S3243: If the response repair progress value is within the range of the second repair threshold, the second repair risk coefficient is determined to be the risk coefficient of the defect at the reference level.

[0152] S3244: If the response repair progress value is within the range of the third repair threshold, the third repair risk coefficient is determined as the risk coefficient of the defect at the reference level.

[0153] S3245: If the response repair progress value is within the range of the fourth repair threshold, the fourth repair risk coefficient is determined as the risk coefficient of the defect at the reference level.

[0154] Specifically, after calculating the second standard workload and the second workload sum, the second standard workload is divided by the second workload sum to obtain the repair progress value of the reference-level defects in the candidate defect set. Based on a preset correspondence table between repair progress values ​​and risk coefficients, the risk coefficients corresponding to the repair progress values ​​(i.e., the first repair risk coefficient, the second repair risk coefficient, the third repair risk coefficient, or the fourth repair risk coefficient) are determined as the risk coefficients of the reference-level defects in the candidate defect set.

[0155] In some embodiments, the correspondence between the repair progress and risk coefficient of reference-level defects in the defect set is shown in Table 4 below:

[0156] Table 4:

[0157]

[0158] As mentioned earlier, the second workload is calculated based on the state of the defects in the candidate defect set. The second standard of standard defects, total standard work Then the repair progress value of the defect at the reference level According to Table 4 above, when the repair progress value of the reference level defect... It falls within the third repair threshold range. , and the third repair threshold range The corresponding third repair risk coefficient is Then determine the third repair risk coefficient. The risk coefficient for defects at the reference level.

[0159] Understandably, Table 4 above is merely an example. The correspondence between the repair progress and risk coefficient of test cases at different levels may be the same or different. Designers design the correspondence between the repair progress and risk coefficient of test cases at each level based on experience data, experimental data, etc. This embodiment of the invention does not impose any limitations on this.

[0160] S325: Calculate the defect risk index of candidate requirements based on the risk coefficient of the reference level defects in all defect sets.

[0161] For example, the weight coefficients corresponding to the reference level defects in all defect sets are obtained. Based on the weight coefficients corresponding to the reference level defects, the risk coefficients of all reference level defects are weighted and summed to obtain the defect risk index of the candidate requirement.

[0162] In some embodiments, a defect risk index for candidate requirements is calculated based on the risk coefficient of defects at the reference level in all defect sets, including but not limited to the following steps S3251-S3253:

[0163] S3251: Obtain the reference weight coefficient corresponding to the reference level of the defect in the defect set.

[0164] S3252: Multiply the risk coefficient of the defect at the reference level by the reference weight coefficient corresponding to the reference level to obtain the repair risk index of the defect at the reference level.

[0165] S3253: Sum the repair risk indices of all reference-level defects to obtain the defect risk index of the candidate requirement.

[0166] For example, each level of defect has a different impact on the defect risk index. Based on the defect level, a weighting coefficient corresponding to each defect level is pre-set; that is, a reference weighting coefficient corresponding to the reference level of the defects in the defect set is pre-set. When calculating the defect risk index of the candidate requirement, the reference weighting coefficient corresponding to the reference level of the defects in the defect set is obtained. The risk coefficient of each reference level defect is multiplied by the reference weighting coefficient corresponding to that reference level to obtain the repair risk index of each reference level defect. The repair risk indices of all reference level defects are summed to obtain the defect risk index of the candidate requirement.

[0167] For example, suppose we obtain three defect sets, including level 1 defects, level 2 defects, and level 3 defects, where the risk coefficient and reference weight coefficient of level 1 defects are respectively... and The risk coefficient and reference weight coefficient for the second-level defect are respectively and The risk coefficient and reference weight coefficient for level 3 defects are respectively and Then, the defect risk index of the candidate requirement is calculated. .

[0168] S330: Calculate the stability risk index of candidate requirements based on the use case risk index and the defect risk index.

[0169] Specifically, the weight coefficients of the pre-set use case risk index and defect risk index are obtained. The use case risk index is multiplied by the weight coefficient of the use case risk index to obtain the product of the use case risk index. The defect risk index is multiplied by the weight coefficient of the defect risk index to obtain the product of the defect risk index. Finally, the product of the use case risk index and the product of the defect risk index are added together to obtain the stability risk index of the candidate requirement.

[0170] For example, the use case risk index and the defect risk index are respectively and The weighting coefficients of the use case risk index and the defect risk index are respectively... and Then the stability risk index of the candidate demand is calculated. .

[0171] In some embodiments, a stability risk index for candidate requirements is calculated based on the use case risk index and the defect risk index, including but not limited to the following steps S331-S334:

[0172] S331: Obtain the use case weight coefficient corresponding to the use case risk index, and obtain the defect weight coefficient corresponding to the defect risk index.

[0173] S332: Multiply the use case risk index by the use case weight coefficient to obtain the first risk index result.

[0174] S333: Multiply the defect risk index by the defect weight coefficient to obtain the second risk index result.

[0175] S334: Add the results of the first risk index and the second risk index to obtain the stability risk index of the candidate demand.

[0176] Specifically, based on the degree of influence of the use case risk index on the stability risk index, a use case weight coefficient corresponding to the use case risk index is pre-set, and based on the degree of influence of the defect risk index on the stability risk index, a defect weight coefficient corresponding to the defect risk index is pre-set. When calculating the stability risk index of the candidate requirement, the pre-set use case weight coefficients corresponding to the use case risk index and the defect weight coefficients corresponding to the defect risk index are obtained. The use case risk index is multiplied by the use case weight coefficients to obtain the first risk index result, and the defect risk index is multiplied by the defect weight coefficients to obtain the second risk index result. The first risk index result and the second risk index result are added together to obtain the stability risk index of the candidate requirement.

[0177] S400: Determine the stability risk level of candidate requirements based on the stability risk index.

[0178] It is understandable that risk assessment is the process of evaluating and quantifying identified risk indices. By assessing the probability and impact of risks, developers and testers can determine the stability risk level of requirements and provide a basis for subsequent risk handling. This invention calculates the stability risk index of requirements based on the impact of test cases and defects on the stability risk index from multiple dimensions. Utilizing this stability risk index can help developers and testers conduct better risk assessments.

[0179] Specifically, as calculated from the aforementioned risk index, the stability risk index range for candidate requirements obtained from test cases and defect dimensions is as follows: The designers pre-defined multiple stability risk index ranges based on experimental and empirical data, with each range corresponding to a stability risk warning level, thus creating a correspondence table between the stability risk index and the stability risk warning level. After calculating the stability risk level of the candidate requirements, the stability risk warning level corresponding to the stability risk index was determined as the stability risk level of the requirement based on the correspondence table.

[0180] In some embodiments, the correspondence between the stability risk index and the stability risk warning level is shown in Table 5 below:

[0181] Table 5:

[0182]

[0183] According to Table 5, for risks with lower ratings (stability risk index at...), For risks with an internal stability risk warning level of Level 1, the option to accept the risk is available, and no immediate action is required to alter the likelihood or impact of the risk. Instead, preparations should be made to address the potential consequences of the risk. For risks with a medium rating (stability risk index at...), the option to accept the risk is available, and no immediate action is required to change the likelihood or impact of the risk. For risks with an internal stability risk warning level of Level 2, mitigation measures can be taken to reduce or eliminate the possibility or impact of the risk. For higher-rated risks (stability risk index at...),... For risks with an internal stability risk warning level of Level 3, avoidance may be an option; however, changes and adjustments to the project plan are necessary to reduce or eliminate the possibility of risk. For risks with an extremely high rating (i.e., a stability risk index of [missing information]), [the risk level is -] [missing information]. If the internal stability risk warning level is level four, you can choose to transfer the risk that has a significant impact to the outside.

[0184] For example, the stability risk index of candidate demand. According to the table showing the correspondence between the stability risk index and the stability risk warning level (as shown in Table 5 above), the stability risk index... Located in the range Within this framework, the second level in the stability risk warning level is determined as the stability risk level for candidate requirements.

[0185] In some embodiments, a stability risk index for candidate requirements is calculated based on the use case risk index and the defect risk index, including but not limited to the following steps S410-S440:

[0186] S410: If the response stability risk index is within the preset first stability index range, the first level is determined as the stability risk level of the candidate demand.

[0187] S420: If the response stability risk index is within the preset second stability index range, the second level is determined as the stability risk level of the candidate demand.

[0188] S430: The response stability risk index is within the preset third stability index range, and the third level is determined as the stability risk level of the candidate demand.

[0189] S440: The response stability risk index is within the preset fourth stability index range, and the fourth level is determined as the stability risk level of the candidate demand.

[0190] Specifically, after calculating the stability risk index of the candidate demand, the stability risk warning level (i.e., level 1, level 2, level 3 or level 4) corresponding to the stability risk index is determined as the stability risk level of the candidate demand according to the preset correspondence table between the stability risk index and the stability risk warning level. That is, in the correspondence table between the stability risk index and the stability risk warning level, the stability risk warning level corresponding to the stability risk index is determined as the stability risk level of the candidate demand.

[0191] S500: Generates a stability risk identifier corresponding to the stability risk level based on the stability risk level.

[0192] S600: Displays a stability risk indicator.

[0193] In this embodiment of the invention, the stability risk identifier is an identifier used to visually represent the stability risk level, thereby prominently reminding developers or testers of the stability risk level of the requirement through the visual stability risk identifier.

[0194] Specifically, after determining the stability risk level of the candidate requirements, a corresponding stability risk identifier is generated based on the stability risk level, and this identifier is displayed on the display device. It is readily understood that embodiments of the present invention can employ image generation technology, image processing technology, etc., to generate the stability risk identifier, and the identifier can be displayed at any suitable location on the display device to alert developers or testers.

[0195] In some embodiments, when the stability risk level of a candidate requirement is Level 1, a first stability risk identifier corresponding to Level 1 is generated, for example, generating... Figure 8 The first stability risk indicator is shown in a1, and the first stability risk indicator is presented.

[0196] In some embodiments, when the stability risk level of a candidate requirement is level two, a second stability risk identifier corresponding to level two is generated, for example, generating... Figure 8 The second stability risk indicator is shown in a2, and the second stability risk indicator is presented.

[0197] In some embodiments, when the stability risk level of a candidate requirement is level three, a third stability risk identifier corresponding to level three is generated, for example, generating... Figure 8 The third stability risk indicator is shown in a3, and the third stability risk indicator is presented.

[0198] In some embodiments, when the stability risk level of a candidate requirement is level four, a fourth stability risk identifier corresponding to level four is generated, for example, generating... Figure 8 The fourth stability risk indicator is shown in a4, and the fourth stability risk indicator is presented.

[0199] It is worth noting that, in the above embodiments, stability risk identifiers corresponding to the stability risk level of requirements are generated and presented. In practical applications, test risk warning identifiers corresponding to the test risk index of each requirement can also be generated and presented, as well as test use case risk warning identifiers and defect risk warning identifiers corresponding to the test use case risk index and defect risk index of each requirement. This allows for comprehensive monitoring of various risks of requirements and timely management of risks in requirements within the software version.

[0200] In summary, the multi-factor-based software requirement risk index calculation and risk management method provided by this invention obtains use case data and defect data corresponding to the requirements of a version, calculates the stability risk index of the requirement based on the use case data and defect data, determines the stability risk identifier of the requirement based on the stability risk index, and finally presents the stability risk identifier. In this way, the stability of the functionality and performance of the requirement can be monitored automatically and efficiently, enabling developers or testers to manage the stability of the functionality and performance of the corresponding requirement in a timely manner, ensuring that the development progress is not affected as much as possible, and improving the quality of software development.

[0201] Those skilled in the art will understand that the embodiments provided by this invention are merely illustrative. The order in which the steps in the methods of the embodiments are written does not imply a strict execution order and does not constitute any limitation on the implementation process. The order can be adjusted, merged, and deleted according to actual needs. Modules or sub-modules, units or sub-units in the apparatus or system of the embodiments can be merged, divided, and deleted according to actual needs. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. For another example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed.

[0202] Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented using software and a general-purpose hardware platform, or it can be implemented using hardware. Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. It should be understood that the storage medium can be flash memory, hard disk, optical disk, register, magnetic surface memory, removable disk, random access memory (RAM), CD-ROM, read-only memory (ROM), electrically programmable ROM, and electrically erasable programmable ROM, etc.

[0203] It should be noted that the above embodiments are for illustrating the technical concept and features of the present invention, and are intended to enable those skilled in the art to understand the content of the present invention and implement it accordingly. They should not be construed as limiting the scope of protection of the present invention. Those skilled in the art can understand that all or part of the processes of the above embodiments can be implemented by modifying the technical solutions described in the embodiments of the present invention, or by making equivalent substitutions for some of the technical features. It is understood that these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and should be considered as equivalent changes and modifications made based on the embodiments of the present invention, all of which should fall within the scope of the claims of the present invention.

Claims

1. A multi-factor based software requirement risk index calculation and risk management method, characterized in that, The method comprises: acquiring at least one requirement of a target version, wherein the target version is a version in a development state in one or more versions of a software project; acquiring use case data and defect data corresponding to a candidate requirement, wherein the candidate requirement is any one of the at least one requirement, the use case data comprises a test case and a state and a level of the test case, and the defect data comprises a defect and a state and a level of the defect; based on the use case data and the defect data, calculating a stability risk index of the candidate requirement, comprising: based on the use case data, calculating a use case risk index of the candidate requirement; based on the defect data, calculating a defect risk index of the candidate requirement; based on the use case risk index and the defect risk index, calculating a stability risk index of the candidate requirement, the stability risk index being a parameter representing functional and performance stability of the candidate requirement; based on the use case data, calculating a use case risk index of the candidate requirement, comprising: dividing the test cases in the use case data into a plurality of test case sets according to the levels of the test cases, one test case set comprising one or more test cases of a reference level; based on the states of the test cases in a candidate test case set, calculating a first total amount of work, the candidate test case set being any one of the plurality of test case sets; determining a first total amount of standard work of standard test cases in the candidate test case set according to the first total amount of work, wherein the standard test cases are test cases in the first standard state in the candidate test case set, and the first standard state is a state representing test case execution passing among the plurality of states of the test cases in the candidate test case set; based on the first total amount of work and the first total amount of standard work, determining a risk coefficient of the test cases of the reference level in the candidate test case set; based on the risk coefficients of the test cases of the reference level in all test case sets, calculating a use case risk index of the candidate requirement; based on the stability risk index, determining a stability risk level of the candidate requirement; based on the stability risk level, generating a stability risk identifier corresponding to the stability risk level, the stability risk identifier being an identifier for visually representing the stability risk level; presenting the stability risk identifier.

2. The method of claim 1, wherein, The method comprises: selecting one or more test cases in the first candidate state in the candidate test case set as candidate test cases, the first candidate state being any one of the plurality of states of the test cases in the candidate test case set; determine a first candidate workload corresponding to the first candidate state based on the first candidate state, wherein the first candidate workload represents man-hours required for performing all work items in a first candidate work stage, and the first candidate work stage is a time period from identifying the candidate test case to the candidate test case being in the first candidate state; multiply the number of the candidate test cases by the first candidate workload to obtain a total workload of the candidate test cases; add the total workloads of all test cases in the candidate test case set to obtain a first total workload.

3. The method of claim 1, wherein, determining a risk coefficient of a test case of a reference level in the candidate test case set based on the first total workload and the first standard total workload, including: dividing the first standard total workload by the first total workload to obtain a test progress value of the test case of the reference level in the candidate test case set; in response to the test progress value being within a first test threshold range, determining a first test risk coefficient as the risk coefficient of the test case of the reference level; in response to the test progress value being within a second test threshold range, determining a second test risk coefficient as the risk coefficient of the test case of the reference level; in response to the test progress value being within a third test threshold range, determining a third test risk coefficient as the risk coefficient of the test case of the reference level; in response to the test progress value being within a fourth test threshold range, determining a fourth test risk coefficient as the risk coefficient of the test case of the reference level.

4. The method according to any one of claims 1 to 3, characterized in that, calculating a test case risk index of the candidate requirement based on the risk coefficients of the test cases of the reference level in the test case set, including: obtaining a reference weight coefficient corresponding to the reference level of the test case in the test case set; multiplying the risk coefficient of the test case of the reference level by the reference weight coefficient corresponding to the reference level to obtain a test case risk index of the test case of the reference level; adding the test case risk indices of all the test cases of the reference level to obtain the test case risk index of the candidate requirement.

5. The method of claim 1, wherein, calculating a defect risk index of the candidate requirement based on the defect data, including: dividing the defects in the test case data into a plurality of defect sets according to the levels of the defects, and one defect set includes one or more defects of a reference level; calculating a second total workload based on the states of the defects in a candidate defect set, the candidate defect set being any one of the plurality of defect sets; determining a second standard total workload of a standard defect in the candidate defect set according to the second total workload, the standard defect being a defect in the candidate defect set in a second standard state or a third standard state, the second standard state and the third standard state being states representing defect repair closure and defect invalid closure in a plurality of states of the defects in the candidate defect set; determining a risk coefficient of a defect of a reference level in the candidate defect set based on the second total workload and the second standard total workload; The risk index of the candidate requirement is calculated based on the risk coefficients of the defects of the reference level in the set of all defects.

6. The method of claim 5, wherein, The second total work amount is calculated based on the states of the defects in the set of candidate defects, including: One or more defects in the set of candidate defects in a second candidate state are selected as candidate defects, the second candidate state being any one of the multiple states of the defects in the set of candidate defects; A second candidate work amount corresponding to the second candidate state is determined based on the second candidate state, wherein the second candidate work amount represents the man-hours required to perform all work items in a second candidate work phase, the second candidate work phase being a time period from identifying the candidate defects to the candidate defects being in the second candidate state; The total work amount of the candidate defects is obtained by multiplying the number of the candidate defects by the second candidate work amount; The second total work amount is obtained by adding the total work amount of all defects in the set of candidate defects.

7. The method of claim 5, wherein, The risk coefficients of the defects of the reference level in the set of candidate defects are determined based on the second total work amount and the second standard total work amount, including: The repair progress value of the defects of the reference level in the set of candidate defects is obtained by dividing the second standard total work amount by the second total work amount; In response to the repair progress value being within a first repair threshold range, a first repair risk coefficient is determined as the risk coefficient of the defects of the reference level; In response to the repair progress value being within a second repair threshold range, a second repair risk coefficient is determined as the risk coefficient of the defects of the reference level; In response to the repair progress value being within a third repair threshold range, a third repair risk coefficient is determined as the risk coefficient of the defects of the reference level; In response to the repair progress value being within a fourth repair threshold range, a fourth repair risk coefficient is determined as the risk coefficient of the defects of the reference level.

8. The method according to any one of claims 5-7, characterized in that, The risk index of the candidate requirement is calculated based on the risk coefficients of the defects of the reference level in the set of all defects, including: A reference weight coefficient corresponding to the reference level of the defects in the set of defects is obtained; The repair risk index of the defects of the reference level is obtained by multiplying the risk coefficient of the defects of the reference level by the reference weight coefficient corresponding to the reference level; The risk index of the candidate requirement is obtained by adding the repair risk indexes of all the defects of the reference level.

9. The method of claim 1 or 5, wherein, The stability risk index of the candidate requirement is calculated based on the use case risk index and the defect risk index, including: A use case weight coefficient corresponding to the use case risk index is obtained, and a defect weight coefficient corresponding to the defect risk index is obtained; The first risk index result is obtained by multiplying the use case risk index by the use case weight coefficient; The second risk index result is obtained by multiplying the defect risk index by the defect weight coefficient; The stability risk index of the candidate requirement is obtained by adding the first risk index result and the second risk index result.

10. The method of claim 9, wherein, The stability risk level of the candidate requirement is determined based on the stability risk index, including: In response to the stability risk index being located in a preset first stability index range, a first grade is determined as the stability risk grade of the candidate demand; In response to the stability risk index being located in a preset second stability index range, a second grade is determined as the stability risk grade of the candidate demand; In response to the stability risk index being located in a preset third stability index range, a third grade is determined as the stability risk grade of the candidate demand; In response to the stability risk index being located in a preset fourth stability index range, a fourth grade is determined as the stability risk grade of the candidate demand.

Images