性能场景执行完成后，便是测试报告阶段。
测试报告阶段
测试报告是统计场景执行并得出结论的阶段，结论包括生产配置参数与性能报告两部分。
生产配置参数
生产参数配置可能大部分由有经验的运维给出，但作为性能测试人员，给出生产配置参数也是合理的。
那么如何给出生产配置参数呢，这里针对微服务架构分：
- 情况一：生产架构是多服务单节点，包括还没有上生产环境的，这种情况一般属于初创企业
- 情况二：生产架构是多服务多节点，呈集群部署，这种情况属于大部分一般企业
我属于情况一，生产架构是单服务节点，且部署在一台单机上，所以这一块直接复制测试环境的配置即可（前提是测试环境的TPS满足预期的容量规划，如果不够需要进行等比扩容，做线性评估测试）
对于情况二，高楼老师给出的解决方案分为以下五步：
第一步：预判生产流量
大概得出生产流量的量级（峰值情况），不用特别精准。
第二步：确定系统组件
之前阶段已经理清系统用到的各种组件，然后分别对各个组件得出性能配置，其中性能配置又分为硬件配置和软件配置
第三步：硬件配置对比
分别统计生产环境与测试环境的硬件环境，以及峰值条件下的资源利用率、TPS、RT数据，比画出表格对比，如下图
为什么要统计生产的TPS等情况呢？容量规划，直接用测试环境做等比评估不就行了吗，我当时看到这里想了很久，以下是我自己的见解。
首先容量测试解决的问题无非两种情况：
一是找到当前硬件条件下系统的最大TPS；二是为支持系统未来某种场景下的TPS提供依据。
按照上面表格来算，理论上当测试环境的CPU资源利用率是30%的时候，对应的TPS应该是3000，所以下面增加一行测试环境实际跑出来的TPS。
- 当该TPS小于3000时，我们还需要继续调优
- 当该TPS大于等于3000时，我们需要继续增加2个场景：60%CPU资源利用率、90%CPU资源利用率
假如30%CPU的TPS为3000，60%CPU的TPS为6000，90%CPU的TPS为9000，则TPS与CPU利用率呈线性关系，可以得出生产环境当CPU90%时该硬件下系统最大TPS为90000。
但正常情况下CPU利用率越高，TPS会不稳定甚至越来越小，假如90%CPU的TPS为8000，则可以推断出生产环境当CPU80%时系统最大TPS为80000。
于是我们找到了当前硬件条件下系统的最大TPS，同理根据该表格等比模型，我们也能推断未来需要更高的TPS下的硬件配比。
注：其中资源利用率用性能决策树的全局计数器，因为每个业务系统消耗的资源会有偏向，要么是计算密集型（CPU），要么是 IO 密集型（内存/磁盘），所以，我们在比对计数器的时候，肯定要比对那些消耗得快的计数器。
第四步：软件配置对比
前面貌似仅用硬件配置就能得出系统的最大TPS了，是因为我们建立在软件配置最优的前提下（配置最优就是能产生最大TPS的配置）
那这里看软件配置是为了什么？
我理解是得到当前系统下最合适的配置参数，即适量减少TPS，来获得更快的响应时间。
在上面的表中可以增加软件配置参数列：
软件配置对比跟硬件有所差别，比如CPU，硬件关注的是型号、主频、核数，而软件层面就是CPU使用率，其他应用软件，高楼老师也罗列了比对参数
其中重要的java微服务应用，配置如下，可直接参考
第五步，获取测试环境配置值
依次调整配置参数，并执行场景得到对应的TPS，这时根据TPS可以确定最合适的配置参数了，高楼老师最后举例Java的应用服务的配置：
server:
port: 8086
tomcat:
accept-count: 10000
threads:
max: 200
min-spare: 20
max-connections: 500
随后调整参数，找到合适的响应时间及对应的TPS，确定线程池（线程数）大小为50 、超时为200ms、队列长度为100。而具体的调大调小，取决于你是想让系统支撑更多的请求，还是想让用户有更好的体验了。
最后整理下等比模型表格，就得出了生产环境的软硬件配置参数。
性能报告
性能报告是一个性能项目的总结，是性能价值的最终体现。如果给老板做汇报，简明扼要即可。
性能报告结论
性能报告要给出明确的结论，表达的是业务系统的性能结论，比如：系统可支持 2000 万人同时在线，20000 人并发。
性能报告表现形式
一是尽量详细的技术型报告
这种报告通常是 Word、PDF、HTML 形式，报告内容包括项目背景、测试范围、需求指标、工具环境、数据量级、业务模型、场景执行策略、场景结果整理、场景结果分析、结论、问题汇总、后续性能工作建议、运维建议。
二是尽量简短型的汇报型报告
这种报告通常是 PPT、Keynote 形式，报告内容包括结论、基本信息描述（用几个简单的页面概括一下即可）、问题汇总、后续性能工作建议、运维建议。
性能报告的内容
主要包括执行场景前的信息与执行场景后的信息。
执行场景前的信息该要如下：
包括项目背景、测试范围、业务模型、性能指标、系统架构图、软硬件环境、压力工具及监控工具、数据、场景设计及报告策略、监控设计。
执行场景后的信息概要如下：
包括场景结果整理、场景结果分析、结论、问题汇总、后续性能工作建议、运维建议。
因为是自研的性能项目，我删减了部分内容，报告结构如下：
总之，重点内容要放在前面、详细的分析可附上链接、能用图的别用表、能用表的别用文字表述。
结语：在工作中虽然整体根据高楼老师的课程实践了一番，收获了很多，但实际效果没有展示出来，特别是获取生产配置参数这里，后续有机会再尝试，也欢迎大家补充讨论。
标签：实战,结论,场景,性能,配置,TPS,参数,CPU From： https://www.cnblogs.com/qgc1995/p/16582650.html