Docs

Appearance

第26讲：基于上下文驱动思维的测试分析 ​

从这一讲开始，我们就进入了第 5 部分内容的学习：敏捷测试分析与计划。在这一部分你将学到：测试需求分析、测试风险的识别、测试策略及测试计划的制定。今天先从基于上下文驱动的测试分析开始。

关于上下文驱动的测试思维，我在第 4 讲中简单介绍过，就是我们要关注项目的上下文（所处的环境、所要满足的条件），并认识到上下文是会变化的，测试策略和方法要根据上下文来制定，并根据其变化及时调整、不断优化。上下文驱动的测试思维是主要的敏捷思维方式之一，也是敏捷模式下测试分析的基础，需要专门讲一讲。

上下文驱动测试流派 ​

软件测试有几个主要的流派，包括分析流派、标准流派、质量流派，敏捷测试也算一个流派，有敏捷测试的思维、敏捷测试的原则、敏捷测试的流程以及一系列敏捷测试实践，比如 UTDD、ATDD/BDD、持续测试等，另外，还有一个著名的"上下文驱动测试流派"。虽然实践它的人不是很多，如果一旦理解它，就会深受影响，对软件测试也会有崭新的理解：测试在你眼里不再是一项简单、重复的劳动，而变成了一项极具创造力的工作，并且赋予你充分的空间，以展示你的才华和技能。

上下文驱动流派最初是由 4 个人发起的，其中 Cem Kaner、James Bach 和 Bret Pettichord 在 2001 年合著了一本经典之作《软件测试经验与教训》（Lessons Learned in Software Testing）。在书里正式提出了上下文驱动流派及其 7 个原则，如图 1 所示。

James Bach 是这个流派里大名鼎鼎的代表人物，多年以来，他和 Michael Bolton 一直在实践和发展上下文驱动的思想，包括他提出的探索式测试、启发式测试策略、SBTM（Session-based Test Management）和快速软件测试（Rapid Software Testing）方法论。可以说，James Bach 的整个测试理论体系都是建立在上下文驱动的测试思维基础之上的。

上下文驱动的测试是一种思维方式，例如，它认为只有优秀实践、没有最佳实践，因为他人的最佳实践，只说明最适合他，但不一定适合我们；即使是自己的最佳实践，也只能说明昨天是最佳的，并不代表今天和明天。软件测试也一样，需要根据不同的上下文制定不同的测试方案、选择不同的测试技术和工具，并对它们运用自如，真正为你所用，然后去发现影响产品价值的缺陷。

这有点像中医看病，同样的病，针对病人的不同情况，会开出不同的药方，而且根据病情的变化，增减不同的药，调整每味药的剂量，你能说哪个药方是治疗某种病的最好药方吗？也没听说过哪位中医只要熟记药方就能成为名医。下面是一些上下文驱动测试的具体例子：

  • 在项目进行中，以前做某一重要模块的开发人员离职了，换了一个没有经验的开发人员，这一模块的风险是不是要重新评估？测试范围是不是需要调整？
  • 你的公司准备把产品的目标用户拓展到医疗或者航天领域，是不是必须遵守医疗或者航天领域的行业规范和安全标准？
  • 敏捷模式下强调测试左移，如果项目很好地实践了需求评审、设计评审和代码评审，你的测试策略是怎样的？如果没有，你的测试策略又该怎样制定？

因此，上下文驱动的测试认为不存在放之四海而皆准的最佳实践，只有根据上下文不断调整的优秀实践。也正因为如此，软件测试才是一项有创造力、需要不断磨练、提升自己的工作。这样的工作才更有意思，不是吗？

与上下文驱动的软件测试相对立的实践是标准流派，一切皆有标准可以参考，可以按部就班进行测试，按照标准所要求的方法、流程和步骤进行测试。标准不仅明确，而且稳定、很少变化，基于标准去做测试，就简单得多，几乎不需要动什么脑子，只要对照标准去做检查（check），检查产品是否符合标准的要求。所以 James 等上下文驱动流派认为这种"检查"不是测试，虽然许多人喜欢这种测试方式，操作简单、上手快、容易复制，也容易实现度量，成熟度也能一级一级地提升上去。

而上下文驱动的测试正好相反，它认为测试是不能标准化的，因为软件研发中没有任何一个上下文是相同的，不同的上下文就需要不同的测试策略和测试方法，提倡关注对于业务需求的测试覆盖和发现对用户有影响的缺陷。

