虽然经历过很多次压测，但是最近跟进的一个项目，在预估 qps 高、业务玩法个性强复杂度高的情况下，整个过程中还是出现了一些问题：
- 与下游交互的模块，不能通过直接屏蔽来进行内部逻辑验证
- 压测需要单独配置，内测期间不能同时进行压测
- 压测接口底层数据依赖交叉，并发抢锁与线上场景不符，账号编排进行了二次更新
- 多压测接口并发窗口重叠有差异，用例编排多次优化才保证了业务逻辑依赖
- 需求节奏紧张，压测流量复用需要多次调整压测用例
虽然准备工作提前开展，却还是不够充分，因此总结下压测准备工作的内容，希望下次的压测能更加顺利。
首先聊一下上面问题的初步解法建议：
- 评估好与下游交互的模块对业务逻辑的影响面积，若下游动作对服务影响较小时，除了正式压测外，调试和复压验证内部服务性能时都可以采用配置屏蔽的方式减少对下游的影响，使压测时间更灵活
- 在服务开发阶段就结合服务架构设计，除了基础架构支持的压测流量识别能力，业务自己的服务基于自身服务特征也做好压测识别，这样就可以多维度测试同时进行又不会相互干扰
- 压测前明确数据存储结构，cr 开发代码，明确哪些接口是会抢占或改变同一份数据，是否单用户会同时发生多个接口请求，通过用户段或实际用户行为来控制好抢锁的事件符合线上真实场景
- 分析每个接口触发的时机，在压测过程中明确每个接口峰值叠加阶段，保证全部峰值和单接口峰值能够合理配合
- 通过复制和分组管理的方式将不同复用场景创建到不同分组，随用随取指定组别用例即可；同时与工具平台联动优化接口/域名的管理功能
有了初步解法后，还是要详细回顾下关于压测的准备工作到底要关注哪些内容。
一、压测方案的设计
压测方案是压测执行的标准依据，但是每次需求下准备压测方案的时机都可能是不同的。有些情况下需要在技术方案梳理结束后就要开始着手准备，而有些在测试快结束时准备也是没问题的，个人认为压测方案的产出时机，除了受业务本身排期和人力限制外，优先考虑的是待压测服务的现状和压测场景的复杂程度。
1. 压测服务的现状
考虑压测服务现状主要是看服务是否必须进行压测，以及压测的目标是什么，有了明确的压测目标才能更好的设计压测方案：
- case1：线上稳定运行的服务有新增逻辑：判断新逻辑对旧逻辑的影响，评估是否只压测新增模块相关功能即可
- case2：新服务有历史同类/类似业务参考：依据已有类似业务评估流量量级和性能瓶颈，看是否必要全量功能压测
- case3：新服务没有历史类似业务参考：拆分代码组成，预估全量功能的流量量级，明确是否需要单独摸底，是否必须全量接口覆盖
2. 压测场景的复杂度
压测场景的复杂程度决定了数据和测试用例的准备和编排工作要投入的人力资源成本，要提前考虑才能在压测开始前就准备好压测所需的数据供给。
- case1：业务流程、接口单一或者相互独立：每个接口单独设计压测场景准备压测数据即可
- case2：接口、业务流程间有数据耦合或者有动作耦合：需要按照用户使用场景拆分+组合的方式编排场景压测用例，并确认好压测数据的混合方案
二、 压测配置的约定
正常情况下，压测的配置要确保不对数据造成污染、不能对已有服务造成干扰，所以压测前应该明确好到底哪些配置要单独做隔离，哪些配置必须要确认好唯一压测标识；若服务不能满足压测隔离，大概率需要进行专门开发，服务隔离能力的开发和测试验证成本都要提前规划。
把压测配置单独拿出来讲，是因为很多需求在压测进行时才发现，常规测试和压测的部分配置冲突，造成无法同时进行多种测试，所以压测和正常配置的区分其实非常关键。
具体的压测配置/压测隔离的方式方法需要结合业务代码框架来看，这里不做过多说明。
三、压测数据的处理
1. 压测数据的生成
压测数据间接限制了压测 case 对线上场景的拟合程度，需要特定状态的数据才能保证压测场景的发生。
- case1：压测数据是实时随着压测产生的：那不需要单独构造数据
- case2：压测数据是需要前置条件的：那么就要考虑是通过接口顺序编排就可以产生数据，还是需要提前人为构造
- case3：压测数据是需要前置条件的，且需要完全拟合实际用户场景：那么更要确认数据构造的方案，若不是简单数据的构造，数据构造能力的开发和构造效果的验证同样需要人力时间投入；拟合用户操作的数据，还要考虑同一个用户多接口并发是否有关联影响，以便更好的模拟用户行为
2. 压测数据的清理
压测数据的清理原本是压测结束后才要考虑的内容，但是，必须要提前明确哪些数据要做清理、是什么类型的数据、在什么时机进行清理。
- case1：非持久存储类数据：不需要单独清理，设置好过期时间即可
- case2：非持久存储类数据，但对后续压测有干扰：那么需要每轮压测结束后专门清理
- case3：持久存储数据：需要确认如何控制人工清理
四、压测用例的编排
单接口用例就不多说，单个接口不需要特殊编排，考虑好用例的用户操作行为贴合度和业务特性模拟即可，场景用例/混合压测的用例就需要考虑好用例编排了；下面罗列的场景并不能涵盖所有情况，但可以在此基础上结合压测诉求和已有压测能力做扩展。
1. 简单场景
简单的场景下，一般不需要考虑过多的接口时序和实际触发时机，只需要保证流量峰值的发生和持续即可，所以简单场景下大概有以下几种编排方式：
- 接口独立执行
- 接口顺序执行
- 接口同步并发
2. 复杂场景
复杂场景往往需要接口之间做好配合，不仅仅是时序和触发时间，还要考虑接口实际作用效果的传递和实际作用对数据流转的影响，所以在简单场景基础上要求更高，就可以考虑下面的编排方式：
- 返回依赖接口需要联动串行
- 逻辑/用户行为的流量错峰
- 单用户多动作接口并发需要动态窗口化
- 多用户多动作接口同时刻叠加
方法或思路整体并不难，难的还是要分析好用户行为和接口作用，明确评估出如何排列/组合接口才能更加贴合线上的真实流量分布，尽可能拟合线上场景才能让压测的可信度更高。
网友评论