进击吧性能QA！

文 | 安和

网易智企资深性能测试工程师

通常在软件产品的研发流程中，性能QA处于被动输出的位置，研发人员提性能需求，性能QA执行，常见流程图如下：

这种工作模式可能出现2种场景：

1. 性能QA被需求淹没，疲于需求执行，但产品性能质量提升程度和头秃程度完全不成正比。
2. 需求越来越少，性能QA时刻面临的一个问题：吓！要失业了吗？

在某些产品中，这是个尴尬的情况：生产环境10天半个月都没有性能问题；业务需求越来越稳定，性能需求减少；用户流量增长趋势缓慢，暂无稳定性风险。没有性能需求，性能QA还有必要存在吗？

如果你是性能QA，如果你出现在如上场景中，也许你需要扪心自问：

我能做的只有执行吗？

我只能做到这种程度吗？

我的价值应该体现在哪里？

问题由现象而来，

但思考可以从根源出发

换个角度，上面的三个问题可以整合为一个问题：我还能为产品多做些什么？

性能QA的本职工作毋庸置疑是保证产品的性能质量满足用户使用需求，我们的思考可以从这个根源展开，试试拆解来看。

这句话有几个关键词：产品、性能质量、满足用户。

1、 产品

产品是核心，性能QA的所有活动都要围绕具体产品研发过程展开，对产品势必要有一定了解，包括但不限于这是什么产品、有什么业务功能及特点、用户群体的行为模式、产品部署的整体架构等等。

了解产品有什么用？

• 产品的业务功能特点：提炼关注重点；（工作优先级）
• 产品的用户行为：提炼测试场景、测试类型、测试目标；（结果有效性）
• 产品的架构特点：提炼测试模式及可能瓶颈点；（结果有效性及测试充分性）
• 产品的研发流程：提炼重要的流程节点；（测试充分性）

在产品研发过程中，性能QA应该处于什么位置？

如开篇所示的流程中，性能QA是作为质量保障的最后一道门槛，处于后方守卫的位置。该位置的缺点是通常被动接受研发人员提出的性能需求。

假设不同产品是不同场地，研发人员是球员，性能QA是守门员，球门线是性能质量及格线，球员要做的是用正确的姿势踢球入门，守门员要做的是把不符合条件的球挡在门外。

如果球员不了解规则，能不能踢进，全靠球员自由发挥；如果多个球员从不同的角度用不同的脚法同时射球，能不能挡住烂球，全靠守门员自由发挥。

那么有2个问题急需解决：

1. 如何提高好球的进球率，即代码质量提升，比如减少重复问题的出现；
2. 如何提高烂球的拦截率，即bug的筛查，比如增加验证及监控手段；

当性能QA开始思考这个问题，已经迈出了突破思维模式局限性的一步，不仅仅是性能需求的执行者，而是球场上的规则制定者。也可以这样说：不想当教练的守门员不是好QA。

此时或许可以基于不同产品的特点总结出进球指南， 比如：

1. A产品的用户对历史数据的查询分析较多（用户行为模式），大量的循环操作可能会带来较大的性能开销；
2. B产品的外部调用较多（业务特点），大量的同步请求操作可能会阻塞系统的正常请求处理；
3. C产品的调用层级较复杂（架构特点），下游异常时系统反应可能会不可预知，需要提前做故障演练；

2、性能质量

保证性能质量必须基于产品来实施。

如开篇所示的流程只能被称为性能测试，输出的内容只是某个性能需求的性能质量，当我们习惯从更多的角度了解产品，并摆正了自己的位置后，能够更清楚的了解到保证性能质量不仅仅依靠性能测试执行，而应该是多视角多维度的。

尝试把保证性能质量看作一个服务性质的产品，首先需要明确以下几点：

1、什么是性能质量？

通过量化指标判断性能满足用户使用需求的程度。在软件质量模型中，性能属于效率，效率不是非黑即白，那么对性能质量的评估，除了基线外，趋势对比同样重要。

