大话性能测试系列（2）-性能测试步骤

⼤话性能测试系列（2）-性能测试步骤
如果你对性能测试感兴趣，但是⼜不熟悉理论知识，可以看下⾯的系列⽂章
性能测试的前提
必要性，是否有做性能测试的必要（关键项评估）
主管部门、监管部门审查
涉及⽣命财产安全
⼤型新系统
核⼼系统
架构调整
业务剧增
重⼤缺陷修复
可测性，可量化为性能指标值
⼀般有需求⽂档，根据⽼板或者产品提出的需求，我们需要将⾥⾯的需求内容量化为性能指标值，这是我们的性能指标预期结果
如果⽆法量化的话，我们就没有预期性能指标值，在性能测试中测出的性能指标值，没有可对⽐的值，那就不知道是否满⾜需求的需要
开展性能测试必备条件
独⽴⽹络
内⽹（zoom域）、外⽹独⽴分开，千万不要⽤跨内⽹外⽹
为什么要独⽴⽹络
在做性能测试会向服务器发送⼤量的请求，会有⼤量的⽹络传输，可能会出现⽹络堵塞
如果和功能测试⼈员使⽤的⽹络相同，将会导致功能测试时请求响应时间变长
建议使⽤直连的局域⽹
这不意味着要单独开辟⼀个条新的⽹线
注意：压⼒机和服务器之间不要通过wifi、vpn、堡垒机、跳板机来连接，他们很容易⽹络不稳定（如丢包），容易造成性能指标值不准确
建议：⽽使⽤局域⽹，有线⽹，压⼒机和服务器相连接的⽹络相对稳定，可以忽略⽹络延迟等⽹络因素影响性能测试结果
结论：如果连⽹络都得不到保障的话，那么测出来的性能指标值则不可信了，因为性能结果很可能会受⽹络因素的影响，从⽽导致和实际结果差异很⼤
如果使⽤公有云服务器
有内⽹、外⽹，测试时⼀般都是⽤公⽹，⽽上⾏会⽐较宽，可以基本忽略⽹络延迟
独⽴环境
功能测试不能和性能测试共⽤环境（测试环境）
在做负载测试的时候，会短时间内占⽤⼤量的系统资源，如果此时有功能测试正在进⾏中，很可能会导致功能的不稳定或异常
在做压⼒测试的时候，会长期占⽤系统的资源，导致⼀段时间内⽆法稳定进⾏功能测试
不能使⽤测试环境、⽣产环境
⽣产环境有真实⽤户的各种数据，数据量肯定⾮常庞⼤【⽤户数据庞⼤】
性能测试模拟⼤数据量测试，最终可能也会产⽣⾮常多的数据【产⽣数据】
这样⼀来，真实⽤户的数据+性能测试产⽣的数据混在⼀起，⽣产环境的数据量翻倍变多，会影响服务器对真实⽤户请求的响应时间【⽣产数据量变⼤，影响真实⽤户的响应时间】
性能测试产⽣的数据属于脏数据，不应该出现在⽣产环境中，所以性能测试不能在⽣产环境中进⾏，但硬件环境要尽可能⼀致【脏数据】
结论
所以，做性能测试需要有单独的⼀套环境，且硬件环境最好和⽣产环境⼀致
这样性能测试最终得到系统所能承受的最⼤负载量会更接近在⽣产环境中，系统所能承受的最⼤负载量
性能测试步骤
性能测试准备
需求分析，熟悉业务：确定需要重点关注的点，如TPS、响应时间（确定需要收集的性能测试指标值）
明确性能测试⽬标（预期性能指标值）和测试范围
了解软件功能、架构
制定测试⽅案、测试计划，做好⼯作量评估
制定测试模型（编辑测试⽤例）：⽐如负载测试，场景要如何设计
搭建性能测试环境
技术准备：选择性能测试⼯具；测试⽅案中涉及到的技术问题；测试数据的收集⽅案实现；如何监控系统资源
被测系统环境搭建（服务器、服务版本更新、数据库数据准备）
⽹络配置
创建初始数据，如：测试账号（预估并发量）
性能测试脚本开发
选取协议
制作脚本
调试脚本
验证脚本
性能测试执⾏
真正开始对服务器进⾏性能测试
试运⾏
场景执⾏
收集并整理测试数据
性能测试结果分析与调优
分析依据：结果图表
分析思路：服务器硬件瓶颈>⽹络瓶颈>服务器os瓶颈（参数配置、数据库、web服务器）>应⽤瓶颈（sql语句、数据库设计、业务逻辑、算法）调优
修改脚本或场景
性能回归，和之前的测试数据进⾏对⽐，是否有优化
服务器硬件瓶颈
如果性能测试环境和⽣产环境的硬件相差甚远，那么硬件很⼤程度造成了性能瓶颈，也不⽤去分析后⾯可能会导致性能瓶颈的其他原因了
性能测试报告与结果跟踪
性能测试报告：整理调优前后的测试数据
性能测试问题跟踪
构建持久化的性能监听平台，监听线上服务器的系统资源。