编辑导语:一个产品的完成最重要的部分就是它的性能，一个好的产品的性能一定是人们需要的。本文详细阐述了产品性能要求的重要性，推荐想了解性能要求的童鞋阅读。

刚开始工作的时候，和一个政府部门做了一个产品。该功能是一个保存到系统中的表单条目。展示给用户看，一切都很完美。

然而，当试运行开始时，出现了一个问题——文档录入完成后，保存后没有任何响应。

后来一看，用户每次都会同时输入多条内容，成功保存100条数据需要30s。500条数据直接保存失败。

当然这是我的问题，忽略了性能要求。

性能的重要性就不用细说了。有数据显示，近80%的用户反馈应用响应时间慢、无点击响应等性能问题。

一般公司会有专门的测试人员来测试系统的性能。但是，测试学生不清楚成绩标准和具体成绩指标有多合适。

这时候就需要产品狗提出性能要求，供测试生参考。

接下来说一下性能要求和性能指标。

文章较长，建议收藏吃骨灰~

性能需求是非功能性需求。通常，在需求文档中需要一个单独的模块来解释性能。

在编写需求文档时，可以一起指定性能需求，在评审需求时，也要评审性能需求，以便各方达成一致。

R&D的学生在进行技术设计时会考虑到这一点，以避免项目后期出现重大性能问题。

在准备测试用例时，测试生要提前规划好性能，提前准备好测试计划。

此外，性能测试也会占用一定的项目时间，所以需要在项目计划中包含性能测试的时间。

性能要求是指对系统性能的标准化描述和对性能指标的明确合理的要求。

主要分为两个方面:

1.系统的总体性能要求

主要指标包括

2.不同功能/接口的性能要求

由于不同功能和接口的频率和重要性不同，我们可以分别对不同的功能和接口提出性能要求。

以下标准可用于确定需要单独定义的功能/接口。

举一个“登录”功能的例子:

并发用户数500，响应时间2s，TPS 500/s，CPU不得超过75%。

下面详细说说绩效指标和绩效指标的标准。

主要有响应时间、并发、吞吐量、CPU等。对于App，要注意FPS、启动时间、功耗等。

让我们一个一个来看看:

1.响应时间-最直观的性能

“系统应该让用户知道发生了什么，并在适当的时间给出适当的反馈。”尼尔森可用性十大原则-状态可见性

尼尔森十大可用性原则“状态可见性原则”中提到的“适当的时间”可以理解为响应时间。

从用户的角度来说，描述就是点击按钮时系统在页面上给出反馈的时间。这个反馈时间是用户最直观的感受，也是对用户体验影响最大的地方。

当响应时间超过5秒时，74%的PC用户和50%以上的App用户会选择放弃操作，30%的用户会选择卸载应用，33%以上的用户会转向竞品。

不吓人？

接下来，让我们看看响应时间的定义:从提交请求到返回对请求的响应之间的时间。主要由网络传输时间、业务处理时间和数据处理时间组成。

对于产品来说，要注意页面的响应时间。即使接口处理完成，数据传输到客户端，也需要在前端进行分析，这需要一定的时间。

满足需求的响应时间是多久？

以前有2-5-10的原则，现在随着技术和硬件的升级，响应时间也有了1-3-5的标准。

即1s之内，用户完全可以接受；3s以内，用户感觉还可以；而且在5s之内，用户会开始焦躁不安。

当然，这只是通用标准，不是固定标准。我们在提出需求的时候，可以综合考虑业务的重要性，数据的大小，使用的频率。

示例:导出excel报表。对于很多B端产品来说，这是一个刚需，高频的功能。

我们可以提出如下性能要求:

我从网上找了一些响应时间的参考指标。你可以看看它们:

2.并发用户数——一个通用而直观的指标。

并发用户数被定义为每秒在同一时间向服务器提交请求的用户总数。

关于并发用户的数量有两种理解:

就性能要求而言，这两种理解可以分别提及，例如:

有几种方法可以评估并发用户的数量。你可以看看它们:

1)公式1:

n:平均每天的访问用户数。App可以直接用日常工作代替。

l:用户一天内从登录到注销的平均时间，可以理解为平均用户使用时间。

t:检查时间长度，以及用户每天使用系统的时间。

例如:

App日活跃10w，用户平均使用时间10min，用户日活跃时间约为上午10点到晚上10点。

公式中，n=10w，L=10min，T=12h。

C=(10w×10min)/12h，时间单位统一为秒。

C=(10w×10×60)/(12×3600)≈1388人/秒

峰值C'=1388×3×根号1388≈1500人/秒

需求可以基于并发用户的峰值数量

2)公式2:

C=(总用户数/统计时间)*影响因子

影响因子一般为3。

比如每天晚上8点到10点，App的用户最活跃，有8w的活跃用户。

8w/2h×3≈33人/秒

3)公式3:

根据80~20原则:80%的请求在20%的时间内产生。然后和PV一起算(注意不是UV，因为一个用UV生成多个PV)

比如一天的PV是100w W。

先算80% PV:100 w×80% = 80w

20%时间:24h×20%=4.8，换算成4.8×3600=17280秒。

并发数为:80w/17280=46人/秒。

如果是B端私有化部署的产品，用户数量一般是固定的，那么我们可以从企业人员数量来评估:用户数量×比例，可以根据具体情况确定，一般取8%-20%。

当然这些都是评测方法，得到的具体数据仅供参考。

3.吞吐量——衡量系统处理能力的重要指标。

