京东物流常态化压测实践_forcebot，2024年最新2024最新软件测试面试笔试

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

在实际生产中，我们的应用往往会提供多个接口，或者同一个接口上会提供不同的方法服务。我们在压测的时候如果仅仅按照单个接口来进行压测，这样的压测数据仅能反应单场景交易下系统本身的性能表现，而实际生产中，尤其是大促时，系统往往在同一时间需要处理多个接口请求，系统资源也是多个接口共享的，所以混合场景压测更能反映系统真实处理能力；

在进行混合压测前，需要首先明确各个接口场景在同一时间段内的调用量比例是多少，在创建压测脚本的时候，需要根据这个比例来设置每个压测场景下压力请求占比rate；

步骤1： 生成标准的JSF回放脚本

在自定义脚本之前，先按照3.3.1所述生成一个标准的JSF回放脚本，以及依赖的lib文件都会自动生成；

步骤2： 生成自定义脚本

在步骤1中生成的默认脚本是不可编辑的，可以查看代码时生成自定义脚本，然后对自定义的脚本进行编辑。

① 首先定义接口路径及其方法，对应不同接口的别名，然后是根据不同的接口进行流量加载；

其中ipList是指定被压测的服务器ip及端口，如果接口别名下是集群部署，只想要对其中某一台机器进行压测的话，需要指定ip及端口；

② 针对不同的接口创建回放事务，此处接口路径、接口的加载流量、接口别名等都需要一一对应。rate为该脚本中涉及的多个接口的调用量比例，比如接口1：接口2：接口3=7:8:5（可参考大促或日常调用峰值期间各接口的调用量比例），则需要在testCase中设置相应的压力比。

③ 因为多接口涉及接口路径、流量源以及接口别名各不相同，需要将默认的无参doReplay方法，修改为传参方法

④ 脚本修改完成后点击保存

⑤ 相同接口不同方法的混合压测脚本创建同理，区别在于同一个接口，别名是一致的，不需要额外再指定其他接口别名；

步骤3： 导入附件jtm.properties

在步骤2中自定义脚本编辑完成后，进行校验执行时还无法成功，因为脚本还缺少流量录制回放的附件文档。保存脚本后，返回上一级目录，将步骤1中生成的标准groovy脚本中的附件jtm.properties下载到本地，然后再将该附件文档上传到我们自定义的脚本中，并修改脚本的附件文档。在附件文档末尾添加
jtm.replay.recent.record.num=1，指定每次压测时都获取绑定周期性流量录制任务最新录制的流量；

4.4 双十一大促高保真压测实践

有了R2流量录制平台提供的便捷，让获取线上流量不再成为难事，可以帮助我们快速的完成压测数据的准备，同时压测流量高保真还原实际业务场景。

在本次双11大促，物流promise业务线全面采用R2流量录制的方式进行大促压测，自压测结果更加接近线上接口性能，真实性达到90%以上；为大促资源扩容评估提供了更加精准的数据支撑。同时，通过这次高保真压测，我们发现多个系统性能问题，其中包含极限业务场景下的可用率降低的问题。

下图为采用R2流量录制压测、军演压测与双十一大促开门红的性能对比。

五、USF常态化压测实践

基于focebot的常态化压测能力，选择USF选择3星核心服务进行常态化压测实践，选择TOP4核心接口，使用R2的录制线上流量，根据大促的流量模型进行的混合场景常态化压测，持续监控USF的核心接口的性能情况。

forcbot常态化压测工具支持，压测任务复用（支持流量录制压测任务）、可配置性能基线包括响应时间TP99和TPS的和服务器CPU等资源指标设进行性能基线设置，并根据性能基线判断压测是否达标，以及可以设置不达标的压测结果自动创建行云缺陷，进行性能问题跟踪处理。并且还提供压测监控对比数据以及压测结果历史记录，便于对性能结果和问题进行分析，自动发送压测邮件通知，及时同步性能压测结果。

目前forcebot的常态化压测支持以下功能：

•1、支持压测任务的复用，可使用历史的压测任务，不用单独创建压测任务和脚本，支持jsf、http、自定义的jimdb、jmq以及回放脚本。

•2、可配置定时执行任务，灵活执行时间。

•3、可支持流量录制。

•4、可自动创建行云缺陷

•5、可配置压测的是否达标基线（生效：是否将指标用于压测达标率统计；勾选会作为指标之一，不勾选则在达标率计算时不作为统计指标。 达标：勾线生效的指标值同时满足时，压测结果即为达标；反之，有任何一个指标值不满足条件，压测不达标。

以下为基于USF进行的常态化压测。

5.1 压测物料准备

压测数据：

•选择业务高峰期14：00-16:00 录制线上10%对应6台机器流量，录制【公共集群】入参1G。（后续会考虑多个集群）

•录制接口服务是USF3.0线上TOP4的接口，已完成星标治理，达到三星的接口，完成可用率、TP99、以及有降级和限流方案治理。

压测场景： 混合场景设计（模型）

应用部署拓扑图：

压测环境：

压测环境目前是与线上同配置的单实例的UAT环境。

•与线上的现数据库、缓存保持一致，均已同步线上数据。

•压测环境数据库的配置和缓存服务的配置与线上保持一致。

1.线上机器配置 * 实例数60

2.应用服务器配置：4C8G

3.数据库配置：16C64G内存

4.压测机器配置

5.应用服务器配置：4C8G

