如何确定性能测试指标

知识星球有同学问了这样一个问题：

开展了一次压测，但不知道如何筛选性能测试报告中的性能指标。需求里没有提到明确的技术指标，测试报告中需要说明被测服务的 CPU、内存使用率数据吗？压测机集群的负载情况，是否需要说明？

很典型的一个和性能测试有关的问题，也是很多性能测试小白比较迷惑的问题。

理论上来说，需求陈述阶段就应该明确相关指标，然后再开展性能测试的执行监控和分析优化工作。但实际工作场景中，一句话需求或者没有明确指标的技术需求很常见。

如何应对并解决这类问题呢？结合我个人的实践经验和理解，这篇文章聊聊这个话题。

性能指标重要吗？

毫无疑问，性能指标很重要。

相比于功能测试或者业务测试来说，性能测试更具有技术属性，即对结果的评估目的性更明确。功能测试如果出现 BUG，原因可能是需求描述不清晰，设计的交互逻辑不合理，或者开发和测试同学对需求实现理解有差异。

但性能测试的结果是更精确，更容易用数值衡量的。比如：响应时间 2 秒和 200ms，是特别大的差异。如果系统的访问量稍高一些，则可能带来更大的影响。

因此在性能测试的全生命周期中，在需求阶段最好就将预期的性能测试技术指标明确，这样才能便于后续方案制定、压测实施监控以及分析优化验证。

当然，很多时候提出性能需求的人可能对此并不了解或看重，甚至一句话需求也很常见。比如：客户要求我们出具一份性能测试报告，那谁你压测一下出个报告。

当然，面对这种一句话需求，同样是有应对方案的，请看下面的内容。

如何确定性能指标？

从我的角度来看，性能指标是一个相对概念，如果没有参考或者技术目标，那性能测试活动开展是很难拿到好结果的。

就像打靶射箭一样，在子弹出膛之前，需要知道子弹射向哪里，然后根据距离、风向等因素调整射击角度。性能技术指标就是那个靶子，告诉我们目标是什么。

同样，性能技术指标是一个滞后的参考值，它只有在有测试结果之后才能发挥真正的作用。

至于性能测试的结果和性能指标之间的关系，我认为性能指标是一个参考值。与之相比更重要的是，最终的性能测试结构是否能被团队或项目中其他角色认可和接受。

在性能测试开展之前要确定性能测试指标，这是按照比较标准的模版或者套路往下走，更适合初学者或者没太多实践的同学。但对于技术能力强有丰富实践经验的同学来说，遇到问题解决问题从来都是因地制宜的，而不是纯粹的参考或者遵循模版或套路。

作为测试同学特别是专职的性能测试同学，有责任也有义务在需求不明确时，牵头搞定这个问题。

需求不明确，那就找相关干系人(产品/研发/运维)沟通确认，帮他们捋清思路，确认需求。作为专业的性能测试人员，你要自信在性能测试领域，绝大多数业务开发和运维，是不如你专业的，术业有专攻。

以上述问题为例：提出需求的人最关心的是系统上线后的能否承载用户访问并正常提供服务。从这里入手，你可以通过沟通获得一些基本信息，比如注册用户数，日活数，或者业务峰值的网关 QPS。

没有具体数值也没事，重点在于通过获得的信息来评估出几个性能技术指标，并说明背后的逻辑，和对方达成一致。

下面是几年前我负责的一个项目案例，供大家参考：

业务目标：双 11 当天，预估平均客单价为 500，单日 GMV 为 10 亿，那么支付订单量为 10 亿/500=200W。

技术指标：

1. 假设日常支付订单量为 50W，支付转化率为 40%，订单支付 QPS 峰值为 200。预估大促时的支付转化率为 60%，则可得：大促峰值订单支付 QPS 为（200/40%）*60%*（200W/50W）=1200QPS。为了留有一定冗余空间，上浮 30%，即订单支付的 QPS 预估为 1500；

2. 电商的导购下单支付链路为：首页→商品详情→创建订单→订单支付→支付成功，这是类似漏斗的一个转化逻辑。假设首页→商品详情转化率为 40%，商品详情→创建订单转化率为 40%，创建订单→订单支付转化率为 40%，那么可得：创建订单 QPS 为 1500/40%=3750，商品详情 QPS 为 3750/40%=9375，首页 QPS 为 9375/40%=23437；

3. 按照核心链路之间的依赖调用关系，借助 trace 追踪，可得到大促期间所有核心应用及核心链路的 QPS 数值。

确认流量模型后，根据业务特性和场景评估出对应的业务可接受 RT，再从稳定性的角度给出服务器的安全水位参考值，沟通确认达成一致。

很多时候，并不存在明确的需求。作为专业领域的人，你的岗位职责中有一项潜在的职责就是抹除不确定性，通过不断的沟通交流和实践，最终得到确定具体的结果。

最后要说明的是，没有通用的性能指标。指标只是一个参考和评估基准，重点在于和提出需求的人达成一致，使其认同。