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

性能测试的前提

必要性，是否有做性能测试的必要（关键项评估）

• 主管部门、监管部门审查
• 涉及生命财产安全
• 大型新系统
• 核心系统
• 架构调整
• 业务剧增
• 重大缺陷修复

可测性，可量化为性能指标值

• 一般有需求文档，根据老板或者产品提出的需求，我们需要将里面的需求内容量化为性能指标值，这是我们的性能指标预期结果
• 如果无法量化的话，我们就没有预期性能指标值，在性能测试中测出的性能指标值，没有可对比的值，那就不知道是否满足需求的需要

开展性能测试必备条件

独立网络

内网（zoom域）、外网独立分开，千万不要用跨内网外网

为什么要独立网络

• 在做性能测试会向服务器发送大量的请求，会有大量的网络传输，可能会出现网络堵塞
• 如果和功能测试人员使用的网络相同，将会导致功能测试时请求响应时间变长

建议使用直连的局域网

• 这不意味着要单独开辟一个条新的网线
• 注意：压力机和服务器之间不要通过wifi、***、堡垒机、跳板机来连接，他们很容易网络不稳定（如丢包），容易造成性能指标值不准确
• 建议：而使用局域网，有线网，压力机和服务器相连接的网络相对稳定，可以忽略网络延迟等网络因素影响性能测试结果
• 结论：如果连网络都得不到保障的话，那么测出来的性能指标值则不可信了，因为性能结果很可能会受网络因素的影响，从而导致和实际结果差异很大

如果使用公有云服务器

有内网、外网，测试时一般都是用公网，而上行会比较宽，可以基本忽略网络延迟

独立环境

功能测试不能和性能测试共用环境（测试环境）

• 在做负载测试的时候，会短时间内占用大量的系统资源，如果此时有功能测试正在进行中，很可能会导致功能的不稳定或异常
• 在做压力测试的时候，会长期占用系统的资源，导致一段时间内无法稳定进行功能测试

不能使用测试环境、生产环境

• 生产环境有真实用户的各种数据，数据量肯定非常庞大【用户数据庞大】
• 性能测试模拟大数据量测试，最终可能也会产生非常多的数据【产生数据】
• 这样一来，真实用户的数据+性能测试产生的数据混在一起，生产环境的数据量翻倍变多，会影响服务器对真实用户请求的响应时间【生产数据量变大，影响真实用户的响应时间】
• 性能测试产生的数据属于脏数据，不应该出现在生产环境中，所以性能测试不能在生产环境中进行，但硬件环境要尽可能一致【脏数据】

结论

• 所以，做性能测试需要有单独的一套环境，且硬件环境最好和生产环境一致
• 这样性能测试最终得到系统所能承受的最大负载量会更接近在生产环境中，系统所能承受的最大负载量

性能测试步骤

性能测试准备

• 需求分析，熟悉业务：确定需要重点关注的点，如TPS、响应时间（确定需要收集的性能测试指标值）
• 明确性能测试目标（预期性能指标值）和测试范围
• 了解软件功能、架构
• 制定测试方案、测试计划，做好工作量评估
• 制定测试模型（编辑测试用例）：比如负载测试，场景要如何设计

搭建性能测试环境

• 技术准备：选择性能测试工具；测试方案中涉及到的技术问题；测试数据的收集方案实现；如何监控系统资源
• 被测系统环境搭建（服务器、服务版本更新、数据库数据准备）
• 网络配置
• 创建初始数据，如：测试账号（预估并发量）

性能测试脚本开发

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

性能测试执行

真正开始对服务器进行性能测试

• 试运行
• 场景执行
• 收集并整理测试数据

性能测试结果分析与调优

• 分析依据：结果图表
• 分析思路：服务器硬件瓶颈>网络瓶颈>服务器os瓶颈（参数配置、数据库、web服务器）>应用瓶颈（sql语句、数据库设计、业务逻辑、算法）
• 调优
• 修改脚本或场景
• 性能回归，和之前的测试数据进行对比，是否有优化

服务器硬件瓶颈

如果性能测试环境和生产环境的硬件相差甚远，那么硬件很大程度造成了性能瓶颈，也不用去分析后面可能会导致性能瓶颈的其他原因了

性能测试报告与结果跟踪

• 性能测试报告：整理调优前后的测试数据
• 性能测试问题跟踪
• 构建持久化的性能监听平台，监听线上服务器的系统资源

标签：指标值,性能,测试步骤,环境,网络,测试,服务器,大话
来源： https://blog.51cto.com/u_12020737/2853923