在敏捷和精益研发的大背景下，产品质量与测试效率的平衡是极为重要的，很多实际情况是这样的：

• 项目需求不清楚，进度紧张，资源有限，然后是 “XX 时候需要保障上线”
• 测试人员的经验不足，对于产品的理解不够，出现遗漏测试覆盖点
• 项目的质量、进度风险高，如何把控成为难点

一个问题

如何“以尽可能少的时间，发现尽可能多的、尽可能重要的 bug”这个问题被推到了风口浪尖

基于 Simon Sinek 提出的黄金圈法则，由内向外思考，从 why 开始。研发效能的提升是数字化时代一个重要的战略目标。精益研发作者何勉提出效能提升的本质在于：“持续地顺畅高质量交付有效的价值”。对于一名测试工作者来讲，在这样的前提背景下，一个重要的职责在于把握产品质量与测试效率之间的这个平衡，做到 “质效合一”。回到这个问题:如何 “以尽可能少的时间，发现尽可能多的、尽可能重要的 bug”,其本质就是产品质量与测试效率的 “平衡之道”。

一种"较优解"

对于测试的日常工作，从一个简要的流程，我们可以理解下它涉及到哪些活动
了解产品需求 - 确定测试范围 - 梳理测试点（测试分析）- 编写测试用例（测试设计）- 测试用例执行 - 产品上线
如果你是一名测试工作者，你会非常熟悉这个流程，这不就是每个迭代周期都在干的事情，这没什么特别的。事实上，的确如此，本文的意图并不在于创新的去提出一种新的测试模式来把握产品质量与测试效率的平衡，其重点在于在日常的测试模式中寻求一个较优解。
对于怎样寻求这个较优解，输入来源重点包含了：James Bach 的 HTSM（启发式测试策略模型）、邰晓梅提出的海盗派测试分析-MFQ&PPDCS，邰晓梅可以算是 James Bach 的学生以及同行者，两人构建的模型框架来讲，一个重要的基础是基于上下文驱动的测试思维，一个重要的原则是基于风险的测试（RBT）。

[一个基础] 上下文驱动的测试思维

上下文驱动的测试思维，其重点在于要关注项目的上下文，并认识到上下文是会变化的，测试策略和方法要根据上下文来制定，并根据其变化及时调整、不断优化。
上下文驱动的测试思维是主要的敏捷思维方式之一，也是敏捷模式下测试分析的基础。
James Bach 是上下文驱动流派里大名鼎鼎的代表人物，多年以来，他和 Michael Bolton 一直在实践和发展上下文驱动的思想，包括他提出的探索式测试、启发式测试策略 HTSM、SBTM（Session-based Test Management）和快速软件测试（Rapid Software Testing）方法论。可以说，James Bach 的整个测试理论体系都是建立在上下文驱动的测试思维基础之上的。
启发式测试策略 HTSM 是基于上下文驱动的测试思维的具体实践，基于上下文驱动的启发式测试策略（Heuristic Test Strategy）侧重考虑质量标准、项目背景、产品元素等 3 个方面对于测试技术、方法、工具的影响，每个方面都包含多项因素，即各种上下文因素，并最终向用户交付满足其质量要求的产品，如图所示。只有把上下文各种因素的影响搞清楚，基于上下文驱动的测试思维才能落地。总体来说，HTSM 是一系列指导性的词语组成，让测试者从"高度抽象"到"底层细节"对产品和测试进行思考。它不是教你如何去测试，而是启发你如何去思考，从而挖掘出测试对象和策略。

接下来针对启发式测试策略模型中的三个方面进行阐述：项目背景、产品元素、质量标准

项目背景（Project Environment）

要做好某个产品或者特性的测试，自然要理清楚项目的背景，特别是和软件测试相关的项目要素，获取、分析和综合理解与这些要素相关的详细信息，更好的明确测试目标、测试范围、测试进度安排、测试资源、测试环境等，采用相适应的测试方法和策略，更好地开展测试活动。James Bach 在启发式测试策略模型中对于 Project Environment 给出的分析引导，如下图所示，结合落地实践来看着重对项目目标（Customer 用户）、测试范围（Test Item）、进度安排（Schedule）、可用的资源（Developer Relationship & Test Team）、测试环境&工具（Equipment&Tool）、测试准出（质量要求&交付件）给出了分析，这些部分是一个测试策略的重要组成部分。

产品元素（Product Element）

产品就是我们的测试对象，自然更要关注。项目一旦启动，测试就要尽早介入，了解产品需求，了解产品的架构设计、界面设计、可用性设计、安全性设计等，并参与相关评审，通过这些活动，能够更好的掌握被测系统。启发式测试策略模型中给出的Product Element 就是为了更好的做测试分析，确认测试覆盖范围，如下示意图

质量标准（Quality Criteria）

质量标准主要从 3 个方面考虑，即产品的目标用户、对质量的具体要求、参照哪些质量标准。从本质上来看，主要在回答好 3 个问题：

• 软件给谁用？
• 用户对质量有什么具体要求？
• 参照哪些质量标准或行业规范？

