性能测试类型
系统的性能是一个相对的概念，覆盖面非常广泛，包括执行效率、资源占用、系统稳定性、兼容性、可靠性、可扩展性等，性能测试就是描述测试对象与性能相关的特征并对其进行评价而实施的一类测试。性能测试是一个统称，它其实包含多种类型，主要有负载测试、压力测试、并发测试、配置测试等，每种测试类型都有其侧重，对这几个主要的性能测试种类分别进行介绍。
负载测试
负载测试指逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统性能指标的情况下，系统所能够承受的负载量。负载测试类似于举重运动，通过不断给运动员增加重量，确定运动员身体状况保持正常的情况下所能举起的重量。对于负载测试来说，前提满足性能指标要求。例如一个软件系统的响应时间要求不超过2s，则在这个前提下，不断增加用户访问量，当访问量超过1万人时，系统的响应时间就会变慢，超过2s，从而可以确定系统响应时间不超过2s的前提下负载量1万人。
压力测试
压力测试也叫强度测试，它指逐步给系统增加压力，测试系统的性能变化，使系统某些资源达到饱和或系统崩溃的边缘，从而确定系统所能承受的压力。压力测试与负载测试有区别的，负载测试在保持性能指标要求的前提下测试系统能够承受的负载，而压力测试则使系统性能达到极限的状态。例如软件系统正常的响应时间为2s，负载测试确定访问量超过1万时响应时间变慢。压力测试则继续增加用户访问量观察系统的性能变化，当用户增加到2万时系统响应时间为3s，当用户增加到3万时响应时间为4s，当用户增加到4万时，系统崩溃无法响应。由此确定系统能承受的访问量为4万。压力测试可以揭露那些只有在高负载条件下才会出现的Bug(缺陷)，如同步问题、内存泄漏等。
并发测试
并发测试指通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时否存在死锁或其他性能问题。并发测试一般没有标准，只测试并发时会不会出现意外情况，几乎所有的性能测试都会涉及一些并发测试，例如多个用户同时访问某一条件数据，多个用户同时在更新数据，那么数据库可能就会出现访问、写入等异常情况。
配置测试
配置测试指调整软件系统的软硬件环境，测试各种环境对系统性能的影响，从而找到系统各项资源的分配原则。配置测试不改变代码，只改变软硬件配置，例如版本更高的数据库、配置性能更好的CPU和内存等，通过更改外部配置来提高软件的性能。
可靠性测试
可靠性测试指给系统加载一定的压力，使其持续运行一段时间(如7×24h)，测试系统在这种条件下否能够稳定运行。由于加载有压力且运行时间较长，因此可靠性测试通常可以检测出系统否有内存泄漏等问题。
容量测试
容量测试指在一定的软硬件及网络环境下，测试系统所能支持的用户数、存储量等。容量测试通常与数据库、系统资源(如CPU、内存、磁盘等)有关，用于规划将来需求增长(如用户增长、量增加等)时，对数据库和系统资源的优化。
性能测试计划
性能测试其实是一个非常庞大的领域，涉及到很多知识和专业技能。而针对不同的被测系统或被测产品，又有不同的测试方式和侧重点。在业务线上做性能测试，首先以了解业务背景为前提条件，在此基础上，去做一个尽可能完备的测试计划，设计出关键且有效的测试场景，用最少的测试执行来回答被测系统性能如何这个问题。在制定性能测试计划之前，需要充分考虑到以下三点：
- 确定需要获取系统哪些性能情况，从而确定性能测试范围。
- 需要采用哪些性能测试类型，来评估系统不同的场景的性能情况。
- 按照制定的性能测试计划测试出来的结果，能否满足业务上线性能需求。
针对以上三点，性能测试计划制定分为四个阶段，分别为：明确性能测试目标、明确性能测试类型、减少差异、产出计划。
明确性能测试目标
在进行性能测试计划制定前，需充分进行信息调研，了解系统和业务特点，不基于业务及系统特点的性能测试计划都是无意义的。
业务目标的确定
在做性能测试计划前，我们应该向项目组核心成员去了解业务情况，询问项目经理、运营、产品、技术负责人，预期的业务量是多少？未来规划的提升量是多少？在哪些方面有特殊的业务要求，比如哪些场景对响应时间有强要求，是否存在类似秒杀这种类型的场景。
性能风险的推测
条件允许的情况下，我们还可以向项目组的每个参与者了解情况：你最担心系统出现的性能问题是什么？为什么会有这样的担心？有时候项目的核心成员并不清楚系统设计的细节，而那些被忽略的细节又常常出其不意的在线上带给我们麻烦。
明确性能测试目标
整理自己对业务的理解，梳理收集到的业务目标和问题，将业务化的目标转化成明确的性能测试目标。
明确性能测试类型
根据第一步性能测试目标的结果，在充分理解不同类型的性能测试方法的特点后，我们就能更好的采用恰当的性能测试方法来尽可能模拟，系统的生产环境的真实使用情况。列如：
- 如果业务目标关心用户操作后多快能收到响应，那么我们会选性能测试（Performance Test）来作为主要测试方法。
- 如果想要知道用户抢购某商品时出现“挤爆了”提示后会不会影响其他业务，以及出现问题后多久能恢复正常，那么我们可以选择压力测试（Stress Test）。
- 如果想要知道业务不断扩张，用户群体不断增长的情况下，最应该先做哪方面的系统优化准备，那么我们会选择进行容量测试（Capacity Test）。
系统性能测试需要根据各种使用场景和需求场景灵活选择性能测试方法，单一的性能测试方法无法满足系统性能测试要求。
减少差异
测试结果能不能支持推断线上系统性能是否符合业务目标？这个问题并不是在拿到最终测试结果的时候才应该去思考的。这个问题的思考时机应当前置，并且贯穿整个性能测试计划设计以及测试执行过程中。为了让我们的测试结果更具有准确性和权威性，在做性能测试计划的时候，应该从两方面考虑：
- 测试环境和生产环境尽可能的保持一致，包括硬件条件和软件配置都尽可能一致，对于达不到一致的方面，要分析差异及存在的影响。
- 测试场景中模拟的用户行为，要尽可能贴近真实用户的行为习惯。在设计压测场景时，不能纯粹靠想象去预估用户行为和各个行为的用户比例，我们应当结合已监控到的真实用户行为，合理建立压测模型。在这两点基础之上，得出压测数据后，再结合其他因素来预估线上性能情况。
产出计划
完成上述准备工作后，可按照相应的内容填充到我们的测试计划中，一个相对全面的测试计划应该包含以下几项关键内容：
性能测试目的：
像前文已经提到过的，我们应该明确性能测试的目的，了解被测业务特点和业务目标，并将业务目标转化为明确的性能指标。为了更好的帮助我们理解被测系统，画出被测系统架构图是很必要的，在整个系统架构图中，确定被测系统范围，集中精力到需要关注的性能表现上。
性能测试环境：
- 了解清楚生产环境的各种配置，明确测试环境需要的硬件、软件条件。
- 思考是否需要借助其他辅助工具来完成性能测试任务。
- 充分对比生产环境和测试环境差异，差异说明可以为后续分析和推测线上性能情况提供参考信息。
测试场景设计：
- 了解业务后，选择关键链路，并对不同链路设置优先级。
- 根据测试场景，做辅助测试数据准备。
- 监控数据项列举。
- 测试脚本准备方案和验证方案。
- 测试场景列表，包含关键项：场景名称、场景描述、并发用户数、用户分布、持续时间等。
测试执行计划：
- 性能测试准入条件。
- 测试执行schedule。
- 测试执行策略，例如单个场景执行三次，统计平均值。
- 测试执行完成条件。
性能测试交付内容：
- 性能测试结果数据。
- 性能测试结论，是否达到预期指标，是否能支持业务需求。
- 性能优化建议。
风险说明：
- 排期风险。
- 技术风险。
- 资源风险。