如果想让本方法很好的用在实际的工作中,那么流程就必须明确的规范的（就是有画出相应业务或者功能走向图）,这样就可以极大的加快了用例编写的速度和质量，但是如果碰到没有明确流程图的时候，可能会花不少的时间去捉摸功能点的流程走向问题，这又让工作进度慢了下来（流程不明确是因为需求没有明确表述和设计没有相应流程描述）,所以在实际工作中想使用这种方法来加快和改进测试用例的进度和质量，还要说服项目组尽可能的规范需求和设计的文档规范性，毕竟软件质量的控制不是我们一组人就能做到的。

拿到这个流程时，第一眼看上去，是不是有点晕晕的呢，确实如此，因为这不能称为标准的流程图，我们需要做一些改进，不妨事先约定，画流程图时，在有判定条件处，Y就往下走，而N就往左走，以下是简化后的流程：

上面这个流程图看上去是不是清晰很多,确实如此,从心理学的角度来讲,正常人的思维是很难接受一个横向很复杂的事物.而且上面的流程图也更规范一点,所以建议大家以后这样画流程图.下图是作进一步的改进:

这个流程图是不是更方便你设计用例呢,尤其是用路径分析法,是不是很方便就能找出其中的路径.