高级性能测试系列《4.性能测试的前提、性能测试工具、性能测试流程》

目录

• 一、性能测试的前提
  • 1、性能测试的必要性研究---关键项评估
  • 2、可测性---可量化为性能指标值
  • 3、公司服务器不足，在项目还没有上线之前，可以用生产环境先做性能测试吗？
  • 4、公司有的项目上线了但是没有用户使用，比如3月项目完成了，4月才提供给用户使用。这样的情况下，能用生产环境做性能测试吗？
• 二、性能测试工具
• 三、性能测试流程

一、性能测试的前提

1、性能测试的必要性研究---关键项评估

做性能测试，首先要进行关键项的评估。

公司的这个产品需要做性能测试。得知道哪些功能需要先做性能测试，哪些功能后做性能测试。

假如产品有100个功能，连个优先级都没有排，我就拿100个功能一起来做性能测试，这样丢了西瓜捡了芝麻，啥也没做成。

1）主管部门、监管部门审查；

2）涉及生命财产安全；

比如银行系统，最近改版了，新版本替换掉老版本，如果没做性能测试，万一在高并发的时候，数据（钱）有问题，就会很麻烦。

3）大型新系统；

新版本替换掉旧版本的时候，肯定是要做新版本的性能测试的，不然响应时间更长，性能更差，用户体验感就越差。

4）核心系统；

例如有100个业务，肯定是做核心的业务，或者是用户使用量最大的优先。

业务的优先级和重要性需要评估，没有那么多时间什么业务都做性能测试。

5）架构调整；

如果公司开发的项目都是用1.8的jdk，现在出现了jdk1.11，发现jdk1.11有很多新的功能。

我就把jdk升级到了1.11版本。升级完毕后，功能测试没有问题，但是性能可能会有问题。

jdk这个东西是最底层的东西，要运行java代码必须要有jre的运行环境，运行环境里就安装了jdk、jre。

这个是底层的依赖，如果这个底层的依赖的性能不能满足要求。那产品上线后，功能没问题，但是用户一旦上来了就出现性能问题了。

所以这种底层的调整，也是需要全面得做性能测试的。

6）业务剧增；

这种促销活动，在上线之前肯定要做性能测试的。

虽然这不是核心业务，这种促销活动做完了，下次可能不会再用这个页面了，但是因为它的特殊性，也得做性能测试。

7）重大缺陷修复。

有的公司的项目里有些陈年老坑，终于花了时间成本的投入，改了很多东西，某一天他把这个坑修复了。

这个坑被修复后，影响范围很大，功能测试人员要加班测试，性能测试人员也得加班测试性能。

因为老坑被修复的时候，改了底层的东西，底层的东西的性能没有跟上，功能是没问题，但是可能还有一大段的代码需要调整。

重大缺陷的修复，一般会改底层改得很广，修复后就需要做性能测试。

2、可测性---可量化为性能指标值

如果你们公司的项目是产品主导型，产品人员提出这个性能的需求，他不懂得性能测试。

如果你们公司是这种项目主导型，项目经理不懂性能测试。

那么他们提出的需求，做性能测试就很难。但是也得去做性能测试，那么就需要你掌握性能测试的知识和技能，来和你们的负责人反复得沟通确定性能指标。

3、公司服务器不足，在项目还没有上线之前，可以用生产环境先做性能测试吗？

项目还没有上线，代码都没有上到生产环境中去，是无法做性能测试的。

虽然有些企业把生产环境切换到测试环境里来用，关键是代码都没有上到生产环境中去，既然代码都没有更新过去，也就做不了性能测试。

如果没测试完就把代码上到生产环境中去，让你做性能测试，这就相当于已经上线了啊。

如果你们公司有灰度发布的环境，这个是可以的。

如果生产环境中有30台机器，可以从里面剥离几台机器先更新代码上去，用一部分的真实用户来体验这个新功能。

看下新功能满足不满足他们的要求。如果满足，再把剩余的机器也更新新的代码。

这个其实把生产环境分为2个环境，一个是老的代码，一个是新的代码。

这个倒是可以把这个环境拿过来用，但是要注意数据库的问题。生产环境做灰度发布环境的时候，一般也会把数据库做2个。

