你错了，确实“天时地利人和”告诉我，我错了。想广大读者道歉，说了一堆自己对单元测试思想的转变。直入正题：

从单元测试角度思考待测试程序：

作为软件系统的最小组成单位，单元测试具有以下属性：

1 它是由一个程序员完成的。

2 它有一个详细的设计说明，包括输入定义、输出定义和加工说明。

3 它是一个可识别的看得见的程序组成部分，并容易被组合成程序。

4 能被单独地汇编和测试。

5 它的规模比较小，逻辑比较简单。

因此单元测试具有以下意义：

单元测试集中注意力于程序的基本组成部分，首先保证每个单元测试通过，才能使下一步把单元组装成部件并测试其正确性具有基础。单元是整个软件的构成基础，像硬件系统中的零部件一样，只有保证零部件的质量，这个设备的质量才有基础，单元的质量也是整个软件质量的基础。因此，单元测试的效果会直接影响软件的后期测试，最终在很大程度上影响到产品的质量。

其实在最小单元上做测试，使每个测试都想做的事情，因为只有从最小单元向上保证，我们对自己的测试对象才更有信心，或者说能做到对待测试的工程做到最大程度上的把控。

单元测试可以平行开展，这样可以使多人同时测试多个单元，提高了测试的效率。

单元规模较小，复杂性较低，因而发现错误后容易隔离和定位，有利于调试工作。

单元的规模和复杂性特点，使单元测试中可以使用包括白盒测试的覆盖分析在内的许多测试技术，能够进行比较充分细致的测试，是整个程序测试满足语句覆盖和分支覆盖要求的基础。

单元测试的测试效果是最显而易见的。做好单元测试，不仅后期的系统集成联调或集成测试和系统测试会很顺利，节约很多时间；而且在单元测试过程中能发现一些很深层次的问题，同时还会发现一些很容易发现而在集成测试和系统测试很难发现的问题；更重要的是单元测试不仅仅是证明这些代码做了什么，是如何做的，而且证明是否做了它该做的事情而没有做不该做的事情。

单元测试的好与坏不仅直接关系到测试成本（因为如果单元测试中易发现的问题拖到后期测试发现，那么其成本将成倍数上升），而且也会直接影响到产品质量，因为可能就是由于代码中的某一个小错误就导致了整个产品的质量降低一个指标，或者导致更严重的后果。

事实上，好处不止一点

总结一下：

1 单元测试是一种验证行为—— 测试和验证程序中每一项功能的正确性，为以后的开发提供支持；

2 单元测试是一种设计行为—— 编写单元测试将使我们从调用者观察、思考，特别是要先考虑测试，这样就可把程序设计成易于调用和可测试的，并努力降低软件中的耦合，还可以使编码人员在编码时产生预测试，将程序的缺陷降低到最小；

3 单元测试是一种编写文档的行为—— 是展示函数或类如何使用的最佳文档；

4 单元测试具有回归性—— 自动化的单元测试有助于进行回归测试（这是我认为测试最大帮助的）；

单元测试的内容

单元测试由一组独立的测试构成，每个测试针对软件中的一个单独的程序单元。单元测试并非检查程序单元之间是否能够合作良好，而是检查单个程序单元行为是否正确。

在单元测试时，测试人员根据详细设计说明书和源程序清单，了解到该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理和不合理的输入都要能鉴别和响应。这就要求对程序所有的局部和全局的数据结构、外部接口和程序代码的关键部分进行桌面检查和代码审查

后续我还会对单元测试展开说，针对每一个端的单元测试。欢迎留言，说出你的诉求，我们一起体会单元测试的艺术。