单元测试的效益

　　1）保证代码质量：集成和系统测试无法完成代码单元的输入覆盖，未覆盖的输入可能隐藏大量细小的错误，只有单元测试可以解决这个问题。

　　2）降低排错成本：排错成本随时间的推移直线上升，把错误消灭在初生之时成本最低。

　　3）提高开发效率：代码单元在开始编写时，即可不依赖于其他代码单独运行，并展现其行为，可以集中思维，降低编程难度，大幅减少调试，提高生产率。

　　4）开发周期可控：即使代码按进度完成，未测试代码隐含的大量错误使产品稳定下来的周期远超预期，造成项目延期和成本高企。单元测试把难于计划的后期排错工作转换为可以计划的常规工作，避免把问题遗留并集中爆发。

　　5）修改自动回归：即使是最小修改也可能引入错误，单元回归测试可以自动检测，避免小量修改可能导致大量的系统级调试与测试。

　　6）解放核心产能：避免骨干成员陷入反复调试排错维护泥潭，专注于创造性工作。

　　7）改进绩效考核：用经过测试的合格代码量来衡量开发绩效，而不是质量未知的未测试代码。

　　总之，单元测试是高效的开发过程质量控制机制，可以帮助企业保证产品质量、降低成本、提高生产率、缩短开发周期、赢得市场先机，提升竞争力。

　　单元测试的目标

　　哪些代码占开发成本的大部分？函数，尤其是较复杂的函数，其编写调试排错占了整体开发成本的大部分，面向对象开发亦如此。单元测试所要解决的就是这些代码的质量和开发效率。单元测试的首要目标是：

　　1）对较复杂函数实现输入覆盖，保证其质量。

　　2）提高较复杂函数的开发效率，大幅减少调试，尤其是效率很低的嵌入式调试。

　　单元测试的基本方法

　　将输入分类（等价类），设定对应的正确输出，执行测试，由工具自动判断实际输出是否相符，这是单元测试的基本方法。

　　工具不可能自动了解程序的设计功能，因此，要达到起码的测试效果，用例必须由能够了解代码功能者人工设计，

　　自动生成用例是一个简单的技术，但只能作为一个补充。工具的价值在于完成太费人工和人工难于做到的工作，例如：解决可测性问题、生成驱动、桩、底层模拟、统计覆盖率、协助找出遗漏用例、自动判断测试结果、描述程序行为、生成测试报告等。

　　单元测试的难题

　　可测性差：高耦合造成的可测性差是单元测试第一难题。不幸的是，程序是客观事物的反映，客观事物本来就互相关联、互相纠缠，代码之间的大量耦合无法避免。

　　失真：作为基本测试技术，自动打桩通常是不得已的选择，必然造成失真，使测试难于进行。

　　不可控：底层代码包括平台代码的有些行为在测试环境下无法控制。

　　工作量大：编写测试代码耗费大量劳力。

　　打扰：编程需要专注，程序员最恨被干扰。