软件给谁用？
用户有哪些？用户的痛点是什么？用户场景是怎样的？用户画像是什么？用户与用户之间的优先级？用户最关心的地方是什么？用户实际使用的环境？···
用户对质量的要求？
在软件质量模型的 ISO/IEC 25010 中定义了:使用质量模型和产品质量模型。软件产品质量模型包含 八 大质量特性：功能适应性、效率、兼容性、易用性、可靠性、安全性、可维护性、可移植性，每项质量特性还进一步分为多项子特性

基于这些质量特性，结合用户、业务和产品特点等进行更深入的分析，以了解用户对质量的具体要求，哪些质量特性需要优先关注。
参照哪些质量标准或行业规范？
产品必须要遵守哪些标准或行业标准？这也是需要了解清楚的。无论是航空航天、汽车电子行业，还是金融、交通等，除了通用的国际 / 国家标准，还有特定的行业质量标准或规范。了解用户来自哪个领域或行业，就要收集和熟悉该行业的规范和标准。例如，如果项目是证券行业的应用系统，就属于金融行业，那么则有 200 多项相关规范标准。
对于产品的特定功能，也有相应的规范和认证，比如支持蓝牙功能的产品，如果想在产品外观上标明蓝牙标志，则必须通过 BQB（Bluetooth Qualification Body）认证，否则会被蓝牙技术联盟视为侵权。这时，企业需要考虑如何开展预测试，以保证产品在预期的时间内拿到认证。

[一个原则] 基于风险的测试

什么是基于风险的测试 (what)

基于风险的测试，Risk Based Testing，简称 RBT，是一种以软件质量风险作为测试出发点和测试活动的主要参考依据的测试方法，它根据风险的严重程度和出现的概率，计算出风险度（风险等级），然后再根据不同的风险等级来决定测试的优先级和测试覆盖范围。

根据产品的风险（risk）设计测试是一种常见的测试设计思路。在复杂的现实世界，产品面临的风险多种多样，只有全面考虑、周密测试才能避免风险暴露导致的严重后果。可以回看这个目标 “以尽可能少的时间，发现尽可能多的、尽可能重要的 bug”，其本质就是在对风险识别和分析后做出的取舍，找到这个平衡。
基于风险的测试最重要的观点是将软件的潜在风险作为测试计划的依据和目标。对当前潜在风险的全面分析和把握，才能有效地设计并组织恰当的测试，用尽可能少的测试资源发现尽可能多的潜在缺陷，最大限度规避潜在风险，降低维护成本。

为什么要基于风险的测试 (why)

由于缺陷的群集效应，相比基于规格说明的测试，基于风险的测试可以通过精准的风险识别来达到更高效的测试。
由于测试的不可穷尽性，在测试过程中经常会面临测试资源、时间不充分等问题。在有限的时间和资源情况下，如何选择测试重点？如何在有限的测试时间内完成测试？如何合理利用测试资源完成测试？只能在有限的时间、资源和质量之间找平衡。
采用基于风险的测试，能帮助测试管理人员优化测试活动，平衡测试时间、成本、范围与质量，合理的制定测试计划和方案，对测试资源、测试优先级做出合理的安排，让测试更具针对性，提高测试效率和产品质量，因此基于风险的测试越来越被广泛的运用于测试活动中。
而且，基于风险的测试也不再强迫所有人依靠诸如缺陷数、测试用例数等不充足的策略性度量来做发布决定，而是和利益相关者一起来做决定剩余风险的可接受级别，从而做出合理的发布决定。

基于风险的测试怎么做 (how)

基于风险的测试主要过程包括收集信息、风险识别、风险评估、风险控制且应贯穿于软件的整个生命周期，涉及测试准备、测试分析与测试设计、测试执行等测试活动中，有效形成闭环。风险最重要的一个特征是风险是不断变化的，永远不要指望着一次性设计出恰到好处的测试案例，让测试分析与测试设计活动告一段落。实际上，每个过程中每一个环节都伴随着无数的猜测，风险发生的可能性和风险的影响也是在不断变化的，这就决定了好的测试分析与测试设计活动不可能是一次性的活动，它注定是一个迭代的，不断进行的活动。

[一种实践] 一种测试模式

将基于上下文驱动的测试思维以及基于风险的测试，落地为一种较好的测试模式是极为重要的，就像基于风险的测试不是按部就班的实施，而是要落地为团队日常测试工作中的一种习惯，一种思考方式。在这方面做得较好的践行者之一，当属邰晓梅，她编写了《海盗派测试分析：MFQ&PPDCS》这本书，书中重点不是讲解一个个已有的测试设计方法，而是秉着 “从实际问题出发，而不是从方法出发” 的思路，站在测试分析和测试设计实战的角度，讲解软件测试可循的规律和方法，如当一个测试人员接手一个新的被测系统或被测特性时，如何运用各种测试技能，一步步分析测试对象，最终完成测试任务。她提出了海盗派 Tester 的核心原则：主动收集信息，尽早提供反馈，及时调整策略，基于风险测试。
有的人读了这本书一开始可能会觉得提了一些新的理念和概念，理解起来不是很顺畅，事实上只要拨开这层迷雾，抓住其本质：站在测试分析和测试设计实战的角度，讲解软件测试可循的规律和方法；其主要内容本质是在阐述一种日常测试工作的测试模式：了解你的测试任务 - 测试覆盖大纲 - 分析建模 - 测试设计 - 测试执行

