接口性能两手抓——性能测试到底是什么

Posted 2021-04-28 双木细谈Java自动化

很多人以为做性能测试，就是做些脚本、参数化、关联，压起来之后，再扔出一个结果。

随着时间的增长，我越做越多。慢慢地，我发现，性能测试好像远不止这些内容。

当我们把性能分析也加入到工作中之后，性能工作一下子变得丰富起来。现在，我们更关注一个性能测试项目在分析调优了之后，响应时间有多大的提升，TPS 有多大的提高，资源有多少的节省。

在一个性能测试项目中，分析是必然的过程，只有这样，性能测试的工作才有落地的价值。而这个过程，最好是性能工程师来做，不是别人，因为只有性能工程师才可以串起完整的链路。

真正的性能工程师，可以把结果整理清楚之后，又可以下结论，提出解决方案：线上根据这个测试结果，做对应的配置，系统肯定可以稳定运行。又或者是这样的：当前测试说明了线上不能支持，后面应该如何优化。

大家看，这样做，性能工程师的价值是不是立刻就显现出来了？

所以，我们努力的方向是性能的完整工程，这就是在开头提到的，既要有前期的测试，还要有中间的分析，以及最后的调优，而不仅仅是做做脚本。

当然了，做脚本和参数、压场景、出报告，这是所有新手都必经的一个过程，就像写代码先从“Hello World”开始一样。但是这个过程，必然要在短时间内渡过。

如果你想把性能测试做好，就不要局限自己的技术范围和认知范围。无论是系统、数据库、代码、中间件、存储、网络，你遇到什么问题，都要试着去分析下该如何判断，并考虑如何在后续的过程中进行调优。

在此需要强调一下，也希望借此可以纠正你的认知，那就是，“性能测试”不仅仅包括测试，还包括分析和调优。

学习性能测试的方法到底是什么？

那现在大家心里是不是有个问题：好，现在知道了这些，但是到底怎样才能做到呢？

在性能行业中，我看到很多人还在拿着一些看似合理实际没用的概念套在当前的性能领域中。

比如说，性能策略中的性能测试、压力测试、衰减测试、配置测试等等。这些概念你可能听了不下百遍了，但如果问你，你在项目中是否用到了这些策略？估计你都不大能想得起来，自己做的某个场景用到过什么样的策略。

比如说“二八原则”、“响应时间 258 或 2510”、“理发店模型”、“最大 TPS 拐点”等等指标类的紧箍咒。在我看来，在项目的实践中，它们不只是百无一用，而且还产生了错误的导向。

因此，针对当前性能行业的现状，结合自己多年来的经验，写了这个合集。在合集中，小编将以实际的项目经历，告诉你在一个具体的项目是如何一步步落实到性能领域的每一个环节中的。

那这个合集是怎么组织的呢？主要分了四个模块。

第一个模块是性能测试基础篇。我想在这个模块里澄清一些性能测试的基础概念，讲解一些关键部分。但并不是对概念的简单描述，而是根据实际项目，告诉你真正具有指导价值的性能测试概念是什么，并解析这些概念在实际操作中的指导性作用。

在第二个模块中，我们将通过性能测试工具的实际操作实例，对应性能测试的前后逻辑关系。在这一部分中，小编会重点给大家讲解，为什么要使用某些工具的某些功能，以便确保工具的使用及结果是为性能测试需求指标和性能分析报告而服务的，而不是浮于表面的“炫技”。

在第三个模块中，将通过操作系统、应用服务器、数据库、缓存服务器、Java、C++ 等监控工具的使用和分析方法，告诉你它们产生的数据在性能分析过程中该如何判断，为测试报告及性能分析提供有效的历史数据。

最后一个模块是对前三个模块的凝练，我们会讲解不同实际操作场景中的性能测试分析过程，比如实际的瓶颈判断的过程是怎样的，怎么分析出根本的原因，如何提出具体的解决方案，最后的实施效果又是怎样的。

性能工程师的前景到底在哪里？

性能领域要求的专业技能并不少，发展的宽度和深度完全取决于你自己的意愿。你可以选择只做一个写脚本的工程师，也可以选择成为一个性能调优的专家。从技术范围上说，测试工具、操作系统、开发语言、实现架构、数据库、网络、存储、部署架构等，都是你需要掌握的内容。

那性能测试价值体现在哪里呢？

在性能测试分析优化之前，如果 TPS 是 100，你做完了之后 TPS 是 10000，这就是价值。

在性能测试分析优化之前，如果响应时间是 0.1ms，你做完了之后是 0.01ms，这就是有价值。

在性能测试分析优化之前，如果 CPU 使用率是 100%，你做完了之后是 50%，这就是有价值。

希望你可以从实用的角度，理性看待性能市场，而不是人云亦云。更希望你能够在性能领域这条路上坚定地走下去，并获得长足的发展。可以骄傲地说，我的目标是性能工程师，我的职位是性能工程师。