性能测试中的常见错误

性能测试执行和监控
在本文中，我们将重点介绍在测试和监控负载测试时可以避免哪些问题以获得更好的性能。在此阶段，虚拟用户脚本根据非功能测试计划中指定的并发用户数和工作负载运行。应在各个系统层启用监控，以将问题隔离到特定层。性能测试和监控是一个迭代过程，应满足性能要求和 SLA

以下是性能测试期间观察到的一些应避免的常见错误：

1. 缺少 NFR 和 SLA
非功能性需求是我们当今业务分析领域面临的最大问题之一。这些是大多数客户和组织最常忽略、误解或歪曲的需求类型。项目/产品团队中的每个人都必须了解什么是非功能性需求、如何最好地表达它们以及它们如何为您的用户故事或应用程序/产品添加巨大的附加值以获得最佳结果。性能工程师需要利益相关者提供适当的输入来了解应用程序架构、用户行为和应用程序/产品性能目标，以成功隔离所需的负载并轻松识别性能下降/瓶颈并成功修复它们。对于任何性能工程师来说，了解每个 NFR 对他或她正在实施的特定功能要求的影响和相关性非常重要，这与该人员拥有多年的经验无关。从他们职业生涯的第一天起就需要养成思考非功能性需求的习惯。

以下是开始性能测试之前需要了解的一些重要且关键的事项：

构建产品或软件的目标或愿景的总体情况清晰。
在开发过程的适当过程中不处理 NFR 的成本方面。
了解如何通过基于敏捷/冲刺的流程逐步实施和交付 NFR。
NFR 需要分解为故事或验收标准，并且必须相应地执行冲刺。
NFR 的最终用户视角更为重要。性能工程师应该能够通过与最终用户交谈来理解隐含的需求。
2. 性能测试结果未经验证
需要验证测试的成功和结果，以确保测试脚本确实正常工作并与系统/应用程序提交事务。根据环境，性能工程师、开发人员或系统管理员可以通过查询数据库或查看创建的平面文件/日志来验证这一点。例如，如果负载测试设计为每小时创建 15,000 个订单，则测试结束时数据库中应可见 15,000 个订单。

3. 工作负载特征未知或未最终确定
在缺乏工作负载特征的情况下，性能测试不会有明确的重点和目标。在这种情况下，生产中预期的工作负载可能与测试的工作负载有很大不同，从而导致分析和建议不正确。性能工程师必须确保所有性能测试都是在与生产环境相同的性能测试环境上进行的，以避免错误的结果和建议。

4.负载测试持续时间太短
计算机系统/应用程序中的所有组件都会经历一段时间内的初始瞬态状态，然后进入稳定状态以进行有效的工作。在规划任何性能测试时需要考虑这些固有特征。为了确保正确的结果，测试持续时间应该足够长，以便仅在稳态期间而不是瞬态期间捕获结果。

图片标题

5.负载测试所需的测试数据填充不足
将足够的数据（生产中预期的数据）加载到数据库中以确保结果的正确性至关重要。例如，在 10GB 数据库上完成的查询不到 1 秒，在 100GB 数据库上可能需要 10 秒以上。在加载数据库进行负载测试时，必须考虑现有的数据量和增长率。

6. 测试和生产基础设施之间的差距
没有直接的数学公式可用于将在较低配置上观察到的结果外推到较高配置上。例如，如果网页在单 CPU 服务器上加载需要四秒，则在四 CPU 服务器上不一定需要一秒加载。因此，建议在与生产环境相当的环境下进行性能测试。

7. 网络带宽未模拟
性能测试时需要考虑最终用户的位置。最终用户可能通过拨号调制解调器（1 Mbps 速度）或通过 WAN（10 Mbps 等）访问应用程序。在这种情况下，通过 LAN（10/100 Mbps）测试应用程序获得的结果与实时观察到的情况有很大不同。性能工程师应利用工具中可用的网络仿真功能，以确保涵盖负载测试的所有用例。

8. 测试时间表被低估
通常认为脚本编写、测试、监视、分析不需要太多时间即可完成。这是一个错误的假设，因为测试环境设置、数据填充、创建强大的脚本、建立监控技术和深入分析都是耗时的活动。项目计划中必须分配足够的时间和精力。这可以通过咨询性能 SME 和性能工程师来估计。

以下矩阵总结了与性能测试相关的各个方面：

好的

更好的

最好的

基础设施

生产量的 50%

容灾站点

100% 的产品

网络

共享局域网

独立的局域网

广域网模拟器

测试工具

本土的

开源

工业标准

测试类型

负载/体积

压力

可用性和可靠性

负载注入

合成的

重播

杂交种

测试工具

分析

优化

容量规划

监控

手动的

外壳脚本

工业标准

测试频率

定期

基于增长

每次发布

测试时间

2周

4周

> 4 周

9. 性能分析与调优
性能测试练习最关键的方面是确定系统/应用程序内的性能瓶颈。需要对所有性能测试结果和监控输出进行彻底的关联和分析，以确定性能问题的根本原因。性能主管、性能工程师和与特定技术相关的专家（例如 Oracle DBA、Linux 管理员、网络专家）应参与生成提高性能的建议。系统/应用程序中应用的任何建议都应经过严格测试，以确定所实现的效益水平，并确保实施不会产生副作用。测试、分析和调整是迭代过程，理想情况下应该继续进行，直到实现所有性能目标或 SLA。

10. 性能测试报告发布
执行的所有测试、分析和调优活动都应记录并作为测试结果文档发布，以促进团队和管理层之间的讨论和知识共享。在性能测试练习结束时，应发布最终报告，该报告主要总结以下内容：

原始非功能测试计划
与测试计划的偏差
结果与分析
提出并应用的建议
实现改进的百分比（例如响应时间、工作负载、用户并发性等）
容量验证
缺口分析
未来的步骤
结束性能测试
系统中总会存在一些瓶颈，但性能工程师必须能够识别它们，直到性能可以接受。在计划结束日期发布包含所有性能相关问题的应用程序是不可接受的；相反，我们需要优先考虑需要修复的缺陷。组织中的许多团队花费的时间不是几个月，而是几年来微调系统。了解和过滤需要修复的性能缺陷是非常棘手的。性能测试团队需要考虑系统的各个方面，并需要业务分析师和开发人员的意见，以确定业务工作流程的潜在问题以及解决的大致时间。