性能测试并发用户数新的计算方法

一件产品的完成，最重要的一环便是它的性能，好产品的性能必定是被人们所需要的。这篇文章详细阐述了产品性能需求的重要性，推荐想要了解性能要求的童鞋阅读。

我刚工作时，和政府部门做了个产品，功能就是个表单录入，录入完保存到系统。拿去给用户演示，一切很完美。

但是当开始试运行时，出现了问题——单据录入完成后，保存无反应。

后来一看是用户在每次会同时录入很多条内容，在保存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人/秒

提需求时可以以峰值并发用户数为准

​

​​

Jmeter高级性能测试实战

​​