敏捷测试的价值观和管理

敏捷测试是为了适应敏捷开发而特别设计的一套完整的软件测试解决方案。

敏捷测试宣言

与开发协作测试 胜于 测试分工与测试工具

可运行的测试脚本 胜于 写在纸上的测试用例

从客户角度来理解测试需求 胜于 从已定义的需求来判定测试结果

基于上下文及时调整测试策略 胜于 遵循测试计划

敏捷测试强调 「与开发协作」「自动化测试」「客户思维」 和 「动态的测试策略调整」

8 项敏捷测试原则

1. 尽早和持续地展开测试
2. 基于风险的测试策略是必须的
3. 测试计划、设计和执行力求简单
4. 能即使完成对软件质量的全面评估
5. 软件本身是测试研究和分析的主要对象
6. 在满足所要求的质量后，测试进行的越快越好
7. 对测试技术精益求精
8. 不断反思，持续优化测试流程与设计

克里斯平和格雷戈里给出的敏捷测试的定义

敏捷测试定义 （莉萨·克里斯平和珍妮特·格雷戈里）：

为了向客户持续交付高质量的、有业务价值的产品进而进行的一些列基于团队协作的测试实践，这些实践贯穿于从研发开始直到交付的整个阶段。敏捷测试中的测试活动侧重于预防缺陷而不是发现缺陷，并努力强化和支持整个团队对质量负责的理念。

敏捷测试包括 （但不限于） 的测试活动：在工作中用具体的实例指导开发人员做测试，评审测试想法和假设，开发测试自动化，执行探索性测试，执行验证质量属性的测试，如性能、可靠性、安全性等。

1. 传统测试更强调测试的独立性：

将 「开发人员」 角色和 「测试人员」 角色分得比较清楚。敏捷测试可以有专职的测试人员，也可以是 「全民」 测试，在敏捷测试中，可以没有 「测试」 角色，强调整个团队对测试负责。

2. 传统测试具有明显的阶段性：

从需求评审、设计评审、单元测试到集成测试、系统测试等，从测试计划、测试设计再到测试执行、测试报告，逐个阶段往前推进。敏捷测试更强调持续测试、持续的质量反馈，没有明确的阶段界限。

3. 传统测试强调测试的设计性：

敏捷测试更强调测试的速度和适应性，侧重不断地调整计划以适应需求的变化。

4. 传统测试强调测试是由 「验证」 和 「确认」 两种活动构成的：

敏捷测试没有这种区分，始终以用户需求为中心，每时每刻不离用户需求，将验证和确认统一起来。

5. 传统测试关注测试文档：

包括测试计划、测试用例、缺陷报告和测试报告等，要求严格遵守文档模板，强调测试文档评审的流程与执行等。敏捷测试更关注产品本身，关注可交付的客户价值。敏捷测试中，强调面对面沟通、协作，强调持续质量反馈、缺陷预防。

敏捷测试的 7 项主要活动：

1. 测试需求的分析与定义

对用户故事、Epic（多个用户故事的合集） 等进行评审，为每一个用户故事建立验收标准，确保它具有可测试性，并从业务需求出发，了解要做哪些测试，初步界定测试的范围。

2. 测试计划

当前迭代的测试计划，包括进一步明确具体的业务要求和质量标准，制定测试目标，明确测试范围和测试项。分解测试目标，识别出测试风险并制定测试策略等。

3. 测试设计

强调的是粗颗粒度的测试设计，包括测试模型设计。如事件流图、状态图等的设计，而不是指测试用例的设计。

4. 版本构建的验证测试 （BVT）

只要有版本构建，不管是每日还是提交时，都需要对软件版本进行自动验证，只有高成功率的持续集成才有意义。这里的 BVT 不但包含传统的冒烟测试，即对当前软件版本实现的基本功能进行测试，而且包含对代码进行扫描，检查代码的规范性、安全性等，即通常所说的静态代码分析。

5. 持续测试是迭代中主要的活动

持续测试包括设计评审、单元测试、用户故事实现的验证和集成测试等。也包含持续的新功能测试和持续的回归测试，及性能测试、安全测试、兼容性测试等针对软件质量属性的专项测试。

6. 版本验收测试

将所有用户故事串起来进行相对全面的测试。从业务流程出发，完成端到端 （End-to-End，E2E） 的测试。相当于许多团队在 Beta 环境、准生产环境中进行一轮完整的测试或试用一段时间。

7. 测试交付与反思

测试交付还包括质量分析，并要回顾、审核整个测试过程，找到测试不佳的地方，从而在下一个迭代中改进。

测试流程管理

流程强调尽可能写出简单的测试计划，能写一页纸就不写两页纸。没有测试用例的设计，而只是粗颗粒度的测试设计。测试执行的双支撑，不但需要自动化测试，而且需要探索式测试。强调质量文化、基础设施等的重要性，并贯穿整个测试周期。

