敏捷测试的“要”与“不要”-- 朱少民
2017-11-03 09:12
375 查看
敏捷测试的“要”与“不要”
2017-09-11 朱少民编辑 软件质量报道
最近在看 Craig Larman和Bas Vodde写的 Practices
for Scaling Lean & Agile Development (精益和敏捷开发大型应用实战)这本书,感觉作者挺重视“测试”的。多数敏捷开发类图书很少单独去谈测试,敏捷宣言和敏捷开发原则中也几乎没有谈到测试,而本书的作者在讲产品管理、计划、需求与PBI、设计与架构...之前就专门用一章的篇幅先谈“测试”,而且有50页的内容,超过其它十四章各个主题。作者叙述这章的方式也特别,用:
“尝试”做什么,
“避免”做什么
来表达作者的观点、所提倡的测试方式、方法和具体的实践,这些也来自于他们多年(敏捷咨询项目的)实践经验。
这里把他们50页的内容浓缩为一张表,左边是尽量避免的项,右边是尽量尝试去做的项,供大家思考,看看是否对大家有启发?你们也可以对照自己公司的做法,在下面留言,谈谈你们自己的想法。
(讽刺的事:一方面他反对certified tester,但自己却被Certified LeSS)
这张表包括三部分:总体上测试的思考、面向用户的测试(褐色内容)、开发者测试(蓝色内容)。
不要/尽量避免 | 要/努力尝试去做 |
假定测试就只意味着测试 将开发与测试分开 成立测试部门 单独的自动化测试团队 在迭代中使用缺陷跟踪系统 商业测试工具 TMM、TPI等模型 IST 13826 QB等认证 复杂的测试术语 | 测试不再仅仅是测试(帮助理解左边内容) 测试人员不再只是进行测试 培训和指导测试工作 测试人员和程序员一起工作 特性团队作为自动化测试团队 所有的测试都要通过,否则“停止并修复” 绝不容忍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教练 在开发环境下运行测试 在实际硬件上运行测试 函数到函数指针的重构 学习测试 为硬件编写“学习测试” 重构测试 只测试一项的小测试 |
绝不容忍Open的缺陷是指:找到一个缺陷就会尽快修复,其好处就是防止:
在跟踪许多bug上花费精力
花费精力在优先级排序上
延迟学到当修复缺陷时产生的知识
花费额外的时间修复Bug,因为开发人员不再记得代码
注2:
项目测试的臭味
多故障的测试
开发人员不编写测试
测试高维护
产品多故障
注3:关于测试的假定
测试必须是独立进行的,因此要与开发相分离
必须有单独的测试部门
必须有测试经理
测试必须由“测试人员”完成
测试不可以在代码完成前开始
测试必须在最末尾进行
测试必须是“计划周详的”
必须有“测试策略”和一个“主测试计划”
测试遵循以下顺序:I)测试用例设计,2)测试用例执行,3)测试用例汇报(一个测试瀑布流程)
百分百测试覆盖率太昂贵。
百分百自动测试太昂贵。
测试需要精密的测试管理工具。
注4:典型的研讨会日程:
PO介绍研讨会目的
Team和PO选择要工作的条目
PO对选取的需求做概述发言
发散:分局成几个子团体,就某个item讨论,写case
聚合大家的成果
重复“发散-聚合”几次
结论
提取
相关文章推荐
- 深入敏捷测试之计划不要忘了全局
- 敏捷测试流程和活动
- 敏捷测试用例设计
- 敏捷测试
- 敏捷下软件测试的七个关键成功要素
- 敏捷测试的思考和新发展
- 《敏捷测试的最佳实践》学习笔记(三)
- 敏捷测试与最佳实践(一) 敏捷定义
- 在敏捷测试中如何设计用例
- 敏捷软件测试常见的七个误区
- 想象力测试看看你的情商有多高(不要做一个冷血的人哦~)
- 与Janet关于敏捷测试若干问题的Q&A
- Base64实现测试,不要太相信apache-common的性能
- 从生产线到生产岛:理解敏捷开发中的设计与测试活动
- 转:敏捷测试感悟(之二)
- 什么是敏捷软件测试
- 如何从架构和测试推动敏捷开发_课程大纲
- 敏捷开发团队管理系列之二:程序与测试团队I
- 敏捷测试的角色
- 敏捷测试的挑战