Use Path Analysis to compile test cases

Anyone familiar with testing theory knows that path coverage is an important method in white box testing and is widely used in unit testing. So is the path-based coverage analysis method only applicable to unit tests? Can it be extended. Generally, in unit testing, a path refers to a branch of the Function Code. In fact, if we regard a process of the software system as a path, we will try to design test cases using path analysis. There are two advantages to using path analysis to design test cases: first, it reduces the difficulty of test case design. As long as you understand various procedures, you can design high-quality test cases, there is no need for much experience in testing. Second, you can select test cases in case of tight testing time, instead of making choices based on experience. The following describes how to use Path Analysis to compile test cases.

The first is to map the various processes involved in the system running process. You can start with the most basic process and abstract the process into sequential execution of different functions. The secondary or abnormal processes are considered on the basis of the most basic processes, so that various processes are gradually refined, which can gradually deepen the understanding of the process, you can also associate seemingly isolated processes. After all the processes are illustrated, all the paths are set.

After finding out all the paths, the following task is to set the priority for each path. In this way, you can first test the high priority and then test the low priority, when the time is tight, you can even consider ignoring some low-priority paths. Priorities are selected based on two principles: first, the frequency of path usage, the higher the priority, and second, the importance of the path. If the failure has a greater impact on the system, the higher the priority. Add the priorities obtained based on the two principles to get the priority of the entire path. Tests can be conducted in a more targeted manner based on the sorting of priorities.
　
After the priority is set for each path, the next task is to select test data for each path and construct test cases. One path can correspond to multiple test cases. When selecting test data, you can use the Boundary Value Selection and other methods to map the input and output of various test data in a table, this completes the design of the test case.

For testers, the design of test cases is very difficult. At the same time, the design of test cases is directly related to the design quality of the entire system. This article introduces a more theoretical design method to simplify this kind of work as much as possible. It extends the path analysis method generally used in unit testing to integration testing, system testing, and other subsequent testing processes, I hope to give you some inspiration. I will keep some of my feelings and Examples after this post.

If you want to make this method well used in actual work, the process must be clear and standardized (that is, you can draw a diagram of the corresponding business or function ), in this way, the speed and quality of case writing can be greatly accelerated. However, if there is no clear flowchart, it may take a lot of time to figure out the process of functional points, this slows down the work schedule (the process is not clear because the requirements are not clearly stated and the design does not have the corresponding process description ), therefore, in actual work, we want to use this method to speed up and improve the progress and quality of test cases, and persuade the project team to standardize the requirements and design documents as much as possible, after all, software quality control is not implemented by a group of people.

　

When we get this process, it looks a little dizzy at first glance. It is true, because it cannot be called a standard flow chart. We need to make some improvements. We may wish to agree in advance, when drawing a flowchart, when there is a judgment condition, go down and go to the left. The following is a simplified process:



The above flowchart seems to be much clearer. Indeed, from a psychological point of view, normal people's thinking is hard to accept a very complex thing. The above flowchart is more standardized, so we suggest you draw a flowchart like this later. It is for further improvement: Is this flowchart more convenient for you to design use cases? In particular, It is very convenient to find the path in path analysis.
 
 
Is this flowchart more convenient for you to design use cases! In particular, it is very convenient to find the path in path analysis.

Use Path Analysis to compile test cases