Q1 基于业务层构建产品质量

业务驱动测试，即包括验收测试驱动开发 （ATDD） 和行为驱动开发 （BDD）、实例化需求和测试驱动设计等。

Q2 基于技术层构建产品质量

侧重持续集成/持续交付技术和环境的支持，实现单元测试开发 （Unit test-driven Development，UTDD），以及良好的自动化单元测试。

Q3 基于技术层评价产品

基于工具的功能、性能、安全性和可靠性等建模、评估、监控与分析，这也依赖于技术和 DevOps 的测试基础设施。

Q4 基于业务层评价产品质量

包括探索式测试、众测和迭代评审等。迭代评审也就是产品利益相关者一起来评审产品，真正从业务角度来评估产品的质量。

1. 帮助敏捷团队提升质量文化，持续关注质量和用户需求，持续向利益相关者提供质量反馈。具体任务包含：

• 获取和明确用户的质量期望
• 建立合适的系统测试、验收测试的质量标准
• （和产品负责人一起） 完成每个迭代的验收测试
• 保持质量度量结果的可视性
• 发现值得关注的测试切入点
• 持续提供质量反馈
• 进行在线日志分析、在线测试
• 进行拜访客户、用户调查等活动

2. 制定测试计划，指导团队使用合适的测试技术和方法，不断收集反馈，改进、推广测试技术和方法，积累软件测试实践经验。具体任务包含：

• 制定的是计划模板、风险列表 （checklist） 和常见的测试策略
• 探索新的测试方法，引入新的测试技术
• 开发更有效的测试工具，持续改进自动化测试
• 通过缺陷根因 （root cause） 分析获得避免缺陷的信息，并通过设计规则和实践避免缺陷的引入

3. 帮助团队构建自动化测试基础设施，提供必要的测试工具。具体任务包含：

• 推进单元测试、开发测试，尽量将测试推到上游
• 建立持续集成框架，以及基于持续集成的质量控制和发布规则
• 创建更高效的工具，持续改进自动化测试

4. 需求、设计和代码的可测试性把关，包括需求、设计和代码的可测试性检查。具体任务包含：

• 建立合适的系统测试、验收测试的质量标准
• 定义需求评审、设计评审的检查表
• 持续推动可测试性的提高

 

制定软件产品研发的迭代测试计划。起草计划、召集评审会等。分析测试范围、列出测试项、定义优先级、识别测试风险、制定测试策略和估算工作量等。收集团队的反馈，洞察新的测试风险，对计划进行优化或调整，协调测试任务或测试资源等。

提高软件的可测试性。参与前期的需求分析和定义验收标准，更好地保证需求、设计、代码等的可测试性。领导团队制定测试性规范或实施指南。

指导团队成员开展测试工作。用户故事的验证、系统级别的测试。单元测试、集成测试。动态测试、需求评审、设计评审、代码评审。

承担部分质量保证。领导团队指定评审流程和规范，帮助开发人员消除不规范行为。寻求机会以提高需求、设计、代码的质量和可复用性。

其他职责。指导团队进行测试基础设施、自动化测试框架等工作，为团队提供相应的内部测试培训以保证团队提高整体测试技术。

五大障碍

 

• 缺乏信任：没有信任，任何团队都没法谈协作，信任是团队协作的基础。
• 惧怕冲突：指团队内部不同观点的直接碰撞，甚至是激烈交锋。
• 欠缺投入：由于缺乏信任、惧怕冲突，争论会少，互相不愿意沟通，在协作、沟通上投入自然就会少。
• 逃避责任：上述几大障碍的存在，自然会导致相互推卸责任，缺乏团队精神。
• 无视结果：逃避责任的结果，就是相当于无视团队的目标和结果。

团队精神

• 制定团队共同的使命和目标
• 传达 「成功必须依靠团队合作」 的信念
• 营造团队中的归属感，并将你我团结在一起以实现共同的目标
• 鼓励团队成员互相帮助、互相尊重和互相信任
• 让每个人都觉得自己的工作很重要，有成就感
• 与团队成员分享责任、胜利与成功、荣誉等

因感到众多软件从业人员分不清软件测试和软件质量管理，不少 IT 企业的管理层不重视质量管理，当万物互联到来之时，这是很危险的。因此特发布质量管理宣言，以引起软件行业的重视。

全员对质量负责 胜于 测试人员对质量负责

产品的质量 胜于 文档的质量

质量由客户来批判 胜于 质量由已有的标准/规范来评判

及时响应客户需求 胜于 遵守已有的约定

缺陷预防 胜于 发现缺陷

一次把事情做对 胜于 过程管理

虽然左边更有价值，我们也承认右边也有价值，提醒大家不要走极端