深聊性能测试，从入门到放弃之：通过这几点获取性能需求，BOSS再也不担心用户投诉了。

1、引言

最近比较感慨，
看到很多求职者把自己的简历武装的很精致，在简历上，都是全栈大佬，等待面试的时候，一问三不知。
其实在当前，也算是一种流行趋势。
虽然都说简历是敲门砖，能否进门，全凭自己本事，
但是，武装的再好，没有硬实力，那最后只能是…

写这篇博文的原因，

• 一来，最近问我性能相关知识的求职者增多；
• 二来，最近公司也在扩招，面试的候选人水平有限，让我有点头疼；
• 三来，我就想单纯的输出点知识，让更多的小姐姐喜欢上学习；

好了，话不多说，咱们进入今天的主题。

2、性能需求获取

2.1 用户信息

2.1.1 调查系统当前和未来的用户数

• 系统用户数：即系统注册的总用户数，不是活跃用户数；
• 在线用户数：同时在线用户数；
• 并发用户数：同时在线并同一时间对某功能进行操作；

注：
估算未来1至5年用户数，可以根据以下两方面进行估算：
- 日志数据值；
- 运维提供数据值；

2.1.2 调查系统当前和未来的日活，月活数

当前活跃用户数，即某天大概有多少用户使用本系统：那么这部分系统一说来也是对当前系统构成的压力的数量。

2.2 业务数据

2.2.1 调查当前和未来的背景数量

例如，从1000条中抽查20条，这很easy； 但是在1000W中抽查20W条数据…

尤其向小鱼公司当前的做的产品，平时的PV都是 上千万个W的！

2.2.2 调查当前和未来业务每天使用的总笔数

每个用户每天可能下多少笔订单，平均需要多少次来执行这个操作？
那么根据用户数，我们就可以确定每天下单的笔数。
举个例子
如50人，平均每人每天下10次，每次下100笔，那么总笔数就是5010100=50000笔。
注:
此数据根据TPS换算后，我们可以换算出系统的业务总处理量是否能达到这个数据，这也是一个很重要的指标。

如果觉得自己的知识有点匮乏，可以参照小鱼的深聊性能测试系统博文！
点击传送门
或者 点击
《深聊性能测试，从入门到放弃之：性能测试技术栈，看完这篇，保证刷新你对性能测试的认知~~》

2.2.3 调查当前和未来高峰时业务的总笔数

即上面所描述的特殊情况，这也是必须要考虑，并且拿到的数据。

2.3 业务场景调查

2.3.1 系统核心业务场景

以主要的业务逻辑点为第一核心：
这些功能对系统或公司来说往往具有举足轻重的地位，无论怎样都必须要优先执行满足这以功能的性能测试。

2.3.2 高访问量功能，经常承受压力功能点

系统中表现在系统关键、核心业务前面必须要经过的地方：
如对于百度搜索来说，其核心业务是搜索功能，但是首先要面对的其高访问量对是搜索输入框加载的首页，百度首页加载即高访问量的请求。

2.3.3 业务高复杂度

往往说来业务逻辑复杂度的都具备1、2点的要素，可能其功能使用的人数较少但是对系统有很严重影响：
这些功能由于其业务逻辑具有的复杂度，往往出错的可能性也比较高，所以这些功能也是必须要进行测试的

2.4 性能相关调查

2.4.1 调查每秒事务数(TPS)

这是衡量系统处理能力的一个重要指标，同时这个指标在一定程序也关系到业务数量是否能够及时完成，所以需要获得。
估算方式大致有三种，如下：

• 估算方式一：BS类可以参考以下指标估算：Vuser*TRequest/RPS=TPS（注意1Requset的含义为Resource=0的请求）。Resource=0的含义其实就是保证此次请求能够真正到达服务器，去掉那些本地可以缓存的东西；
• 估算方式二：CS类可以参考每小时的业务数/3600s，这是没办法的办法；
• 估算方式三：API类往往要求是Vuser*1API=TPS，由于公司的API都是提供给机构用户的，所以API要求往往比较高，所以需要保证其远算得非常快；

