2020年软件测试趋势报道：彻底实现持续测试（中）

2020年软件测试趋势报道：彻底实现持续测试（上），介绍了什么是持续测试和持续测试工具链。这一篇侧重介绍持续测试的实现框架，这或许是大家更为关心，基于实现框架，持续测试才能落地。

在介绍持续测试的实现框架之前，交待一下“什么是持续测试”，它具有下列三个特点：

• 测试可以随时开展起来，且具有连续性，平滑有序地打通整个测试过程，从测试左移到测试右移，从单元测试到端到端的系统测试，从静态测试到动态测试，从测试分析到测试报告

• 测试和开发、运维能很好地融合、匹配和同步起来，**打通整个DevOps过程，让测试融合到DevOps的各个环节**，融入到DevOps的整个基础设施，相互促进，最终能够实现彻底的持续交付

• 以最少的测试、最快的速度覆盖交付所面临的业务风险，整个测试过程要快，不管是研发阶段中每个迭代的测试活动，还是产品发布后对于缺陷修复的代码变更的验证，有变更，就有验证，就能够快速提供验证结果

之所以特别强调持续测试，是因为软件测试常常是实现DevOps的最大障碍，软件测试常常面临如下问题：

• 尽管自动化测试已经推行很多年，但在大多数企业中主要的测试方式还是手工测试。

• 即使在自动化水平较高的组织中，测试人员仍然花费平均17%的工作时间分析由于各种不稳定因素造成的测试结果的误报，还会花费14%的时间维护自动化脚本。

• 超过一半的测试人员每周会花费5-15小时准备和管理测试数据。

• 84%的测试人员都遭遇过因为测试环境的问题而造成的测试任务的延迟。

• 一套自动化回归测试集平均需要16.5天执行一遍，但是敏捷开发的一次迭代时间普遍要求是两周。

• 一个软件应用平均要和52个第三方系统组件进行交互，这些第三方系统组件包括其它的微服务和接口，以及各式各样的移动设备。

实现彻底的持续测试，就是为了解决上述问题，各个击破，在正确的时间执行正确的测试，该精简测试范围的时候给予科学合理的精简，给决策者提供快速的质量反馈，这一切就依赖持续测试的实现框架。

持续测试实现框架

持续测试的实现框架如图1所示，分为三个模块：实现基础、中间过程、技术手段/方法。实现基础包括三个方面：测试数据管理、服务虚拟化、和DevOps的集成；中间过程包括基于风险的测试分析和测试影响分析；实现的技术手段和方法包括探索式测试、测试自动化、测试设计方法，总共有8个方面（中篇讲4个方面，下篇再讲另外4个方面+ 持续测试成熟度）。

图1 持续测试的实现框架

1. 测试数据管理（TDM）

测试数据的准备和管理是软件测试中重要的环节，也是自动化测试中的非常重要的环节，系统端到端的自动化回归测试需要测试数据管理功能的支持。持续测试需要考虑如何缩短测试数据的创建和维护所需要的时间。

有两种测试数据的主要来源，一种是使用生产数据，但需要对数据进行脱敏，以满足GDPR（通用数据保护条例，General Data ProtectionRegulation）的要求；另一种是生成需要的测试数据。在测试中常常需要综合利用两种方式来满足不同的测试需要：经过脱敏处理的生产数据可以更快速的覆盖常见的测试场景，而生成的测试数据可以实现更广泛的覆盖范围，比如一些异常场景需要的数据在生产环境中难以发现，

另外，测试数据管理服务还需要考虑如何隔离测试数据的使用，避免多个测试任务修改测试数据造成的互相干扰；哪些数据可以事先准备，哪些数据需要在测试执行中实时生成。

2. DevOps工具链集成

随着DevOps工具链的形成和日益丰富，企业可以选择各种各样的工具建设自动化的软件交付流水线。这些工具的集成和协同越有效，团队成员的工作和协作就越高效。测试工具与CI系统的集成是将测试活动无缝融合到持续交付流水线的基础，这也是对于现代测试工具的基本要求。

测试工具应该具备直接集成到CI环境中的能力，或者先连接到一个专门的测试管理平台，该平台可以协调测试管理、跟踪和报告，另外，在需要时利用加速测试执行的技术，如分布式测试执行、故障恢复等，可以帮助团队在限定的时间内完成更多的测试。

3. 服务虚拟化

服务虚拟化是一种模拟（Mock）技术，即使被测试对象依赖的系统组件（API、第三方应用等）不能被正常访问，测试也可以自动运行。服务虚拟化的目标是保证测试环境不影响测试的速度、准确性，和完整性，测试可以达到业务期望的质量和效能。

现代软件应用系统越来越错综复杂，搭建测试环境也变得越来越具有挑战，因此有的测试干脆直接在生产环境中进行，但不可能把所有研发阶段的测试全部右移。当被测试对象需要与所依赖的系统组件交互时，被依赖的系统组件如果处于下列状态就变得不可用：

• 还在开发中的、不可靠的第三方组件
• 超出所在研发团队的控制范围的第三方组件
• 使用时容量或时间有限制
• 在测试环境中难以配置或部署
• 不同团队需要同时设置不同的测试数据而引起冲突

越复杂的场景往往依赖更多的系统组件，因此端到端的自动化回归测试就会有更多的限制。服务虚拟化可以消除被依赖的系统组件的不稳定，把测试和与之相互作用的各种依赖性隔离开来，为自动化测试提供稳定的环境。当测试失败时，可以排除与之相关的测试环境问题，更方便进行问题定位，也可以为复现缺陷和验证修复提供稳定可靠的测试环境。

