敏捷测试的核心

本文首发于「BY林子」，转载请参考版权声明。

---

Q：质量内建跟敏捷测试的关系是什么？能分开吗？

A：我认为质量内建是敏捷测试的核心。

01. 传统测试

敏捷测试是相对于传统测试而言的，在聊敏捷测试之前，我们先看传统测试是什么样的。传统测试通常有如下的特点：

• 独立的测试部门：测试人员跟开发人员不属于同一个部门，各自独立。
• 测试工作主要由测试人员承担：功能与非功能测试，手动与自动化测试，冒烟测试、回归测试、发布测试等，基本都是测试人员的事情。
• 详尽的测试用例文档：测试用例文档一般都要求详细的执行步骤。
• 集中的回归测试：有独立的集中回归测试阶段，对所有功能进行全面的测试覆盖。
• 发现更多的bug：测试人员的目的是发现更多的bug，甚至有些部门会把bug数量作为绩效考核的目标。

02. 敏捷测试

敏捷测试是伴随着敏捷开发过程的所有质量相关活动，有着如下的特点：

• 不能独立存在，不是一种测试类型或方法
• 敏捷测试不仅是测试人员的工作，敏捷测试是团队的活动
• 抛开敏捷开发谈敏捷测试没有意义

敏捷测试的目标也不再是发现更多的bug，而是尽快的交付高质量的软件。

那么软件的高质量怎么获得呢？著名质量管理专家指出：质量不是检测出来的，产品生产出来质量已经在那里了。因此，通过加强测试保障没法提高软件质量，需要将质量内建到软件产品中。

03. 质量内建

软件的缺陷暴露的越晚，修复的成本就越高；前期对缺陷预防的少，后期发现的缺陷就会多；前期做好了缺陷预防，后面暴露的缺陷就会减少。因此，我们需要提前预防缺陷，而不是等开发完成了才发现很多的问题，这就是质量内建。

早在12年前接触敏捷测试的时候，有三个词深深的印在了我的脑海里“Test early，test often，test first（尽早测试、频繁测试、测试先行）”，其实，它们正好对应着质量内建的三个关键实践：测试左移、持续测试、测试驱动开发，是敏捷测试最核心的部分。

测试左移

测试左移要求测试在软件开发生命周期的左侧尽早介入，可以是需求分析阶段，也可以是更早的inception阶段。左移的测试人员可以做的事情可以有一起挖掘需求、分析需求、澄清需求、评审需求、参与技术方案讨论等，主要目的是利用测试人员独有的视角和对系统的了解，在各个环节进行必要的输入，确保团队对于需求理解的一致性，确保团队能够做正确的事情。

测试人员参与需求分析的价值主要体现在下面两个方面：

业务价值

1. 尽早的接触需求能够让测试人员更好的理解业务价值，从而为后续的系列测试工作提供帮助。
2. 同时，需要测试人员更多的考虑业务价值，在各个需求环节能够从业务价值的角度提供输入，包括终端用户行为、业务流程、业务风险等维度的考虑。可以参考我的文章《敏捷测试如何优化业务价值》。

用户故事

用户故事作为敏捷开发过程中传递业务需求的载体，非常重要。对于用户故事的拆分和用户故事验收条件的描写都有很高的要求，测试人员参与可以帮助评审用户故事，提升用户故事的质量，以更清晰的方式在团队传递需求。要求测试人员能够透彻的理解用户故事拆分的“INVEST”原则，并利用这些原则来评审用户故事：

• 独立的（Independent）：要尽量避免故事间的依赖，做到相互独立，如果碰到两个依赖很强的用户故事，可能需要合并或者换一种拆分方式摆脱依赖。
• 可讨论的（Negotiable）： 故事是可讨论的，不是签署好的合同或者软件必须实现的需求。故事卡是功能的简短描述，细节将在客户团队和开发团队的讨论中产生。
• 有价值的（Valuable）：用户故事要对用户或者客户有价值。注意，有些用户故事可能不会给终端用户带来价值，比如信息配置类的故事，用户不会关心，但是对客户是有价值的。
• 可估算的（Estimable）： 开发人员没法估算某个故事可能的原因是开发人员缺少相关的领域知识或技术知识，也可能是用户故事太大了。对于前者，需要给开发人员讲述清楚业务上下文和相应的领域知识，并且要有相关技能的开发人员参与估算；如果是故事太大了，则需要进一步拆解成更小的可以估算的故事。
• 小的（Small）：故事太大不利于估算，可能需要拆解；故事太小也不利于计划，可能需要合并。故事的大小需要根据团队具体情况来定，但要尽量小一点。
• 可测试的（Testable）：用户故事必须是可以测试的，不然就没法验证开发人员实现的正确性。