特别是数据库如果有表结构的变更，你没有做两个数据库的话，灰度发布环境是发不了的。

但是也得把灰度发布环境的数据库切换掉，不能用灰度发布环境的数据库，因为用了以后也会有脏数据到灰度发布的环境里面去。

因为灰度发布环境，有一天是会转换成正式环境的。

脏数据到灰度发布环境的数据库里去了，有一天也会成为生产环境的脏数据的。

4、公司有的项目上线了但是没有用户使用，比如3月项目完成了，4月才提供给用户使用。这样的情况下，能用生产环境做性能测试吗？

产品已经发布上线，但是没有什么用户量。或者是会迭代一直发布新的功能到生产环境里去，让潜在客户先来体验，体验了之后，满足了客户的要求，才会有真正的付费用户来使用。

这种情况，如果做性能测试也会存在脏数据的情况。清理生产环境的脏数据是清理不干净的。

先备份，然后去做性能测试，做完了之后再用备份来还原，这种方式清理掉脏数据的成功率不高。

而且有成本和操作上的风险，一般情况下公司不会让你去这样干。

二、性能测试工具

开源：jmeter

java开发、跨平台、版本更新快（建议v5.1.1以后+jdk1.8）。

商业：loadrunner

性能测试标杆软件、c语言、国内破解（< lr11)、lr12免费试用50限制用户数、更新慢。

自研：python+locust

python语言自行开发。

三、性能测试流程

1.性能测试准备

• 1）需求分析-----熟悉业务。
• 2）明确性能测试目标（指标值）。
• 3）了解软件功能、架构。
• 4）指定测试计划，做好工作量评估。
• 5）制定测试模型（编辑测试用例）。

和功能测试有区别，相同的是都要进行需求分析。

功能测试关注的是单个人发起请求，目的是找bug。但是专业的性能测试人员关注的是多个人发起请求，这个时候出现了功能bug，我也不管。

并不去直接了解业务，但是要了解整体的数据流、整体的架构、整体的功能。

具体接口的功能逻辑的实现，不清楚也没关系。但是要整体了解功能间如何交互数据的，哪个功能需要依附什么数据。

服务器架构，服务间如何进行数据交流的，是什么样的配置，这个得清楚。因为接下来搭建环境需要清楚这些。

工作量的评估：会比功能测试、自动化测试的时间都要长。同等的工作，消耗的时间大概是他们的2-3倍的时间。

并不是所有的功能都需要做性能测试，只是部分功能做性能测试。

测试用例转换下来就是性能测试场景、负载测试场景等。

2.搭建性能测试环境

• 1）工具选型与准备。

不同的协议，会采用不同的工具。

• 2）被测系统环境搭建（服务器、服务版本更新、数据库数据准备、监控环境）。

测试前，数据库的数据量级要准备好。

• 3）网络配置。

3.性能测试脚本开发

• 选取协议。
• 制作脚本。
• 调试脚本。
• 验证脚本。

可以在测试环境制作脚本，调试脚本。

在开发的时候，功能测试人员也在测试，性能测试人员写的脚本可以直接对接测试环境。

将来只要把环境的ip对接到性能测试环境中去，就可以在性能测试环境中做性能测试了。

脚本的开发也不受影响，因为功能测试环境的代码比性能测试环境的代码先更新的。

调试脚本和验证脚本，会逐步转移到性能环境里面来。

4.性能测试脚本执行

• 试运行。
• 场景执行。

要把测试用例使用到脚本里面，进行场景的转换，执行场景。

要搭建一个监控环境，收集测试结果的性能数据。用于后面的性能测试结果的分析与调优。

5.结果分析与调优

• 1）分析依据：结果图表。
• 2）分析思路：服务器硬件瓶颈>网络瓶颈>服务器os瓶颈（参数配置、数据库、web服务器）>应用瓶颈（sql语句、数据库设计、业务逻辑、算法）。
• 3）调优。
• 4）修改脚本或场景。

6.测试报告与结果跟踪

• 性能测试报告。
• 性能测试问题跟踪。

发现的性能问题并不能这次就能解决。比如发现个内存问题，有可能是代码的结构性的调整来解决这个问题。

那就当期解决不了了。

那就等后期解决了，再反复的验证与调试，看这个问题有没有被真正解决。