今天完成的事情：学习单元测试

明天计划的事情：学习集成测试、系统测试、验收测试

遇到的问题：总感觉记不住

收获： 单元测试 对软件中的最小可测试单元进行检查和验证

单元是什么

要根据不同情况来看  对于c语言，单元可以看成函数

java 面向对象语言 单元看成每一个类

对于有界面的功能软件 具体的功能项  一个菜单项 子窗口的具体功能

总之，单元是一个可测试的最小模块

单元测试一般都是针对代码测试

单元测试的原则

1> 尽可能保证各个测试用例是互相独立的，不要有依赖。正确的做法是编写一个模拟方法来取代使用外部依赖。

2>一般由写代码的人来检验代码功能是否符合要求。

单元测试的益处

1>能尽早发现缺陷，对需求的二次确认和理解的过程，保证开发人员对需求设计有一个清晰地理解。

2>有利于软件重构。进行完善的单元测试，最大限度地重构软件。在重构的时候，可以快速的识别错误的重构点。

3>简化集成，保证了最小单元模块的稳定性正确性，为集成测试奠定基础。充分进行单元测试，才能更好的聚焦到模块之间的关系上，不用再发更多精力到单元内部逻辑的验证上。

4>它是一种编写文档的行为。单元测试是一种无价的文档，它是展示函数或类如何使用的最佳文档。这份文档是可编译、可运行的，并且它保持最新，永远与代码同步。

5>它是一种设计行为。编写单元测试将使我们从调用者观察、思考，迫使我们把程序设计成易于调用和可测试的。

单元测试的限制

1>不能覆盖所有的执行路径，也不能保证捕捉到所有路径的错误。

2>每一行代码，一般需要多行测试代码才能完成单元测试。单元测试的投入非常大。

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序list 中去，然后确认该值出现在list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。

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

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

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

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

要进行充分的单元测试，应专门编写测试代码，并与产品代码隔离。我认为，比较简单的办法是为产品工程建立对应的测试工程，为每个类建立对应的测试类，为每个函数（很简单的除外）建立测试函数。首先就几个概念谈谈我的看法。

一般认为，在结构化程序时代，单元测试所说的单元是指函数，在当今的面向对象时代，单元测试所说的单元是指类。以我的实践来看，以类作为测试单位，复杂度高，可操作性较差，因此仍然主张以函数作为单元测试的测试单位，但可以用一个测试类来组织某个类的所有测试函数。单元测试不应过分强调面向对象，因为局部代码依然是结构化的。单元测试的工作量较大，简单实用高效才是硬道理。