Case design method based on agile test
By dividing the system into modules and designing test cases based on their weights, the system automatically executes and supplements tests for high-risk modules, thus solving the problem of uneven resource allocation in agile testing, improving testing efficiency and defect discovery capabilities, and optimizing the continuous delivery system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- TENTH RES INST OF TELECOMM TECH
- Filing Date
- 2026-03-03
- Publication Date
- 2026-05-12
AI Technical Summary
In agile testing, an imbalance in the allocation of testing resources leads to insufficient testing of critical business modules and excessive resource consumption in edge scenarios, creating a Pareto trap. The lack of scientific priority evaluation criteria results in a mismatch between testing depth and defect detection rate.
The system is divided into functional modules. The module weights are determined based on user frequency, code reusability, logical complexity, and R&D coding capabilities. Basic test cases are designed, and defects are automatically executed and recorded. Defect density and risk index are calculated. Test cases are added for high-risk modules, and iterative optimization is carried out until the risk index of all modules is less than the threshold.
By focusing testing resources on key modules, testing efficiency and defect discovery capabilities are significantly improved, resolving the conflict between quality and efficiency and providing a measurable optimization path for the continuous delivery system.
Smart Images
Figure CN122019393A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer software testing technology, and in particular to a test case design method based on agile testing. Background Technology
[0002] Against the backdrop of rapid iteration in internet technology, the software development industry is facing increasingly severe competitive pressure, placing higher demands on the speed of product value delivery and the efficiency of system iteration. As a key component of the agile development system, agile testing, with the dual goals of ensuring product quality and shortening delivery cycles, urgently needs to break through the limitations of traditional testing models. Current testing practices commonly suffer from quality risks caused by time compression, imbalanced allocation of testing resources, test coverage gaps caused by requirement changes, and systemic risks caused by defect propagation. Especially at the test case design level, due to the lack of scientific priority evaluation standards, a mismatch often occurs between test depth and defect detection rate: on the one hand, insufficient investment is made in testing critical business modules, while on the other hand, peripheral scenarios consume a large amount of testing resources, forming a Pareto trap in testing efficiency.
[0003] Therefore, it is necessary to improve one or more of the problems existing in the above-mentioned related technical solutions.
[0004] It should be noted that this section is intended to provide background or context for the technical solutions of this disclosure as set forth in the claims. The description herein does not constitute an admission that it is prior art simply because it is included in this section. Summary of the Invention
[0005] The purpose of this invention is to provide a test case design method based on agile testing, thereby overcoming, at least to some extent, one or more problems caused by the limitations and defects of related technologies.
[0006] This invention provides a test case design method based on agile testing, comprising: S1. Divide the system to be tested into different functional modules, and determine the weight of each functional module based on user frequency, code reusability, logical complexity and R&D coding ability. S2, design basic test cases for each functional module; S3 automatically executes test cases and records the number of defects and test cases for each functional module; S4. Calculate the defect density and risk index of each functional module based on its weight, number of defects, and number of test cases. S5, supplement test cases for functional modules whose risk index is higher than the threshold; S6, iteratively optimize S3-S5 until the risk index of all functional modules is less than the threshold.
[0007] In this invention, in step S1, when the test object is a functional module, each functional module is divided into multiple sub-functional units.
[0008] In this invention, in S1, the weights of each functional module are... It is expressed as follows:
[0009] in, Based on user usage frequency, For logical complexity, For code reusability, To develop coding capabilities.
[0010] In this invention, in S2, equivalence class partitioning, boundary value analysis, and scenario analysis are used to design basic test cases for each functional module.
[0011] In this invention, in S3, the process of executing test cases includes: the first round of automatically executing the basic test case set, and subsequent rounds executing only defect-related test cases, high-priority test cases of functional modules with defects, and supplementary test cases.
[0012] In this invention, in S4, the risk index of each module... It is expressed as follows:
[0013] in, For defect density, The mean defect density Standard deviation For weights.
[0014] In this invention, in step S5, at least one supplementary test case is used from the following methods: fuzz testing, penetration testing, error guessing, and exploratory testing.
[0015] In this invention, the threshold for execution in the m-th round is: .
[0016] In this invention, the number of supplementary test cases is expressed as follows: It is expressed as follows:
[0017] in, The number of defects. The mean defect density The number of basic test cases.
[0018] The technical solution provided by this invention may include the following beneficial effects: This invention presents a test case design method based on agile testing. It utilizes data analysis techniques to identify key test modules in a system, focusing test resources on these modules. At the implementation level, by analyzing historical test case execution and defect data, test cases are supplemented in a targeted manner, constructing a dynamic test case set. This effectively resolves the conflict between quality and efficiency in agile testing and provides a measurable implementation path for test optimization under a continuous delivery system. While ensuring a high defect detection rate, this application concentrates test resources on key modules, enabling resource reallocation and significantly improving testing efficiency and defect discovery capabilities. Attached Figure Description
[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.
[0020] Figure 1 A flowchart illustrating an exemplary embodiment of the present disclosure shows a test case design method based on agile testing; Figure 2 A flowchart illustrating a test case design method based on agile testing in yet another exemplary embodiment of this disclosure is shown; Figure 3 A schematic diagram of the structure of a test case design apparatus based on agile testing in an exemplary embodiment of this disclosure is shown; Figure 4 This diagram illustrates a computer implementation system for use case design based on agile testing in an exemplary embodiment of this disclosure. Detailed Implementation
[0021] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that this disclosure will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0022] Furthermore, the accompanying drawings are merely illustrative diagrams of embodiments of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities.
[0023] This example implementation first provides a test case design method based on agile testing. Please refer to [link / reference]. Figure 1 and Figure 2 This method may include: S1-S6. Specifically: S1. Divide the system to be tested into different functional modules, and determine the weight of each functional module based on user frequency, code reusability, logical complexity and R&D coding ability. S2, design basic test cases for each functional module; S3 automatically executes test cases and records the number of defects and test cases for each functional module; S4. Calculate the defect density and risk index of each functional module based on its weight, number of defects, and number of test cases. S5, supplement test cases for functional modules whose risk index is higher than the threshold; S6, iteratively optimize S3-S5 until the risk index of all functional modules is less than the threshold.
[0024] In this embodiment, data analysis techniques are used to identify key testing modules of the system, focusing testing resources on key tests of these modules. At the implementation level, by analyzing historical test case execution and defect data, test cases are supplemented in a targeted manner to construct a dynamic test case set. This effectively resolves the contradiction between quality and efficiency in agile testing and provides a measurable implementation path for test optimization under a continuous delivery system. This application, while ensuring a high defect detection rate, concentrates testing resources on key modules, thereby reallocating testing resources and significantly improving testing efficiency and defect discovery capabilities.
[0025] The specific process of each step in the above embodiments will be described below.
[0026] S1, Divide the software into functional modules and determine their weights.
[0027] Following the principle of grouping the same user story's workflow into the same functional module, the system was divided into different functional modules for system testing, such as a user management module, a query module, and a logging module. The user management module, query module, and logging module have the following user usage frequencies: f 1 = 60%, f 2=75%, f 3 = 80%, code reusability r 1 = 20%, r 2 = 30%, r 3 = 20%, logical complexity c 1 = 5 c 2 = 8 c 3=3, R&D coding capabilities s 1 = 50 s 2=40, s3=60, weight , respectively w 1 = 0.3 w 2 = 0.5 w 3 = 0.2, therefore the weight .
[0028] Among them, user usage frequency is obtained by statistical analysis of past user logs or communication with users, and the value is between 0 and 1; code reusability is obtained by the ratio of the number of lines of code that have passed the confirmed test to the total number of lines of code in the module, and the value is between 0.01 and 1; logical complexity is obtained by static code analysis tools such as Cobot, and the value is between 1 and 20; R&D coding ability is obtained by the review results of R&D experts on historical code, and the value is between 10 and 100.
[0029] For functional module testing, the functional module is divided into more granular sub-functions. For example, for the user management module, it is divided into more granular sub-functions such as adding users, editing users, assigning permissions, and logging in.
[0030] S2, build the basic use case set.
[0031] Use classic methods such as equivalence class partitioning, boundary value analysis, and scenario-based testing to design basic test cases for each module. For example, equivalence class partitioning (including normal and abnormal inputs), boundary value analysis (at least two), and scenario-based testing (covering 100% of common user scenarios along the user story path). For instance, for user login in user management, at least the following scenarios should be included: normal user login, abnormal user login (incorrect password), 200 user logins, 201 user logins, frequent logins locking users, and prolonged online inactivity.
[0032] S3 automates the execution of test cases.
[0033] Automated execution of test cases, recording the number of defects in each module. and the number of test cases The scope of test cases executed automatically in the first round is the basic test case set. Subsequent rounds only execute defect-related test cases, high-priority test cases of defective modules, and supplementary test cases.
[0034] For example, the number of defects found in the user management module, query module, and log module in the first round are as follows:
[0035] The number of test cases executed is as follows:
[0036] S4, Dynamic Evaluation.
[0037] Calculate the module defect density X and module risk index Z Dynamically assess the risk of insufficient test coverage.
[0038] Calculate the defect density of each functional module and functional module risk index Defect density of each functional module Risk index of each functional module , ,variance , This represents the module weight.
[0039] For example, the defect density of the user management module, query module, and log module. Defect density of each functional module Functional module risk index Risk index of each functional module , Weights of functional modules, mean ,variance .
[0040] S5, Use Case Supplement.
[0041] For functional modules with a risk index exceeding the threshold, supplementary test cases are prepared using advanced testing methods such as fuzz testing and exploratory testing. The threshold should be adjusted accordingly based on the number of iterations; the threshold for the m-th iteration is... That is, the execution threshold in the first round. The threshold is 0.2, which is the execution threshold for the second round. The threshold is 0.4, which is the execution threshold for the third round. It is 0.8, and so on.
[0042] Therefore, when the test cases are executed in the first round, if the risk index of the user management module is... If the value is 0.42, then it is greater than the threshold. We need to use higher-order testing methods to supplement the test cases. The specific approach is as follows: Use fuzz testing to increase test data. For example, normal test data includes usernames consisting of Chinese characters, English letters, numbers, special symbols, and combinations of Chinese characters, English letters, numbers, and special symbols, and passwords consisting of English letters, numbers, special symbols, and combinations of English letters, numbers, and special symbols. Abnormal test data includes usernames that are empty, usernames that are all combinations of special characters, passwords that are empty, passwords that are case-sensitive, passwords that have extra spaces before or after them, and passwords that have extra special characters. Use exploratory testing methods to increase test scenarios, such as no user login system, no activated user login system, user login system without permission, locked user login system, expired user login system, and concurrent login by multiple users; Use penetration testing techniques to increase the number of test scenarios, such as SQL injection to input passwords, XSS attacks, etc. Use risk-based testing methods to increase test scenarios, such as login from different IP addresses or login from unbound terminals; Use the error guessing method to increase the number of test scenarios (abnormal operation scenarios with a high probability), such as the same user logging in on different terminals, logging in when the browser version is too low, or logging in when using a non-mainstream browser.
[0043] Maximum number of supplementary use cases According to the formula The calculation means that a maximum of 40 entries can be added.
[0044] S6, iterative optimization.
[0045] The test cases are executed automatically in a loop, and advanced testing methods are used to supplement the test cases for modules with risk indices greater than the threshold, until the risk indices of all modules are less than the threshold.
[0046] For example, after adding 28 test cases to the user management module, the number of defects found in each functional module during the second round of testing was [number missing]. Number of test cases executed Defect density of each functional module Defect density of each functional module Functional module risk index Risk index of each functional module , , ,variance The requirement is that the risk index of all functional modules is less than the threshold. As required, the iteration ended, resulting in the final version of the test cases.
[0047] It should be noted that for the testing of this system, subsequent rounds will only execute defect-related test cases and high-priority test cases of modules with defects.
[0048] This invention provides a test case design method based on agile testing. It is an agile test case design methodology based on the Pareto principle (80 / 20 rule). This method uses data analysis techniques to identify key test modules of the system, focusing 80% of testing resources on the critical paths that generate 80% of defects. At the implementation level, by analyzing historical test case execution and defect data, test cases are supplemented in a targeted manner to build a dynamic test case set. This effectively resolves the contradiction between quality and efficiency in agile testing and provides a measurable implementation path for test optimization under a continuous delivery system.
[0049] In this embodiment of the invention, by dividing the software into functional modules and determining their weights, test cases are designed for each functional module using classic methods such as equivalence class partitioning, boundary value analysis, and scenario analysis. Test cases are executed automatically, and the number of defects Q and the number of test cases K for each module are recorded. The defect density and risk index of each module are calculated. For modules with risk indices greater than a threshold, advanced testing methods such as fuzzy testing and exploratory testing are used to supplement test cases. The process of automatically executing test cases and supplementing test cases for modules with risk indices greater than the threshold is repeated until the risk indices of all modules are less than the threshold. This adjusts the testing focus and reallocates testing resources, aiming to concentrate testing resources on key modules while ensuring a high defect detection rate, thereby significantly improving testing efficiency and defect discovery capabilities.
[0050] This disclosure also provides a test case design apparatus based on agile testing. Please refer to... Figure 3 and Figure 4 ,include: The functional module division unit 101 is used to divide the system under test into different functional modules and determine the weight of each functional module based on user frequency, code reusability, logical complexity and R&D coding ability. The basic test case design unit 102 is used to design basic test cases for each functional module. The test case execution unit 103 is used to automatically execute test cases and record the number of defects and test cases for each functional module. The calculation unit 104 is used to calculate the defect density and risk index of each functional module based on the weight, number of defects and number of test cases of each functional module. Test case supplement unit 105 is used to supplement test cases for functional modules whose risk index is higher than the threshold. Optimization unit 106 is used to iteratively optimize test case execution and test case supplementation until the risk index of all functional modules is less than the threshold.
[0051] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.
[0052] It should be noted that although several modules of the system for executing actions are mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more modules described above can be embodied in one module. Conversely, the features and functions of one module described above can be further divided into multiple modules for embodiment. Components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the present invention according to actual needs. Those skilled in the art can understand and implement this without any inventive effort.
[0053] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims. All of these forms are within the protection scope of the present invention.
Claims
1. A test case design method based on agile testing, characterized in that, include: S1. Divide the system to be tested into different functional modules, and determine the weight of each functional module based on user frequency, code reusability, logical complexity and R&D coding ability. S2, design basic test cases for each functional module; S3 automatically executes test cases and records the number of defects and test cases for each functional module; S4. Calculate the defect density and risk index of each functional module based on its weight, number of defects, and number of test cases. S5, supplement test cases for functional modules whose risk index is higher than the threshold; S6, iteratively optimize S3-S5 until the risk index of all functional modules is less than the threshold.
2. The test case design method based on agile testing according to claim 1, characterized in that, In S1, when the test object is a functional module, each functional module is divided into multiple sub-functional units.
3. The test case design method based on agile testing according to claim 1, characterized in that, In S1, the weights of each functional module It is expressed as follows: in, Based on user usage frequency, For logical complexity, For code reusability, To develop coding capabilities.
4. The test case design method based on agile testing according to claim 1, characterized in that, In S2, equivalence class partitioning, boundary value analysis, and scenario analysis are used to design basic test cases for each functional module.
5. The test case design method based on agile testing according to claim 1, characterized in that, In S3, the process of executing test cases includes: the first round automatically executes the basic test case set, and subsequent rounds only execute defect-related test cases, high-priority test cases of functional modules with defects, and supplementary test cases.
6. The test case design method based on agile testing according to claim 1, characterized in that, In S4, the risk index of each module It is expressed as follows: in, For defect density, The average defect density. Standard deviation, For weights.
7. The test case design method based on agile testing according to claim 1, characterized in that, In S5, at least one supplementary test case is used from the following methods: fuzz testing, penetration testing, error guessing, and exploratory testing.
8. The test case design method based on agile testing according to claim 1, characterized in that, The threshold for execution in the m-th round is .
9. The test case design method based on agile testing according to claim 1, characterized in that, Number of supplementary test cases It is expressed as follows: in, The number of defects. The average defect density. The number of basic test cases.