敏捷测试宣言与原则解读

01. 敏捷测试宣言

全程的测试介入 over 孤立的测试阶段

团队整体对质量负责 over 测试人员独力把关质量

持续性的精准自动化测试 over 回归式的全量自动化测试

质量内建 over 质量检测

解读

敏捷测试宣言表达的是我们对于敏捷测试的信仰和价值观，分别包括流程、团队合作、自动化和核心价值观四个维度。

在以往软件发布周期较长、需求变化频率较低、不同角色间的合作壁垒较高的环境下，传统的开发模式所采用的孤立的测试阶段、测试人员独立把关质量、回归式的全量自动化测试和质量检测，是有其价值的。但是，在敏捷开发模式下，敏捷测试则更强调左侧的价值观。

全程的测试介入

敏捷测试提倡测试左移和右移，从软件生命周期的早期（左侧）一直到产品发布上线后的生产环境，都需要有测试的介入和测试活动的开展。

左移是为了更好的理解和澄清需求，以减少需求理解不一致导致的浪费；而右移是充分利用生产环境的数据来优化开发和测试流程，以增强软件系统应对各种不可预测性的能力。

左移和右移并不仅仅是将测试活动移到两侧端点，更强调的是每个环节的参与，也就是全程测试介入，这是从流程上保障高质量软件交付的关键。

团队整体对质量负责

敏捷提倡全功能团队，团队的角色之间分工不再那么明确，不同角色间的协作更加密切，团队一起为质量负责，是敏捷测试需要遵循的指导性原则。

团队需要对质量目标有统一认识，在敏捷软件生命周期的每个环节有不同角色的共同参与，实现质量目标是每个角色的职责。

持续性的精准自动化测试

自动化测试是敏捷测试的基础，是快速反馈的必要手段。自动化测试不能一味的追求覆盖率，而是要追求有目的的精准覆盖。也就是说，自动化测试首先必须是有效的，是基于业务风险考虑的，才能真正实现快速反馈。

自动化测试需要能够在持续集成流水线上持续的运行，为每次代码提交提供反馈，以确保系统功能不会因为新代码的提交而被破坏；同时，随着功能的不断迭代，自动化测试需要相应的更新、增加，确保新功能是有有效自动化测试覆盖的。

质量内建

质量内建是敏捷测试的核心，需要将测试全程介入、团队为质量负责和持续精准的自动化测试结合起来，在敏捷软件生命周期的每个环节做好缺陷的预防，把质量融入到产品的开发构建中。

02. 敏捷测试原则

1. 我们的目标在于和团队一起尽快地交付高质量软件。
2. 测试人员尽早参与软件早期阶段，与所有团队角色合作，通过实例化需求，确保对业务价值理解的一致性。
3. 测试人员关注生产环境状态，收集数据，指导和优化前期的分析、开发和测试。
4. 测试人员和开发人员同处一个产品项目团队，而不是独立的测试团队或部门。
5. 测试人员负责探索性测试，和开发人员结对，设计、实现和维护自动化测试。
6. 自动化测试在流水线中持续精准执行，快速发现每次代码提交对于已有功能的影响。
7. 测试数据对于自动化测试是充分的，并能按需获得。
8. 测试活文档化，和代码一起，作为知识资产进行版本化管理。
9. 自动化测试需要有效的分层。
10. 预防缺陷，而不是关注缺陷的数量。

解读

敏捷测试需要遵循如下10条原则：

1. 我们的目标在于和团队一起尽快地交付高质量软件。

敏捷测试的目标，所有的测试活动都围绕这一目标开展。敏捷测试人员要有思维上的转变，不再是关注于发现更多的缺陷，而是思考和采取相应的措施以帮助团队更快、更高质量的交付软件。

2. 测试人员尽早参与软件早期阶段，与所有团队角色合作，通过实例化需求，确保对业务价值理解的一致性。

测试左移，团队合作，需求的清晰表达，确保团队在做对的事情，拥抱变化的同时能够少走弯路。

3. 测试人员关注生产环境状态，收集数据，指导和优化前期的分析、开发和测试。

测试右移，由于生产环境的特殊性，并不能将测试活动简单右移到生产环境，只能通过收集和分析生产环境的数据，利用这些数据来优化开发、测试和业务价值，让生产环境和开发过程形成良性环路。

4. 测试人员和开发人员同处一个产品项目团队，而不是独立的测试团队或部门。

测试人员属于开发团队的一员，推倒角色之间的沟通壁垒，测试人员与开发人员进行密切的合作。

5. 测试人员负责探索性测试，和开发人员结对，设计、实现和维护自动化测试。

自动化测试不只是测试人员的职责，单元测试和接口测试主要由开发人员负责，而界面层自动化测试同样需要开发人员一起参与设计、实现和维护，这样才更高效；同时，可以让测试人员抽离出来去做更有价值的事情——探索性测试。

6. 自动化测试在流水线中持续精准执行，快速发现每次代码提交对于已有功能的影响。

自动化测试需要在持续集成流水线中运行，并且做到能够按需精准执行，在追求完备覆盖的同时还能高效运行，快速提供反馈。

7. 测试数据对于自动化测试是充分的，并能按需获得。

自动化测试应该有完备的数据集，包括正常和异常情况的覆盖、满足不同环境或不同平台的执行要求等；同时，需要有完善的数据创建和管理方案，确保不同需求下的自动化测试能够获得相应的测试数据。

8. 测试活文档化，和代码一起，作为知识资产进行版本化管理。

需求文档要跟自动化测试关联，变成可执行的活文档，并且要跟产品代码一起作为知识资产进行版本化管理。

9. 自动化测试需要有效的分层。

自动化测试要根据不同的测试对象进行有效分层。越往底层的测试实现成本更低、执行更高效、定位更准确，但覆盖范围有限，不能跟业务很好的关联；越往顶层的测试越接近业务、更能体现业务价值，但是执行速度、稳定性较差、定位问题较难。需要根据系统要求、技术架构等项目具体情况规划每层测试的合理占比，不能盲目的追求多而全的覆盖。

10. 预防缺陷，而不是关注缺陷的数量。

质量内建是敏捷测试追求的核心价值观，而质量内建本质上就是缺陷预防。敏捷测试需要团队把重心放在预防缺陷上，提高软件的内建质量，而只关注缺陷数量、甚至把缺陷数量当做考核指标的情况是违背这一核心价值观的。当然，对缺陷数量趋势的正确跟踪和对缺陷根因的深入分析，是帮助预防缺陷的有效手段，是值得推荐的。

文/ThoughtWorks 林冰玉

---

更多精彩洞见，请关注微信公众号：ThoughtWorks洞见