[置顶] The Clean Coder —— 测试策略

最新推荐文章于 2025-04-11 11:00:23 发布

原创最新推荐文章于 2025-04-11 11:00:23 发布 · 730 阅读

0 ·

CC 4.0 BY-SA版权

本文源自《代码整洁之道》，介绍了开发人员的目标、QA的角色以及自动化测试金字塔，强调单元测试作为设计文档的重要性，并指出软件质量源于设计而非测试。测试策略包括单元测试、组件测试、集成测试、系统测试、人工探索式测试，以及验收测试的区分。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

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 需求文档），测试只是它们的附属职能。