单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。下面我们一起来看，彻底测试的方法。
1、彻底测试的可能性
有一种说法是，“测试总是不彻底的”，对于软件整体来说，要做到彻底测试确实很难，但对于局部代码，则是完全可能的。先说 “理想的彻底测试”，对于一段程序，比如一个函数，如果它的所有可能输入都测试过，并且都没有错误，那么可以肯定，这个函数是没有错误的，这就是 “理想的彻底测试”。“理想的彻底测试”是做不到的，有没有 “现实的彻底测试”？有！“现实的彻底测试”就是所有的等价类都经过测试。
先说说等价类。“类”是指把输入数据分组，“等价”是指测试效果上的等价，“等价类”就是在一组输入数据中，任取一个进行测试，如果测试通过，那么，可以认为同组的其他输入数据也可以测试通过，也就是说，测试了一个，就等于测试了一组。如果把所有的等价类都找出来进行测试，就相当于所有输入都经过测试，这就是“现实的彻底测试”。
对于一段程序来说，“等价类”通常是有限的，因此，从理论上来说，对局部代码进行“现实的彻底测试”是完全可能的。
2、等价类划分的基本方法
通常从三个方面考虑程序的输入：正常输入，边界输入，非法输入。
正常输入：例如字符串的Trim函数，功能是将字符串前后的空格去除，那么正常的输入可以有四类：前面有空格；后面有空格；前后均有空格；前后均无空格。
边界输入：上例中空字符串可以看作是边界输入，如果输入是一个指针的话，空指针也算是边界输入。再如一个表示年龄的参数，它的有效范围是0-100，那么边界输入有两个：0和100。
非法输入：非法输入是正常取值范围以外的数据，或使代码不能完成正常功能的输入，如上例中表示年龄的参数，小于0或大于100都是非法输入，再如一个进行文件操作的函数，非法输入可能有：文件不存在；目录不存在；文件正在被其他程序打开；权限错误。
一般情况下，只要考虑：有哪些正常输入？有哪些边界输入？有哪些非法输入？就可以找出大多数等价类，例如，一个函数，功能是把小写金额转换成大写，输入是小写数字，输出是大写金额，那么：
正常输入有：只有整数，只有小数，既有整数又有小数
边界输入有：整数部分很大，0.0，小数位数超过两位
非法输入有：空串，非数字，负数
“等价类”这个词是从测试的角度来说的，从开发的角度来看，“等价类”与“功能点”具有对应关系，例如，字符串的Trim函数，功能点有：
如果只有左边有空格，返回删除左边空格后的结果(等价类：左边有空格)；
如果只有右边有空格，返回删除右边空格后的结果(等价类：右边有空格)；
如果两边都有空格，返回删除两边空格后的结果(等价类：两边有空格)；
如果两边都没有空格，返回原串(等价类：两边无空格)；
如果是空串，直接返回(等价类：空串)；
如果是空指针，直接返回(等价类：空指针)；
……
一个“等价类”对应程序的一个“功能点”，如果程序的所有功能点都正确实现了，那么这个程序的功能就肯定没问题。程序员在写代码时肯定要想清楚程序的主要功能点，否则代码无从写起，因此，如果程序员边编码边测试的话，大部分等价类都是现成的。如果由测试部门做单元测试，测试部门只能依据设计文档来测试，设计文档也会规定程序的功能，要不然就无从测起，同样可以说大部分等价类是现成的。
3、彻底测试的基本思路
前面说过：如果把所有的等价类都找出来进行测试，就相当于所有输入都经过测试，这就是“现实的彻底测试”。
如何把所有的等价类都找出来？根据程序的功能，大部分等价类都是容易想到的，甚至是现成的，但是，如何衡量是否完整？例如，前面所举的两个例子：删除字符串两边空格的函数和将金额小写转大写的程序，我们可以肯定，等价类最多也就十几个，相当有限，但是，已经列出的等价类是完整的吗？有没有遗漏的？
要找出所有等价类，关键是要有衡量完整性的指标。等价类实际上就是程序的功能点，程序的功能是人为规定的，很难衡量完整性，但白盒测试却很容易衡量完整性，因此，我们可以考虑使用白盒测试的覆盖率来衡量测试完整性。
看一下这个简单的例子：
- void Func(int* p)
- {
- if(p)
- {
- *p = 0;
- }
- else
- {
- return;
- }
- }
参数p是一个指针，测试时当然要将空指针作为一个等价类，如果漏了这个等价类，会怎么样呢？分支覆盖会不完整：else分支未覆盖。从这个例子可以看出，未覆盖的逻辑单位通常对应未测试的等价类，因此，白盒覆盖可以衡量等价类是否完整。
还是上面的例子，假如程序员完全忘了有空指针这回事，把代码写成这样：
- void Func(int* p)
- {
- *p = 0;
- }
由于判断p是否为空指针的代码不存在，白盒覆盖当然不会提示说“某某代码或某某分支未覆盖”，因此，白盒覆盖不能发现“程序员未处理某些特殊输入”这种情形，也就是说，即便达到了***的白盒覆盖率，仍然不能保证找出所有等价类。
程序员会忘记处理哪些输入呢？常见的输入一般是不会记的，否则程序的起码功能都未实现，容易忘记的是一些“偏僻”的输入，例如，空指针、空字符串、很大的数、很小的数、合法取值边界附近的值等等，从输入的角度来看，这些特殊值通常跟数据类型有关，从程序的行为来看，这些特殊输入常常会导致崩溃、产生异常，或超时，即具有行为特征，正好是自动动态测试可以发现的，因此，我们可以利用自动动态测试来捕捉“程序员未处理某些特殊输入”形成的错误。
4、彻底测试方法
基于上一节的思路，经过长时间摸索和改进，我们提出了实现彻底测试的“三步法”：
1）根据代码的功能，人工设计测试用例进行基本功能测试；
2）统计白盒覆盖率，为未覆盖的白盒单位设计测试用例，实现完整的白盒覆盖，比较理想的覆盖率是实现100%语句、条件、分支、路径覆盖；
3）自动生成大量的测试用例，捕捉“程序员未处理某些特殊输入”形成的错误。
第1步的测试用例通常是现成的，因为详细设计文档会规定程序的基本功能，没有文档的，程序员在编程时也要想清楚程序的功能，这些基本功能就是基本测试用例；
第2步是在第1步的基础上，检查未覆盖的白盒单位，由于未覆盖的逻辑单位通常对应未测试的等价类，因此第2步可以找出第1步所遗漏的测试用例；
第3步用自动动态测试弥补第2步的固有缺陷。
“三步法”尽量避免重复工作，白盒方法和黑盒方法相结合，人工方法和自动方法相补充，如果第2步的覆盖率比较理想，那么基本上可以保证找出所有等价类。在开发过程允许的限度内，“三步法”已接近极限，当得起“彻底测试”四个字。
5、是否需要其他测试？
“三步法”使用了人工动态测试和自动动态测试，未使用人工静态分析和自动静态分析，要不要再使用这两种方法呢？这就要看合不合算了，毕竟项目时间和预算是有限的。
“三步法”的测试完整性是***的，读者可以比较一下，自己参与过的项目，所要求达到的覆盖率是怎么样的？做得比较好的，一般只是要求达到100%的代码覆盖，执行中还未必能做到，而“三步法”所要达到完整性是这样的：1)100%语句、条件、分支、路径覆盖；2)用自动动态测试捕捉未考虑某些特殊输入形成的错误。经过这种彻底测试后，遗留的错误可以说已经极少了。
自动静态分析只能发现语法特征错误，现代编译器对多数这类错误会给出警告，另外，现有的自动静态分析技术会产生大量的误报，在一大堆报告中去一条一条人工辨别，寻找遗漏的错误，无异于“大海描针”。人工静态分析也差不多。先做这两项又怎么样？显然也是没必要的。
为了统一代码风格，可以偶尔抽查代码，也就是说，可以用人工静态方法检查代码风格和编码规范。
原文链接：http://www.51testing.com/html/78/n-222978.html
【编辑推荐】
