试着回答一下这个问题。

首先要划分系统类型：有状态还是无状态，业务系统还是存储系统。根据不同的业务场景，设立性能测试的目标：是要测 QPS，还是 TPS 还是 TPS，还是任何其他【性能】-从广义来讲，一个存储系统到底能够以多高的平均时延来管理大多的存储空间，可能也是性能的一种。

有了性能测试的目标，接下来就是拆解用例。如果把性能测试归为测试的话，测试就需要测试用例，测试用例只是用例的形式化表达。把用户的使用场景勾勒出来，把每一步拆解成的流程图或者时序图—我们已经得到了一个纸上的集成测试计划，只是没有跟性能挂上钩。

接下来就进入真正写测试用例的环节了。

我们的测试报告如果要涵盖足够立体的信息，则既要了解每一个环节/接口/API 的性能指标，又要了解整体的性能指标。

这个时候测试工具的覆盖面就很重要了。如果我们选择偏黑盒的测试工具，apache ab /JMeter，则我们的测试用例就要围绕着对外交互的 API写，也只能测到外围接口的性能。这样的测试用例写起来最简单，无需侵入任何内部代码中。

如果我们使用了 JMH 一类的工具，则可以自由编写对任何方法的测试用例。但需要对系统有非常深的理解，知道测试用例应该落在什么调用上，也需要对系统有一定的侵入性（至少对原有的功能/验收/单元/集成测试计划有侵入性）。

我们还可以使用 Profiling/Sampling 工具（不同的语言都有不同的工具），这样的工具甚至都不需要我们怎么写代码来截取各种时间戳，就可以自动地帮我们生成性能剖面图。但这些工具并不是包治百病的，亲身使用过这类工具的朋友一定有所体会，这些工具对性能的绝对性能是有影响的，而且影响的大小难以预测。胆敢直接用这类工具 attach 生产环境的程序员都有可能受到惩罚。而且，使用这样的工具就好像在系统混沌变化的各种性能曲线里寻找一个剖面（profiling 言之不虚），要找到的正确的性能热点，还是需要测试脚本的支持。

当然不管我们用什么样的测试工具，测试用例的衍生，一定要按照上面拆解流程图或者时序图的思路来做。

最后，决定系统的性能因素排名往往是：架构-》算法-》Runtime 性能。

最好保证测试环境和目标环境使用相同的架构，相同的软硬件介质（这个在当前比较混乱的发布环境的团队里很难达到）。这个条件很难做到。

所以现在新的做法就是基于 Sampling 了。直接使用 Dapper/把脉一类系统的带有时间戳的 log，用线上验证+大数据聚合的思路来分析系统性能分布。这是现代的做法，却不能称作测试了。

众所周知，测试对于业务代码是必须如影随形的，是很重的负担，有了线上验证的思路，性能测试还真的有必要吗？