同时，上下文驱动也是敏捷测试甚至是敏捷开发的重要基础。因为敏捷模式强调拥抱变化，快速响应客户需求，而实践上下文驱动的软件测试就是要根据项目的变化及时调整测试策略和测试方法，给与快速和持续的反馈。

基于上下文驱动的启发式测试策略（Heuristic Test Strategy）侧重考虑质量标准、项目背景、产品元素等 3 个方面对于测试技术、方法、工具的影响，每个方面都包含多项因素，即各种上下文因素，并最终向用户交付满足其质量要求的产品，如图 2 所示。只有把上下文各种因素的影响搞清楚，基于上下文驱动的测试思维才能落地，下面我们就来好好分析、讨论这些上下文因素。

质量要求 ​

软件的质量要求，从根本上说是为了引导和满足用户的需求。软件测试的目标在一定意义上说，就是为了保证软件产品质量具有较高的水平。产品的质量主要靠构建，也在很大程度上依赖于软件测试的投入以及执行的结果，所以要做好测试工作，必须认真回答下面几个问题。

  • 软件给谁用？

用户是谁？有天天离不开它的核心用户，也有偶尔使用的外部用户，如系统后台维护、技术支持的用户。当前的用户构成怎样？拿到的用户画像是怎样的？年龄、职业、受教育程度等是如何分布的？未来哪些人会成为新的用户？软件测试人员要站在用户角度想问题，分析、设计软件测试。下一讲，我会专门讲解作为测试人员如何培养自己的业务与用户体验分析技能。

  • 用户对质量有什么具体要求？

根据 ISO 25000 系列标准，软件产品质量包含 8 大质量特性------功能适应性、兼容性、可靠性、易用性、安全性、效率（性能）、可维护性和可移植性，每项质量特性还进一步分为多项子特性，如图 3 所示。

基于这些属性，结合用户、业务和产品特点等进行更深入的分析，以了解对质量的具体要求，哪些质量特性需要优先关注。比如对于运营商定制的手机产品，不同的运营商有不同的验收测试体系和质量要求，美国 AT&T 制定的 10776 等系列标准，对手机稳定性的要求非常高。

  • 参照哪些质量标准或行业规范？

产品必须要遵守哪些标准或行业标准？这也是需要了解清楚的。无论是航空航天、汽车电子行业，还是金融、交通等，除了通用的国际 / 国家标准，还有特定的行业质量标准或规范。了解用户来自哪个领域或行业，就要收集和熟悉该行业的规范和标准。例如，如果项目是证券行业的应用系统，就属于金融行业，那么则有 200 多项相关规范标准。

对于产品的特定功能，也有相应的规范和认证，比如支持蓝牙功能的产品，如果想在产品外观上标明蓝牙标志，则必须通过 BQB（Bluetooth Qualification Body）认证，否则会被蓝牙技术联盟视为侵权。这时，企业需要考虑如何开展预测试，以保证产品在预期的时间内拿到认证。

项目因素 ​

软件测试是软件项目的一部分，要做好软件测试，自然要清楚项目的背景，特别是和软件测试相关的项目要素，获取、分析和综合理解与这些要素相关的详细信息，更好的明确测试目标、测试范围、测试进度安排、测试资源、测试环境等，采用相适应的测试方法和策略，更好地开展测试活动。需要收集的项目因素包括以下几个。

  • 项目目标：测试是为了实现项目的目标，或者说，测试目标是在项目目标的基础上制定的。
  • 交付物：每次产品发布中，研发团队不仅要交付软件版本，而且要交付相关的文档，包括用户手册、管理员手册等。交付物也直接影响测试范围和测试工作，如果要交付用户手册、管理员手册等，这些文档也需要验证；如果要交付测试计划、测试用例，那么自然必须要有而且需要规范、易读。
  • 质量要求：这里的质量要求是指当前项目（即敏捷中的每次迭代）对质量的具体要求。例如，这次迭代中待实现的某个功能要求团队特别关注，而另一个功能只是尝试，这样在功能测试项的优先级安排上，前一个功能的优先级要高得多------尽早测试、充分测试；再比如，这次迭代系统能支持的用户并发数要比上次迭代提高 30%，决定了性能测试验证的具体指标值。
  • 项目范围：在敏捷开发里，每次迭代的目标是产生一个可交付的软件，但不一定每次迭代后都必须交付或发布给用户，很多团队选择几次迭代发布一次。每个要发布的版本及其中每次迭代的用户故事列表就构成了项目范围，项目范围是决定测试范围的关键要素之一。
  • 进度：项目（每次迭代）开始和结束日期、期间重要的里程碑等会影响测试计划的制定，例如每次迭代中持续测试、用户故事验收测试以及后续的端到端的验收测试，都需要参考项目进度计划来制定。
  • 可用的资源：每项测试活动都需要资源，而资源都是有限的，清楚项目的预算和资源，包括可用的人员、工具、环境等，对测试人员安排、测试环境准备都是有必要的。
  • 项目类型：是长期性的产品开发，还是一次性项目？是独立项目，还是多方合作的综合性集成项目？和合作方的合作方式是什么？是本地项目，还是外包项目？
  • 研发团队：研发团队的人员数量以及技术水平。开发、测试、业务分析的相关经验如何？单元测试是否充分？代码评审效果以往表现如何？这些对测试策略、测试工作量都有较大影响。
  • 开发工具和语言：是 Visual Studio，还是 Eclipse、IDEA、PowerBuilder？是 Java/JSP，还是 C++、Python、Go 等语言的一种或几种？开发工具和编程语言的选择对测试环境搭建、自动化测试实施等也有影响。