2、目标用户

研发团队/产品负责人：直接用户；

软件产品的使用群体：最终用户；

3、 目标用户的需求

• 产品负责人：能够支撑多少用户顺滑且稳定的使用；是否存在潜在风险以及如何规避等。
• 研发人员开发：架构设计是否合理；代码是否存在不合理的资源占用/资源竞争等。
• 软件产品的使用群体：软件是否操作顺滑且状态稳定，一直顺滑一直爽；

4、提供什么样的服务

基于如上的目标用户及用户需求，性能QA提供的服务应该具备以下几个特点：

1） 基线和对比

2） 兼顾局部性能、系统性能、业务场景性能及服务稳定性；

3） 能够规避风险、预知风险、评估风险；

4） 及时跟踪用户体验；

即从多视角出发，推动性能活动介入到产品整个生命周期中，提供全方位的支撑，可以称为性能质量保障或非功能质量保障。性能质量保障并不等同于性能测试，性能测试是指一类测试行为，而性能质量保障是一系列行为活动的集合，其中包括性能测试执行。

3、 满足用户

是否满足，对不同产品可能会有不同判断标准，通常在用户正常使用过程中，50ms和500ms的差别很难有明显感受，但是“不满足”都有相似表现，比如说页面加载失败、用户操作无响应等（非功能上的异常）。

性能QA需要做的除了验证“满足”，更要保证“不满足”的情况能够不发生或者能够及时补救，保证产品能够保持稳定的性能表现。如果功能是指“做的对”，性能是指“做的快”，稳定就是指“做的好”。

但研发过程是不断产生“不满足”风险的过程，性能QA怎么规避风险呢？

首先来分析一下研发过程中，哪些阶段可能会产生风险以及产生的原因，以一个简单的流程图为例：

性能QA可以做什么：

1） 人为因素：减少人为因素的干扰；在研发阶段卡点评估风险。

2） 客观因素：预案管理、提前演练

思路有了，

还怕不知道做什么吗？

汇总上述章节的思路，当性能QA思考“我可以为产品多做些什么”的时候，可以从这几个方向入手：

1）从熟知产品出发，转换视角

2）尝试多总结多输出，转换角色

3）扩展关注产品性能表现的角度和深度

4）从多方位规避风险

5）及时跟进用户体验

尝试列出脑图：

从这些思考中可以大致整理出工作规划的几个方向：

1） 版本迭代性能需求

由研发或业务QA提出的性能测试需求，主要用于发现新功能的性能问题、处理瓶颈以及性能影响范围。

2） 版本回归

线下全链路压测，用于对比历史版本的性能表现，关注是否存在性能下降、资源占有异常等性能风险。

3） 线上全链路压测

线上容量评估，为服务扩容和线上容量规划提供参考数据。

4） 核心模块摸底

对核心模块的核心接口进行性能摸底，关注该模块核心接口的性能表现及性能瓶颈。

5） 故障演练&服务治理

单模块或全链路的故障演练，根据故障用例和故障恢复预案，模拟真实故障情况的演习。目的是服务治理、预案验证，即验证系统的故障恢复能力，是有效预防系统失控的手段。

6） 非功能质量线上巡检

关注线上性能表现及资源使用情况。

7） 赋能

旨在增强研发团队对于产品性能的意识及主观能动性，提高研发效能。

当我们清楚可以做什么后，接下来是如何做、如何做的更好、如何评估、如何持续做，本文不做展开。

总结

在软件产品开发这个行业里，性能质量的范围非常庞大，从前端到后端、从网络到操作系统、从虚拟机到数据存储，而性能质量保障的方法手段同样层出不穷，展开来分分钟怀疑人生。那么如何规划和规范这些手段，使之井然有序、高质高效的为产品服务，称之为性能质量保障体系的建设。这是个逐渐演变、逐渐完善的过程，是我们需要进一步思考和实践的方向。

“道可道也，非恒道也；名可名也，非恒名也”，请性能QA独立行走！共勉！