2.4.2 调查95%响应时间

只看平均时间是不太科学的，对于我们的系统来说需要保证绝大多数的用户其响应时间都是非常快的，所以我们从95％或以上用户响应时间为指标的标准。
估算方式大致有三种，如下：

• 估算方式一：BS类，按通用的标准2一5一8的标准来进行。不同业务，不同客户类型要求不同，但对于我们的产品来说绝大多数是不能超过5s；
• 估算方式二：CS类，根据处理的数据量其时间不同，但一般说来是不能超过15s的；
• 估算方式三：API类，从行业的角度来说，一般要求是毫秒级（<500ms)；

2.4.3 平均响应时间和TPS的波动率

这是对响应时间的补充，要求其系统响应时间应尽量稳定，TPS的波动率受测试方法和思考、间隔时间的影响。可参考以下的计算方式：

• T=（TPS标准差/TPS平均值）*100％一般说来小于10％
• T= (RPS标准差/RPS平均值）*100％一般说来小于10%

一、前端性能测试(客户端)：

• B/S：HttpWatch、FireBug、YSlow、JS内存泄漏、大数据量下的功能测试、浏览器长时间运行的稳定性测试等。
• C/S：内存泄漏、CPU使用、显卡使用等：
• 网络性能测试：利用工具分析网络传输以及延时等，为宽带拓展做铺垫。

二、服务端性能测试：

• 性能测试：是指以性能预期目标为前提，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期。（即：系统是否满足预定的性能目标？）
• 负载测试：是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到临界值，例如某种资源已经达到饱和状态等：（即，最大并发数是多少？在什么时候，响应时间不可接受”系统的服务器资源瓶颈是什么？）
• 稳定性测试：是指被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定，一般稳定性测试时间为n*12小时。（即系统在一般压力条件下，是否可以提供连接不断的优质服务？系统在长时间最大压力条件下，是否崩溃？）

2.4.4 测试前环境的检查收集

一、环境检查包括：

• 服务器的架构以及部署方案，
• 服务器的配置、中间件的参数配置，
• 需求、功能测试报告、API调用方式等

二、服务器的配置需要收集生产环境与实测试环境的服务器的配置。
主要收集：

• CPU：型号、核心、速度、核数、倍频、总线速度，己耗费平均CPU
• 内存：总物理内存、所在磁盘的虚拟内存、可用物理内存
• 磁盘：转速（如是旧有电脑，在执行前最好磁盘碎片整理一下）
• 网卡：一般是100Mb，专用网络可能在1000MB以上。

三、业务：
某个功能在一段时间内的使用频率：每天使用此功能大概有多少次？在多长时间内会操作此功能？
举个例子
设计脚本用例为：登录>进入单表查询（70％）>通过目录导航（80％）>检索>下载（80％），根据功能的重要性，这个用例应该首先要测试单场景，并且并发数也可能比其它的功能大一些，所以需要设置集合点。

四、思考时间：
以一个正常用户使用系统业务的角色，录制脚本随机产生，随后根据实际情况调整其值：在运行场景的时候，以50％至120％的比例随机使用思考时间。

2.4.5 持续时间

用户操作此功能的时间段，采用二八定理，取80％的场景时间；
注意用户操作此功能时间段，如果是业务类软件，中午的时间要去掉；

2.4.6 加载和退出方式

一般采用缓慢登录的方式，以便观察当用户数降低时其服务器的资源情况。但登录和退出功能除外，更多的登录和退出是集中在一个时间段。

3、总结

性能测试，不是一朝一夕就能学会的，也不是自己随便弄个Jmeter 或者Loadrunner ，运行一下，就说自己是大佬。
这都是扯淡。
真正的性能测试大佬，都是被各种摧残过，折磨过，而挺过来的人。
所以，必要相信所谓的，我会用Jmeter，我就会性能测试！
最后，如果想持续学习性能测试，可以持续关注小鱼的博客；
也可以关注小鱼性能测试专栏，从理论到实战，小鱼让你成为真正的性能测试大师。