《敏捷测试实践》.pptVIP

敏捷测试实践 敏捷测试 简而言之，敏捷测试是指在采用敏捷技术的项目中开展的测试 同时，敏捷测试也意味着测试遵循敏捷的基本原则，接纳敏捷的核心价值观（交流，简单，反馈，勇气） 保持简单 以任务为导向，而不以过程或是角色为导向 通过沟通和反馈保证测试能够建立合适的质量标准 尽可能减少测试周期的时间需求 敏捷测试要求“交付可用产品”而非单纯的“发现缺陷” 敏捷测试 vs. 传统意义上的测试 敏捷测试带来的挑战（一） 质量文化上的挑战 发现缺陷 vs. 在产品中内建质量 敏捷带来的担心：测试工程师应该做什么？ 敏捷带来的担心：测试工程师能够做什么？ 敏捷测试核心价值观 共享质量目标 开发和测试团队共享同样的质量目标，当然也共享同样的质量责任，每个工程师在测试方面都同样承担任务 在产品中内建可测试性 为产品建立更好的自动化测试不仅仅依赖于测试工程师的工作，更重要的是，产品本身内建的可测试性 关注产品质量的提升，测试周期的缩短，而不是仅专注于发现缺陷 敏捷测试中的测试工程师可以做什么 获取和明确用户的质量期望 建立合适的系统测试、用户验收测试质量标准 建立可见的质量度量体系，让产品和代码质量反馈持续可见 推进单元测试、开发测试，促进代码质量 建立持续构建框架 建立与维护合适的自动化测试以减少测试的时间投入 敏捷测试带来的挑战（二） 测试工程师面临的挑战 必须通过与开发团队的密切合作获取产品信息，制定测试计划而不是依赖文档 必须密切介入开发过程，参与设计，甚至是代码 必须能够自我驱动 必须具有足够的自动化测试技能与探索性测试技能 拥抱变化，改变工作方式 与开发工程师密切合作 转变角色，测试工程师不再是“裁判”，而应该是“支持者”和“帮助产品具有更好质量的角色” 将测试推动到上游 自我驱动，积极参与敏捷过程，主动工作而非仅仅被动接受任务 提升自己的技能，尤其是自动化测试方面的技能、探索性测试能力、快速学习能力 敏捷测试带来的挑战（三） 测试团队面临的挑战 与传统测试不同的考核标准 与传统测试不同的人员技能要求 与传统测试不同的测试过程管理 与传统测试不同的团队管理方式 建立适合敏捷测试的团队 建立以“质量和生产率”为核心的激励机制 提升团队成员技能，招聘合适的测试工程师 质量驱动，而非过程驱动 在团队内形成对敏捷的认知和认可 给团队成员更大的自主空间 鼓励团队关于自动化测试技术 敏捷测试的四个象限 敏捷测试体现的与传统测试的不同 作用于产品（Critique product）的测试 探索性测试（Exploratory Testing） 场景测试（Scenario Testing） 用户验收测试（UAT） 性能测试，安全性测试 …… 作用于支持团队（Supporting the team）的测试 单元测试 模块/组件级别的测试 功能测试 用户故事（User Story）测试 …… 敏捷测试的目标 作用于支持团队的测试 作用于产品的测试 敏捷测试实践 There are good practices in context, but are no best practices. --来自《Agile Testing – A Practical Guide For Testers and Agile Teams》 敏捷测试过程 针对一个迭代周期 计划一个迭代周期内的测试 了解细节，确定测试范围 创建并执行测试 发布 敏捷测试中的持续任务 提高代码质量与产品质量 从更多层面建立测试（单元测试、模块测试、系统测试等） 建立产品的质量度量 改进自动化测试（更稳定，更高的覆盖率） 计划一个迭代周期内的测试 计划的内容 产品发布标准（验收测试准则） 需要在本迭代周期内测试的内容 需要安排的测试类型 需要使用的测试环境（包括数据） 管理计划管理 一页纸测试计划（ One Page Test Plan） 可以使用各种形式表达测试计划：在线文档，测试点列表，自动测试列表，白板或是电子表格 了解细节，确定测试范围 了解本次迭代的产品细节 有哪些新增加的功能？ 开发工程师为相应的功能建立了哪些测试？ 需要增加哪些验收测试？ 应用的哪些部分可以通过自动化测试覆盖？ 应用的哪些部分需要通过手工测试覆盖？ 确定测试范围 哪些部分应该被纳入回归测试内？ 哪些部分需要新增加自动化测试？ 哪些部分需要新增加手工测试？ 用自动化手段帮助确定测试范围 Diff技术 后端（数据） 发送请求 比较输出 Diff工具 Diff的作用 识别应用中发生变化的部分 包括对接口，UI等各层面