You must know how to simplify black box test cases

Previous articles have introduced several use-case designs for black-box testing, including equivalence class partitioning, boundary value analysis, error guessing, cause-and-effect diagrams, decision table-driven methods, orthogonal experimental designs, and functional diagrams.

The use case coverage rate designed by these methods is very high. Of course, there are too many use cases, which also means more workload. That's no problem. In the case of ensuring a certain coverage rate of use cases, we try to reduce our work as much as possible. To achieve the highest efficiency, for example, how to judge a large number of repeated use cases and invalid use cases. Today, I will talk about my thoughts on simplifying use cases. The

first is to combine repeated use cases. The so-called repeated use cases does not mean that many use cases are exactly the same, but Say that some use cases have the same checkpoints or influencing factors, the same operation steps, the use cases look like duplicate use cases, and for this case, it can be merged.

When the functions of the object parts are similar, the checkpoints and influencing factors are the same, and the operation steps are the same, the same parts can be merged. If the checkpoints and influencing factors are the same, the merging method is also the same. This simplified use case method is applicable to one operation step, and can check multiple checkpoints. If only the checkpoints are the same, but the steps are different, it is still not recommended. Merge

Next , delete the invalid use cases, find out the relevant checkpoints for the test object, and then start from the checkpoints to diverge the influencing factors. This use case method is a pure black box use case design method, but in many cases, the Not just a pure black box, but a gray box. The internal logic of the function is not black for us. After understanding the development and implementation, we will find that some of the influencing factors emanating from the pure black box are actually unnecessary and can be removed directly.

If the developer expresses that he uses the built-in window function of the system to draw, then these influencing factors need to be retained;
if the developer expresses that he draws by the window function he wrote himself, which will not adapt to the current situation of the system, then these influences There will be redundant factors, and system-related modifications will not affect the display of the self-drawing window.
If the developer said that he wrote the window function himself, but it will be adapted according to the system, then you need to know more about which situations will be adapted.

This way of simplifying use cases is to add, delete, and modify use cases according to the development and implementation. This degree depends on the progress of the development and implementation.

Therefore, if we want to efficiently complete app functional testing or other software functional testing, we not only need a suitable functional testing tool to assist, but more importantly, the design method of use cases, and simplifying use cases to help us test more efficiently.

TestBird - Automated testing platform for mobile games and apps