6.数据库配置：16C64G内存

5.2 压测风险评估

•压测环境选择：

•1）先在同配置的UAT环境常态化压测，根据性能结果不断调整性能基线

•2）稳定后再复用生产环境的应用和中间件进行常态化压测。

•任务执行窗口：

•选择业务低峰期进行压测，结合ump监控USF服务的高峰期一般在白天的上午6-9、9-11、14-17系统使用的高峰期。所以目前任务执行的窗口期是工作日17:40。目前是有人值守的报警信息及时处理，监控应用和数据库相关情况。

•压测链路同步：

•压测上下游链路梳理，确定压测范围、压测量级、压测时间，同步相关方达成共识。

5.3 常态化压测任务创建

5.3.1 压测模版任务选择准则

•复用历史的压测任务（模版任务），直接创建常态化压测任务。实际选用历史的压测任务场景时，建议根据系统的实际情况来选择，一般可以选择性能拐点场景或者压到预期值的场景（如CPU60%或者TPS达标），一般建议不要压测系统资源饱和的状态场景。

•示例：此处USF我们选用历史的压测任务，是接口满足双十一的吞吐TPS的场景，此时服务器的CPU压力在27%，数据库的CPU在36%。

模版任务选择：

查看任务，可以看到该场景下的执行的脚本，发压相关设置并发线程数、执行的模式（并发模式和RPS模式）、执行时间，可根据需要进行一定的调整。

5.3.2 压测定时任务设置

•可以通过周期或者Cron表达式指定执行周期，usf此处使用Cron ：0 40 17 * * ? 每天下午5点40执行。并在此处设置目标线程数和执行时长。（这个会覆盖压测任务中的线程数和执行时长）。

•常态化压测执行的频率以及执行的时间参考根据代码上线周期和业务的调用低峰时间段综合定制。

1)执行模式-RPS模式

绑定的是压测任务是RPS，那么我们创建的常态化压测任务也是RPS模式。目标QPS设置，并非脚本中所有接口的QPS的和，而是脚本中占比最大的接口对应的压测目标值，如果配置错误会导致过度发压。

2. 执行模式-并发数模式

绑定的压测任务是并发模式，那么我们创建的常态化压测任务是并发执行模式。目标线程数设置。

5.3.3 压测基线设置

•根据压测任务对应的压测场景，根据事务名称（接口方法）设置合理的压测基线，如果关联的压测任务是混合脚本，那么可以分步骤设置多个接口事务（事务名称默认：forcebot.测试方法名 ）的性能基线。 一般关注的指标平均TPS、TP99、错误数、CPU监控。允许波动的范围，根据接口的实际情况给一定的波动空间。若大于设置的波动范围，并且选中设置提交行云缺陷，就会自动提交行云bug，便于bug跟踪闭环。

•基线指标设置注意点：如果基线值特别低的情况，那允许的波动范围百分比需要设置的比较大才可以，否则很小的波动都会被认为压测不通过。基线波动范围，具体接口具体分析，研发和测试达成共识，

1. 自定义性能基线设置

•USF的findUserInfo服务设置示例：

•TPS基准值=2700，允许波动范围10%。（2430-2970） 上下浮动

•TP99基础值=12ms，允许波动范围50%。（12ms-18ms） 上浮动，时间相关的是向上浮动。

•错误数基准值=0，允许波动范围0。

•CPU监控基线值=25%，允许波动范围=20%。（20%～30%）上下 浮动

事务名称： 目前无法自动识别,可以写脚本的中事务名称默认是forcebot.测试方法名，也可以增强脚本使用自定义事务名称就是
TestUtils.transactionBegin(“findUserInfo”)，即findUserInfo

性能基线设置例如：接口性能tp99在12ms左右，此时基线值设置为12ms，允许波动的范围如果设置为10%，那允许的波动范围就是12ms*10% = 13.2ms，超过13.2ms就认为压测不通过，这显然是不合理的，此时需要根据我们的接口tp99最大接受范围来设置允许波动百分比。

2. 多接口性能基线设置

自定义基线设置中，可以添加多个接口事务，该事务就是脚本中的事务名称。

默认事务名称：forcebot.测试方法名

自定义事务名称： 如TestUtils.transactionBegin(“findUserInfoByOrgCode”);

5.3.4 行云缺陷跟踪

对于不满足性能基线设置各项指标值，常态化压测结果就为不达标，若该任务配置开启了自动创建行云缺陷，就会对不达标的执行结果自动提交行云缺陷，这样可以保证bug生命周期各阶段可追溯，保证问题及时处理解决。

5.3.5 监控定位问题

可以查看一段时间该服务的性能趋势，如果接口性能波动较大，需要进一步排查接口性能下降的原因。

1. 监控数据-TPS

2. 监控数据-TP99

3. 执行记录对比详情PK

执行记录中，有脚本版本和，是否达标以及bug详情。选中达标和不达标的结果，进行PK对比，对比项中有TPS、TP99、Error Per Second等指标。

USF相关接口的压测结果，达标和不达标的PK如下：发现是12-04存在一次错误调用，进一步跟踪错误产生原因

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
中达标和不达标的结果，进行PK对比，对比项中有TPS、TP99、Error Per Second等指标。

USF相关接口的压测结果，达标和不达标的PK如下：发现是12-04存在一次错误调用，进一步跟踪错误产生原因

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）
[外链图片转存中…(img-BDL44zMp-1713453413190)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！