进击吧性能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独立行走!共勉!

你可能感兴趣的