目录
- 一、性能测试的前提
- 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.测试报告与结果跟踪
- 性能测试报告。
- 性能测试问题跟踪。
发现的性能问题并不能这次就能解决。比如发现个内存问题，有可能是代码的结构性的调整来解决这个问题。
那就当期解决不了了。
那就等后期解决了，再反复的验证与调试，看这个问题有没有被真正解决。