吞吐量是指单位时间内系统能够处理的请求数量，反映了系统处理请求的能力。

吞吐量的量化指标是TPS(每秒事务数)和QPS(每秒查询数)。

TPS:指每秒的事务数量。事务是指服务器发送请求，服务器响应的过程。

整个过程是:用户进行操作>:& gt请求服务器>:& gt处理服务器>:& gt服务器处理完成并返回给用户。

每秒能完成多少个进程就是多少个TPS。

简单理解:登录是一次一个交易，每秒可以完成两个登录交易，也就是两个TPS。

QPS:指每秒的查询速率。指服务器每秒可以响应的查询数量。

QPS基本类似于TPS，只是一个交易完成后，会有多次对服务器的查询，所以应该是TPS≤QPS。

另外，TPS和QPS的响应时间与并发用户数有关，对应的公式为:

TPS=并发用户数/平均响应时间。

当性能测试完成，测试说500TPS的时候，我们需要有一个大概的概念。如果响应时间计算为1s，则并发数为500。

一般标准是:

4.中央处理器

CPU指标主要指CPU利用率。

当程序运行时，它将使用CPU做处理计算。会占用CPU的空。如果占用太多，系统就会卡死，没有反应。

CPU标准:

当> 75%时，就需要注意了。

在web端，一般指服务器的CPU。对于移动终端来说，往往是指手机的CPU。

App的cpu一般在20-40%，最多不能超过75%。如果长时间CPU利用率过高，会烧，会闪退。

5.记忆

内存的主要作用是运行和处理CPU发来的指令，然后在内存中处理后反馈给CPU。

网络或硬盘上加载的资源肯定会在内存中进行交换，可以理解为:页面上加载的图片和文字会暂时存储在内存中，处理后删除。

类似CPU，资源有限。如果它们被占用太多，就会出现卡顿或闪回。

恒定的内存使用量作为指标，一般小于70%。

6.磁盘吞吐量

磁盘吞吐量是指单位时间内通过磁盘的数据量，主要是每秒读写请求的大小。

一般来说，性能是由磁盘繁忙率决定的，磁盘繁忙率低于70%。

这个指标可以理解。

7.网络流通量

是指每秒有多少兆的流量进出，正常情况下不能超过设备最大传输能力的70%。

这个指标可以理解。

8.出错率

错误率=(失败交易数/总交易数)*100%。

在一定的并发下，如果一个接口被重复调用，接口会报错。错误率通常为0。

在高并发的情况下，错误率一般低于0.6%，即成功率高于99.4%。

这个指标可以理解。

CPU、内存、磁盘、网络是指服务器的资源利用率，主要针对公司。

在性能测试中，学生非常清楚这些指标的标准。对于我们的产品来说，需要了解这些定义和具体标准，性能要求提没提问题不大。

1.英国制药学会会员

FPS是指每秒显示的帧数，主要用来反映app的流畅度。

App的FPS一般>每秒24帧，最好是每秒60帧。

FPS高不代表更流畅，FPS低不代表页卡。

还应该注意帧率的稳定性。如果帧率一直很低，卡顿现象就不明显了。如果帧率忽高忽低，会有明显的掉帧和卡顿现象。

游戏类app，帧率高。对于非游戏类app，我觉得保证没有明显卡顿现象就够了。

2.功率消耗

在App中，CPU处理、蓝牙、定位、传感器、GPU(图形处理)都会加快功耗。

不同的app单位时间的耗电量是不一样的，通过对比可以得出耗电量的标准:

3.应用启动时间

在谈到响应时间的时候，我们提到了1-3-5的原则，到5s的时候，用户已经着急了。

App的启动时间是用户感知的第一个时间段，直接影响用户对App的初级体验。如果第一次留不住，用户再回来就更难了。

App的响应时间标准是不超过5s。

如果启动时间过长，将会优化优化。

当然，你也可以和竞品对比版本历史，看看自己的App在哪里。和支付宝一样，启动时间都是秒。

性能指标一般都在这些以上，我们需要了解。

一般性能测试学生在测试完成后会给出相应的性能测试报告。我们可以通过阅读性能报告的内容来判断是否需要优化性能。

在我的工作经验中，经常会出现表现不达标的情况。如果不符合性能要求，我们可以通过以下方式确定:

1.重新分析指标是否合理。

一般评估时对性能要求过高，需要重新定义性能指标后再做判断。

2.确定实际性能和性能要求之间是否有太大差异。

如果差别不大，可以先发版本，推迟性能问题。

如果差异太大而无法接受，则需要与R&D沟通，以确定是否有优化方案、优化方案的内容以及优化是否会导致延迟。

如果会造成延误，就要反馈给领导，同步各方。

性能问题说到底是技术问题，而为了达到更好的性能指标和最佳的用户体验，我们也可以在产品设计上做一些手脚。

以上方法虽然是技术相关的，但是是直接影响产品的用户体验还是需要我们提出产品？

另外，为了缓解用户的焦虑，可以用有趣好玩的加载动画来分散用户的注意力。

进度条也可以用来反映系统处理的进度。如果处理时间真的很长，给用户一个大概的时间，让用户有个心理预期。

性能需求是一个容易被忽视但又极其重要的地方。如果你总是忽略性能需求，一定要把它们写在下一个需求文档中。

不提的话，一旦线上系统被卡成狗，你就是产品，你的锅。

本文由@王大陆原创发布。每个人都是产品经理。未经许可，禁止转载。

图片来自Unsplash，基于CC0协议。