三、 圈复杂度

　　有了控制流图以后，很自然地，我们要知道我们到底要写几个测试用例，才能来满足基本路径测试。

　　当大家看到上面介绍的控制流程图的时候，学过离散数学或者是数据结构的人，我想都是会有很一种很熟悉的感觉，不错，控制流程图就是来源于图及有向图（这会不会再一次让大家感觉到数学对我们的重要性呢？）下面我就介绍一下新的概念——圈复杂度。

　　圈复杂度是一种为程序逻辑复杂性提供定量测试的软件度量。将该度量用于计算程序的基本独立路径数目。为确保所有语句至少执行一次的测试数量的上界。

　　公式圈复杂度V（G）=E-N+2，E是流图中边的数量，N是流图中结点的数量。

　　公式圈复杂度V（G）=P+1 ，P是流图G中判定结点的数量。

　　通俗的说圈复杂度就是判断单元是不是复杂，是不是好测试的标准。一般来说如果圈复杂度如果大于20就表示这个单元的可测试性不好，太复杂

　　从图中我们可以看到：

　　V（G）=10条边-8结点+2=4

　　V（G）=3个判定结点+1=4

　　上图的圈复杂图是4。这个结果对我们来说有什么意义呢？它表示我们只要最多4个测试用例就可以达到基本路径覆盖。

　　四、 程序基本路径

　　现在我们知道了起码要写4个测试用例，但是怎么设计这4个测试用例？导出程序基本路径，根据程序基本路径设计测试用例子。

　　程序基本路径：基本独立路径就是从程序的开始结点到结束可以选择任何的路径遍历，但是每条路径至少应该包含一条已定义路径不曾用到的边。（看起来不好理解，让我们看例子）。

　　让我们看上面的流程图：从结点4到24有几条路径呢？很明显：

　　A 13->35

　　B 13->15->17->35

　　C 13->15->23->29->33->13->35

　　D 13->15->23->25->33->13->35

　　还有吗？

　　E 13->15->23->29->33->13->15->17->35算吗？

　　不算，为什么？因为上面的4条路径已经包括了所有的边。第5条路径已经不包含没有用过的边了。所有的路径都遍历过了。

　　好了，现在我们有了4条基本独立路径根据独立路径我们可以设计测试用例。

　　A 13->35

　　输入数据： flag=0，或者是flag<0的某一个值。

　　预期结果： temp=0.

　　B 13->15->17->35

　　输入数据： count =1; flag=0

　　预期结果： temp=101.

　　C 13->15->23->29->33->13->35

　　输入数据： count =1;flag=1

　　预期结果： temp=10.

　　D 13->15->23->25->33->13->35

　　输入数据： count =1; flag=2

　　预期结果： temp=20.

　　上面的测试用例还可以简化吗？当然可以

　　来看 路径 A 13->35和 C 13->15->23->29->33->13->35，路径1是路径4的真子集，所以1是可以不必要的。上图的圈复杂度是4。这个结果对我们来说有什么意义呢？它表示我们只要最多4个测试用例就可以达到基本路径覆盖。所以说圈复杂度标示是最多的测试用例个数，不是一定要4个测试用例才可以。不过有一点要申明的是测试用例越简化代表你的测试越少，这样程序的安全性就越低了。

　　接下来的任务就是根据我们的测试用例来使用测试工具进行测试了。

　　五、 小结

　　到这，单元测试的基本路径法已经简单的给大家介绍了一下，一个完整的测试是多种测试方法结合在一起进行的。另外，我还想说的一点就是，无论你设计多少测试用例，无论你运用了多少种的测试方法，也不管你的测试方案是多么的完美，你都不可能100%的发现所有的BUG，我们进行测试，要做的就是用最少的资源，做最多的测试检测，来让程序尽可能少的出现BUG。还有一点就是，穷举测试是最有效的，但是那是不可能的，这也是我们这个基本路径法运用这么广泛的一个原因。