性能方案在性能项目中是重要文档之一，它指导整个项目的执行过程，也约束项目边界，定义相关人员职能。但如今变得“微不足道”。
很多常见的性能项目中，性能方案就是个文档，且是个静态文档。里面写的东西是啥，项目后续会不会按这内容做，没人关心。它就成了形式，只有评审方案时才拿出看看。甚至一些第三方测试项目中，有些甲方连方案内容都不看，直接问有没有？有，就过去了。一个必需的交付物无人关心。
性能方案是个重量级文档。性能项目中被叫成“性能测试方案”。在我这，我把“测试”二字拿掉，因为这取决于我性能工程理念，我希望把整个项目的过程都描述在方案。
0 我的性能方案 V.S 那些常见性能方案
经常看到有这样目录的性能测试方案：
这样的目录大纲组成
- 常规项目信息：如测试背景、测试范围、测试准则、测试环境、实施准备、组织结构、项目风险、里程碑。
- 性能实施信息：如测试模型、测试策略、监控策略。
- 项目输出：如测试脚本、测试用例/测试场景、监控采集数据，测试报告、调优报告。
从性能测试方案的角度来说，这些内容似乎够。但若抛弃“测试”视角，从一个完整的性能项目的角度来看，这些内容还不够。
以前经常有人问我要一个性能项目方案模板，我一直不理解，就这么一个目录，为什么还非得要？自己一个字一个字也照样写得出来吧。后来我慢慢理解，他们要的其实不是大纲目录，而是一个完整的性能方案内容。
项目实施的性能方案基本不可能直接发出来，即便脱敏，一些内容也可以看出是属于某些企业。所以网上看不到完整的性能方案。尽管网上方案不完整，在性能市场上，还是看到有太多性能方案抄来抄去，总体结构大同小异。这也就导致性能项目中，大量方案都只流于形式。
因为我们需要基于一个完整的项目来编写，所以，我把这个项目整体的方案写在这里。你将看到，我认为的真正完整并且有意义的性能方案是啥样。
由于性能方案的内容比较多，并且相对琐碎，整理了一张性能方案的目录表格，你可以对应这张表格，学习具体内容。
来看真实的性能项目实施方案：
1 背景
1.1 项目背景
由于各企业的商业软件有限制，只能选择一个开源项目，并且这个项目最好可以覆盖常见的技术栈，以便能给你提供更多可借鉴内容。因此搭建了一套电商项目：
- 这个项目是较为完整的
- 当前电商的系统比较典型，并且这个项目完全开源，便于改造
不过，也因为这是一个开源的项目，功能和性能都不知道会有什么样的问题，我们只有在性能实施的过程中一步步去发掘，所以这是一个非常符合我们当前目标的项目。
1.2 性能目标
- 根据经典的电商下单流程，测试当前系统的单接口最大容量。
- 根据业务比例设计容量场景，充分利用当前资源，找到当前系统的性能瓶颈，并优化，以达到系统的最佳运行状态。
- 根据稳定性场景，判断当前系统可支持的系统最大累加容量。
- 根据异常场景，判断当前系统中的异常对性能产生的影响。
在每一个性能项目中，性能目标都会影响项目的整个过程。因此，对目标的把握将决定一个性能项目的走向。
某项目，客户要求做到支持1000万人在线，项目不算小，开发团队有300人左右。到那一看只有两个性能测试人员，其中一个还刚毕业。于是，我就过去找他们科技部老大，说这项目我做不了。因为根据这个目标和这样的人员配置，这坑不是我能填上的，得赶紧认怂。后来，那个科技部的老大问，需要什么样资源才能做下去？于是我提几个必需条件，直到这些条件都满足，才接这项目。
性能目标在上下级眼中根本不一样，而我这样的处理，是希望把性能目标在上下级的脑袋中变得一致。这很重要。
2 测试范围
2.1 需要测试的特性
电商主流程：
2.2 不需要测试的特性
批量业务。
3 准则
3.1 启动准则
- 确定系统逻辑架构和部署架构和生产一致。
- 确定基础数据和生产一致或按模型缩放。
- 确定业务模型可以模拟生产真实业务。
- 环境准备完毕，包括：
4.1. 功能验证通过。
4.2. 各组件基础参数梳理并配置正确。
4.3. 压力机到位，并部署完毕。
4.4. 网络配置正确，连接通畅，可以满足压力测试需求。
- 测试计划、方案评审完毕。
- 架构组、运维组、开发组、测试组及相关专家人员到位。
3.2 结束准则
- 达到项目要求的性能需求指标。
- 关键性能瓶颈已解决。
- 完成性能测试报告和性能调优报告。
3.3 暂停/再启动准则
1. 暂停准则
- 系统环境变化：举例：系统主机硬件损坏、网络传输时间超长、压力发生器出现损坏、系统主机因别的原因需升级暂停等。
- 测试环境受到干扰，比如服务器被临时征用，或服务器的其他使用会对测试结果造成干扰。
- 需要调整测试环境资源，如操作系统、数据库参数等。
- 该测试机型无法达到规划指标要求。
- 出现测试风险中列出的问题。
2. 再启动准则
- 测试中发现问题得以解决。
- 测试环境恢复正常。
- 测试风险中出现的问题已解决。
- 环境调整完毕。
4 业务模型和性能指标
4.1 业务模型/测试模型
这个模型是直接从生产环境中取得的业务比例，通过统计日志就能做到。
有些企业的生产数据都在运维手里，性能团队怎么也得不到，因为没有权限，就连做业务模型的数据都没有。那性能项目可直接终止，因为做了也没多大意义，最多也就是找那些瞎吹牛的架构师和乱写代码的开发人员，犯的一些错而已。
业务模型一般还可以由项目组提供生产上的业务报表，根据业务报表查看业务频繁的交易进行按比例，设计测试模型
业务指标/性能指标
在不清楚项目目标TPS的情况下，我暂定目标TPS为1000。根据经验来说，在这样的硬件环境下，定为1000并不算高，除非是没有合理的软件架构。
5 系统架构图
架构图的重要性：方便测试人员根据架构判断是否存在隐患及问题排除
5.1 系统技术栈
系统技术栈是让我们知道整个架构中用了哪些技术组件。而这些技术组件中有哪些常见的性能瓶颈点，有哪些性能参数，我们都可以在查看技术栈时得到一些相关信息。而在后续的工作中，我们也要整理出相应的关键性能参数配置。
下面这张表格，就是我们在后续案例分析中，会用到的技术栈。我在搭建这个系统时，考虑的是尽量覆盖当前技术市场中的主流技术组件。
5.2 系统逻辑架构图
为后续性能分析的时候，脑子里能有一个业务路径。做性能分析时，要做响应时间的拆分，只有了解逻辑架构图才知道从哪拆到哪。
5.3 系统部署架构图
画部署架构图是为让我们知道有多少节点、多少机器。在执行容量场景时，要有概念，这样的部署架构最大应该可以支持多少的容量上限。
对一些无理的性能需求，你看了部署架构后，就可拒绝。比如说前段时间有个人跟我说，他们有一个CRM系统，在做性能的时候，说要达到1万的并发用户。而实际上，那个系统就算是上线了，总用户数可能都不到1万。
系统部署架构图是不是就是系统各个层用了那些东西，这些是不是都要知道？是的。就是要知道各个层面用了哪些技术组件。同时还要知道业务路径是从哪里到哪里。
根据系统部署架构图，咋就能知道支持多少容量上限？有啥评判方法吗？这个问题，动手实践即知道。对你测试的系统，验证单节点的容量上限是多少，就能大概判断整个架构能支持多少，当然这过程中要有模型的创建过程。如在一个2C 4G机器，我直接用一个post接口做一个insert动作，在我的经验中，大概就是在500-600TPS左右。
