第十次读书笔记 软件工程：方法与实践

单元测试

我们在开发的过程中应该实时的对新产生的代码进行测试，一是为了及时发现问题及时更改，避免日后代码复杂庞大，debug工作难度会指数级上升，这样及时测试，缩小了bug范围，能快速找到问题关键，避免不必要的时间浪费；不断的发现问题，可能是是自己编写代码前逻辑关系的错误，这种致命的错误越早发现，越早改正，越早走上正轨，还能帮助自己更好的理解整体的框架内容，逻辑结构。

单元测试应该由软件开发人员进行，而不是专门的测试团队。自己开发的代码，自己心里清楚内部的处理是怎么进行的，换另一个人测试会大大降低测试效率。更加广义的测试不仅仅是测试漏洞的所在，还可以是测试代码的运行效果，并且进行一些修改、优化、更正，这些显然不是另一个专门的测试人员可以轻松做到了。那么，如上所述可以清晰的看到，代码一经编写，就要及时测试，所以单元测试与代码的编写是一体的，可以看作是软件构架的一部分。

单元测试应尽可能的采取自动化的方式。单元测试应该和代码修改同步，频繁执行。以开发人员手工测试的时间成本和精力成本是巨大的。那么自动化的测试可以大大减轻开发人员的负担，还可以增加测试的频率。但是这一步我还没有学到什么方法可以做到这一点，除了用一些集成功能强大的IDE可以自动检查一些基础的bug其他都还是只能开自己手动检查。

所谓单元、单元，肯定是要将代码隔离分开进行测试。那么怎么隔离就是一个首先要想到的问题。回忆结对编程的过程，就是要在编写代码的时候有很清晰的逻辑层次，调用层次，将整个代码框架方块化模块化，那么对于每一个模块就是一个个较为独立的单元，优先编写下层代码，测试下层单元，然后再写上层的代码，上层代码难免会必须调用下层代码，但这时下层代码已经被检查测试过不会是bug的发生点，贯彻了单元测试的优势（快速找到问题所在）与意义（实时检查），如若下层代码未编写完成，那么先编写的上层代码就没办法很好地检查测试，堆积问题，这样就违背了单元测试的初衷。

自动化单元测试框架

自动化单元测试框架一般都需要提供的功能有：（1）方便地编写测试用例，并清晰地声明期望的测试结果；（2）运行测试用例，检查测试用例的运行结果并产生报告；（3）对测试用按照一定的规则进行组织。测试普遍所用的框架有：JUnit、NUnit、cppUTest。使用了统一的某几个框架可以使所有人编写测试代码时统一风格，保持一致性；同时肯定可以提高测试的开发效率。

测试单元代码也是代码，要简单，全面地检查到各种情况。测试代码也要遵循编写代码的一些要求：可理解性，可维护性等等。每一个测试代码的编写都应该遵循建立——执行——验证——拆卸四个步骤。

建立阶段：所谓建立阶段是指测试代码建立被测试代码的前置条件，使得被测试单元为测试做好准备；

执行阶段：测试代码调用被测单元接口；

验证阶段：测试代码通过断言确定是否获得预期的结果，从而判断被测试代码的正确性；

拆卸阶段：测试代码，将被测目标及环境恢复到测试前的初始状态，以避免影响后续的测试。