敏捷测试是一种遵循敏捷原则的软件测试实践，强调从用户的角度进行测试，而非严格的测试流程。它要求测试团队与开发团队紧密合作，共同承担质量责任，提升产品质量，并采用自动化测试和持续集成等技术以缩短测试周期。敏捷测试面临着测试工程师和团队在角色、技能以及管理方式上的挑战，需要在文化上推动质量的内建。

1. 敏捷测试实践 段念 www.qconbeijing.com

2. 什么是我们谈论的敏捷测试？

3. Agile testing is a software testing practice that follows the principles of the agile manifesto , emphasizing testing from the perspective of customers who will utilize the system. Agile testing does not emphasize rigidly defined testing procedures , but rather focuses on testing iteratively against newly developed code until quality is achieved from an end customer's perspective. In other words, the emphasis is shifted from "testers as quality police" to something more like "entire project team working toward demonstrable quality." -- 来自 wikepedia

4. 敏捷测试 简而言之，敏捷测试是指在采用敏捷技术的项目中开展的测试 同时，敏捷测试也意味着测试遵循敏捷的基本原则，接纳敏捷的核心价值观 （交流，简单，反馈，勇气） 保持 简单 以 任务 为导向，而不以过程或是角色为导向 通过 沟通和反馈 保证测试能够建立合适的质量标准 尽可能 减少测试周期的时间需求 敏捷测试要求“ 交付可用产品 ”而非单纯的“ 发现缺陷 ”

5. 敏捷测试 vs. 传统意义上的测试

6. 敏捷测试 带来的挑战（一） 质量文化上的挑战 发现缺陷 vs. 在产品中内建质量 敏捷带来的担心：测试工程师应该做什么？ 敏捷带来的担心：测试工程师能够做什么？

7. 敏捷测试 核心价值观 共享质量目标 开发和测试团队共享同样的质量目标，当然也共享同样的质量责任，每个工程师在测试方面都同样承担任务 在产品中内建可测试性 为产品建立更好的自动化测试不仅仅依赖于测试工程师的工作，更重要的是，产品本身内建的可测试性 关注产品质量的提升，测试周期的缩短，而不是仅专注于发现缺陷

8. 敏捷测试 中的测试工程师可以做什么 获取和明确用户的质量期望 建立合适的系统测试、用户验收测试质量标准 建立可见的质量度量体系，让产品和代码质量反馈持续可见 推进单元测试、开发测试，促进代码质量 建立持续构建框架 建立与维护合适的自动化测试以减少测试的时间投入

9. 敏捷测试带来的挑战（二） 测试工程师面临的挑战 必须通过与开发团队的密切合作获取产品信息，制定测试计划而不是依赖文档 必须密切介入开发过程，参与设计，甚至是代码 必须能够自我驱动 必须具有足够的自动化测试技能与探索性测试技能

10. 拥抱变化，改变工作方式 与开发工程师密切合作 转变角色，测试工程师不再是“裁判”，而应该是“支持者”和“帮助产品具有更好质量的角色” 将测试推动到上游 自我驱动，积极参与敏捷过程，主动工作而非仅仅被动接受任务 提升自己的技能，尤其是自动化测试方面的技能、探索性测试能力、快速学习能力

11. 敏捷测试带来的挑战（三） 测试团队面临的挑战 与传统测试不同的考核标准 与传统测试不同的人员技能要求 与传统测试不同的测试过程管理 与传统测试不同的团队管理方式

12. 建立适合敏捷测试的团队 建立以“质量和生产率”为核心的激励机制 提升团队成员技能，招聘合适的测试工程师 质量驱动，而非过程驱动 在团队内形成对敏捷的认知和认可 给团队成员更大的自主空间 鼓励团队关于自动化测试技术

13. 敏捷测试的 四个象限

14. 敏捷测试体现的与传统测试的不同 作用于产品（ Critique product ）的测试 探索性测试（ Exploratory Testing ） 场景测试（ Scenario Testing ） 用户验收测试（ UAT ） 性能测试，安全性测试 …… 作用于支持团队（ Supporting the team ）的测试 单元测试 模块 / 组件级别的测试 功能测试 用户故事（ User Story ）测试 ……

15. 敏捷测试的目标 作用于支持团队的测试 作用于产品的测试

16. 敏捷测试实践 There are good practices in context, but are no best practices. -- 来自《 Agile T esting – A Practical Guide For Testers and Agile Teams 》

17. 敏捷测试过程 针对一个迭代周期 计划一个迭代周期内的测试 了解细节，确定测试范围 创建并执行测试 发布 敏捷测试中的持续任务 提高代码质量与产品质量 从更多层面建立测试 （单元测试、模块测试、系统测试等） 建立产品的质量度量 改进自动化测试 （更稳定，更高的覆盖率）