产品元素 ​

产品就是我们的测试对象，自然更要关注。项目一旦启动，测试就要尽早介入，了解产品需求，了解产品的架构设计、界面设计、可用性设计、安全性设计等，并参与相关评审，通过这些活动，能够更好的掌握被测系统。

为了更好分析被测对象，可以从以下几个方面去分析。

  • 结构：软件系统的结构体现在层次性、组件化和接口标准化等。基于这些信息，从而能够考虑是否可以进行分层测试、面向接口进行测试，以及如何构建 Mock 对象等。
  • 功能：产品的业务需求是通过软件功能承载的。同时，还需要了解系统功能之间的依赖关系、功能之间的交互作用等，基于这些信息，才能更有效地开展功能测试以及功能之间的交互测试。
  • 数据：从测试覆盖来看，可以分为两部分：控制流和数据流，控制流体现在代码逻辑覆盖、基本路径覆盖和业务流程覆盖，而数据流则体现在业务数据的输入/输出、存储和恢复等方面的覆盖上，一些业务规则也是由数据构成，甚至可以说，整个计算机系统就是在处理数据，所以在许多时候，数据是测试研究的重要对象。
  • 平台：软件运行的平台，包括操作系统、数据库、浏览器、虚拟机、云平台及平台参数的组合，是测试环境设置、兼容性测试重点考虑的因素。
  • 操作：用户的行为、操作方式，包括产品是否提供遥控器操作、用户界面触摸操作？对于触屏设备，手指的触摸方式；另外，也包括异常操作、恢复出厂设置操作等。
  • 时间：在测试实时应用系统或对时间敏感的应用系统测试之时，比如在线视频系统、嵌入式系统、工业物联网等，需要特别关注。

另外，Google 还有对产品研究的一个模型：ACC，即特性、组件（结构）、能力/功能等。

  • 测试技术特性：Attributes（Adjectives of the system），区分竞争对手、提升产品质量的表现， 比如快、安全、稳定、优雅等。
  • 组件/模块：Components（Nouns of the system），系统构成的单元等，比如 Google+ 的个人信息、圈子、通知、帖子、评论、照片等。
  • 能力/功能：Capabilities（Verbs of the system），特定组件要满足系统特性所需要的能力，比如在线购物系统需要"用 HTTPS 处理交易、在购物篮里增加商品、显示库存、计算总额、按交易量排序"等。

今天的课到这里就结束了，我来总结一下：

  • 启发式测试策略是上下文驱动的测试思维的具体实践，主要从产品的质量标准、项目背景、产品元素等 3 个方面考虑对测试技术的影响，从而向用户交付满足其需求的产品；
  • 质量标准主要从 3 个方面考虑，即产品的目标用户、对质量的具体要求、参照哪些质量标准；
  • 项目背景需要考虑多个因素，包括项目目标、交付物、项目的具体质量要求等；
  • 产品元素主要从 6 个方面去分析，包括产品结构、功能、数据、平台、操作、时间等。

最后留一个思考题给你：你认为上下文驱动的思维适用于自动化测试吗？如何让工具更好的为人所用、更好的为测试服务？可以参考我公众号的几篇连载《上下文驱动的自动化测试方法》（原著是 James Bach）文章。