The equivalence class division, boundary value analysis, scenario method, etc. that are often used in the testing process cannot cover all the requirements. We have talked about the rarely used causality diagram method before. Let’s talk about another one that is not often used. A familiar but very important test case writing method - the test outline method.
The test outline method is suitable for scenarios where there are multiple windows, each window has multiple actions, and each action is related to each other, such as a mobile phone case customization function.
Let's talk about the steps:
Outline
List each window and its actions.
There are 7 pages in total: the home page, the mobile phone brand and model selection page, the mobile phone case appearance selection page, and the successful submission page.
The actions on the home page include: online customer service, system instructions, and start customization.
Mobile phone brand and model selection page: submit, previous page, next page.
Case skin selection page: Submit, Previous, Next.
The actions for submitting a successful page include: returning to the home page and order list.
Instructions page: Return to the home page.
Online customer service page: Return to the home page.
Order List.
Draw a relational diagram
First, let's analyze the connection between windows in a graphical way:
Then write the test case according to the diagram, and use the diagram to find the connection between the windows more clearly, avoiding omissions and confusion.
By writing use cases, we found that use case 1 and use case 12, use case 2 and use case 11 can be combined, we can merge use case 11 and use case 12 into use case 1 and use case 2, the optimized use case is as follows:
When encountering such similar requirements in the usual testing process, you may write use cases according to your own feelings without analysis, but what I want to say is that if you write use cases without logic, it is easy to cause use cases to be missed or use cases are redundant. Only after the analysis can all possible situations be listed and redundant use cases removed.
Writing test cases in this way is cumbersome, but the logic is clear. If you encounter a more rigorous system and software, you still need to go through strict analysis to write test cases, otherwise it may cause losses.
I hope this article can help everyone~
Finally, I would like to thank everyone who has read my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, you can take it away if you need it:
These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey, and I hope it can help you! Partners can click the small card below to receive