How to design test cases

1、 Test case design

1.1、 Determine test scope

1、 There must be a complete requirements document

2、 Requirements have been reviewed and clarified

3、 There must be a complete list of functions

1.2、 Use case design principles

1、 follow “ The boundary value ” The principle of full coverage

2、 follow ” Equivalence class partition scenario “ The principle of full coverage

3、 follow ” The test case path is unique “ principle

When there are multiple paths , You need to create a new use case to cover . A use case covers only one test point . Reduce the risk of missing measurements .

4、 follow “ Single use case coverage is minimized ” principle

If you want to test a function A, It has three sub function points A1,A2 and A3, There are two ways to design test cases ：

Method 1： Cover three sub functions with one test case - TestA1A2A3

Method 2： Three separate use cases are used to cover three sub functions - TestA1,TestA2,TestA3

Method 2 Followed “ Single use case coverage is minimized ” principle , benefits , When the use case execution fails , Reduce recurrence / Positioning complexity

5、 follow “ Minimum coupling between test cases ” principle

（1） Use the results of the previous test case carefully , As input for the next test case .

（2） Every test case , Should be completely independent .

The advantage of this is that it is easy to pull test cases 、 Reuse 、 Maintainable 、 Reduce subsequent input costs .

1.3、 Use case design dimension

1、 function

（1） positive （ normal ） scene

（2） reverse （ abnormal ） scene

2、 Non functional

（1） performance

Performance testing , First of all, we need to have specific 、 Clear performance index requirements .

Performance focus indicators ：CPU、Memory、IO、 Network transmission rate, etc .

a. Item （ modular ） performance , such as SDK、 Algorithm 、 Individual performance requirements

b. Overall performance , Performance requirements after system integration

c. Network transmission performance

（2） reliable （ Stable ） sex

a. Time dimension

b. Load stability

（3） Robustness,

a. watchdog

b. Abnormal power failure

c. Restart again and again

（4） Ease of use

a. Ease of installation

b. O & M ease of use

c. Functional ease of use

（5） customer experience

For example, video playback effect 、 Whether the operation is smooth 、 Startup time, etc .

（6） Security

a. Data storage security

b. Network transmission security

2、 Test case writing

2.1、 Test case writing premise

1、 The test scope has been determined

2、 The test points have been sorted out

3、 Use case transformation path ： Business needs - functional requirement - Test requirements - Test point - The test case

2.2、 Use case title

Outline the main content of the test case , Clarify the use case test intent

1、 The language is simple , Clarify what this use case does

2、 A complete sentence

3、 follow “ Conditions / action " The rules

2.3、 Use case level distribution

1、Lve 1： basic （～10%）

System basic function use cases , It can be used for smoke test during version submission , It can be used as the basis for whether the version passes the transfer test and business acceptance .

Basis of division ： The failure of the execution of this use case will lead to the failure of many important functions .

for example ： Switchgear 、 Upgrade, etc. .

2、Lve 2： important （～20%）

Important functional use cases in the system .

Basis of division ： It mainly includes some functions related to interaction 、 Various application scenarios 、 Normal function test cases that are frequently used by customers .

for example ： Equipment report 、 Video playback effect 、 Preview and other functions .

3、Lve 3： commonly （～60%）

General functions of the system .

Basis of division ： General functional use cases , Test cases including exception paths ; The frequency of use is lower than 2 Level use cases .

for example ： Form input boundary value 、 Verification of special characters, etc .

4、Lve 4： Obscure （～10%）

There are generally few use cases at this level . It is mainly some functions that are rarely used . If the use case execution fails , Test cases that will not cause too much harm to the system and business .

Basis of division ： This use case corresponds to the less common preset conditions and data settings .

for example ： Logging errors, etc .

2.4、 Preset conditions

1、 Key prerequisites for executing test cases

2、 Let the executor of the use case know more about the current state of the system

3、 Preset conditions cannot block the execution of test cases

2.5、 Operation steps

1、 It needs to be clear “ Test key inputs ” data

2、 The operation path is unique , If it is not unique, multiple use cases cover （ To reduce the coupling ）

3、 With “ Process oriented ” Write in the form of

（1） The process description is accurate 、 unambiguous .

（2） The context must be consistent .

benefits ： Reduce execution costs 、 Reduce the cost of subsequent maintenance

2.6、 Expected results

1、 Each step of operation has corresponding expected results

2、 The expected result must be objective 、 Decidable

（1） That is to say, the correctness of test execution results can be determined , Each test case should have the corresponding expected results .

（2） The expected results prohibit the use of correct , normal , Vague subjective words like mistakes .

3、 The expected result must meet the demand

4、 The expected result must be certain

For the same test case , The execution results of the system should be the same 、 affirmatory .

3、 Test case review

3.1、 Before review

1、 Make the review object familiar with test cases in advance

2、 Talk about requirements in reverse

3、 Clarify the final test scope

3.2、 Under review

1、 test

（1） Explanation of test cases .

（2） Once again, make a deep understanding of the requirements .

2、 Development

（1） From the perspective of development and coding , Check whether the test case is missing .

（2） From the perspective of code implementation , Provide suggestions on the internal association logic of the module .

3、 The product manager

（1） Check whether the test case scenario meets the business requirements .

（2） Provide suggestions for test cases from the customer's point of view .

3.3、 After review

1、 Send and file review minutes

2、 Update test cases according to review recommendations

Learning resource sharing

Finally, thank everyone who reads my article carefully , Watching the rise and attention of fans all the way , Reciprocity is always necessary , Although it's not very valuable , If you can use it, you can take it

These materials , For those who want to engage in 【 software test 】 For our friends, it should be the most comprehensive and complete war preparation warehouse , This warehouse also accompanied me through the most difficult journey , I hope it can help you ！ You can get it for free by joining our communication group below , I hope that's helpful …….