性能测试攻略(一)：需求分析

性能测试成为软件开发和运维过程中不可或缺的一环。性能测试不仅能够帮助我们了解系统在特定条件下的表现，还能帮助我们发现并解决潜在的性能问题。那么我们怎么做一次完整的性能测试呢？首先，我们需要进行需求分析，来明确我们的测试目的。比如，本次测试要验证哪些内容，达到什么样的性能指标，或者要满足多少用户使用我们的系统。其次，我们要确定测试范围，考虑测试需求，根据我们的系统架构、模块划分、接口关系等因素，测试范围要尽可能全面。再次，我们需要确定我们使用的测试工具，如：LoadRunner、JMeter等，测试工具要满足测试需求。然后，我们就可以进行测试场景的设计，包括用户数量、操作频率、数据规模等。确定好上面的内容，就可以来制定我们的测试计划了，测试计划包括目标、范围、工具、场景、资源、时间和任务分配等。最后，我们需要准备我们的测试环境，要尽可能的模拟生产环境，包括硬件配置，软件版本、网络条件等。这样我们就可以执行性能测试。测试完成后对系统的测试结果进行分析，分析性能瓶颈，然后对瓶颈优化后，再次验证优化效果。

本篇内容，主要介绍一下性能测试的需求分析相关内容。

性能测试需求分析的重要性

性能测试需求分析是性能测试的第一步，也是至关重要的一步。它决定了性能测试的方向和重点，为后续的测试设计提供了依据。以下是性能测试需求分析重要性的几个方面：

• 明确测试目标： 通过需求分析，我们可以明确性能测试的目标，如确定系统的最大用户并发数、验证系统在特定负载下的响应时间等，从而确保测试工作的方向性和针对性。

• 指导测试设计： 需求分析的结果将直接指导测试设计，包括测试场景的选择、测试数据的准备、测试工具的选取等，确保测试工作的全面性和有效性。

• 评估系统性能： 性能测试需求分析的结果将作为评估系统性能的依据，帮助我们了解系统在特定条件下的表现，发现潜在的性能问题，为系统优化提供数据支持。

• 提升用户体验： 通过性能测试需求分析，我们可以更好地了解用户需求，模拟用户行为，从而确保系统在用户实际使用过程中表现良好，提升用户体验。

性能测试需求分析主要方式

• 用户调研： 通过用户调研，了解用户对系统性的需求和期望，如响应时间、并发用户数等，从而确定性测试的目标和指标。当然，用户不一定指系统真实的使用用户，也可以为系统的运营管理人员、产品设计人员或相关的业务人员都可以。

• 业务场景分析： 通过对业务场景的分析，了解系统的业务流程、数据规模、用户行为等，从而确定性能测试的场景和数据。尤其是对于访问频次多、业务复杂、数据量大等业务场景的分析。

• 系统架构设计： 了解系统的架构设计，包括服务器配置、网络拓扑、数据库、数据中间件等，以便在性能测试中模拟真实的系统环境。对于性能测试人员，一定要了解系统的整体架构，这样才能确保我们的测试范围覆盖的广、场景设计的全面、结果分析的准确。

• 历史数据分析： 通过分析历史数据，了解系统在过去的性能表现，如响应时间分布、错误率等，从而为性能测试提供参考。还要了解数据库在一定时间内产生的数据量，方便我们测试中模拟出铺底数据，使得我们在更接近生产数据量的环境下进行性能测试。容易发现数据操作类的性能问题。

• 行业标准和规范： 参考行业标准和规范，如响应时间标准、吞吐量标准等，以确定性能测试的指标和阈值。

性能测试需求分析要明确的目标

测试指标

我们要根据性能测试需求，来明确我们最终的性能指标。为我们的测试提供一个准则，满足指标即可判定为测试通过。下面举例说明几个指标：

• 交易响应时间： 用户从客户端发起一个请求，到客户端接收到从服务器返回结果的响应结束，整体过程所耗费的时间；响应时间=网络传输时间+服务器处理延迟时间+数据库服务器处理延迟时间，简单交易小于1.5s，一般交易小于3s，复杂交易小于5s。

• 业务处理能力(TPS)： 每秒处理交易笔数 以82原则计算交易峰值负载：3000人测试人员，每日提交缺陷10个，任务领取5个，任务列表20，执行列表20次，上传图片5次，上传视频5次，下载测试报告5次，导入用例3次。日交易总量为：3000x73=219000， 日交易量 = 交易总量合计(219000) x 80% =T T =175200 日交易时间 = 营业时间8小时*20% =1.6 TPS目标计算为：T /1.6 / 3600 = 30.41笔/秒

• 并发用户： 系统需求的最大使用人数

• 系统处理正确性： 在负载情况下，交易错误率。错误率=(失败交易数/交易总数)*100%。（不同系统对错误率的要求不同，但一般不超出千分之五。稳定性较好的系统，其错误率应该由超时引起，即为超时率。）

• 业务处理稳定性： 系统在标准压力（系统的预期日常压力）情况下，能够稳定运行。（一般来说，对于正常工作日（5X8小时）运行的系统，至少应该能保证系统稳定运行10小时以上。对于7X24运行的系统，至少应该能够保证系统稳定运行48小时以上。）

• 系统资源： CPU<=80% 内存使用率无明显上升趋势 磁盘繁忙率<=80%

测试范围

对于我们测试范围应该选什么？一般如果有明确的测试需求，那我们按照测试需求来即可，如果没有明确的测试需求，比如只要求了系统整体的性能指标，那可以参考以下的原则：

已上线系统：

• 测试交易要覆盖各个渠道；
• 一般系统：选取日均交易量TOP20、TOP10的交易；
• 选取生产上曾经出现或者容易出现问题的交易；
• 选取生产上占用资源较高的交易；
• 选取业务逻辑复杂的交易；
• 选取交易路径较长的交易；
• 选取处理时间较长的交易；
• 选取特殊需求的交易（测试并发、测试登录）。

未上线系统：

• 测试交易覆盖各渠道；
• 选取预期交易量大的交易；
• 选取预期交易量增长迅速的交易；
• 选取占用资源较高的交易；
• 选取交易路径较长的交易；
• 选取处理时间长交易；
• 选取业务逻辑复杂的交易；
• 选取频繁调用数据库的交易；

根据系统架构：

• 针对Redis，我们要测试大量redis key同时失效模式，一个热key的失效模式等，避免出现缓存穿透、雪崩的出现。
• 针对数据库，要测试大量的写入操作，避免出现数据库性能问题，针对一些可以多人操作的数据，要避免出现死锁现象。在大量的数据铺底情况下，测试复杂的查询交易。如果是数据库集群，还要考虑数据一致性和故障测试。
• 针对网络代理层，我们需要根据配置，测试超出配置最大连接数、缓存等相关内容。
• 针对服务层，我们需要考虑服务与服务之间的调用情况、避免相互调用，或者环形调用。
• 针对服务器，我们需要考虑服务器的内存、CPU、I/O、网络等资源，还有句柄、线程等。

性能测试需求问题

• 沟通与交流： 性能测试需求分析，我们要多方面考虑影响系统性能的因素，因此我们要与业务需求方、客户、开发人员、运维人员保持密切沟通。我们需要了解整体系统的功能架构、技术架构、应用部署方式、网络环境等一系列的内容。所以需要深入沟通，才能进行深度的分析。

• 简化测试场景： 虽然我们要根据多方面考虑，覆盖更广的测试范围，但是我们要简化测试场景。简化测试场景，可以降低测试难度和复杂度，构建接近真实的测试场景。