`

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层测试深深地折磨过后,系统才会被设计成易于测试。

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

 

各位业内人士,扪心自问:

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

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

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

  • 大小: 103 KB
  • 大小: 13.4 KB
  • 大小: 8.7 KB
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics