《构建之法》笔记---第二章 个人技术和流程

《构建之法》—笔记

第二章 个人技术和流程

---

---

前言

单元测试，回归测试，效能分析，个人软件开发流程（PSP）

---

一、单元测试

目的

保证模块功能定义尽量明确，模块内部改变不会影响其他模块，模块质量能得到稳定的、量化的保证。

创建单元测试的主要步骤

• 设置数据
• 使用被测试类型的功能
• 比较实际结果和预期结果
  注：除了主要的功能，代码还有很多其他情况（例如一些异常处理等），需要对应的测试用例完善单元测试。

单元测试标准

1. 在最基本的功能/参数上验证程序的正确性：例如类、基本功能点（几个基本类组成）、测试API中的每一个方法及每一个参数；
2. 由熟悉代码的人来写：最好在设计时就写好，这样的单元测试能体现API的语义；
3. 单元测试过后，机器状态保持不变：可不断地运行单元测试，如果单元测试创建了临时文件或目录，应该在Teardown阶段删掉。如果单元测试在数据库中创建或修改了记录，那么也需要删除或恢复这些记录，或者每个单元测试使用一个新的数据库，保证单元测试不受之前单元测试实例的干扰；
4. 单元测试要快（一个测试运行的时间是几秒而不是几分）：如果软件有相互独立的几层，在测试组中可以分类，如果修改了某块内容，只运行对应层次的单元测试；
5. 单元测试应该产生可重复、一致的结果；（为了增加测试的真实性使用随机数，一般情况不好，如果某个随机数导致程序出错，但下一次运行不易复现，任于事无补。虽然要使用随机数增加测试真实性，但不是在单元测试中，单元测试不能解决所有问题，不必期望它会发现所有缺陷）；
6. 独立性：单元测试的运行/通过/失败不依赖于别的测试，可人为构造数据，以保持单元测试的独立性，比如如果依赖其他模块的结果，而其他模块不稳定或费时，可人为构造其他模块的正确输出数据，以保证独立性；
7. 单元测试的代码覆盖率应该覆盖所有代码路径：包括错误处理路径；
8. 单元测试应该集成到自动测试的框架中
9. 单元测试必须和产品代码一起保存和版本维护；

二、回归测试

倒退/退化/退步（Regression）

一个模块或功能以前是正常工作的，在一个新的构建中出了问题，那这个模块就产生了regression，从正常工作状态退化到不正常工作状态。
注：退化是由于模块功能发生变化引起的话测试基准用例则需要修改，以便和新feature保持一致。

模块的功能基准线（Baseline）

一个模块的所有单元测试（通过）是这个模块最初的Baseline

说明

在新版本上运行之前版本所有已经通过的单元测试，以验证新版本有没有“退化”情况发生，这就是一个“Regression Test”
注：针对bugfix也需要做回归测试，验证新代码确实改正了bug同时没用破坏模块的现有功能。
回归测试最好自动化，这样可以对每一个构建快速运行所有回归测试，以保证尽早发现问题。
单元测试是回归测试的基础。

三、功能测试

从用户角度检查功能完成得怎么样

四、效能分析工具

分析方法

先用抽样方法找到瓶颈，然后对特定的模块用代码注入的方法进行详细分析。

抽样

程序运行时，工具间隔看下程序运行在哪个函数并记录，程序运行结束后能得到关于程序运行时间分布的大致印象。 不须改程序，快，数据不精确，不能准确表示代码中调用关系树。

代码注入

将检测代码加入到每一个函数中，程序每步都被记录，观测精准，慢，数据文件大，影响程序真实运行情况。

名词

调用者（Caller）
被调用者（Callee）
调用关系树（Call Tree）
消逝时间（Elapsed Time）
应用程序时间（Application Time）
本函数时间（Exclusive Time）
所有时间（Inclusive Time）

注：避免未经过分析的盲目优化，可能事倍功半

五、个人开发流程

任务清单

• Planning 计划 6
  • Estimate 明确指求和其他相关因素，指明时间成本和依赖关系
• Development 开发 88
  • Analysis 分析需求 10
  • Design Spec 生成设计文档 6
  • Design Review 设计复审（和同事审核设计文档）6
  • Coding Standard 代码规范（为目前的开发制定合适的规范） 3
  • Design 具体设计 12
  • Coding 具体编码 21
  • Code Review 代码复审 9
  • Test 测试（包括向测，修改代码，提交修改）21
• Record Time Spent 记录用时 6
• Test Report 测试报告
• Size Measurement 计算工作量
• Postmortem 事后总结
• Process Improvement Plan 提出过程改进计划

特点

• 不依赖具体软件技术（例语言），着眼开发流程
• 不依赖考试，自己收集数据，分析，提高
• 小、初创团队需求质量不高，程序输出质量往往也不高
• PSP依赖数据
• 目的是记录工程师如何实现需求的效率，而不是记录顾客的产品满意度。

---

总结

整个过程中前期的设计和后期的测试占比相对具体编码会更大一些。单元测试比较重要，对于大型项目，好的单元测试和持续集成测试能有效提升每次修改后手动挨个测试的效率，回归测试能避免新的改动影响到之前的功能，而回归测试的基础是单元测试。