了解你的测试任务（KYM）

依据黄金圈法则，由内向外思考：

• 为什么要做 KYM？
• 怎么做 KYM？ 阐述如图所示

KYM 是启发式的，对于 “基于风险的测试” 中，它是收集信息的重要动作，主要包括 4 个方面的信息收集：了解用户（Customers）、了解项目（Project）、了解产品（Product）、了解任务（Mission）

为什么要做 KYM？

核心观点：促进测试人员与周边人员的沟通，及时获取有价值的信息，提前发现风险所在。
从日常测试中，会有以下现象（只列举一二）：

• 测试人员不了解真实需求的背景，拿着需求、设计文档就开始做测试设计
• 测试人员离用户太遥远，对用户漠不关心，为什么提这样的需求，最终要达到什么目的
• ·······

从实际的工作中来看，产品研发有一个愿景是希望缺陷越早发现越好，有些时候在个人汇报中，可能还会提及到自己在需求阶段发现了多少个缺陷。事实上这些问题的发现，是需要来源于对用户、项目、产品了解的 “信息” 所作出的决策，这也是为什么要做 KYM，其价值在于：促进测试人员与周边人员的沟通，及时获取有价值的信息，提前发现风险所在。

怎么做 KYM？

核心观点：KYM 的本质就是通过不断的问问题，收集信息，了解上下文
获取信息的过程就是不断的问问题，而如何问问题，问什么问题，就是怎么做 KYM 的本质所在。问问题（Ask Question）的能力对于测试人员来说是非常重要的。邰晓梅借鉴了 James Bach 启发式测试策略模型中的 Project Environment 来构建问问题的指引，缩写为 “CIDTESTD” 引导词法，如图所示，CIDTESTD 的 8 个方面来了解用户，了解项目，了解任务。

什么时候应用 KYM？

核心观点：在项目的任何阶段介入都可以应用 KYM，KYM 贯穿整个测试项目始终，它不是一次性的行为

测试覆盖大纲（TCO）

为什么要做 TCO？

做过了 KYM，已经对用户、任务和被测对象有了一定的了解，是否现在就可以开始做测试分析和测试设计？答案是否定的，因为对于被测对象的认识还是过于粗糙，如果只抓住一个点就往下深入，很可能陷入 “只见树木，不见森林” 的迷雾。画 TCO 主要帮助达成的是：信息提炼、信息重组

怎么做 TCO？

测试覆盖大纲的编写可以有两种方式：
一种是依据启发式测试策略模型中产品元素（SFDIPOT）
一种是 MFQ，MD（基于模型的单功能测试分析与测试设计）、FI（功能交互的测试分析与测试设计）、QC（非功能的质量属性的测试分析与测试设计）
前者提供的是简单快速的分析，以便可以通过输出的 TCO，选取测试点快速进行探索性测试
后者提供的是更深入系统的分析，以便能够全面的测试验证被测对象

分析建模（Modeling）

为什么选择 PPDCS 方法？

邰晓梅在《海盗派测试分析》中提出了通过 PPDCS 方法来进行进行分析建模，Torbjorn Ryber 给出的 Model 解释是模型（Model）以表格、流程图或其他图形化的形式刻画系统是如何工作的。事实上，Model 是对测试对象抽象化和简单化的一种表示，被测对象也可以用 model 表示其内在的逻辑关系，画 model 的过程就是测试分析的过程。
一个重要的问题：面对各具特征的被测对象，面对种类繁多的测试涉及方法，选取哪一种方法来建模最有效？
仔细研究那些基本的测试技术，发现他们大体可以分为几个类别，每一类别有其独特的 “特征”；而研究被测对象时，发现对于被单独测试的单功能来说，其内部逻辑也体现出某种主要的特征。那么当两种 “特征” 吻合时，就可以用测试技术来分析这个单功能了，这就是《海盗派测试分析》中提出了 PPDCS 方法的由来
什么是 PPDCS 方法？

怎么做 PPDCS？

PPDCS 方法实施时，可以从以下 4 个方面展开：
关注触发词语 Triggers
抓住核心功能 Essentials
尝试不同特征 Spanning Differences
围绕既定目标 Targets

总结

本文的出发点是思考如何提升团队内部测试同学的测试效率，进而延伸思考一个问题如何 “以尽可能少的时间，发现尽可能多的、尽可能重要的 bug”。其核心是从日常的测试工作模式中寻求一种较优解，结合业界一些大佬，例如 James Bach、邰晓梅、朱少民等提出的模式框架，进而以上下文驱动的测试思维为基础，以基于风险的测试为原则，推导出一种优秀的测试实践模式。

参考引用

• James Bash 的 HTSM
• 邰晓梅的《海盗派测试分析：MFQ&PPDCS》
• 朱少民老师专栏中关于测试策略的讲解