18. 计划一个迭代周期内的测试 计划的内容 产品发布标准（验收测试准则） 需要在本迭代周期内测试的内容 需要安排的测试类型 需要使用的测试环境（包括数据） 管理计划管理 一页纸测试计划（ One Page Test Plan ） 可以使用各种形式表达测试计划：在线文档，测试点列表，自动测试列表，白板或是电子表格

20. 了解细节，确定测试范围 了解本次迭代的产品细节 有哪些新增加的功能？ 开发工程师为相应的功能建立了哪些测试？ 需要增加哪些验收测试？ 应用的哪些部分可以通过自动化测试覆盖？ 应用的哪些部分需要通过手工测试覆盖？ 确定测试范围 哪些部分应该被纳入回归测试内？ 哪些部分需要新增加自动化测试？ 哪些部分需要新增加手工测试？

21. 用自动化手段帮助确定测试范围 Diff 技术 后端（数据） 发送请求 比较输出

22. Diff 工具 Diff 的作用 识别应用中 发生变化 的部分 包括对接口， UI 等各层面的检查 发生变化的部分是需要重点测试和覆盖的部分 不同的 Diff 方法 HTML diff DOM tree diff Image Diff 接口数据 Diff ……

23. 创建测试并执行 建立测试执行的基础架构（ Test Infrastructure ） 持续集成框架 建立自动运行的 Sanity Check Test Suite 维护验收测试集（ Accept Test Suite ） 在一个迭代周期中创建与执行测试 创建各个层次的测试 使用自动化测试框架运行测试 使用基于脚本的手工测试与探索性测试完成对新功能，以及部分原有功能的回归测试

24. 敏捷测试中的测试方法 探索性测试：主要用于探索和测试新功能，或是基于对应用的了解发现可能的缺陷 基于脚本的手工测试：在某些无法自动化测试的部分，使用手工测试或是半自动测试执行某些回归测试用例 自动化测试 从不同层次 / 级别验证应用 性能测试，安全性测试，模糊测试（ Fuzz Testing ）等 通过重构等方式建立更加稳定的自动化测试

25. 敏捷测试中的自动化测试工具 单元测试与模块测试 xUnit 工具 Mock 工具 HTTP/HTML 层面测试工具 HttpUnit WebDriver(HtmlUnit) UI 层面的测试工具 Selenium/Webdriver Watir/WatiN

26. 性能测试工具 JMeter 持续集成工具 安全性测试工具 其他测试工具 Link Checker Crawler Fuzz 测试工具

27. 发布 为达到质量标准的产品进行 Sign off 面向用户发布本迭代周期得到的 Release 在产品环境中验证本 Release 数据迁移（可能） 为可能的回滚做准备 总结本迭代周期内的测试，持续改进 缺陷分析 发现可测试性的问题，持续提高可测试性 在团队中分享测试知识

28. 敏捷测试中的自动化测试工具 单元测试与模块测试 xUnit 工具 Mock 工具 HTTP/HTML 层面测试工具 HttpUnit WebDriver(HtmlUnit) UI 层面的测试工具 Selenium/Webdriver

29. 软件可测试性 Testability is the degree to which it can be established that a system performs according to the requirements .

30. 软件可测试性 可操作性：易于测试执行，允许同时开发和测试 可观察性：应用有明确的可观察的输出 可控制性：可以通过灵活的方式控制应用 可分解性：系统模块之间的独立性强 简单性：功能简单，代码简单，结构简单 稳定性：软件的变化是可控的 易理解性：软件是自明的，具有良好的技术文档

31. 可测试性示例——验证码 提高可控制性的方法 在测试版本中取消验证码 万能验证码 向应用注入钩子

32. 代码可测试性 class Hello { … String sayHello() { Calendar cal = new Gregorian Calendar(); int hour = cal.get (Calendar.HOUR) ; if(t < 12 ) return “Morning”; else if(t < 18) return “Afternoon”; else … } }

33. 使代码 可测试 class Hello { … String sayHello( Calendar cal ) { // Calendar cal = new Gregorian Calendar(); int hour = cal.get (Calendar.HOUR) ; if(t < 12 ) return “Morning”; else if(t < 18) return “Afternoon”; else … } } Hello hellotest = new Hello(); mockCal = EasyM ock.create Mock (Calendar.class); expect( mockCal. get(Calendar.HOUR)) . adnRe turn( 10 ); replay(mockCal); String result = hellotest.sayHello(mockCal); Assert.assertEqual(result, “Morning”);

34. 提高产品可测试性 强调可测试性设计 松耦合 足够的“内部 API” （测试接口） 使用合理的设计模式 …… 使用单元测试 / 开发测试提高代码可测试性 Think Test First 代码可测试性是高单元测试覆盖率的必要条件 编码规范 设计评审 ……

35. Q&A