转载：https://mp.weixin.qq.com/s?__biz=MzkwNTI2NjAxMA==&mid=2247484048&idx=1&sn=6700370d90c5c5ceae2729297f6e8ef4&chksm=c0fb14a5f78c9db3ae1bd31e50a1253a95d2a97ae1888ee22025d0c5bed4bd86a63599dd36cb&scene=178&cur_album_id=2331539939861282817#rd
话接上回(我眼中的性能测试)，聊了个人对性能测试的一些看法。后来在直播间和老张，CC一起聊了如何构建个人的性能知识体系这个话题，本文做个总结，个人觉得这个话题非常有意义。单纯的碎片化知识很难产生效应，应该学会如何把这些零散知识点串联起来，形成自己的知识体系，才能更好地运用。那么，如何构建自己的性能知识体系呢？
1. 理解名词背后的原理
在性能测试领域，有很多名词（缩略词），像TPS、响应时间、并发数、线程数等等。不同人眼中对于这些名词的定义并不一样。比如开发看中的可能是线程数（服务端），产品希望得到的是并发数（用户侧），但这二者并不是等同的。还有，TPS和QPS虽然在某些场景下是等同的，但更多时候又不是等同的，因为现在的事务更加复杂，一个T（事务）往往需要多次的Q（查询）来完成。（参考：TPS、并发数与线程数，傻傻分不清楚？）
所以，团队成员在沟通对话在时，需要先拉同对齐对这些概念，确保大家说的是同一个问题，避免陷入无休止的争论，但其实说得都不是同一件事。
2. 理解压力是怎么生成的
这是做性能测试的第一步，也是最重要的一步。如果我们不能很好的梳理被测系统的生产压力来自哪些功能，那么就会出现用登录场景来评估系统性能的尴尬局面了。在这个知识领域，我们需要弄清楚三个模型：业务模型、数据模型及流量模型。
业务模型：决定了我们要测试哪些场景。因为被测系统的功能那么多，不可能所有的功能点都需要做性能测试（虽然理论上是都要测试，但是成本太高，并不现实），那么如何选择就是个难点。如何做选择呢，笔者简单列了个导图，具体的就不展开了。
数据模型：在性能测试开始前，我们需要做哪些铺底数据？做多少？这个是需要我们提前规划好的。因为不管是哪类数据库，对于不同体量的数据，所走的查询器选择都是不一样的。几百行的数据走全表扫描肯定比走索引要好，但如果是几百万行呢？这方便需要我们具体地做评估。还要注意的是，为什么我们需要做参数化呢？参数哪些数据？这也是数据模型中要考虑的事。同样的，列个导图，仅供参考
流量模型：主要指的是每个功能点或者子系统的流量转化率，需要结合我们的业务模型来共同管理，例如，对于秒杀或者整点活动类的场景，流量模型就要特别关注并发的线程数，需要结合用户量来做参考。而对于流程比较长的业务，每个节点都会有流量流失（并不是所有的场景，用户都会从头走到尾），那么这个百分比如何控制，需要结合历史数据，和产品共同来制定。这个强依赖场景，所以就不列导图了。
有了这三个模型之后，剩下的就是性能测试脚本的编写和测试执行了。当下很多学性能测试同伴，把更多的精力投入到性能测试工具的学习中，虽然不能说不对，但这仅仅是性能测试的一部分，而且还需要根据实际情况针对性地做选型（虽然Jmeter能解决大部分的问题），代码能力，是做性能测试必备的条件哟。
3. 被测系统是如何搭建的
当我们对某个系统做性能测试时，一定要对这个系统架构要有整体的认知，知道被测系统是如何运转起来的，你在做压测和监控时，才能游刃有余。最常见的两种表达系统架构的图是技术架构图和物理拓扑图。
技术架构图：这个是希望所有测试人员都要能够画出来的，不论你是做业务测试还是测试开发。当只有你能完整地图出你所测试系统的技术架构时，你才能知道系统到底用到了哪些技术组件，这些组件是如何通信的。只有这样，你才能更有针对性地设计你的测试用例和场景，覆盖到一些组件常见的性能问题。如果你能自己画出自己测试系统的技术架构来，才能说明你对这个系统真的熟悉。
物理拓扑图：这个一般是运维同学关注的，现在多数的CMDB系统都可以直接拉出对应的图形，这个有助于在性能测试的过程中更好的设置监控项，以便于更好的发现资源性能问题。
4. 应用如何监控
在做性能测试时，我们不能只关注业务层的数据（TPS、响应时间、正确率、稳定性等），还需要我们关注一些技术指标（JVM、线程数、缓存、连接数及各类中间件的配置指标）及系统资源（CPU、内存、IO）。这些指标不能只靠人眼去观察，需要有一整套的监控体系来协助你。
业内常见的Zabbix、Glances、Prometheus+Grafana 等都是可视化监控常用的手段，对于代码层的链路追踪，常用的有SkyWalking、PinPoint等等。当然，这些监控工具都离不开最基础的命令监控，类似于TOP、IOSTAT、JSTACK等命令，能够快速帮助我们定位和发现问题。建议大家熟练使用一些常用命令，因为有时候生产环境并不会让你安装那么多监控工具。
现在，更多的服务部署在云上，或者容器中，给监控带来了更多的挑战，这些新技术的出现，希望我们也要与时俱进，掌握监控它们的方案。
5. 如何定位及排错
性能测试一定不会是一帆风顺的，在测试过程中，我们会遇到各类问题，那么如何定位那些问题呢。我们至少需要做到以下几点：
了解计算机的基本原理：比如CPU是如何工作的，为什么需要内存，什么情况下说明内存是不够用了（需要了解Linux与Windows对于内存管理的机制异同点）？为什么会流行一句话“一切性能问题皆IO”？只有当我们了计算机的基本原理后，我们才能有方向。
理解技术实现的原理：比如在数据库层，为什么索引会更高效？它的弊端又是什么？为什么研发要引入Redis，它的好处是什么？如何理解Redis的透传与雪蹦现象，等等类似的问题，我们需要理解很多中间件的实现细节。这些你不一定需要自己全懂，但至少要有个映像，能够和开发进行更多的沟通，而不仅仅是报一些监控数据。
验证你的猜想：这一点其实非常的重要。在性能测试的过程中，我们遇到的问题往往是综合因素共同作用产生的，这就需要我们要有一定的猜想能力，依据自己或者团队的验证，猜想可能是什么问题，但不能仅停留在猜想上，需要我们有验证的能力，否则就是瞎猜，不足为凭。（参考数据什么会走丢了呢？）
6. 性能测试实践
“纸上学终觉浅，绝知此事要躬行”，道理懂得再多，也需要有实践的机会。性能测试是非常考验测试人员的个人经验。需要在不断的实践中成长。很多人可能会抱怨没有实践的机会，因为公司并没有提供相应的机会。个人的观点是，你日常的被测系统，其实就是最好的联系对象，尝试去理解那些技术组件，自己动手搭建一套玩玩。在夜深人静的时候，写写脚本去压一压，和运维搞好关系，要点监控的权限，都是可行的方案。因为，当初的我，就这么练习过来的。只有你做出成绩了，团队才会重视，才有可能给出对应的资源，让你去成长。
7. CC的观点总结
关于如何构建知识体系，CC 也给出了自己的一些看法
性能测试的工具原理与使用。
性能测试目标与场景分析。
如何制定性能测试指标；参考数据有哪些，怎么获取；常见的性能测试场景有哪些，如何通过这些场景来提高性能测试的覆盖率，等等。这些都是性能测试方案的组成部分，只有制定了正确的性能测试方案才能做出有效的性能测试。
分层监控体系建设：重点是监控和问题定位，包括如何做硬件监控、系统链路监控，如何打造可视化的监控报表。监控是性能测试必要的步骤，是你发现性能问题的“眼睛”。
性能分析优化实践：如何从服务端、中间件、数据层三个角度了解如何定位和优化问题，如何结合自身工作场景进行性能调优。
8. 老张的观点
理论：需要有扎实的性能理论支持，团队一起构建同频的交流环境；
工具：光有理论，如果无法生成压力（先不论压力生成是否符合业务要求），也是无法开展工作的。所以，对于测试工具，必须有一个擅长的，能够懂得它的实现原理，能进行必要的二次开发或者高阶使用。
方法：就是上面提到的三个模型，通过正确的方法，结合工具的使用，达到做性能测试的必要条件。
实践：实践是最好的老师，通过实践，积累经验。
经验：定期回顾+复盘，总结经验，不能让同样的错误重复发生。
9. 小结
通过对性能测试知识体系的整体介绍，让读者对于性能测试有更直观地了解。在上面的小点中，抛出了很多问题，没有给出答案，是因为文章篇幅有限，本文旨在帮助大家构建一个性能知识的框架，然后大家可以根据自己已有的知识点，对应的填充到这个架构中，形成有机的整体，查缺补漏。只有网状的体系化知识，才能让你在工作中应用自如。
