我觉得这种方法难就难在对流程的深刻剖析上，要滴水不漏的抓住所有引起分叉路径的要点，有些是很容易看出来的，有些则是隐藏较深的，如果对系统不是深刻理解，估计一时半会找不出来。还有输入的数据也很重要，因为各条路径均是由不同的数据驱动的，设计出好的数据可以提高效率。
对于复杂的系统测试流程的自动化，前期的录制，修改，调试的工作也是大的惊人啊，唉，由于团队小，以及对自动化软件不精通，一直不敢用啊。感觉弄不好效率会更低。
以上是本人的一点愚见。
[ Last edited by michelle_happy on 2005-7-1 at 13:58 ] 想覆盖所有路径挺困难的
这得需要对软件相当的了解了，否则很难做到的。
这个方法是不错。
还有个也是类的，假设一个流程的由功能A,B,C，串起来。你也可以这样入手，A的来源数据有那些，全部列出来，出口数据有那些，全部列出，（其余类似），这样的话也可以理清楚。但是这样有个不好的地方就是都是正常流程。我们测试过程中不金仅仅要考虑正常流程，也要考虑异常的流程，备选的流程。
不错,可惜
不错,要是能有个具体的例子就更好了! 个人感觉楼主的提议是个好方法但是不一定适用所有的软件
对强化流程的软件可以采用
但又不能是关系非常复杂的
像蜘蛛网结构的软件 偶是新人，很有收获
顶 关于如何很好的将基本路径法用到黒盒测试中,我曾经研究过很长一段时间,个人感觉,基本路径法可以很好的用在一些流程的测试中,尤其是办公自动化类的测试! 似的 方法选对了 就会少走很多弯路 我也在试着用这种方法写测试用例，基本上可以通过需求分析中的业务流程去设计我们的测试用例，但是也会碰到一些麻烦，比如说需求描述的不够清楚，我想去规范是有必要的，但是实际上往往会有许多事情是做不到的，那么我想及时跟写需求的人员进行沟通去解决这个问题也是一种办法，可能好的时间会多。但是毕竟漏掉的，或者说没有详尽描述应该是居于少数的，大部分的公司不是太有可能做到那么规范，能处处到位！这是我们应该要想办法去克服的问题！ 谢谢了~！~！！！ 想法的确不错，很有感触，如果能用一个例子说明将会更好 根据流程确定优先级 不错的想法， 楼主COPY我的文章，为什么不连同例子一起COPY过来让大家一起讨论讨论！
如想了解更多，就参看原文：http://community.hf-mstc.org/cs/forums/1228/ShowPost.aspx 谢谢! 谢谢sdlkfj2 这种测试方法我明白，也常用，但是如果设计用例采用那个用例模版好呢，很多不适合
测试方法我通常都会，但是一提到设计用例就没有思路了
谢谢指教 这就是系统测试用例设计方法中的流程分析法，这种方法的关键是从对应的需求规格项中抽象出业务的流程图，流程图只要包括3个部分，一是用户的操作(输入数据，确认等)，然后就是系统的对用户输入的反应了，再有就是一些条件的判断，只要搞清楚了这三部分内容就基本上可以画出业务流程图了，画好了流程图后就可以把所有的路径都确定出来，对于每一条路径使用等价类边界值等方法来确定测试数据，从而形成测试用例。
