本文由作者刘静媛授权网易易盾发布
如何做好一次性能测试计划呢？对于性能测试新手来说，也许你非常熟悉Jmeter的使用，也许你清楚的了解每一个系统参数代表的意义，但是想要完成好一次性能测试任务，并不仅仅是简单的写脚本，加压力，再拿到响应结果和监控数据这么简单。有哪些关键因素需要好好考虑呢？以下是我个人总结的一些关键点，供大家参考。
性能测试其实是一个非常庞大的领域，涉及到很多知识和专业技能。而针对不同的被测系统或被测产品，又有不同的测试方式和侧重点。此文谈及的性能测试是针对互联网后端服务的性能测试。
在业务线上做性能测试，首先以了解业务背景为前提条件，在此基础上，去做一个尽可能完备的测试计划，设计出关键且有效的测试场景，用最少的测试执行来回答被测系统性能如何这个问题。我总结了一些个人在做性能测试计划方面的心得和体会，希望能够对大家在做性能测试计划的时候有所帮助。
在做性能测试计划的时候，我们首先需要充分思考这几个问题：
○ 我们需要知道系统的哪些性能情况？
○ 我们要采用哪种类型的性能测试，通过哪些测试场景来评估系统的性能情况？
○ 按照我们制定的性能测试计划，最终拿到的测试结果能不能支持推断出系统性能是否符合业务目标的结论？
一、明确目标
要回答第一个问题，最好的切入点是了解业务目标是什么。
○ 业务目标的确定：在做性能测试计划前，我们应该向项目组核心成员去了解业务情况，询问项目经理、运营、产品、技术负责人，预期的业务量是多少？未来规划的提升量是多少？在哪些方面有特殊的业务要求，比如哪些场景对响应时间有强要求，是否会有促销手段可能导致线上出现秒杀情况等等。
○ 性能风险的推测：条件允许的情况下，我们还可以向项目组的每个参与者了解情况：你最担心系统出现的性能问题是什么？为什么会有这样的担心？有时候项目的核心成员并不清楚系统设计的细节，而那些被忽略的细节又常常出其不意的在线上带给我们麻烦。
○ 整理自己对业务的理解，梳理收集到的业务目标和问题，将业务化的目标转化成明确的性能测试目标。
二、选取方法
关于第二个问题，在我们已知性能测试目标的情况下，应该采用哪种类型的性能测试手段呢？我总结了一下几种主要的性能测试的特点，如下表所示：
| 类型 | 定义 | 优点 | 短板 |
| 性能测试（Performance Test） | 性能测试是用于确定或验证被测产品的响应性，速度，可扩展性和稳定性的一种测试技术 | 1.可以确定应用程序的速度，可伸缩性和稳定性特征，从而为制定合理的业务决策提供参考意见。 2.可以帮助确定用户是否会对系统的性能特点满意 3.测试结果可以支持系统的容量规划和优化工作 |
1.可能无法检测到仅在高负载下出现的某些功能缺陷。 2.除非在用户真正使用的生产环境上进行测试，否则结果总会存在一定程度的不确定性。 |
| 负载测试（Load Test） | 通过逐步增加系统负载，确定在满足性能指标的情况下，系统所能承受的最大负载量。 | 1.可用于确定应用程序在性能受损之前可以处理的业务量。 2.可以发现高负载情况下才会出现的功能缺陷 3.可以验证负载均衡的有效性 4.可以依据测试数据进行可伸缩性和容量规划。 |
1.采用负载测试的主要目的不是用来关注响应速度 |
| 压力测试（Stress Test） | 指应用程序在超出正常或峰值负载条件下运行，用以发现在超负载情况下程序出现的错误，确定超负载情况下应用程序的表现 | 1.确定极限负载下，业务数据是否会出错，以及出错后是否可以修复 2.可以确定不考虑速度缓慢这个问题，应用程序在出现故障和错误之前能承受多大的压力 3.帮助确定最有价值的错误应急方案 |
1.压力测试的结果通常不是利益相关者最关心的情况 2.压力测试需要在独立的测试环境完成，否则可能对环境产生严重破坏，造成较大的影响 |
| 容量测试（Capacity Test） | 用来确定被测系统在满足性能指标的情况下，最多能支持多少用户或事务 | 1.正确规划的容量测试，其测试数据可以为业务发展规划提供有力支持 2.对现有系统进行容量测试，结合业务增长计划，可以提前做系统优化准备 |
1.评估容量的测试场景比较难以设计 2.并非所有的业务量评估都可以用容量测试结果来评估 |
○ 如果业务目标关心用户操作后多快能收到响应，那么我们会选性能测试（Performance Test）来作为主要测试方法。在已知这些不同类型性能测试的特点后，我们就能更好的做出选择，采用恰当的方式更高效的达到测试目的。例如：
○ 如果想要知道用户抢购某商品时出现“挤爆了”提示后会不会影响其他业务，以及出现问题后多久能恢复正常，那么我们可以选择压力测试（Stress Test）
○ 如果想要知道业务不断扩张，用户群体不断增长的情况下，最应该先做哪方面的系统优化准备，那么我们会选择进行容量测试（Capacity Test）
当然，大多实践的时候，你会发现单一的测试方式并不能回答我们关于被测系统或被测应用的全部问题，我们需要采用几种测试方法共同完成一次性能测试任务。
三、减小差异
第三个问题，测试结果能不能支持推断线上系统性能是否符合业务目标？这个问题并不是在拿到最终测试结果的时候才应该去思考的。这个问题的思考时机应当前置，并且贯穿整个性能测试计划设计以及测试执行过程中。为了让我们的测试结果更具有准确性和权威性，在做性能测试计划的时候，应该从两方面考虑：
第一，测试环境和生产环境尽可能的保持一致，包括硬件条件和软件配置都尽可能一致，对于达不到一致的方面，要分析差异及存在的影响。
第二，测试场景中模拟的用户行为，要尽可能贴近真实用户的行为习惯。在设计压测场景时，不能纯粹靠想象去预估用户行为和各个行为的用户比例，我们应当结合已监控到的真实用户行为，合理建立压测模型。在这两点基础之上，得出压测数据后，再结合其他因素来预估线上性能情况。
四、产出计划
想清楚上述问题后，我们再来填充我们的性能测试计划。个人认为一个全面的测试计划，应该包含以下几个部分：
1.性能测试目的
像前文已经提到过的，我们应该明确性能测试的目的，了解被测业务特点和业务目标，并将业务目标转化为明确的性能指标。为了更好的帮助我们理解被测系统，画出被测系统架构图是很必要的，在整个系统架构图中，确定被测系统范围，集中精力到需要关注的性能表现上。
2.性能测试环境
（1）了解清楚生产环境的各种配置，明确测试环境需要的硬件、软件条件。
（2）思考是否需要借助其他辅助工具来完成性能测试任务
（3）充分对比生产环境和测试环境差异，差异说明可以为后续分析和推测线上性能情况提供参考信息。
3.测试场景设计
（1）了解业务后，选择关键链路，并对不同链路设置优先级
（2）根据测试场景，做辅助测试数据准备
（3）监控数据项列举
（4）测试脚本准备方案和验证方案
（5）测试场景列表，包含关键项：场景名称、场景描述、并发用户数、用户分布、持续时间等
4.测试执行计划
（1）性能测试准入条件
（2）测试执行schedule
（3）测试执行策略，例如单个场景执行三次，统计平均值
（4）测试执行完成条件
5.性能测试交付内容
（1）性能测试结果数据
（2）性能测试结论，是否达到预期指标，是否能支持业务需求
（3）性能优化建议
6.风险说明
（1）排期风险
（2）技术风险
（3）资源风险
以上是基于个人的有限性能测试经验总结出的几个关键点，包括做性能测试设计时应该注重的几个关键问题，同时给出了一个性能测试计划里应包含的关键部分。具体实践中，涉及到的问题可能还有很多，设计方案还需要考虑方方面面的因素，但是这些关键要素能帮我们快速思考清楚如何准备当前的性能测试任务。性能测试领域还有很多知识待挖掘，许多经验待总结和分享，希望我的这篇总结对大家能有所帮助。