构建之法第二章总结

  软件是由多人完成的，不同人员的工作之间相互有依赖关系，正是因为这样，软件才会有很多错误。程序员对模块功能的误解，疏忽或者理解不了模块的变化，都会造成错误。所以让自己定义的模块功能明确，模块内部的改变不会影响其他模块，而且模块的质量得到稳定的量化的保证很重要。所以单元测试就是一个重要解决方案。

  一个好的单元测试的标准是：单元测试应该在最基本的功能/参数上验证程序的正确性；单元测试必须由最熟悉代码的人写；单元测试后，机器状态保持不变；单元测试要快；单元测试应该产生可重复、一致的结果；单元测试的运行/通过/失败不应该依赖于其他别的测试，可以人为构造数据，以保持测试的独立性；单元测试应该覆盖所有代码路径；但愿测试应该集成到自动测试的框架中；单元测试必须和产品代码一起保护和维护。

  单元测试是回归测试的基础，如果一个模块或功能以前是正常工作的，但是在一个新的构建中除了问题，那么这个模块就出现了“退步”，所以对于回归测试中的回归，我们可以将其理解为回归到以前不正常的状态。回归测试最好自动化，这样就可以对吗吗，每一个构建快速运行所有回归测试，以保证尽早发现问题。测试完后，我们就希望提高程序的运行速度，即效能分析，我们可以选择两种方法：抽样，代码注入。抽样就是程序在运行时候时不时看一看这个程序运行在哪一个函数内，并记录下来。这个方法不需要改动程序运行快，可以很快找到瓶颈，但是不能精确得到数据，也不能准确表示代码中的调用关系树。代码注入是将检测的代码加入到每一个函数中，程序的一举一动都被记录下来，程序的各个效能数据都可以被精准的测量。但是程序的运行时间会大大提高还会产生大量数据文件，也相应增加了数据分析的时间，并且注入的代码也影响了程序的真实运行情况。如果没有测试就盲目优化也许会事半功倍。