引子

　　一般的业界认为，80%的缺陷将会在单元测试阶段（Unit Test）被发现并解决，而系统集成测试（SIT）只能发现总缺陷数的15%，最终在客户验收测试（UAT）只会发现少于5%的缺陷，而这3个阶段修改的成本也是成几何级数增长，比如在单元测试阶段花1块钱能修复的缺陷，到了系统集成测试阶段就需要至少10块钱，因为经过测试人员的发现，开发人员确认修复，最后测试人员的关闭，经历了一系列的流程，成本自然会很高，至于到了客户验收测试的时候，除去了修改缺陷，内部回测以外，大量缺陷往往会遗失客户的信心，危害巨大。于是本文将着力介绍单元测试，希望对广大开发人员有所帮助。

　　关键字

　　单元测试，系统集成测试，用户接收测试

　　单元测试的定义

　　单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把在出生日期的输入框中输入”我爱方正”，那么我们的程序需要截获这样的异常，并在页面给与客户友好的提示信息。

　　单元测试通常是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

　　工厂在组装一台电视机之前，会对每个元件都进行测试，这，就是单元测试。

　　其实我们每天都在做单元测试。你写了一个函数，除了极简单的外，总是要执行一下，看看功能是否正常，有时还要想办法输出些数据，如弹出信息窗口什么的，这，也是单元测试，我们把这种单元测试称为临时单元测试。只进行了临时单元测试的软件，针对代码的测试很不完整，代码覆盖率要超过70%都很困难，未覆盖的代码可能遗留大量的细小的错误，这些错误还会互相影响，当BUG暴露出来的时候难于调试，大幅度提高后期测试和维护成本，也降低了开发商的竞争力。可以说，进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。

　　对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。

版权声明：原创作品，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。本文出自风过无息的51Testing软件测试博客：http://www.51testing.com/?3528

　　为什么要使用单元测试

　　我们编写代码时，一定会反复调试保证它能够编译通过。如果是编译没有通过的代码，没有任何人会愿意交付给自己的老板。但代码通过编译，只是说明了它的语法正确；我们却无法保证它的语义也一定正确，没有任何人可以轻易承诺这段代码的行为一定是正确的。

　　幸运，单元测试会为我们的承诺做保证。编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。有了单元测试，我们可以自信的交付自己的代码，而没有任何的后顾之忧。

　　什么时候测试？单元测试越早越好，早到什么程度？XP开发理论讲究TDD，即测试驱动开发，先编写测试代码，再进行开发。在实际的工作中，可以不必过分强调先什么后什么，重要的是高效和感觉舒适。从我们的经验来看，先编写产品函数的框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码，每写一个功能点都运行测试，随时补充测试用例。所谓先编写产品函数的框架，是指先编写函数空的实现，有返回值的随便返回一个值，编译通过后再编写测试代码，这时，函数名、参数表、返回类型都应该确定下来了，所编写的测试代码以后需修改的可能性比较小。

　　由谁测试？单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。测试部门可以作一定程度的审核。

　　单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行维护。

　　经常与单元测试联系起来的另外一些开发活动包括代码走读（Code review），静态分析（Static analysis）和动态分析（Dynamic analysis）。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。