性能理论-软件性能测试方法论（四）

软件性能测试方法论

性能测试方法主要包括 SEI 负载测试计划过程和 RBI 方法。

1. SEI 负载测试计划过程

SEI 负载测试计划过程（SEI Load Testing Planning Process）是一个关注于负载测试计划的方法，其目标是产生清晰、易理解、可验证的负载测试计划。SEI 负载测试计划过程包括 6 个关注的区域（Area）：目标、用户、用例、生产环境、测试环境和测试场景。

SEI 负载测试计划过程将以这 6 个区域作为负载测试计划需要重点关注和考虑的内容，其重点关注以下几个方面的内容。

1. 生产环境与测试环境的不同

   由于负载测试环境与实际的生产环境存在一定的差异，因此，在测试环境上对应用系统进行的负载测试结果很可能不能准确地反映该应用系统在生产环境上的实际性能表现，为了规避这个风险，必须仔细设计测试环境。

2. 用户分析

   用户是对被测应用系统性能表现最关注和受影响最大的对象，因此，必须通过对用户行为进行分析，依据用户行为模型建立用例和场景。

3. 用例

   用例是用户使用某种顺序和操作方式对业务过程进行实现的过程。对负载测试来说，用例的作用主要在于分析和分解出关键的业务，判断每个业务发生的频度、业务出现性能问题的风险等。

从 SEI 负载测试计划过程的描述中可以看到，SEI 负载测试计划过程给出了负载测试需要关注的重点区域，但严格来说，其并不能被称为具体的方法论，因为其仅仅给出了对测试计划过程的一些关注内容，而没有能够形成实际的可操作的过程。同功能测试一样，性能测试也必须经历测试需求、测试设计、测试执行、测试分析等阶段，但由于性能测试自身的特殊性（例如，需要引入工具，分析阶段相对重要），性能测试过程又不能完全套用功能测试过程。

SEI 负载测试计划过程在负载测试需要关注的具体内容上提供了参考，但其并不是一个完整的测试过程。

2. RBI 方法

RBI（Rapid Bottleneck Identify）方法是一种用于快速识别系统性能瓶颈的方法。该方法基于以下一些事实：

1. 发现的 80% 系统的性能瓶颈都由吞吐量制约。

2. 并发用户数和吞吐量瓶颈之间存在一定的关联。

3. 采用吞吐量测试可以更快速地定位问题。

RBI 方法首先访问服务器上的小页面和简单应用，从应用服务器、网络等基础的层次上了解系统吞吐量表现；其次选择不同的场景，设定不同的并发用户数，使其吞吐量保持基本一致的增长趋势，通过不断增加并发用户数和吞吐量，观察系统的性能表现。

在确定具体的性能瓶颈时，RBI 将性能瓶颈的定位按照一种自上而下的分析方式进行分析，首先确定是由并发还是由吞吐量引发的性能表现限制，然后从网络、数据库、应用服务器和代码本身 4 个环节确定系统性能具体的瓶颈。

RBI 方法在性能瓶颈的定位过程中能发挥良好的作用，其对性能分析和瓶颈定位的方法值得借鉴，但其也不是完整的性能测试过程。

3. 性能测试基本过程

面试性能测试时，经常会问一个问题：能否简单地介绍一下性能测试的过程？多数人的回答都不咋地，原因是很多人不清楚性能测试以至于回答问题的思路混乱。其实，大家在应聘性能测试职位时，必须要清楚这个职位是具体做哪些工作的，并且按照工作的流程把每一个环节都表述清楚。

下面结合过往公司实际工作流程与阿里云性能测试流程给大家介绍一下，性能测试的过程到底是如何进行的。

本体系将性能测试工作共分为：需求阶段、准备阶段、执行阶段、报告阶段、总结阶段 5 部分。力求简单、实用、有效的指导当前的性能测试工作活动。

需求阶段	准备阶段	执行阶段	报告阶段	总结阶段
根据内部或外部客户的需求，项目经理需进行可行性分析、进行项目组筹建	执行具体的性能测试计数方案，并评审通过	按照测试计划中的测试内容规定项目执行各项测试	编制《性能测试分析报告》汇报测试结果以及对系统性能的评估	编制《性能测试总结报告》，总结性能测试过程、方法、经验、教训等，改进工作流程的建议等
项目经理针对客户的系统，需召集相关的人员开项目启动会	环境搭建准备，由客户方实施，并通过冒烟测试	详细记录测试工作步骤以及测试结果
项目经理组织人员进行详细的需求调研与分析，确定具体的需求范围	测试人员进行脚本设计、数据准备，监控部署等	根据测试结果和性能跟踪数据、监控数据进行系统瓶颈分析
制定详细的测试和优化分析计划并通过广泛的评审	编写日报或者周报并汇报上级管理层，接收上级管理层的监管与指导

总结整个性能测试流程体系，共包括 5 大阶段、7 项主要活动。

• 5 大阶段：需求阶段、准备阶段、执行阶段、报告阶段、总结阶段

• 7 项主要活动：项目启动、需求调研与分析、项目计划制定、性能测试准备、性能测试执行、性能测试报告、项目总结

4. 测试体系活动描述

4.1. 需求阶段

4.1.1. 活动 1—项目启动

附件下载：

• 附件 5-1-1-1：《性能测试需求》
• 附件 5-1-1-2：《项目启动会议记录》
• 附件 5-1-1-3：《性能测试需求分析报告》

