性能测试并发用户数新的计算方法
一件产品的完成，最重要的一环便是它的性能，好产品的性能必定是被人们所需要的。这篇文章详细阐述了产品性能需求的重要性，推荐想要了解性能要求的童鞋阅读。
我刚工作时，和政府部门做了个产品，功能就是个表单录入，录入完保存到系统。拿去给用户演示，一切很完美。
但是当开始试运行时，出现了问题——单据录入完成后，保存无反应。
后来一看是用户在每次会同时录入很多条内容，在保存100条数据要30s才能保存成功。500条数据直接保存失败。
当然，这是我的问题，忽略了对性能的要求。
性能的重要性不必细说，有些数据表明：近80%的用户反馈应用响应时间慢、点击没反应等性能问题。
一般在公司里会有专门的测试人员对系统进行性能测试，而对于性能的标准，具体性能指标多少合适，测试同学是不清楚的。
这个时候就需要产品狗们提出性能要求，给测试同学作参考。
接下来我们说说性能需求咋提以及性能指标。
文章较长，建议收藏吃灰~
一、性能需求什么时候提
性能需求属于非功能需求，一般在需求文档内需要有单独模块对性能做说明。
在写需求文档的时候就可以把性能需求一起规定好，在需求评审时也要评审下性能需求，让各方达成一致。
研发同学在做技术设计时考虑进来，避免在项目后期，出现重大性能问题。
测试同学在准备测试用例时，把性能也提前规划进来，提前准备好测试方案。
另外性能测试也会占用一定的项目时间，需要在制定项目计划时，把性能测试的时间也纳入计划中。
二、性能需求怎么提
性能需求是指对系统性能进行规范化描述，提出明确、合理的性能指标要求。
主要分为2个方面：
1.系统整体性能需求
主要指标包括
-
-
在线用户数数量：如支持在线用户数200w
-
-
平稳运行时间：如7×24h
-
-
平均响应时间：如页面打开时间低于2s。（对于一些主要页面可以在做单独性能要求）
-
-
CPU：CPU使用率＜75%
2.不同功能/接口性能需求
由于不同功能、不同接口的使用频率、重要程度不同，我们可以对不同功能、不同接口单独提出性能需求。
可以从下边几个标准来确定需要单独明确的功能/接口
-
-
高频：系统中高频率使用的功能，高频调用的接口，像刷动态
-
-
关键：系统中不能出现问题的功能，像登录、注册、支付
-
-
特色：系统中的亮点功能，产品的卖点，比如处方合理性审核系统、风险监控系统，还有像交友的在线匹配功能。
-
-
涉及大量数据：比如说报表查询。
举个“登录”功能的例子：
并发用户数500，响应时间2s，TPS到500/s，CPU不得超过75%。
下边我们详细说说性能指标以及性能指标的标准
三、常见的性能指标有哪些
主要有响应时间、并发数、吞吐量、CPU等，对于App需要关注FPS、启动时间、耗电量等。
我们一个个看看：
1. 响应时间——最直观的表现
“系统应该让用户知道发生了什么，在适当的时间内做出适当的反馈。”尼尔森可用性十原则——状态可见性
在尼尔森可用性十原则中的“状态可见性原则”提到的“适当的时间”就可以理解为响应时间。
站在用户角度描述就是点击一下按钮，系统在页面上给出反馈的时间。这个反馈时间是用户最能直观感受到的，也是对用户体验影响最大的地方。
当响应时间＞3秒后，74%的PC端用户、50%以上的App用户会选择放弃操作，30%的用户会选择卸载应用，33%以上的用户会转身使用竞品。
吓人不？
我们接着看下响应时间的定义：提交请求和返回该请求的响应之间使用的时间。主要由网络传输时间和业务处理、数据处理时间组成。
而对于产品来说，需要关注的是页面响应时间，就算接口处理完成，数据传到客户端上了，在前端也需要解析出来，也会消耗一定时间。
响应时间多长才能满足要求呢？
之前有个2-5-10原则，而现在随着技术、硬件的更新换代，响应时间也有了1-3-5标准。
即1s内用户完全可以接受，3s内用户觉得还可以，5s用户就会开始焦躁不安。
当然这只是个通用标准，不是个固定标准。我们在提出需求时，可以结合业务重要性、数据量大小、使用频次来做综合考虑。
举个例子：导出excel报表。对于很多B端产品，这是个刚需、高频的功能。
我们可以这样提出性能要求：
-
-
1万条数据，导出完成用时3s。
-
-
3万条数据，导出完成用时5s。
-
-
10万条数据，导出完成用时8s。
我从网上找到一些响应时间参考指标，大家可以看下：
-
-
互联网企业：500毫秒以下，例如淘宝业务10毫秒左右。
-
-
金融企业：1秒以下为佳，部分复杂业务3秒以下。
-
-
保险企业：3秒以下为佳。
-
-
制造业：5秒以下为佳。
2. 并发用户数——笼统也直观的指标
并发用户数的定义是每秒同时向服务器提交请求的用户总数量。
关于并发用户数有2个理解：
-
-
多个用户同一时间做不同操作，比如多个用户有发动态的，有刷动态的。
-
-
多个用户同一时间做同一个操作，比如多个用户一起发动态。
对于这2个理解，在性能需求上可以分开提，比如：
-
-
系统支持并发用户数500
-
-
发布动态：支持300人并发发布动态。
有几种并发用户数评估方法，大家可以看下：
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人/秒
提需求时可以以峰值并发用户数为准
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人/秒
提需求时可以以峰值并发用户数为准
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人/秒
提需求时可以以峰值并发用户数为准
