软件测试白盒测试之基本路径测试方法

在白盒测试中，基本路径测试方法当然是最优秀的一种测试方法，根据流程图画出控制流图，再画出控制流图的时候，我们要注意两点

一：＆＆和｜｜组合条件需要拆开，即改成单一条件

二：关于求解路径条数的时候，用判定点来算路径总数是有风险的

        1.else语句不存在 2.case 语句也称为判定点，是不稳定的，举个例子，case情况有很多且每种情况没有其他判定，这么算来，总的路径条数就会变少。 

        所以我建议大家还是使用数圈圈的个数即 N+1 或者也可以为 E-N+2 其中 E 为边的条数，N 为结点个数，两者的值是相等的。

      （关于case 如果把它描绘成各个判定点的话，也可以用判定点的个数+1 来进行计算得到，且由case得到的判定像是一个楼梯一样的判定哦！！！）

三：防止犯了先验性错误（极容易犯错，导致路径丢失）这也是我要在这边特别强调的（本人就是在这个问题上纠结了个把个小时，终于找出来了）

        为什么会有这种错误呢，因为我们在分析了程序之后，潜意识中把实际代码中，逻辑相互矛盾，不可能出现的路径给排除了！！！到后来会发现怎么总缺少一点。

   

       从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。从这里我们也可以看出一点，并不是每条测试用例会设计出一个测试用例！！！

       这么讲未必抽象了点，我来举一个今晚我做的实验吧，控制流图已经画出如下所示：

注意路径4 为 我一直被我潜意识排除的那条！！！

因为实际中，我们在设计路径的时候是不该考虑这种情景是否会出现的！！！

而且 我们也可也发现，白盒测试也是很脆弱的了，若没有 2 29 2001  本身这是不符合实际的，但若在白盒测试中没有用到这个用例，也是无法检测出错误来。所以现在业内有些人就开始发问，白盒测试是在浪费时间，它的功能完全可以用黑盒测试来取代，遗憾的是，到现在为止还没有被证明哈！

路径1：1-2-3-4-5-6-7-8-31-33

路径2：1-3-4-5-6-7-8-31-33

路径3：1-3-5-6-7-9-10-12-31-33

路径4：1-3-5-7-8-31-33

（注意：这条路径被我先验性得排除了，以至于一直少了一条，虽然不存在，但在设计用例的时候应该要考虑进去的）

路径5：1-3-5-7-9-10-12-31-32-33

路径6：1-3-5-7-9-10-11-31-32-33

路径7：1-3-5-7-13-16-31-32-33

路径8：1-3-5-7-13-14-15-31-32-33

路径9：1-3-5-7-17-18-19-31-32-33

路径10：1-3-5-7-17-18-20-21-22-31-32-33

路径11：1-3-5-7-17-18-20-21-24-31-32-33

路径12：1-3-5-7-17-18-20-23-21-22-31-32-33

路径13：1-3-5-7-17-18-20-23-21-24-31-32-33

路径14：1-3-5-7-17-18-20-23-24-31-32-33

路径15：1-3-5-7-25-26-27-28-31-32-33

路径16：1-3-5-7-25-26-27-29-31-32-33

路径17：1-3-5-7-25-26-30-31-32-33