4.1.2. 活动 2－需求调研与分析

附件下载：

• 附件5-1-2-1：《性能测试需求调研大纲》
• 附件5-1-2-2：《性能测试需求分析报告》

4.1.3. 活动 3－项目计划制定

附件下载：

• 附件5-1-3-1：《性能测试项目工作计划》

4.2. 准备阶段

4.2.1. 活动 4—性能测试准备

附件下载：

• 附件5-2-1-1：《性能测试技术方案》
• 附件5-2-1-2：《性能测试方案样例》

4.3. 执行阶段

4.3.1. 活动 5—性能测试执行

附件下载：

• 附件5-3-1-1：《性能测试执行日志记录》
• 附件5-3-1-2：《性能测试结果与缺陷跟踪》

4.4. 报告阶段

4.4.1. 活动 6—性能测试报告

附件下载：

• 附件5-4-1-1：《性能测试报告》
• 附件5-4-1-2：《性能测试报告样例》

4.5. 总结阶段

4.5.1. 活动 7—项目总结

附件下载：

• 附件5-5-1-1：《XX项目总结》

---

5. 性能测试需求分析

性能测试的目的就是把客户的真正需求搞清楚，这是性能测试最关键的过程。

有很多客户对性能测试是不了解的，客户可能会提出的我们需要对所有的功能都进行性能测试、系统用户登录响应时间小于 3 秒、系统支持 10 万用户并发访问等要求。那么这些需求是否存在什么问题呢？我们来分析下：

1. 我们需要对所有的功能都进行性能测试

   每位用户都希望自己公司应用的系统有良好的性能，从客户的角度讲，肯定都是希望所有的系统应用都有好的系统性能表现，那么是不是所有的功能都要经过性能测试呢？答案当然是否定的，通常性能测试周期较长。

   首先，全部功能模块都进行性能测试需要有非常长的时间；其次，根据 80-20 原则，通常系统用户经常使用的功能模块大概占用系统整个功能模块数目的 20%，像参数设置等类似的功能模块，通常仅需要在应用系统时管理员进行一次性设置，针对这类设置进行性能测试也是没有任何意义的。

   通常，性能测试是由客户提出需求内容，性能测试人员针对客户的需求进行系统和专业的分析后，提出相应的性能测试计划、解决方案、性能测试用例等与用户共同分析确定最终的性能测试计划、解决方案、性能测试用例等，性能测试的最终测试内容通常也是结合客户真实的应用场景，客户应用最多，使用最频繁的功能。所以说，对所有的功能都进行性能测试是不切实际也是不科学的做法，作为性能测试人员必须清楚。

2. 系统用户登录响应时间小于 3 秒钟

   从表面看这句话似乎没有什么问题，仔细看看是不是看出点什么门道呢？

   其实这句话更像一个功能测试的需求，因为其没有指明是在多少用户访问时，系统的相应时间小于 3 秒，作为性能测试人员必须清楚客户的真实需求，消除不明确的因素。

3. 系统支持 10 万用户并发访问

   从表面看这句话似乎也没有什么问题。在进行性能测试时，系统的可扩展性是需要我们考虑的一个重要内容。

   例如，一个门户网站，由于刚开始投入到市场上，访问用户量目前只有几百个用户，随着广告、推荐等措施推动了系统宣传力度，那么我们在做系统性能测试时候，需要对未来两三年内系统应用用户有一个初步预期，以至于在两三年后系统仍然能够提供给用户以好的性能体验。

   但是，倘若用户应用该系统的时候，日常每天只有几十个用户，在未来的 5～10 年内，也不过几百个用户，这是不是需要进行 10 万级用户并发访问的性能测试呢？

   建议是把这种情况向客户表达清楚，在满足当前和未来用户应用系统性能要求的前提下进行测试，能够节省客户的投入，这样客户会觉得你更加专业，也真正从客户的角度出发，相信一定会取得更好的效果。如果系统用户量很大，考虑到可扩展性需求，确实需要进行 10 万级用户这种情况的性能测试。我们也需要搞清楚 10 万级用户的典型应用场景，以及不同操作的人员比例，这样的性能测试才会更有意义。

性能测试成功的关键不在于性能测试工具，而在于有效的性能测试分析方法和实践。只有切实掌握了性能测试需求分析方法，才能保证一个应用性能测试的成功、有效。

1. 80/20 原则

   所谓 80/20 原则，即每个工作日中 80% 的业务在 20% 的时间内完成。

   举例：每年业务量集中在 8 个月，每个月 20 个工作日，每个工作日 8 小时，即每天 80% 的业务在 1.6 小时完成。去年全年处理业务约 100 万笔，其中 15% 的业务处理中每笔业务需对应用服务器提交 7 次请求，70% 的业务处理中每笔业务需对应用服务器提交 5 次请求，其余 15% 的业务处理中每笔业务需对应用服务器提交 3 次请求。根据以往的统计结果，每年的业务增量为 15%。考虑到今后 3 年业务发展的需要，测试需按现有业务量的 2 倍进行。

   每年总的请求数 = (100×15%×7 + 100×70%×5 + 100×15%×3) × 2 = 1000（万次/年）

   每天请求数 = 1000/(20×8) = 6.25（万次 / 天）

   每秒请求数 = (62500×80%)/(8×20%×3600) = 8.68（次 / 秒）

   即服务器处理请求的能力应达到 9 次/秒。