读构建之法 第二章：个人技术和流程

Posted 2020-09-13

绝大部分软件都是由多人合作完成的，大家的工作相互有依赖关系。某人负责的模块的功能被其他人调用，但如何让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证？？？单元测试就是一个很有效的解决方案。

创建单元测试函数的主要步骤是：

1.设置数据（一个假象的正确的E-mail地址）

2.使用被测试类型的功能（用E-mail地址来创建一个User类的实体）

3.比较实际结果和预期的结果（Assert.IsTrue(target!=null）

创建完就可以运行单元测试了，同时可以看看代码覆盖报告，代码百分百地都被覆盖了。

 

怎样才算一个好的单元测试呢？单元测试应该准确、快速地保证程序基本模块的正确性。

验证单元测试好坏的一系列标准：

1.单元测试应该在最基本的功能、参数上验证程序的正确性；

2.单元测试必须由最熟悉代码的人（程序的作者）来写；最好是在设计的时候就写好单元测试，这样单元测试就能体现API的语义，保障语义的准确性。

3.单元测试过后，机器状态保持不变；这样就能不断地运行单元测试。

4.单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）；快才能保证效率

5.单元测试应该产生可重复、一致的结果；

6.独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性；

7.单元测试应该覆盖所有代码路径，包括错误处理路径；（要注意：100%的代码覆盖率并不等同于100%的正确性）

8.单元测试应该集成到自动测试的框架中；把单元测试自动化，这样每个人都能随时随地运行单元测试。

9.单元测试必须和产品代码一起保存和维护；

在单元测试的基础上，建立关于这一模块的回归测试（Regression Test）

针对一个Bug Fix，我们也要做Regression Test。目的是1.验证新的代码的确改正了缺陷 2.同时要验证新的代码有没有破坏模块的现有功能，有没有Regression

回归测试中的回归可以将其理解为“回归到以前不正常的状态”

回归测试最好要自动化，这样就可以对于每一个构建快速运行所有回归测试，以保证尽早发现问题。

VSTS提供了方便的效能分析工具，让我们能很快地找到程序的效能瓶颈，从而能有的放矢，改进程序。

效能分析可以选择两种分析方法：

1.抽样（Sampling）优点：不需改动程序，运行较快，可以很快找到瓶颈，缺点：不能得出精确的数据，也不能准确表示代码中的调用关系树

2.代码注入（Instrumentation）缺点是程序的运行时间会大大加长，还会产生很大的数据文件，相应的增加了数据分析的时间，同时注入的代码也影响了程序真实的运行情况。

一般的做法是先用抽样的方法找到效能瓶颈所在，然后对待定的模块用代码注入的方法进行详细分析。

看个人项目耗时对比记录表，显然，从学生到职业程序员，并不是更加没完没了的写程序——花在写代码上的时间反而少了许多。

实践是理论的基础和验证标准

实践最简单的项目：WC，根据书上项目要求，实现一个统计程序

如何保证质量——回归测试

如何为这个程序做有效的测试，有以下几种方法，自动化程序由低到高。

1.手动测试，手工比较

2.要做到不断地测试，可以把WC的主要功能封装成一个类，然后测试程序员调用这一个类的主要函数，得出结果并与标准作比较。

3.更进一步，比较测试的输出和标注结果

4.再进一步，把自动构建脚本和构建验证测试结合起来。记录出现的bug。

我看完认为第二章主要讲的是 在设计的时候就写好单元测试，保证程序基本模块的正确性；在单元测试的基础上，建立模块的回归测试，保证之前所有已经发现并修复的bug的确得到了修复，并没有在最后一个版本中复发，才能保证尽早发现问题。还有对程序的效能分析，提高效能，优化程序。