另外，服务虚拟化还提供了一种简单方法来模拟测试环境中的边缘情况和错误条件下的行为，以便覆盖更多的测试场景。例如，验证被测系统在不同的依赖组合在关闭、延迟时的状态。

4. 基于业务风险的测试分析

在敏捷开发和DevOps环境中，软件发布的决策需要快速制定，最好是直观的、自动的、实时的。传统的，基于测试用例数量的测试结果已经不能满足快速决策的要求。为什么这样说呢？很多团队在测试结束后提交的测试结果常常是这样的：

• 总共有10,000条测试用例，测试覆盖率为95%
• 90%的测试用例（9,000）执行成功
• 5%的测试用例（500）执行失败，相关的功能模块包括……
• 5%的测试用例（500）没有执行，相关的功能模块包括……

组织的决策团队面临的问题是，很难基于上述报告直观判断一个软件是否可以发布。他们常常会有很多疑问：没有覆盖到的需求是不是有很大风险？失败的和没有执行的测试用例所关联的功能特性是不是关键的业务功能？对于用户会造成什么影响？

因此，几乎总是需要组织发布前的评审会来了解测试结果背后的细节，才能做出判断。这不仅会浪费时间，还会因为主观和仓促的判断错误估计了质量风险。以测试覆盖率为例，测试覆盖率只告诉我们一个应用的功能点被测试用例覆盖的百分比，例如，如果一个应用总共有100个功能点，测试了其中95个，那么测试覆盖率为95%。如果每个功能点都同样重要，这个指标是有意义的，但实际上并非如此，例如，一个在线教育APP的听课功能肯定比课程推广功能更重要。如果5%没有被测试覆盖的功能点正好包括听课功能，那相应的软件版本还能发布吗？

为了解决上述痛点，Tricentis公司提出了一种新的数字化测试范围优化方法，其过程如图2所示，主要包括以下几点：

• 对需求进行业务风险的量化评估、排序。
• 设计测试用例对业务风险进行有效的覆盖。
• 建立需求与测试用例之间的映射关系，把需求的量化风险关联到测试用例。
• 根据给定的测试执行时间和业务风险确定测试范围和优先级。
• 在测试结果的报告中，采用业务风险覆盖率代替传统的测试覆盖率。根据业务风险覆盖率进行软件发布决策。

图2 基于业务风险的测试范围优化过程

这个方法的亮点在于需求风险的量化评估和根据风险覆盖率进行发布决策。

首先介绍需求风险的量化评估，这里需要解释几个术语：需求的业务风险（Business Risk）、风险权重、风险贡献率、风险覆盖率（Risk Coverage）。

业务风险，用来量化一个需求，即Epic或用户故事对业务产生负面影响的可能性，公式如下：

业务风险 = 使用频率 x 失效危害（Risk = Frequency x Damage）

其中，使用频率和失效危害的定义如下：

使用频率（Frequency），是对需求对应的功能特性用户使用频率的度量。如果用户经常使用一个功能，那么这个功能通常比较关键。

失效危害（Damage），是对需求对应的功能特性失效可能导致的损失进行的度量。会不会造成核心功能的瘫痪，还是只是造成使用上的不便？是否会造成重大的财务损失？有没有监管违规？

某个功能特性的用户使用频率越高，并且一旦失效可能造成的损害越大，业务风险就越高。

风险绝对权重（Absolute Weight），是根据每个需求的Frequency和Damage按照下面的公式计算出来的：

用户故事的风险权重按照上面的公式直接计算，Epic的风险权重是对其包含的用户故事的风险权重求和。

风险相对权重（Relative Weight），是指每个需求相对于同一层级中其它需求的业务风险权重百分比。例如，在某个Epic下面一共有3个用户故事，风险的绝对权重分别是256、128、128，那么用户故事的风险相对权重分别为50%、25%、25%。

风险贡献率（Risk Contribution），是指每个需求占所有需求的风险贡献百分比。

下面是对需求进行业务风险量化评估、排序的推荐流程：

1. 项目关键干系人承诺参加一个历时一天半的会议，参与风险评估。
2. 对于Epic、用户故事等需要测试的业务需求进行简要评审。如果软件系统非常复杂，建议一开始把注意力放在Epic级别，而不是用户故事级别。
3. 按照每个需求实际或者预期的使用频率对需求进行风险排序，从选择最常用的需求开始，将其列为5级。接下来，将最不常用的需求列为1级。随后，把其它的需求与最常用和最不常用的进行比较，每个级别的频率应该加倍，例如，2级需求的使用频率是1级的两倍，3级需求是2级的两倍。接下来对造成的损害重复相同的过程：如果这个需求对应的功能失效，可能导致的损害级别。先对每个Epic级别的需求进行排序，然后对每个Epic包含的用户故事进行排序。
4. 排序完成后，给与其它相关方评审风险评级结果的机会。
5. 计算每个用户故事和Epic的风险绝对权重、相对权重，以及风险贡献率。

我们以一个在线教育App的用户故事为例，表1列出了用户故事和Epic的风险分析结果。其中，账户管理、课程购买，和课程学习这三个Epic的业务风险最高，分别贡献了30.19%的业务风险，课程发现和课程分享这两个Epic的业务风险较低。而Epic“账户管理“中，用户故事“注册登录”贡献了94.12%的业务风险，远远高于另一个用户故事“充值”的业务风险。

表1 在线教育App需求风险评估表

到这里，我们对业务需求的风险评估就完成了，对被测软件应用的风险也有了一个清晰、量化的认识。

未完待续，敬请期待“2020年软件测试趋势报道：测试实现持续测试（下）”。