我刚工作时，和政府部门做了个产品，功能就是个表单录入，录入完保存到系统。拿去给用户演示，一切很完美。
但是当开始试运行时，出现了问题——单据录入完成后，保存无反应。
后来一看是用户在每次会同时录入很多条内容，在保存100条数据要30s才能保存成功。500条数据直接保存失败。
当然，这是我的问题，忽略了对性能的要求。
一般在公司里会有专门的测试人员对系统进行性能测试，而对于性能的标准，具体性能指标多少合适，测试同学是不清楚的。
这个时候就需要产品狗们提出性能要求，给测试同学作参考。
接下来我们说说性能需求咋提以及性能指标。
一、性能需求什么时候提
性能需求属于非功能需求，一般在需求文档内需要有单独模块对性能做说明。
在写需求文档的时候就可以把性能需求一起规定好，在需求评审时也要评审下性能需求，让各方达成一致。
研发同学在做技术设计时考虑进来，避免在项目后期，出现重大性能问题。
测试同学在准备测试用例时，把性能也提前规划进来，提前准备好测试方案。
二、性能需求怎么提
性能需求是指对系统性能进行规范化描述，提出明确、合理的性能指标要求。
主要分为2个方面：
1.系统整体性能需求
主要指标包括
2.不同功能/接口性能需求
由于不同功能、不同接口的使用频率、重要程度不同，我们可以对不同功能、不同接口单独提出性能需求。
可以从下边几个标准来确定需要单独明确的功能/接口
下边我们详细说说性能指标以及性能指标的标准
三、常见的性能指标有哪些
我们一个个看看：
吓人不？
即1s内用户完全可以接受，3s内用户觉得还可以，5s用户就会开始焦躁不安。
当然这只是个通用标准，不是个固定标准。我们在提出需求时，可以结合业务重要性、数据量大小、使用频次来做综合考虑。
举个例子：导出excel报表。对于很多B端产品，这是个刚需、高频的功能。
我们可以这样提出性能要求：
2.并发用户数——笼统也直观的指标
并发用户数的定义是每秒同时向服务器提交请求的用户总数量。
关于并发用户数有2个理解：
对于这2个理解，在性能需求上可以分开提，比如：
有几种并发用户数评估方法，大家可以看下：
1）公式1：
n：平均每天的访问用户数。App可以直接用日活代替。
举个例子:
公式里的n=10w，L=10min，T=12h
C=（10w×10×60）/（12×3600）≈1388人/秒
峰值C’=1388×3×根号1388≈1500人/秒
提需求时可以以峰值并发用户数为准
2）公式2：
影响因子一般为3
比如App的每天晚上8点-10点用户最活跃，且活跃用户有8w。
8w/2h×3≈33人/秒
3）公式3：
比如1天的PV有100w
先算80%的PV：100w×80%=80w
并发数就是：80w/17280=46人/秒
如果是B端私有化部署的产品，一般使用人数比较固定，我们可以从企业人员数量做评估：用户数量×比例，比例可以视具体情况而定，一般取8%-20%。
当然这些都是评估方法，得出的具体数据量只是做个参考。
3.吞吐量——衡量系统处理能力的重要指标。
吞吐量的量化指标有：TPS（每秒事务数）、QPS（每秒查询数）
TPS：是指事务数/秒。一个事务是指服务器发送请求，服务器做出反应的过程。
整体过程就是：用户做出操作>>请求服务器>>服务器处理>>服务器处理完成返回到用户。
每秒能完成多少个流程就是多少个TPS
QPS：是指每秒查询率。指一台服务器每秒能够响应的查询次数。
QPS基本类似于TPS，不同的是：在完成一个事务时，会存在多次查询服务器，所以应该是TPS≤QPS。
一般的标准有：
4.CPU
CPU指标主要指的CPU利用率。
程序在运行的时候，会使用CPU做处理计算。就会占用CPU的空间，如果占用过多，系统就会出现卡顿、无响应的情况。
CPU标准：
对于web端，一般指服务器的CPU。而对于移动端，常指手机的CPU。
5.内存
内存主要是运行处理CPU发出的指令，在内存里处理完毕后，再反馈给CPU。
在网络上或者硬盘上加载的资源，一定会通过内存交换，可以理解为：页面加载出来的图片、文字会暂时存到内存里的，处理完成后就删掉。
内存和CPU类似，资源都是有限的，如果占用过多，会出现卡顿或闪退的现象。
内存常内存使用率做为指标，一般＜70%。
6.磁盘吞吐量
一般用磁盘繁忙率来确定性能，磁盘繁忙率要＜70%。
这个指标了解即可。
7.网络吞吐量
是指有每秒有多少兆流量进出，一般情况下不能超过设备最大传输能力的70%。
8.错误率
错误率=(失败事务数/事务总数)*100%。
在一定并发下，循环调用某个接口，会出现接口报错的情况。错误率正常情况下要为0。
在高并发的情况下错误率一般要低于0.6%，就是成功率要高于99.4%。
像CPU、内存、磁盘、网络是指服务器的资源利用率，主要是对公司内部来说。
性能测试的同学对于这些指标的标准都很清楚，对于我们产品，需要明白这些定义与具体标准即可，性能需求提不提问题都不大。
FPS是指每秒显示的帧数，主要用来体现出app的流畅度。
App的FPS一般＞24帧/秒，最好是60帧/秒。
FPS的越高并不意味着越流畅，FPS低也不意味着页面卡。
对于游戏类app帧率要求较高，对于非游戏类app，我认为只要能保证没有明显的卡顿现象就可以了。
2.耗电量
在App中，CPU处理、蓝牙、定位、传感器、GPU（图形处理）都会加快耗电量。
性能指标一般就以上这些，大家需要理解下。
五、性能需求达不到怎么办
一般性能测试同学在测试完成后，会给出对应的性能测试报告，我们可以通过解读性能报告的内容来判断是否需要优化性能。
在我的工作经历中，很多时候会出现性能不达标的情况，如果性能需求不满足，我们可以按照以下方式确定：
1.重新分析指标合不合理
一般在评估时会对性能要求过高，需要重新定义性能指标再做判断。
2.判断实际性能与性能需求是否相差太多
如果相差不大，可以先发版，延期处理性能问题。
如果相差太大，不能接受，就要与研发沟通，确定是否有优化方案、优化方案内容、优化是否会导致延期。
如果会引起延期，就要和领导反馈，以及同步各方。
六、如何从产品设计上提高性能
性能问题归根到底是技术问题，而为了达到更好的性能指标，达到最好的用户体验，我们也可以从产品设计上整点花样。
另外对于缓解用户的焦虑感，可以使用有趣、好玩的加载动画，分散用户的注意力。
七、总结
性能需求是个容易忽视，却无比重要的地方。如果你一直忽略性能需求，下次的需求文档里一定要写上。
如果你不提，一上线系统卡成狗，你是产品，就是你的锅。
本文由@王大鹿原创发布于人人都是产品经理。未经许可，禁止转载