以上是我在知乎提出的问题，感谢梧桐同学的回答，Quote中的文字是我的描述
在做系统的过程中会遇到需要对整个系统做测试的情况，包括一些基准测试，容量测试，压力测试等。如何做一份精致的性能报告书，在测试过程中有哪些量化指标是需要重点考虑的？
有一个现象是很奇怪的，在这行业6年到现在为止，我尝试弄清楚各种性能测试的概念，但是至今貌似没有一个统一的标准，因此大伙理解的某个性能测试方法和我所理解的可能完全相反。有人可以为性能测试定义3种方法、也有7种的、甚至更多，但是无论多少种，都是一种方法总有它对应的需求，而性能需求就是干系人的需求，这种需求实在不容易分类。以下是我针对自己的理解进行的一些回答：
题主已经列举出了基准测试、容量测试、压力测试，相信对这些测试也已经有一定的了解，但如果题主再进一步了解一定会发现，其实，这些测试并不是所有项目干系人都会关心的。
答主在这里说到了项目中不同的人所关心的测试的不同维度
譬如作为系统最终用户来说，根本不可能去关心系统的性能基准，最终用户往往关心的是系统能够带给他的实际性能体验，好比你去秒杀抢购，你只关心你要到达的付款页面有多快响应，根本不会管系统性能基准在哪一个水平、系统性能容量如何、如何通过设备的扩展为性能带来伸缩。
但是，这些恰恰问题又是系统的运维人员关心的，运维人员还关心“配置测试”，通过对被测系统软硬件环境的调整，了解各种不同环境/不同参数对性能测试影响的程度，从而找到各项资源的最优分配原则、还有可靠性测试、失效恢复测试，即某一设备出现故障以后系统是否仍然能够提供正常的响应服务，对于开发人员来说，他们关心的是锁、是内存泄漏诸如此类的设计和实现问题。
- 用户: 实际体验性能
- 运维: 优化，可用，恢复
- 开发: BUG，性能
我所理解的、精制的性能测试报告：是一份能够通俗的显示用户实际获得性能体验的的测试报告、或者是一份能够告知系统运维人员系统所面临实际性能风险的性能测试报告、又或者是一份能够告诉开发人员系统设计实现上所存在的性能缺陷报告，就这些问题来说，往往都不会出现在同一份的报告当中。所以，请先弄清楚报告面对的项目干系人是谁、他所关系的究竟是什么。
从用户角度来说，平均响应时间能够很好的衡量用户整体所获得的性能体验，但前提是同一请求响应时间整体分布上必须呈现的是正态分布，否则平均响应时间除了误导你，什么用都没有。
所以，一个更有参考价值，但是可能会为测试人员和开发人员带来不必要麻烦的指标是响应时间的90百分位，也就是90%请求响应时间所处于的范围，这是一个对系统比较苛刻的指标，但是非常靠谱。
相应时间区间来作为速度衡量指标
除了平均响应时间和响应时间90百分位值，还有响应时间的“标准差”也是作为衡量整体用户所能获得实际性能体验是否稳定的指标，在“相对稳定”的性能体验中，标准差（经验来说）往往是平均值的一半。
相应时间标准差作为稳定指标
访问应用服务时在带宽上每秒的吞吐表面上是一种网络资源开销，但系统对带宽的占用实际上影响着用户的性能体验。
从运维与开发角度来说，一定也有着他们自己的性能指标阈值标准、或他们所关心的性能风险，例如CPU的占用率、内存、硬盘性能计数器、JVM内存、GC频率与暂停时间等等。
运维和开发以硬件消耗率作为指标
总结
对于项目/产品经理来说，在报告中要着重说明不同的业务场景、场景中不同的负载级别下，用户所能获得的实际性能体验是什么；对于运维人员来说，在报告中要着重说明系统在资源开销上的风险、设备资源上扩充、配置的变更产生的影响；对于开发人员来说，在报告中着重说明设计上的缺陷，锁、内存泄漏、资源开销与释放等。
[原]如何做一份精致的性能测试报告？,布布扣,bubuko.com
原文地址：http://www.cnblogs.com/Bozh/p/3806155.html