持续测试

测试左移是为了让团队清晰一致的理解需求，从而做正确的事情；而持续测试则是在整个开发生命周期里的各个环节（生命周期最左侧，一直延续到最右侧的生产环境）的测试活动，以帮助快速收集反馈，从而正确的做事情。

持续测试的内容包括对持续功能测试，也包括性能、安全等的内建、持续测试；形式可以是静态分析、评审，也可以是动态的测试，包括手动执行的各种测试，以及持续集成流水线上的持续执行的自动化测试。下面我们从用户故事生命周期为例来看可以有哪些持续的测试活动：

故事分析： 这个阶段主要是对故事的拆分、故事里的AC（Acceptance Criteria，验收标准）等内容进行评审，包括功能和跨功能需求的确认，看是否有需求遗漏或者不合适的需求，同时可以重点标注一些开发或者后期验证需要特别注意的点。

故事启动： 故事启动是在开发人员开始实现用户故事之前对需求进行澄清，确保业务、开发和测试对该用户故事要实现的需求达成一致的认识，包括功能和跨功能需求（安全、性能等）。

故事开发： 开发人员开始开发用户故事，并完成底层自动化测试（单元测试和接口层测试等）；测试人员可以开始设计相应的测试用例和UI层功能自动化测试，同时可以将在测试设计过程中发现/想到的用户故事相关的问题反馈给团队。

故事验收： 故事验收是开发人员开发完成一个用户故事之后，对系统实现进行验收的环节，这个环节跟“故事启动”环节是对应的，同样包括对功能需求和跨功能需求的验证。

故事测试： 完成相应的功能自动化测试，让其在持续集成流水线上按需执行；同时，需要基于该用户故事执行相应的探索性测试。

故事演示： 将开发完的功能演示给客户，一般以特性为单位，需求、开发或测试人员来负责演示都可以，目的是尽早收集到客户的反馈，是客户验收的环节。

测试驱动开发

测试驱动开发就是大家所熟知的TDD，常见的有两种测试驱动开发，分别是：

单元测试驱动开发（UTDD）： 在编写产品代码之前，先写单元测试，由单元测试驱动出产品功能代码，主要是为了保证设计的完备性，更好的实现质量内建。单元测试一般都是开发人员来实现的，测试人员不参与实现，但可以在故事验收阶段对开发编写的单元测试进行评审，确保单元测试覆盖的有效性。

验收测试驱动开发（ATDD）： 除了单元测试之外，还可以先实现自动化的功能验收测试，在功能开发完成之后，要求所有验收测试都是能通过的。这样做可以尽早利用功能自动化测试收集反馈，更好的保证功能需求实现的正确性。验收测试可以由开发人员和测试人员结对完成或者测试人员独自完成。

说到ATDD，我们通常很容易联想到行为驱动开发（BDD），常被人们混为一谈，有必要再次说明一下。其实，BDD强调的是不同角色之间的协作，更好的理解和澄清需求，确保需求理解的一致性。BDD不是关于测试的，可以没有测试，但是可以指导测试，我们通常可以基于BDD的方式实现自动化测试。而ATDD是关于测试的，必须有测试。更多关于BDD的内容，可以参考我的文章《说起BDD，你会想到什么》。

04. 总结

1. 敏捷测试的核心是质量内建，而质量内建就是缺陷预防；
2. 测试左移、全阶段的持续测试、测试驱动开发是质量内建成功的关键。

---

---

本文首发于「BY林子」，转载请参考版权声明。