进击吧性能QA！

文 | 安和

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

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

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

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

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

若是你是性能QA，若是你出如今如上场景中，也许你须要扪心自问：

我能作的只有执行吗？

我只能作到这种程度吗？

个人价值应该体如今哪里？

问题由现象而来，

但思考能够从根源出发

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

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

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

一、 产品

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

了解产品有什么用？

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

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

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

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

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

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

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

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

此时或许能够基于不一样产品的特色总结出进球指南， 好比：

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

二、性能质量

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

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

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

一、什么是性能质量？

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

二、目标用户

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

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

三、 目标用户的需求

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

四、提供什么样的服务

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

1） 基线和对比

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

3） 可以规避风险、预知风险、评估风险；

4） 及时跟踪用户体验；

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

三、 知足用户

是否知足，对不一样产品可能会有不一样判断标准，一般在用户正常使用过程当中，50ms和500ms的差异很难有明显感觉，可是“不知足”都有类似表现，好比说页面加载失败、用户操做无响应等（非功能上的异常）。

性能QA须要作的除了验证“知足”，更要保证“不知足”的状况可以不发生或者可以及时补救，保证产品可以保持稳定的性能表现。若是功能是指“作的对”，性能是指“作的快”，稳定就是指“作的好”。

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

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

性能QA能够作什么：

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

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

思路有了，

还怕不知道作什么吗？

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

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

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

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

4）从多方位规避风险

5）及时跟进用户体验

尝试列出脑图：

从这些思考中能够大体整理出工做规划的几个方向：

1） 版本迭代性能需求

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

2） 版本回归

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

3） 线上全链路压测

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

4） 核心模块摸底

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

5） 故障演练&服务治理

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

6） 非功能质量线上巡检

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

7） 赋能

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

当咱们清楚能够作什么后，接下来是如何作、如何作的更好、如何评估、如何持续作，本文不作展开。

总结

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

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