本周因几门课结课，加上参加了普通话水平测试，总的来讲有些忙碌。忙里偷闲，把上周看了少量的第二章作了补全，第三章也简简单单开了个头。

      第二章中，仅凭简单朴实的文字，说来重点也不过几句寥寥，却让人了解到了软件开发中非常重要的几个环节：测试及能效分析。简单来讲，测试又分为几个模块。其中，单元测试又涵盖几个要求：好的单元测试应该在最基本的功能/参数上验证程序的正确性、必须由最熟悉的人（即代码作者）来写。单元测试过后，机器状态应保持不变，且测试要快，应该产生可重复、一致的结果。另外，单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性，且单元测试应该覆盖所有代码路径，虽然100%的代码覆盖率并不等同于100%的正确性。此外，单元测试应该集成到自动测试的框架中，且必须和产品代码一起保存和维护。

      另外，书中还介绍了测试的另一个部分：回归测试。单元测试是回归测试的基础，在软件项目中，如果一个模块或功能以前是正常工作的，但在一个新的构建中出现了问题，那么就说这个模块出现了一个“退步”或是“倒退”（两者均对应为 Regression）。工程师就需要在新版本上运行所有已经通过的测试用例，来验证后面的版本没有出现软件"退化"的情况。如果“倒退”是由模块功能发生了正常变化引起的，那么测试用例的基准就需要修改，以和新的功能保持一致。针对修复Bug而改动的代码，我们也需要做一个回归测试，目的是验证新的代码的确改正了缺陷，同时要确认新的代码有否破坏模块的现有功能，即有没有发生“Regression”。

      能效分析，看起来普普通通的字眼实现起来却并不简单。每个程序员都希望自己的程序跑得又快又好，这就需要注意了解和修改程序运行中反复运行的部分。具体来说，能效分析有两周方法可选。其一是抽样，即程序运行时时不时地关注一下程序运行在哪个函数内并加以记录，程序结束后就可以得到一个关于程序运行时间分布的大致印象。这种方法的优点是不需要改动程序，且运行较快，很快就能找到瓶颈，但无法得出精确的数据，也无法准确的表示代码中的调用关系树。其二就是代码注入，即将检测的代码加入到每一个函数中，这样程序的一举一动都会被记录在案，各个效能数据都可以被精准地测量，但缺点是运行时间会大大加长，且会产生很大的数据文件，相应的也增加了数据分析的时间。同时，注入的代码本身也可能影响程序真实运行的情况。综上，一般常用的做法是先用抽样的方法找到效能瓶颈所在，然后对特定的模块用代码注入的方法进行详细分析。

      真正的程序工程师在需求分析和测试上花的时间更多，而花在具体编码中的时间一般比在校大学生少的多。从学生到职业程序员，以后在写代码的时间会少很多，更多是用在分析上。因此，从现在开始培养我们对程序进行分析、测试的能力和思维必将使我们获益良多。

构建之法阶段小记二