被测的业务部署架构是什么意思呢，简单来说就是 被测服务涉及哪些组件，每个组件部署在哪些服务器上，服务器的配置是怎样的？你需要画一个部署架构示意图，有了这张图，才能知道如何做到全貌监控，以及遇到问题从哪些服务入手。
我用一个自己画的架构示意图来说明这个问题，如下图所示，这是一个经典的链路：从客户端发起到服务端，服务端从代理层到应用层，最后到数据层。需要注意的是，你需要明确被测的环境里的各个服务有多少节点，比如客户层的压测机节点有几台，分别在哪个网段。同理我们可以去调研服务层和数据层的节点。
而且现在都是云服务，会做到弹性扩容，不同的时间节点会有不同的实例节点，这些都应当做好记录。
3、对测试数据进行调研
关于测试数据调研，包含了非常多的内容，对于业务测试来说数据调研就是获取必要的参数来满足既定的场景可以跑通。那对于性能测试来说，需要做哪些方面的数据调研呢，我带你一一解读。
① 数据库基础数据量分析
数据库的基础数据量就是目前线上数据库实际的数据量，为什么要统计基础数据量呢？很多公司往往有独立的性能测试环境，但是数据库的数据量与线上相比差距较大，可能出现一条 SQL 在性能测试环境执行很快，但上了生产却会很慢的问题。这就导致测试觉得该测的都测了，但上了生产还是会有问题出现。
这种问题可能会因为索引缺失以及性能环境数据量较少而不能将问题暴露出来，所以在 性能测试环境下的数据量一定要和生产上一致。为了达到这个目的，有的公司可以将生产数据脱敏后备份，有的则需要你自己写脚本来根据业务规则批量造数据。
② 压测增量数据分析
除了数据库的基础数据量，我们也需要考虑一轮性能测试下来会增加多少数据量。往往增加的数据量最终落到数据库，可能会经过各种中间件如 Redis、Mq 等，所以涉及的链路可能存在数据量的激增，所以这方面需要根据增加情况制定相应的兜底方案（即 最差情况下的临时解决办法）。
③ 冷热数据的分析
以我的从业经历来讲，能够在方案阶段考虑到冷热数据分布的公司并不多，往往都是从性能测试结果的一些异常点或者实际产线出现的问题去追溯。接下来我就带你了解下什么是冷热数据，以及如果不对其进行分析可能会带来什么影响。
- 冷数据，是指没有经常被访问的数据，通常情况下将其存放到数据库中，读写效率相对较低。
- 热数据，是经常被用户访问的数据，一般会放在缓存中。
在性能测试的过程中，被频繁访问的冷数据会转变为热数据。如果参数化数据量比较少，持续压测会让 TPS 越来越高。而在实际大促情况下，往往有千万级的用户直接访问，但大多都是冷数据，会存在处理能力还没达到压测结果的指标，系统就出现问题的情况。所以在需求调研时，你也需要考虑：数据会不会被缓存，缓存时间多久的问题？
4、测试监控
为什么监控很重要，它是发现问题的眼睛，而且一旦在过程中没有及时监控和发现，还原现场是有难度的。不仅需要罗列清楚你所需要的监控工具和访问方式，同时也需要层次分明地传递你监控的内容。对我来说做监第一个关键词：全。
怎么去理解“全”呢？先举一个典型的例子，有时候做一个新的项目，询问支持的同学有没有部署监控，他们说已经部署了，但等你真正使用的时候发现只监控了一台应用服务器的 CPU。这个例子我相信大多数人都似曾相识，所以我说的全，至少包含两个方面：
- 涉及所有服务器；
- 涉及服务器基础监控，包括 CPU、磁盘、内存、网络等。
第二是分层，不仅仅硬件相关的，还有链路相关的，都要监控，工具如skywalking，pinpoint等。来一张我以前PPT用过的大图，具体怎么玩都配套了。
如上图所示，监控的内容很多。
监控还有个很重要的点是设置阈值来报警，无论是线上和线下的性能测试，报警功能都是必需的。因为通过人工的观察，往往不能以最快的速度发现问题。一旦能够及时报警，涉及的人员就可以快速响应，尽可能降低风险。
源自公众号 测试架构师影响力