第2章 敏捷测试
1 在敏捷环境下的传统测试
在敏捷环境下传统测试面临的困境
在敏捷环境下传统测试面临的挑战
(1)时间极短
(2)文档极少
(3)变更极频繁
(4)资源极缺
2 敏捷测试的概念
敏捷测试的定义
敏捷测试是遵从敏捷软件开发原则的一种测试实践。
敏捷开发模式把测试集成到整个开发流程中，而不再把它当成一个独立的阶段，因此，测试变成了整个软件开发过程中非常重要的环节。
敏捷测试的核心内涵：
(1)敏捷测试遵从敏捷开发的原则，强调遵守
(2)测试被包含在整个开发流程中，强调融合
(3)跨职能团队，强调协作
(4)敏捷测试是为了交付业务价值，强调价值
3 敏捷测试宣言
敏捷测试宣言 Agile Testing Manifesto |
测试是一个活动， 胜于测试是一个阶段。 Testing is a activity Over Testing is a phase 预防缺陷 胜于 发现缺陷。 Prevent Buss Over Finding Bugs 做测试者 胜于 做检查者。 Be a tester Over Be a checker 帮助构建最好的系统 胜于 破坏系统。 Helping wo build the BEST system Over Breaking the system 团队为质量负责 胜于 测试者为质量负责。 whole team takes responsibility for quality Over Tester is responsible for quality |
测试是一个活动 胜于 测试是一个阶段
《Google 软件测试之道》中写道:“当你把开发过程和测试放到一起，将它们像在搅拌机里一样混合搅拌，直到不能区分彼此的时候，你就得到了质量。”
待办 开发 测试 完成
->
待办 处理中 审核 完成
预防缺陷 胜于 发现缺陷
做测试者 胜于 做检查者
帮助构建最好的系统胜于破坏系统
团队为质量负责胜于测试者为质量负责
4 敏捷测试的特点与价值
敏捷测试的特点
(1)更强的协作：反对：开发需要测试帮忙。开发->开发领导->测试领导->测试
(2)更短的周期
(3)更灵活的计划
(4)更高效的自动化
(5)更广泛的技能要求:T型人才
敏捷测试与传统测试差异
重要维度 |
传统测试 |
敏捷测试 |
测试发生的时间节点 |
测试发生在软件生命周期的最后阶段，在 |
测试发生在每次 Sprint 迭代内，以及 Sprint 的集成过程中 |
团队沟通 |
团队之间除了正式沟通，还有很多非正式沟通，软件发布上线前团队之间的沟通是正式的，很多时候以邮件为载体 |
团队之间除了正式沟通，还有很多非正式沟通如口头沟通 |
测试自动化 |
测试自动化是可选项 |
测试自动化被高度推荐。测试自动化是决定敏捷测试成功的重要因素之一 |
测试标准 |
测试以需求规格文档为准，用户真正的需求很多时候在转换成需求文档时会失真 |
测试以用户最终需求为准，敏捷中的行为驱动开发(BDD) 实践等就是以用户最终求为准的 |
测试计划的详细程度 |
详细的测试计划。传统模式属于“预定义”过程控制模式，需求相对晰明确 |
精益化的测试计划。在最初阶段，需求本身比较模糊，无法也没有必要编写详细的测试计划 |
测试计划的制订方式 |
做计划是一次性的活动，因为传统模式按阶段划分，做计划会被安排在最初阶段，后面不再进行相关的计划工作 |
做计划是持续性的活动，分为不同的级别:·最初阶段做粗粒度的计划·在后续的迭代中不断优化为刚好够用(Just-In-Time)的计划 |
测试计划制订人 |
测试主管计划整个团队的测试工作，一般做计划时采用“自顶向下”的方式 |
团队被授权并主动参与计划，一般做计划时采用“自底向上”的方式 |
需求的详细程度 |
在最初阶段就要求给出详细的需求，并且需求需要经过严格评审，不欢迎需求变更 |
在最初阶段允许提出粗粒度的需求，在后面的迭代阶段逐渐细化，欢迎需求变更 |
需求呈现的方式 |
标准的需求规格说明书 |
需求以用户故事的方式呈现 |
客户参与 |
在需求被定义后，客户只是有限地参与，只有在需求调研的时候会较多地参与 |
客户参与贯穿整个项目生命周期，包括每次迭代的计划会和评审会等 |
敏捷测试的价值
1.加快上市时间(Time-to-Market)，缩短价值交付周期。
2. 质量由团队保障，提高整体产品质量。
3.化繁为简，节省成本
首先，敏捷测试不要求详细的测试计划和测试文档，也没有定义繁复冗长和缺陷管理流程。
其次，敏捷测试提倡尽早测试，更早发现缺陷。
最后，敏捷测试分小批量迭代执行。
