性能测试从零开始实施指南——测试报告篇
性能测试的目的，是通过模拟真实的业务场景和海量的用户请求及数据对业务系统进行多种场景的测试，来验证各个服务的性能表现是否满足实际的业务需要。
长期来看，性能测试最终的目标是为生产环境容量规划提供可靠地参考数据，使生产服务的可用性、扩展性和稳定性更高，让技术更好的服务业务，创造更多的价值。
从整个性能测试的生命周期来说，测试报告的产出就意味着一次完整性能测试项目的结束。那么，怎样的测试报告，才是真正具有价值的呢？
这篇博客，聊聊一份完善且具有价值的性能测试报告，都包含哪些内容。。。
关键词：信息完善，简洁明了，有图有数据有结论！！！即让每一个业务服务能够清晰地知道：
单机水位是多少、满足业务需求要上多少机器、什么时候该加机器、什么时候应该减机器。双11等大促场景需要准备多少机器，既能保障系统扩展性和稳定性，又能节约成本。
一份完善且具有价值的性能测试报告，主要包含如下几个方面：
一、测试背景
首先要阐述本次性能测试的背景，即被测系统类型，面向哪些用户，具备什么特点，为什么要进行性能测试，预期的一些指标等等。
比如：为了保证“双十一”大促期间，系统能稳定运行且保障业务的高可用，进行性能测试。
核心：评估系统性能、分析性能变化趋势、定位系统瓶颈风险、协助规划系统容量。
二、测试目的
测试的目的要根据测试背景来分析设定，比如：
1、线上服务由于流量过高某部分应用挂了，那测试目的就是：定位瓶颈、分析调优验证；
2、运营做了拉新和新的渠道拓展，那测试目的就是：评估系统性能是否满足新的线上业务；
3、系统架构由集群技改为微服务，那测试目的就是：验证稳定性、可用性、单实例容量，为线上服务扩容提供容量规划数据；
三、测试范围
比如，梳理出测试的业务域、场景、对应的服务：
| 业务归属模块 | 业务涉及场景 | 对应服务 |
| 订单 | 创建订单 | order-service |
| 取消订单 | ||
| 购物车 | 添加购物车 | |
| 删除购物车 | ||
| 商品 | 商品列表 | product-service |
| 商品详情 | ||
| 支付 | 余额支付 | payment-service |
| 支付宝支付 | ||
| 微信支付 |
或者，以思维导图的形式进行说明也可以，如下图：
四、预期指标
这里的性能指标包含如下两项：
①、业务性能指标
即预期的TPS、RT、99%RT、请求成功率（一般默认请求成功率≥99.99%）。
②、硬件性能指标
即服务端资源耗用指标（也称为水位），常规的资源监控指标有：CPU使用率、Memory使用率、系统IO、网络IO等。
③、应用流量指标
比如：核心业务链路的QPS、Redis的命中率、DB的峰值QPS等数值。
五、实施说明
实施说明主要包含如下两项：
1、环境配置
| 服务名称 | 数量 | 配置 | 备注 |
| gateway server | 5 | 4C8G | 网关服务，身份验证和请求转发 |
| web server | 2 | 4C8G | |
| app server | 2 | 8C8G | |
| Redis | 2 | 12G | 哨兵模式，一主一从 |
| DB | 2 | 8C16G | 一主一从 |
2、测试策略
本次性能测试所采用的测试策略，比如：
探测系统性能拐点，需要阶梯式压测；
探测系统在可接受的性能指标下最大的处理能力，需要采用负载、容量测试策略；
验证系统的稳定性和高可用，需要采用稳定性、高可用测试策略；
验证系统在不同配置下的性能表现，一般采用配置测试策略；
六、测试结果
测试结果展示，依据具体的测试范围、目的来选择性展示。展示的方式可以是多种形式，最常见的是图表类型。
举个例子：单链路基准的场景，一般只需要以表格形式罗列出测试结果即可，做个记录。全链路压测，可以用相对具体的图表来提现测试的结果。
但最重要的，还是结论！以及最终在线上环境所展现的价值。
demo1：表格统计
demo2：图形化展示
PS：报告中具体贴多少的图表，以公司实际的流程和技术文化为准。比如银行金融业就比较重视，互联网企业，一般只需要核心的数据证明即可。
七、阶段进度
这里主要指的是从需求阶段到结束，各个阶段的工作进展以及资源安排，建议采用看板的方式，及时更新进度，方便推进工作的开展。示例如下：
|
阶段 |
事项 |
开始时间 |
结束时间 |
状态 |
责任人 |
|
需求阶段 |
需求评审 |
|
|
完成 |
多方参与 |
|
系统架构图 |
|
|
完成 |
开发 |
|
|
需求调研 |
|
|
完成 |
性能测试人员 |
|
|
准备阶段 |
环境交付 |
|
|
完成 |
运维、开发 |
|
应用部署 |
|
|
完成 |
运维、开发 |
|
|
数据准备 |
|
|
完成 |
开发、DBA、测试 |
|
|
脚本开发 |
|
|
完成 |
性能测试人员 |
|
|
实施阶段 |
执行压测 |
|
|
未完成 |
性能测试人员 |
|
服务监控 |
|
|
未完成 |
运维、测试 |
|
|
数据收集 |
|
|
未完成 |
性能测试人员 |
|
|
结束 |
报告评审 |
|
|
未完成 |
多方评审 |
八、问题记录
压测过程中的问题进行记录汇报，也是很有必要的，测试同学懂得都懂。。。下面是一个示例的问题记录表格，请参考。
九、测试结论
还记得本篇文章最开始是怎么说的么？性能测试的最终目的是，让每一个业务服务能够清晰地知道：
单机水位是多少、满足业务需求要上多少机器、什么时候该加机器、什么时候应该减机器。双11等大促场景需要准备多少机器，既能保障系统扩展性和稳定性，又能节约成本。
下面是一个比较万金油的描述，具体的结论还需要根据具体的压测需求和场景来描述：
本次性能测试在性能测试环境进行，所有涉及场景已测试完毕；测试过程中发现的缺陷已全部修复并验证通过。
A-service服务在水位为50%时最大TPS为200，业务预期指标为2000TPS，生产环境现有同等配置服务器8台。
为满足本次活动的营销增长需要，线上建议部署12台机器（10台正常提供服务，2台留作buffer）经过评估，当前性能表现满足预期性能指标，达到上线要求。
本次性能测试通过。
如上，就是一个比较完整地性能测试报告内容，当然，可以根据研发部门或者公司具体的情况进行内容的增删，仅供参考。。。
