The Clean Coder —— 测试策略

来源：《代码整洁之道：程序员的职业素养》

 

1. 开发人员的目标

开发人员应把“QA找不到任何错误”作为努力的目标。

（虽然这个目标几乎无法实现，但仍然是我们努力的目标。正所谓“求其上，得其中；求其中，得其下；求其下，必败”。）

 

2. QA在项目中的角色

QA在团队中的角色是需求规约定义者（specifier）和特性描述者（characterizer）。

（某些项目中，特别是业务复杂需要较强专业能力的项目中，会设有全职的业务研究员（BA）。在这些项目中，BA会负责上述角色中偏业务的部分，QA则负责偏测试理论的部分。）

 

3. 自动化测试金字塔

测试类别	测试操控方式	覆盖率	编写者
单元测试	XUnit	100%	程序员
组件测试	API	50%	业务人员 & QA
集成测试	API	20%	系统架构师 / 主设计师
系统测试	GUI	10%	系统架构师 & 技术负责人

 

 

3.1 单元测试

单元测试就是设计文档，它描述了系统最底层的设计细节。在TDD中，测试先行的需要会迫使我们去考虑什么是好的设计。单元测试要尽可能覆盖所有的代码。

 

3.2 组件测试

组件测试是验收测试的一种。由业务人员和QA编写。通过调用API的方式实现。需要使用模拟技术（Mocking）将被测组件与其它组件解耦。主要是业务人员编写的针对正常路径的测试。也会包含一些明显的极端情况、边界状态和可选路径。大多数异常路径由单元测试覆盖。在组件测试层对异常路径进行测试无意义。

 

 

3.3 集成测试

只对组件很多的较大型系统有意义。也是通过调用API的方式实现，也需要Mocking技术实现解耦。由系统架构师或主设计师编写。集成测试是编排性（choreography）测试，主要测试组件装配在一起是否协调，不测试业务规则。这层可以开始考虑性能测试和吞吐率测试。

  

3.4 系统测试

这是最终的集成测试。包含性能测试和吞吐率测试。一般通过GUI层的操作实现。一般会覆盖10%的代码。由系统架构师和技术负责人编写。系统测试的目的确保正确的系统构造，而不是系统行为（即不是业务计算逻辑）。GUI测试的成本非常大，应尽量减少GUI测试。最好把GUI和业务规则解耦，在测试GUI时用测试桩替代业务规则。

 

3.5 人工探索式测试

人工探索式测试的目标是确保系统在人工操作下表现良好，同时富有创造性地找出尽可能多的“古怪之处”。覆盖率、业务规则和运行路径是否正确都不是目标。一般由QA专人负责，或在特定时间内所有项目成员参与找bug。

 

3.6 单元测试 vs 验收测试

单元测试是程序员写给程序员的，是正式的设计文档。

验收测试业务方写给业务方的，是正式的需求文档。

a. 测试执行路径不同。单元测试深入系统内部，调用特定类的方法。验收测试在系统外部，通过API或GUI操作。

b. 根本不同点：它们首先是文档（设计文档 vs 需求文档），测试只是它们的附属职能。

 

4. 小结

$ 要确保软件系统质量良好，其根本在于需求和设计的质量。只有设计出易于测试的软件，才能使项目健康发展。

$ 单元测试是自动化测试中的关键。它会迫使我们去思考什么才是好的设计。只有事先考虑到测试，才会有意识地去设计易于测试的软件。

$ 根据我的经验，必须将GUI层的测试完全由系统架构师和技术负责人负责。GUI层的测试成本太大了。只有这些有权决定系统设计的人被GUI层测试深深地折磨过后，系统才会被设计成易于测试。

$ 同理，必须将系统的质量问题完全由开发人员负责，即这帮有权决定系统架构设计的人，才能使软件质量真正提高。将测试重担，甚至质量问题，推给测试人员是极度不专业的行为。软件的质量是设计出来的，不是测出来的。

 

各位业内人士，扪心自问：

作为项目组员之一的你，在做决定前是否对测试策略有清晰的认识？

自己的努力是否施展在正确的方向？

如果你是项目领导，你是否在团队中起到了应有的作用？你的技术储备足够吗？软件工程理论扎实吗？组织架构合理吗？每个组员的责、权、利统一吗？你有充分调动组员的积极性，挖掘他们的潜力吗？