MongoDB 冒烟测试套件Smoke Test Suites实战指南面向迭代开发的本地快速回归方案【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo在 MongoDB 服务端这类大型 C 代码库中改动某个组件后最担心的问题往往是没有破坏该组件的核心功能。本文基于 MongoDB 仓库中的冒烟测试套件文档buildscripts/smoke_tests/README.md编写系统讲解 MongoDB 各团队冒烟测试套件的定位、bazel test标签体系与运行命令、Storage Execution 组件拆分方式以及一键式 Python 脚本smoke_tests.py的完整工作流。读完本文你将掌握如何在本地迭代开发中快速运行某个组件的核心回归测试并在合入前用更轻量的方式替代部分补丁构建patch build的等待时间。什么是冒烟测试套件冒烟测试套件Smoke Test Suites是一类专为本地迭代开发设计的测试集合。按文档的定义它们的目的是在开发过程中给开发者一个合理的把握——判断对某个组件的改动是否破坏了该组件的核心功能。关键定位有三点本地运行所有命令都在开发者自己的机器上通过 Bazel 执行不依赖 Evergreen 等远程 CI。快速反馈相比提交合并前必须运行的完整补丁构建patch build冒烟测试能在本地较快给出结果。不能替代补丁构建文档明确强调They are not meant to replace running a patch build before merging in a change——冒烟测试通过后合入前仍应跑正式的补丁构建。从仓库结构看冒烟测试套件相关的代码集中在 buildscripts/smoke_tests/ 目录其中包括每个团队的子目录如replication/、server_ttl/、catalog_and_routing/、统一的BUILD.bazel定义以及核心入口脚本 smoke_tests.py。测试套件的底层形态resmoke_suite_test每个团队子目录下的BUILD.bazel并不是手写的测试用例清单而是通过resmoke_suite_test宏定义于 bazel/resmoke/resmoke.bzl声明的一个个测试目标。例如 buildscripts/smoke_tests/server_ttl/BUILD.bazel 中的no_passthrough目标resmoke_suite_test( name no_passthrough, srcs [ //jstests/noPassthrough/ttl:ttlMonitorSleepSecs_parameter.js, //jstests/noPassthrough/ttl:ttl_batch_deletes.js, ... ], config //buildscripts/resmokeconfig:suites/no_passthrough.yml, data [...], resmoke_args [--runAllFeatureFlagTests], tags [ ci-development-critical-single-variant, server-ttl, ], deps [ //src/mongo/db:mongod, //src/mongo/s:mongos, //src/mongo/shell:mongo, ], )从这些 BUILD 文件中可以看到冒烟测试的典型构成srcs选入套件的 JavaScript 测试用例来自 jstests/ 目录很多套件会注明这些用例的历史失败次数与 p90 运行时长如failed 53.0:13023 times, success p90 1.660s可以推断套件倾向于挑选历史上最能暴露回归的高风险用例。config对应的 resmoke 套件配置文件位于 buildscripts/resmokeconfig/suites/。tags这是冒烟测试命令的核心——每个套件都会打上一个组件专属标签如server-ttl、catalog-and-routing同时通常还会打上ci-development-critical-single-variant。deps测试运行所需的mongod、mongos、mongoshell等可执行文件目标。resmoke_suite_test宏在生成测试规则时还会自动追加no-cache、resources:port_block:1、resmoke_suite_test等标签确保测试不会被错误缓存复用。冒烟测试与 Bazel 标签命令的通用结构所有冒烟测试命令都基于 Bazel 的--test_tag_filters标签过滤机制通用形态为bazel test --test_outputsummary --test_tag_filters过滤器,组件标签 //...几个关键参数的含义--test_tag_filters-intermediate_debug,tag只运行打了tag标签且没有intermediate_debug标签的测试。-intermediate_debug用于排除中间调试构建产物相关的测试几乎所有套件命令都带有这个过滤条件。--test_outputsummary只输出测试结果摘要避免大量日志刷屏。//...表示对仓库全部目标做过滤而 Replication 套件则把范围收窄到//src/mongo/db/repl/...与//buildscripts/smoke_tests/...。各团队的冒烟测试套件Catalog And Routing目录与路由该团队的测试标签为catalog-and-routing。运行命令bazel test --test_outputsummary --test_tag_filters-intermediate_debug,catalog-and-routing //...从 buildscripts/smoke_tests/catalog_and_routing/BUILD.bazel 可以看到该套件由sharding_jscore_passthrough、sharded_collections_jscore_passthrough、replica_sets_jscore_passthrough、no_passthrough四个resmoke_suite_test目标组成覆盖了list_collections、list_databases、list_indexes、rename_collection、move_primary、enable_sharding、shard_collection_basic等目录catalog与分片路由routing核心能力并依赖mongod、mongos与mongoshell 构建目标。Server Integration服务端集成该团队的测试标签为server-integration-smoke。运行命令bazel test --test_outputsummary --test_tag_filters-intermediate_debug,server-integration-smoke //...在 buildscripts/smoke_tests/server_integration/BUILD.bazel 中有多个目标被打上server-integration-smoke标签用于验证服务端各组件的集成行为。Replication复制Replication 的冒烟测试分为两部分集成测试标签为replication-smokebazel test --test_tag_filtersreplication-smoke //...单元测试运行复制相关目录下的全部单元测试bazel test --test_outputsummary --test_tag_filters-intermediate_debug //src/mongo/db/repl/...两者合并运行这也是推荐做法bazel test --test_outputsummary --test_tag_filtersmongo_unittest,replication-smoke,-intermediate_debug //src/mongo/db/repl/... //buildscripts/smoke_tests/...注意合并命令中的标签过滤器是mongo_unittest,replication-smoke,-intermediate_debug——同时命中单元测试标签与冒烟测试标签。这与 smoke_tests.py 中component_name_to_test_tag映射表的定义一致replication: mongo_unittest,replication-smoke并且脚本在运行 Replication 套件时会把测试目标限定为//src/mongo/db/repl/...与//buildscripts/smoke_tests/...两个路径。从 buildscripts/smoke_tests/replication/BUILD.bazel 看Replication 冒烟套件基于replica_sets_initsync_static_jscore_passthrough配置对应 buildscripts/resmokeconfig/suites/replica_sets_initsync_static_jscore_passthrough.yml选入的用例集中在事务txns、时间序列timeseries、复制记录 IDreplicate_record_ids、全文索引fts等与复制行为强相关的领域。Server Programmability服务端可编程性该团队的测试标签为server-programmability。运行命令bazel test --test_outputsummary --test_tag_filters-intermediate_debug,server-programmability //...在 buildscripts/smoke_tests/server_programmability/BUILD.bazel 中core、failpoints、no_passthrough三个目标共享该标签覆盖 failpoint故障注入点、服务器参数、启动/关闭路径、BSON 处理、中断interruption等可编程性核心区域。其中还留有一条注释说明pin_code_segments_on_startup.js因依赖宿主机 ulimit 配置、结果不稳定而未包含在套件中体现了冒烟套件稳定优先的选择原则。Storage Execution存储执行Storage Execution 团队将冒烟测试按组件拆分每个组件拥有独立的测试标签。运行全部组件bazel test --test_outputsummary --test_tag_filters-intermediate_debug,server-bsoncolumn,server-collection-write-path,server-external-sorter,server-index-builds,server-key-string,server-storage-engine-integration,server-timeseries-bucket-catalog,server-tracking-allocators,server-ttl //...各组件及其运行方式如下均使用bazel test --test_outputsummary --test_tag_filters-intermediate_debug,组件标签 //...组件测试标签是否含集成测试Server-BSONColumnserver-bsoncolumn否目前仅单元测试Server-Collection-Write-Pathserver-collection-write-path是Server-External-Sorterserver-external-sorter否目前仅单元测试Server-Index-Buildsserver-index-builds是Server-Key-Stringserver-key-string否目前仅单元测试Server-Storage-Engine-Integrationserver-storage-engine-integration是Server-Timeseries-Bucket-Catalogserver-timeseries-bucket-catalog否目前仅单元测试Server-Tracking-Allocatorsserver-tracking-allocators否目前仅单元测试Server-TTLserver-ttl是其中server-ttl组件在 buildscripts/smoke_tests/server_ttl/BUILD.bazel 中对应no_passthrough目标选入了ttlMonitorSleepSecs_parameter.js、ttl_batch_deletes.js、ttl_with_restart.js、user_write_blocking_ttl_index.js等 TTL 索引行为用例。在 smoke_tests.py 中Storage Execution 全套组件的标签被汇总为一行test_tag与 README 中全部组件一起跑的命令完全一致。StreamsAtlas Stream ProcessingStreams 组件比较特殊它要求启用 streams release 构建配置。运行命令bazel test --test_outputsummary --test_tag_filters-intermediate_debug,streams-smoke --streams_release_buildTrue //...其中的--streams_release_buildTrue是 Bazel 构建标志。在 bazel/config/BUILD.bazel 中定义了streams_release_build构建设置及其 enabled/disabled 两个取值对应 bazel/config/configs.bzl 中的streams_release_build规则Streams 冒烟测试目标还通过target_compatible_with select(...)在禁用该配置的平台声明为不兼容确保测试只在正确的构建模式下运行。buildscripts/smoke_tests/streams/BUILD.bazel 中的streams目标是一个shard_count 3的大型套件选入了几十个来自//src/mongo/db/modules/enterprise/jstests/streams/的用例如infinite_loop.js、parse_only.js、documents.js、dlq.js、checkpoint_backwards_compat.js等覆盖流处理管道的合并、窗口、死信队列与检查点等核心能力。一键式入口smoke_tests.py 脚本除了直接使用bazel test命令仓库还提供了更完整的入口脚本 buildscripts/smoke_tests/smoke_tests.py。它的文档注释明确了设计目的在提交 Evergreen 补丁之前本地运行依次保证以下内容通过clang format代码格式化clang tidy静态检查构建install-dist-test安装/发行版测试目标对应组件/团队的单元测试对应组件/团队的冒烟测试运行方式与组件名映射python buildscripts/smoke_tests/smoke_tests.py componentcomponent的可用值由脚本中的component_name_to_formal_name/component_name_to_test_tag映射表给出包括catalog-and-routing、server-integration、replication、server-bsoncolumn、server-collection-write-path、server-external-sorter、server-index-builds、server-storage-engine-integration、server-timeseries-bucket-catalog、server-tracking-allocator、server-ttl等此外还可能包含所检出模块modules在buildscripts/modules/*/smoke_tests/smoke_tests_metadata.json中声明的额外组件。脚本开头的ensure_python3_venv()会强制切换到仓库自带的 Python 虚拟环境python3-venv随后才导入buildscripts.resmokelib.utils.evergreen_conn等模块保证运行环境一致。命令行参数参数默认值说明component位置参数无要运行冒烟测试的组件名--log-path~/.logs/smoke_tests各阶段日志存放目录脚本会按仓库路径哈希追加唯一子目录--run-clang-tidyFalse是否运行 clang tidy耗时较长且会把构建配置切换为configclang-tidy--send-slack-notification1结束后是否向本地 Evergreen 配置中登录的用户发送 Slack 通知--schedule-patchNone成功后自动提交 Evergreen 补丁使用requiredalias不带值时使用mongodb-mongo-master也可指定如--schedule-patchmongodb-mongo-v8.0位置参数之后的所有参数会被parse_known_args捕获并作为bazel_args原样透传给后续的 bazel 构建/测试命令——这就是 README 中 Streams 示例的写法python buildscripts/smoke_tests/smoke_tests.py streams --//bazel/config:streams_release_buildTrue这里--//bazel/config:streams_release_buildTrue是 Bazel 风格的构建标志透传即bazel test --//bazel/config:streams_release_buildTrue作用与前面--streams_release_buildTrue等价。内部执行流水线脚本内部用一个依赖图CommandRunnerNode把各阶段组织成有依赖关系的并行任务并可用parallelism默认取os.cpu_count()控制并发。默认流水线如下质量检查quality checksbazel run checks -- --fix --group format --group lint执行 clang format 与 lint 修复。构建可执行文件bazel build 透传参数 //:install-dist-test依赖第 1 步完成。组件测试bazel test 透传参数 --test_tag_filters组件标签,-intermediate_debug --test_outputsummary --dev_stacktraceFalse 目标路径依赖第 2 步注释说明这并非真正的依赖关系而是为了串行化 bazel 访问避免并发冲突。clang tidy仅当--run-clang-tidyTruebazel build --configclang-tidy --verbose_failures --keep_going //src/mongo/...同样用于串行化 bazel 访问并防止 clang-tidy 在测试结束前改掉构建配置。任一步骤失败返回码非 0会立即中止并抛出异常。全部通过后如果指定了--schedule-patch脚本会临时git add -A暂存所有改动含未跟踪文件以--uncommitted方式提交 Evergreen 补丁随后恢复原来的 git 暂存状态如果--send-slack-notification开启则通过 Evergreen API 向本地配置的用户发送结果摘要含各阶段耗时、失败命令与日志路径。结语MongoDB 的冒烟测试体系是一个典型的标签驱动 宏生成 脚本编排三层结构resmoke_suite_test宏负责把精选的高风险 jstest 用例编译成可被标签过滤的 Bazel 测试目标开发者用一行bazel test --test_tag_filters...命令按组件快速回归需要完整流程时再交给smoke_tests.py自动完成格式化、构建、测试与可选补丁提交。对于日常迭代建议记住两条核心命令模式通用组件用bazel test --test_outputsummary --test_tag_filters-intermediate_debug,组件标签 //...Replication 用合并命令同时覆盖单元测试与冒烟测试无论哪种方式合入前都别忘了仍要跑正式的 Evergreen 补丁构建来兜底。【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考