敏捷测试的“要”与“不要”-- 朱少民

敏捷测试的“要”与“不要”

2017-09-11   朱少民 编辑   软件质量报道

最近在看 Craig Larman和Bas Vodde写的 Practices for Scaling Lean & Agile Development （精益和敏捷开发大型应用实战）这本书，感觉作者挺重视“测试”的。多数敏捷开发类图书很少单独去谈测试，敏捷宣言和敏捷开发原则中也几乎没有谈到测试，而本书的作者在讲产品管理、计划、需求与PBI、设计与架构...之前就专门用一章的篇幅先谈“测试”，而且有50页的内容，超过其它十四章各个主题。作者叙述这章的方式也特别，用：

• “尝试”做什么，

• “避免”做什么

来表达作者的观点、所提倡的测试方式、方法和具体的实践，这些也来自于他们多年（敏捷咨询项目的）实践经验。

这里把他们50页的内容浓缩为一张表，左边是尽量避免的项，右边是尽量尝试去做的项，供大家思考，看看是否对大家有启发？你们也可以对照自己公司的做法，在下面留言，谈谈你们自己的想法。

（讽刺的事：一方面他反对certified tester，但自己却被Certified LeSS）

这张表包括三部分：总体上测试的思考、面向用户的测试（褐色内容）、开发者测试（蓝色内容）。

不要／尽量避免	要／努力尝试去做
假定测试就只意味着测试 将开发与测试分开 成立测试部门 单独的自动化测试团队 在迭代中使用缺陷跟踪系统 商业测试工具 TMM、TPI等模型 ISTQB等认证 复杂的测试术语	测试不再仅仅是测试（帮助理解左边内容） 测试人员不再只是进行测试 培训和指导测试工作 测试人员和程序员一起工作 特性团队作为自动化测试团队 所有的测试都要通过，否则“停止并修复” 绝不容忍Open的缺陷（见注1） 测试社区／社团 技术文档工程师进行测试 辨认出项目测试的臭味（见注2） 挑战关于测试的假定（见注3） 简单的测试分类
面向用户的测试
传统的需求交接 认为ATDD只适用于测试人员 混淆TDD与ATDD ATDD使用传统的测试工具 多个需求描述 “优化”需求研讨会 在研讨会上使用电脑和投影仪 混淆验收与用户验收测试 测试中和测试件的重复 通过UI测试 可追溯性（两边都有，辩证地看） 昂贵的测试（两边都有，辩证地看）	ATDD ATDD与迭代节奏相吻合 ATDD并行开发 利用ATDD教练与专业引导员 尝试Product Backlog提炼时采用研讨会形式讨论 “确认”（需求）优先于“编写测试” 使用示例（用例） 产品负责人编写测试 压缩工作流程到业务规则中 使用表格来表达商业规则 通过工作流（业务流）进行测试 测试墙 典型的研讨会日程（见注4） 提取重点的测试 集成测试框架/FitNesse Robot框架或其它ATDD兼容工具 将传统的测试工具封装进ATDD工具中 在Sprint review会议上展示测试 探索式测试（不同于传统的手工测试） 为探索式测试期间加上计划和时间盒（session） 自动化所有测试 为不可自动化的需求编写ATDD测试 持续运行所有测试 持续集成系统 可维护的测试 删减测试 可追溯性 昂贵的测试 自动化昂贵的测试 把非功能性测试当作功能性测试对待（自动化和持续性） 为非功能性需求设定需求域
开发者测试
由单独的人员进行单独的测试 编写自己的xUnit框架 缓慢的单元测试	单元测试 适合于C的C++ xUnit框架 编写自己的xUnit框架（当没有可用时） TDD 利用（内聘／外聘）TDD教练 在开发环境下运行测试 在实际硬件上运行测试 函数到函数指针的重构 学习测试 为硬件编写“学习测试” 重构测试 只测试一项的小测试

注1: 绝不容忍Open的缺陷是指：找到一个缺陷就会尽快修复，其好处就是防止：

• 在跟踪许多bug上花费精力

• 花费精力在优先级排序上

• 延迟学到当修复缺陷时产生的知识

• 花费额外的时间修复Bug，因为开发人员不再记得代码

 

注2: 项目测试的臭味

• 多故障的测试

• 开发人员不编写测试

• 测试高维护

• 产品多故障

 

注3:关于测试的假定

• 测试必须是独立进行的，因此要与开发相分离

• 必须有单独的测试部门

• 必须有测试经理

• 测试必须由“测试人员”完成

• 测试不可以在代码完成前开始

• 测试必须在最末尾进行

• 测试必须是“计划周详的”

• 必须有“测试策略”和一个“主测试计划”

• 测试遵循以下顺序：I）测试用例设计，2）测试用例执行，3）测试用例汇报（一个测试瀑布流程）

• 百分百测试覆盖率太昂贵。

• 百分百自动测试太昂贵。

• 测试需要精密的测试管理工具。

注4:典型的研讨会日程：

1. PO介绍研讨会目的

2. Team和PO选择要工作的条目

3. PO对选取的需求做概述发言

4. 发散：分局成几个子团体，就某个item讨论，写case

5. 聚合大家的成果

6. 重复“发散-聚合”几次

7. 结论

8. 提取