说到负载测试，总是有一个价值百万美元的问题，“在性能方面，客户希望如何使用他们的应用程序和系统？” 我敢肯定，你永远不会得到一个简单的答案，我们大多数人总是假设一些情况并执行性能测试，这可能最终遗漏测试关键部分，从而导致客户不满意。不满意的客户意味着对你的组织业务的损失以及作为性能工程师的职业生涯下滑。但别担心，本文将讨论创建一个清单，它将帮助你解答这些问题。
该清单更像是一个逐步流程，你可以遵循并适应你的性能测试生命周期。在讨论的场景中，我们不能总是责怪客户，因为他们起初可能不知道具体想要的性能结果，但他们对应用程序在不同条件下的工作原理有明确的了解。一个优秀的性能测试人员可以通过定义明确的问卷来管理这种不确定性。这就是清单的第一项——需求收集问卷。
需求收集问卷
下面是你可以在项目中参考的问卷格式。我们需要尽可能多地获得这些问题的答案。最好能通过电话讨论这些问题。确保应用架构师或开发人员与你和客户一起参加电话会议。额外人员的参与可以提供见解，揭示你之前可能没有考虑到的问题。下面的问题为你创建更高效、有效的负载测试提供了路线图。
| 编号 | 主题 | 问题 |
| 1 | 应用程序 | 待测试的应用类型（例如，网页应用、移动应用等）。 |
| 2 | 应用架构及技术/平台。 | |
| 3 | 使用的负载均衡技术。 | |
| 4 | 客户端与服务器之间的通信协议（例如：HTTP/S、FTP）。 | |
| 5 | 性能测试目标。需要监控的性能指标（例如，每个操作的响应时间、并发用户数等）。 | |
| 6 | 性能测试的关键场景。 | |
| 7 | 后台定时作业/进程的详细信息（如有）。 | |
| 8 | 会话管理技术及支持的并行会话数。 | |
| 9 | 客户 SLA/需求 | 预计并发用户数和总用户基数。涵盖场景的用户分布。 |
| 10 | 涵盖性能测试范围内所有事务的 SLA（预期吞吐率、响应时间等）。 | |
| 11 | 需要执行的性能测试类型（负载测试、耐力测试等）。 | |
| 12 | 系统/环境 | 测试环境详情（网页/App/数据库等，以及节点数）。建议使用类似生产环境的环境执行性能测试。 |
| 13 | 生产环境与性能测试环境的对比。 | |
| 14 | 性能测试执行期间是否隔离应用程序以避免与其他应用交互。 | |
| 15 | 内置日志机制或监控机制的详细信息。 | |
| 16 | 其他 | 应用性能基线结果。 |
| 17 | 当前性能问题（如有）。 | |
这些问题的答案将帮助你制定高质量的测试策略/测试计划。如果客户无法提供所有答案也无需担心。我们总可以探索被测应用并找到答案。例如，如果有APM/日志工具，我们可以从生产系统中推导出并发用户数、吞吐量和响应时间。切记，不要假设你能在不询问的情况下获得所需信息。
寻找合适的性能测试工具
性能测试人员应慎重选择最佳性能测试工具。确定并推荐工具前需考虑诸多因素。记住，客户预算始终是选择性能测试工具时的重要因素。
如果你正在寻找性价比高、易用且能提供完整性能解决方案的性能测试工具，绝对值得尝试LoadView。与传统负载测试工具相比，LoadView无需昂贵投资、耗时设置或提前掌握脚本框架知识。此外，该平台提供20多个全球节点供加载注入，允许你在每次测试中从多个地点测试和测量性能。
所有类型的性能测试都需投入时间和精力。负载测试能帮助组织避免潜在的尴尬，但在免费开源工具如JMeter上进行同样测试却无法体现投资价值。真正从终端用户视角理解网站或应用性能时，基于协议的测试是不够的。你还必须测量客户端交互和步骤的性能。这里有LoadView与其他性能/负载测试解决方案的对比，及为何应选择LoadView满足你的性能测试需求。
面对网站和应用加载缓慢，用户会迅速失去耐心，如果你的站点或应用不能满足他们的期望，他们会离开寻找替代品。了解你的网站/应用能承受多少负载很重要，基于多种原因，但LoadView平台可以协助处理几种重要场景：
- 适应性和扩展性。确定为何当多个用户访问时你的站点或应用变慢。
- 基础设施。理解是否需要硬件升级。额外硬件的实施和维护成本可能成为资源浪费。
- 性能需求。你的站点或应用能妥善处理少量用户，但现实情况如何？
- 第三方服务。观察外部服务在正常甚至高峰负载情况下的表现。
性能测试计划/策略
一旦收集了客户需求并选择了合适的性能测试工具，我们需要记录测试计划/测试策略。启动任何性能活动前，务必获得客户对测试计划的批准。这非常重要，能帮助你避免后续不必要的阻碍。测试计划应包括以下几点：
- 性能测试目标。我们的目标是什么。
- 项目范围。项目范围，例如：脚本数量、测试时长等。
- 应用架构。应用详情，如应用服务器、数据库服务器，如果有，请附架构图。
- 环境详情。测试环境的详细信息。性能测试最好使用隔离环境。
- 基础设施搭建。性能测试的初始设置（例如，云环境、工具安装等）。
- 性能测试方法。测试的执行方式。应从少量用户开始baseline测试，逐步增加用户数，执行不同类型的测试，如压力测试、耐力测试等。
- 进入和退出标准。非常重要。应在功能缺陷为零时开始性能测试。同时应记录何时终止性能测试。
- 缺陷管理。应使用客户采用的相同工具和流程记录性能测试相关缺陷。
- 角色与责任。涉及性能测试各项活动的相关人员详细信息。
- 假设与风险。如果有可能影响性能测试的风险，应记录。
- 测试数据策略。测试数据策略及提取方法的详细信息。
- 测试计划时间表及关键交付物。脚本编写、测试执行、分析及交付物的时间安排和客户审核计划。
实际性能测试依赖多种技术组合。为达预期目标，不同的性能测试需求需要不同策略。包括用户负载、并发用户、工作负载模型等指标都需考虑。如果你曾做过工作负载建模，可能听说过Little定律。建议学习并应用它以规划测试，获得理想结果。
实时性能脚本/场景
一旦与客户达成性能计划或策略，就可开始使用选定的性能测试工具进行脚本编写。构建优质脚本是性能测试成功的关键，整个过程需牢记若干重要事项。
首先，编写脚本时务必遵循测试用例步骤以确保准确性。先回放单用户脚本，解决关联或参数化问题。参数化可能涉及头信息、Cookie或请求体参数。脚本在单个用户下运行顺畅后，测试多次迭代和不同用户数据。准备根据新数据调整关联或参数化。
某些用例可能需编写定制代码片段。例如，提取特定响应数据为某用户使用，并用于另一个请求。别忘了根据工作负载模型加入思考时间、节奏控制和错误处理机制。验证脚本功能时，通过文本或图像检查保证预期结果。
除了脚本编写，还应考虑模拟缓存、Cookie及不同网络条件以反映真实场景。作为性能工程师，创建真实虚拟用户行为至关重要，始于需求阶段准确细节的收集。
关键问题包括：
- 业务时间内，应用交互的总用户数是多少？
- 用户通常执行哪些操作，频率如何？
- 高峰负载时的用户数是多少？
这些答案可通过需求收集问卷获取，或分析APM解决方案、Google Analytics等工具统计数据。事务分析尤其有助于识别关键业务事务，设计真实反映实际使用的性能测试场景。遵循这些步骤，你将有效执行性能测试，交付可靠结果。
工作负载建模
我们可以以不同方式规划工作负载模型。性能工程师应先学习并实践“Little定律”再选用工作负载模型。以下是一些常见的工作负载模型。当然，性能工程师应根据手头需求选择合适模型。
工作负载模型1。简单模型，测试过程中用户数持续增加。例如，每秒新增一个用户，直至测试结束。
工作负载模型2。用户数以阶梯式增加，整个测试期间维持一定时间。例如，前15分钟为100用户，接下15分钟为200用户等。适合耐力测试计划。
工作负载模型3。最常见的性能测试模型。用户数在一定时间内持续增长（称为增长期），之后保持稳定一段时间，然后逐渐减少结束测试。例如，计划测试1.5小时，首次15分钟渐增用户，最后15分钟渐减，稳定期为1小时。分析结果时只考虑稳定期数据。
工作负载模型4。用户数整个测试期间突然增加和减少。该测试类型有多种名称，如猴子测试、峰值测试等。
我们需建立全面的性能测试目标与需求。定义性能参数及各项的验收标准。如果你既不了解测试需求，也不清楚期望结果，那么性能测试就是浪费时间。
数据收集
以下是工作负载建模时需监控的一些非常重要的指标。
响应时间：响应时间是服务器响应客户端请求所耗时间。许多因素会影响服务器响应时间。负载测试可帮助发现并消除导致响应时间变长的因素。
平均响应时间：负载测试稳定期内响应时间的平均值。
90百分位响应时间：90百分位响应时间指90%的响应时间低于该值。例如，500个请求中各自响应时间不同，90百分位值对应90%的请求响应时间低于此值，仅10%的响应时间高于此值。当部分请求响应时间极长，导致平均响应时间偏高时，该指标非常有用。
每秒请求数：需通过APM工具或生产日志获取该值。根据并发用户数，规划每秒发送到服务器的请求数。
内存利用率：基础设施指标，帮助发现瓶颈。应规划合理的工作负载，避免连续过多请求压垮服务器。
CPU利用率：同内存利用率，运行性能测试时需关注。
错误率：应跟踪交易的成功/失败比例。错误率不应超过成功交易的2%。如果随着并发用户增加错误率上升，可能存在瓶颈。
并发用户数：通过APM工具或生产日志获取，通常依据典型业务日确定。
吞吐率：显示服务器处理并发用户的能力。并发用户数与吞吐率直接相关。用户增多时，吞吐率应升高；若随用户增多反而降低，可能存在瓶颈。
用户负载分布：设计工作负载时需考虑，假设有五个脚本代表五个不同功能，应根据生产或APM工具调查结果尽可能真实地分配用户负载。
设计工作负载模型时应牢记以上重要指标。其他指标亦会因客户端应用架构和需求而异。
性能测试环境检查清单（执行前）
下面的清单通常用于企业级端到端性能测试，涉及大量系统。建议小规模性能测试也参考环境检查清单。具体活动会根据应用环境不同而变化，尤其是云端应用与本地应用间差异巨大。
结论：负载测试准备清单
成功的软件性能测试不是偶然。架构师、产品负责人、开发人员和性能测试团队必须协作，共同解决性能测试需求，然后再评估软件。想了解更多关于LoadView平台的详细信息，可阅读我们的技术概览，了解如何最大化你的性能测试。性能测试应是一个持续过程。随着网站或Web应用的发展，需要针对增长的用户基数做出调整。任何应用和测试都有改进空间。
希望本文让你对性能测试的最佳实践有了深入了解。如果你想全面演示LoadView解决方案，报名参加演示，性能工程师将逐步指导你完成从负载测试脚本创建、测试配置到测试执行和结果分析的全过程。
或立即注册LoadView免费试用开始运行负载测试。我们将赠送你免费负载测试额度！祝测试愉快！