提升测试质量的四个关键特征

今年写了很多质量保障相关的文章，也在星球内部或者公开做了几次分享，内容主要包括质量内建、质量门禁、测试左移、质量度量等。我试图通过这些内容，从不同的角度阐述我对于质量保障体系建设的实践和思考，这些方法和实践最终要达成的目标都是一致的：提升质量。

最近在思考一个问题：如何证明经过测试的软件系统，质量得到了提升？质量提升又有什么特征？

这篇文章，来聊聊关于提升测试质量的几个关键特征以及我的一些思考。

当前现状

在聊提升测试质量的特征之前，我想先聊聊当下的一些现状和面临的挑战。

• 业务多样：业务多样不难理解，我们的测试对象可能只是一个具体的 APP 或者 web 页面，但它背后的业务逻辑可能极为复杂，且不同的业务场景之间互相依赖，在银行保险等企业工作过的技术同学应该深有体会。

• 架构复杂：为了实现多样复杂的业务，系统的架构也在不断变得复杂。虽然有各种设计模式如 DDD(领域驱动设计)等指导如何设计一个优雅的架构，但在实现以及迭代过程中，最终都会变成代码屎山。

• 迭代快速：为了更快的将业务上的创新变成实际的功能提供给用户，近几年版本迭代的速度越来越快。以前几个月一次的瀑布模型，现在也逐渐演进为一周或者两周一个版本的敏捷化交付。

• 管控难度大：这里的管控包含多个方面，诸如发布权限、发布窗口、配置变更、需求变更等多个方面。大多的线上故障都是变更带来的，可控变更也是提升测试质量必须达到的一个目标。

预期目标

聊完现状和挑战，从中不难看出提升测试质量这个抽象目标下，更具体描述质量变化的目标。

• 应用可信：从技术角度来说，测试的对象是一个个应用服务。如果我们能达到对服务的正确性和健壮性有很高的置信值，那么应用可信就可以看做一种可以描述测试质量的目标。

• ps：置信区间这个概念源于统计学，可信度源于安全领域，核心内容是：持续验证，永不信任。

• 数据可信：在复杂的系统架构下，为了便于测试验证和排查问题，一般都会做很多的埋点采集数据。这些采集的数据会形成一个请求链路，包含一次请求上下游的完整数据，借助这些链路数据，可以更好的评估研发和测试质量，因此数据可信也可以看做是一种描述测试质量的目标。

• 质量可信：在业务需求快速迭代的情况下，通过持续快速验证的方式，达到每次迭代交付的质量有很高的置信值，那么质量可信也可以看做是一种可以描述测试质量的目标。

• SLA 可信：对于线上业务和服务的稳定性来说，可控的变更除了要控制变更的影响范围，更要对变更带来的风险和可能导致的损失有具体的数值来辅助评估，因此 SLA 可信也可以看做是一种描述测试质量的目标。

• SLA：服务等级协议，包含 SLO(服务质量目标)和 SLI(服务质量指标) 2 个指标，常见的有 P99，源于 SRE 工程实践的理论。

四大特征

聊完了现状和预期目标，其实提升测试质量的四个关键特征，已经不言而喻了，如下图所示：

要提升测试质量，保障最终的线上交付质量，我个人认为测试过程应具备下面四个特征：

• 可识别：业务多样，场景复杂，在需求阶段就对业务迭代带来的影响范围和可能存在的风险进行识别，做好风险评估和冗余设计，以达到被测服务和应用可信。

• 可追踪：系统架构复杂，就需要在基础技术设施建设方面发力，通过链路追踪来获取系统处理请求时所产生的各种数据，通过这些数据来评估代码实现质量以及测试过程质量，提升研发过程效率，达到数据可信。

• 可验证：版本迭代快，多版本并行现在都是很常见的场景，但持续的可测试可验证能力，才是保障测试质量的底层能力。只有持续的测试验证，才能做到提测-验证-反馈-修复的质量闭环，达到质量可信。

• 可量化：变更是正常的，变更是有风险的，对于变更影响的范围、可能存在的风险需要尽量做到可量化，做好兜底策略和应急响应机制，这样才能提升线上服务的可用性，提升技术对业务的支撑能力。