杂集之软件测试之单元测试(控制流图)

一、 什么是单元测试
软件测试的方法有很多种，从不同的角度来看，也有不同德分类，若从一个软件开发的过程来看，一般把软件测试分成单元测试、集成测试、确认测试、验收测试、系统测试，可见，单元测试是软件开发过程中进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明某段代码的行为和我们期望的一致。
单元测试通俗的说就是一个实现简单功能的函数，用一组特定的输入(测试用例)测试函数的功能是否正常，并且返回了正确的输入。
二、 单元测试之基本路径法
单元测试的方法也有几种，我要介绍的是运用比较广泛的基本路径法。基本路径法事基于程序控制流程图(控制流程图和程序的语句可以说是对应)的一种对某段代码的各个执行路径一一进行测试的方法。所以，说到基本路径法就不得不先介绍一下程序控制流程图。
例：

注：上图是组成完整控制流图的几个基本的单元结构。
下面我给大家写一段程序，然后画出这个程序的控制流图
代码：

控制流图：

注: 图中的数字是指代的代码的行号。看到这个流图之后，大家多少会有点疑惑，图中的那些代码行号是怎么选择出来的，为什么要选择图中的那些呢？是这样的：
图中选择的行号的代码都是出现了选择分支，循环操作，判断等，顺序执行的语句可以合并成。这也是画控制流图的一般规则。
三、 圈复杂度
有了控制流图以后，很自然地，我们要知道我们到底要写几个测试用例，才能来满足基本路径测试。
当大家看到上面介绍的控制流程图的时候，学过离散数学或者是数据结构的人，我想都是会有很一种很熟悉的感觉，不错，控制流程图就是来源于图及有向图(这会不会再一次让大家感觉到数学对我们的重要性呢?)下面我就介绍一下新的概念——圈复杂度。
圈复杂度是一种为程序逻辑复杂性提供定量测试的软件度量。将该度量用于计算程序的基本独立路径数目。为确保所有语句至少执行一次的测试数量的上界。
公式圈复杂度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。还有一点就是，穷举测试是最有效的，但是那是不可能的，这也是我们这个基本路径法运用这么广泛的一个原因。