Notes on writing test points in mind mapping

1、 Distinguish between test points and use case steps

Let's take an example ：

Here are two different descriptions of the same test purpose .

Obviously , The above description , We can see at a glance that the purpose of testing is to verify 「 Set to star 」 The function of , The second description , Of course, you can also know the purpose , But too many steps will make the readability greatly reduced .

The first description is closer to the concept of test point , The second description is to soften all the relevant contents of the test case into one sentence , If so , Use mind maps and Excel There's no difference , Instead, Excel Split the different parts to make it clearer .

Of course , Use the second way , One of the benefits is that it can be described as brainless , Friendly to new people , alike , For others, the purpose is complicated and unclear , Therefore, the first description method is recommended for this purpose , If you feel that you don't know how to operate in the process of use case execution , You can put the operation steps into the node notes .

remember , Try not to write use case steps into test points , Try to highlight the purpose of the test .

2、 Distinguish between conditions and classifications

Let's continue with the example ：

As you can see from the picture above , The way 1 And way 2 All of them are classified , But the standard of classification is different , The way 1 It's classified by different entrances , The way 2 It's refining , The standard of classification is 「 Different entrances 」.

I prefer the second way , The first kind of classification , In fact, it's still conditional classification , The execution of the following use cases , Can't do without the description of the previous node / Front operation , If you remove the previous conditions , The purpose of the test will be completely different .

The logic of this example is simple , You may not realize the obvious difference between the two ways , actually , If there are many conditions , By way 1 It goes on like this , It's going to be me in the end 《 Mind maps are two formats for writing test cases 》 The first kind of conditional partition is mentioned in , This is not in line with our original intention .

in general , The condition belongs to the pre operation , Is part of the regular test case format , However, it is not recommended as a classification standard for test points , Classification is to make the test points look more organized , So the classification standard should be refined 、 A general description , That's the way in the picture above 2 The way ;

Of course , In some places where the logic is relatively simple , This line will be ambiguous , Then we should continue to select the classification conditions based on the principle of practicality .

3、 Distinguish between operational association and logical association

Let's start with a requirement description ：

There is a child check box setting item ：
When the female check box is not checked , All corresponding functions are turned off ;
When the female check box is checked , Need to refer to sub check box status , When the sub check box is checked , The corresponding function is on , When the sub check box is not checked , The corresponding function is off ;

Here are the test points written in two different ways for this description ：

You can see it , The obvious difference between the two methods is when verifying the state of the sub check box , Whether you want to add the status description of the female check box in the test point description , My advice is not to bring , Recommended use 2.

This is a use case for the presentation layer , That is to say, the use case execution can only be completed through user scenario operation , Then, to check or not to check the sub check box , Be sure to check the parent check box first , That is to say, it's a default premise , And for this test point , This step is not part of the purpose of the test , So I think we can omit , Of course , You can put it in the node notes as a test step .

If this is a test point in the logical layer , For example, if it is verified by the registry value , We need to treat them differently , Because the condition of logic layer can be simulated , That is to say, you can simulate that the corresponding registry value of the parent check box is not checked , At the same time, set the status registry value of the sub check box to check , The purpose of the test can be achieved , But whether it is necessary to do so is another matter .

Therefore, logical layer verification and presentation layer verification should be treated differently , Verification for the presentation layer associated with operations , Unnecessary operation descriptions can be omitted , For logical layer verification with logical association , Then we need to make clear the purpose of the test, and then determine whether the related operation can be omitted .

4、 The premise of writing test points

Since we're talking about writing test points , Instead of detailed test cases , So we have an implicit premise , Is the person who writes the test point and executes the test , Be very clear about the needs , If you ignore this premise , The test points we wrote are very clear , But the readability will be poor .

When a project has participants who are only performing roles , The explanation of test points can be improved by adding notes of test points , Depending on the ability to participate in the role , The level of detail can be adjusted accordingly , Of course , It's best to let the people involved in the project clearly understand the requirements and the purpose of testing as much as possible .

above , On the basis of last time , This paper explains the way to write test points in mind map , I don't know if you encounter similar problems in the process of implementation , How to solve it ？ Welcome to leave me a message about your thoughts .