WAMR BA Issues 回归测试框架实战从 issue 复现到自动化回归【免费下载链接】fluent-bitFast and Lightweight Logs, Metrics and Traces processor for Linux, BSD, OSX and Windows项目地址: https://gitcode.com/GitHub_Trending/fl/fluent-bit导读本文以 WAMRWebAssembly Micro Runtime仓库内的 BA Issues 回归测试目录lib/wasm-micro-runtime-WAMR-2.4.1/tests/regression/ba-issues为蓝本系统讲解如何把来自 GitHub issue、模糊测试fuzzing报告中的异常 wasm 用例沉淀为可重复执行的回归测试从helper.sh批量创建用例目录、build_wamr.sh编译多版本wamrc/iwasm运行环境到在running_config.json中声明运行配置、再用run.py一键回归并解析结果。读完本文你将掌握一套可直接复用的bug 复现 → 用例收纳 → 自动回归工作流并能针对新 issue 扩展自己的测试条目。说明该测试框架位于本仓库内嵌的 WAMR 2.4.1 源码树中相关脚本与配置均可在lib/wasm-micro-runtime-WAMR-2.4.1/tests/regression/ba-issues/目录下直接查看。一、BA Issues 是什么为每个 bug 建立回归护城河BA Issues 是 WAMR 维护者针对历史 bugBug/Issue建立的回归测试集合。其核心思想非常朴素每一个被修复或确认的 issue都对应一个或多个能够触发该 bug 的 wasm 文件将其按issues/issue-编号/目录收纳并配以期望的退出码 期望的标准输出从而保证修复过的 bug 不会在后续版本中死灰复燃回归通过 ASanAddressSanitizer构建的运行时能持续发现内存安全类问题如out of bounds memory access、double free、SIGSEGV同一类问题例如来自同一轮 fuzz 报告的多个用例可以共享一份运行配置降低维护成本。从当前仓库的目录结构看issues/下已收纳了从 issue-2700 到 issue-3514 的大量用例issues-deprecated/下则存放因 spec 变更而弃用的用例如 issue-47 至 issue-84 的PoC.wasm与 README 描述一一对应。整个工作流可以概括为四步用helper.sh创建issues/issue-xxx目录必要时解压 zip 用例若新用例需要不同的构建配置在build_wamr.sh中追加构建命令在running_config.json中为新用例添加运行配置用run.py运行测试并检查结果。二、helper.sh批量创建 issue 用例目录helper.sh的作用是快速为测试用例创建目录并在需要时解压 zip 格式的用例文件。它在处理一次性收纳大量 issue 用例的场景下尤其高效。# 创建 issues/issue-2944 至 issues/issue-2966 共 23 个目录 ./helper.sh 2944 2966 # 只创建单个目录 issues/issue-2999 ./helper.sh 2999 # 创建目录并解压目录内的所有 *.zip 文件-x 选项 ./helper.sh -x 2944 2966从 helper.sh 的源码可以看到其具体行为脚本会先cd issues再调用create_directory()函数创建issue-$1目录传入两个参数时会校验第二个参数不小于第一个参数然后从num1循环到num2逐个建目录helper.sh启用-x后会遍历目录下所有*.zip文件并unzip -o解压到同目录随后删除原 ziphelper.sh脚本内部注释还保留了wasm2wat --enable-all PoC.wasm -o PoC.wast的参考用法提示你可以将 wasm 反汇编为 wat 文本以便审查。实操提示目录命名必须遵循issue-数字规范。run.py正是通过正则issue-(\d)扫描issues/issue-*目录来收集待测用例 ID 的见 run.py。三、build_wamr.sh构建多版本 wamrc 与 iwasm回归测试需要覆盖 WAMR 的多种执行模式classic-interp 经典解释器、fast-interp 快速解释器、fast-jit、llvm-jit、AOT 等因此需要编译多个配置版本的iwasm运行时。直接运行./build_wamr.sh该脚本会依次完成两类构建build_wamr.sh1. 编译wamrcAOT 编译器build_wamrc函数先执行wamr-compiler目录下的./build_llvm.sh准备 LLVM 依赖再在build/build-wamrc下通过 CMake 编译wamr-compiler工程build_wamr.sh。2. 编译多个变体的iwasmbuild_iwasm函数接受两个参数——CMake cache 变量配置和运行时名称在build/build-iwasm-名称目录下编译并统一附加-DCMAKE_BUILD_TYPEDebug -DWAMR_BUILD_SANITIZERasan即所有回归运行时都开启 AddressSanitizer 检测build_wamr.sh。脚本内置了以下构建变体运行时名称CMake 配置要点覆盖的测试模式defaultREF_TYPES AOT FAST_INTERPfast-interp、AOTdefault-gc-enabledGC AOT FAST_INTERP SPEC_TESTGC 相关 spec 用例llvm-jitREF_TYPES JITllvm-jitmulti-tier-jitREF_TYPES FAST_JIT JITclassic-interp、fast-jit、llvm-jit、multi-tier-jitdefault-wasi-disabled同上 default 但WAMR_BUILD_LIBC_WASI0禁用 WASI 的 fast-interp、AOTllvm-jit-wasi-disabled同上 llvm-jit 但WAMR_BUILD_LIBC_WASI0禁用 WASI 的 llvm-jitmulti-tier-jit-wasi-disabled同上 multi-tier-jit 但WAMR_BUILD_LIBC_WASI0禁用 WASI 的 multi-tier 系列例如要新增一个禁用 WASI 开启 FASTER_INTERP BULK_MEMORY FAST_JIT的变体只需在脚本末尾按以下格式追加一行# 格式build_iwasm CMake cache 变量配置 运行时名称 build_iwasm -DWAMR_BUILD_LIBC_WASI0 -DWAMR_BUILD_LIBC_BUILTIN1 -DWAMR_BUILD_REF_TYPES1 -DWAMR_BUILD_BULK_MEMORY1 -DWAMR_BUILD_JIT1 -DWAMR_BUILD_FAST_JIT1 multi-tier-wasi-disabled上面这行会编译出build/build-iwasm-multi-tier-wasi-disabled/iwasm你便可以在 running config 的runtime字段中引用它。脚本末尾的 TODO 注释也提示后续还可以继续扩展 SGX 等更多版本的运行时。四、running_config.json声明用例如何运行与断言测试如何运行、以什么作为通过标准全部由 running_config.json 顶层test cases数组中的每个条目决定。一个完整条目的字段含义如下字段说明deprecated是否弃用为true时该条目下的所有用例被跳过不参与运行ids该配置覆盖的 issue 编号列表可多个 issue 共享一份配置runtime使用的运行时名称对应build/build-runtime/iwasmfile用例文件名支持通配符*.wasm在issues/issue-id/目录内 glob 匹配mode执行模式classic-interp、fast-interp、fast-jit、llvm-jit、aot等options传给iwasm的运行时选项如--heap-size0 -f to_testargument传给被测试函数的参数expected return断言对象ret code期望退出码、stdout content期望 stdout 内容支持模糊匹配、description用例描述compile_options可选需要先用wamrc编译 AOT 时的编译配置见下文第三种模式4.1 仅运行 iwasm 的简单配置这是最常见的形式。以 issue-2955 为例它在fast-interp模式下运行iwasm_fast_interp_unexpected_value.wasm期望以退出码 0 结束并输出0x44e5d17eb93a0ce:i64{ deprecated: false, ids: [ 2955 ], runtime: iwasm-default-wasi-disabled, file: iwasm_fast_interp_unexpected_value.wasm, mode: fast-interp, options: --heap-size0 -f to_test, argument: , expected return: { ret code: 0, stdout content: 0x44e5d17eb93a0ce:i64, description: expected output 0x44e5d17eb93a0ce:i64 } }4.2 多个用例共享一份配置通配符匹配来自同一轮 fuzz 报告的多个用例往往触发的是同一类问题、期望同一份输出。此时可以把它们的 id 全部放进同一个ids数组并用通配符匹配文件名。例如 issue-2966、2964、2963、2962 四个用例都以fast-jit模式运行、期望输出0x0:i32{ deprecated: false, ids: [ 2966, 2964, 2963, 2962 ], runtime: iwasm-multi-tier-wasi-disabled, file: *.wasm, mode: fast-jit, options: --heap-size0 -f to_test, argument: , expected return: { ret code: 0, stdout content: 0x0:i32, description: expected output 0x0:i32 } }在真实的 running_config.json 中可以看到类似的分组2966/2964/2963/2962 共享0x0:i32的断言2961/2960/2959/2958 则共享0x1:i32的断言充分体现了同类用例合并配置的维护思路。4.3 仅编译只使用 wamrc有些用例只需要验证能否被wamrc成功编译为 AOT 文件不需要运行。此时使用compile_options并设置only compile: true{ deprecated: false, ids: [ 2956 ], compile_options: { compiler: wamrc, only compile: true, in file: *.wasm, out file: out.aot, options: --targetx86_64, expected return: { ret code: 0, stdout content: , description: } } }README 中标注该示例为 dummy config占位示例正式使用时应替换为真实用例。此配置对应的实际编译命令由 run.py 中的COMPILE_AOT_COMMAND ./build/build-wamrc/{compiler} {options} -o {out_file} {in_file}拼装。4.4 先编译再运行wamrc iwasm 组合当用例需要先编译为 AOT 文件再交给iwasm运行时将only compile设为false并在外层再补充运行相关的字段{ deprecated: false, ids: [ 2956 ], compile_options: { compiler: wamrc, only compile: false, in file: *.wasm, out file: out.aot, options: --targetx86_64, expected return: { ret code: 0, stdout content: , description: } }, runtime: iwasm-multi-tier-wasi-disabled, file: out.aot, mode: aot, options: --heap-size0 -f to_test, argument: , expected return: { ret code: 0, stdout content: 0x0:i32, description: expected output 0x0:i32 } }该流程对应run.py中的run_issue_test_wamrc()先编译并断言编译结果与run_issue_test_iwasm()再以aot模式运行out.aot并断言运行结果两个函数串联执行run.py。4.5 处理弃用用例deprecatedWebAssembly spec 持续演进部分用例可能因 spec 变更而失效。当确认不是 WAMR 的 bug而是用例本身应当废弃例如通过wasm-validate等工具验证后应当将用例目录移动到issues-deprecated/下在其 running config 中把deprecated设为true。示例如下README 原文案例对应 issue-47 至 issue-84 的经典解释器回归用例{ deprecated: true, ids: [ 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84 ], runtime: iwasm-default, mode: classic-interp, file: PoC.wasm, argument: , expected return: { ret code: 0, stdout content: , description: no segfault } }run.py遇到deprecated为true的条目时会直接跳过run.py目录issues-deprecated/中 issue-47 至 issue-84 的PoC.wasm即为实际落盘证据。五、run.py一键回归与结果解读5.1 运行方式在ba-issues目录下直接执行# 运行全部用例 ./run.py # 只运行指定 issue--issues / -i 缩写 ./run.py --issues 2833 # 测试 issue #2833 ./run.py -i 2833,2834,2835 # 测试 3 个 issue#2833 #2834 #2835-i参数会按逗号切分并逐个转为整数run.py。脚本每次运行前会删除上一次遗留的issues_tests.log保证日志干净可追溯run.py。5.2 执行与断言逻辑run.py的核心执行流程如下通过get_issue_ids_should_test()扫描issues/issue-*目录用正则issue-(\d)提取全部待测 issue IDrun.py解析running_config.json逐条遍历test cases跳过 deprecated 条目对每个ids中的 issue先与目录中真实存在的 issue取交集run.py若配置含compile_options则先执行run_issue_test_wamrc()only compile为false时编译成功后继续执行run_issue_test_iwasm()run_issue_test_iwasm()中mode与命令行参数的映射关系为run.pyclassic-interp→ 追加--interpfast-interp→ 不追加任何模式参数默认即 fast-interp其他模式如fast-jit、llvm-jit→ 追加--modeaot→ 使用不含模式参数的 AOT 运行命令模板TEST_AOT_COMMAND。断言规则run.py实际退出码须等于期望ret codestdout 的匹配采用精确相等或子串匹配的宽松策略——若期望内容长度大于 30 个字符或期望内容恰为Compile success则只要实际输出包含该期望串即判为通过这一设计让超长异常消息如带地址的报错也能稳定断言。5.3 结果输出与常见场景解读全部跑完且通过时输出形如 Test results Total: 22 Passed: 22 Failed: 0 Left issues in folder: no more Cases in JSON but not found in folder: no more场景一目录里有用例但忘记在 JSON 中添加配置。此时该用例不会被消费结果中会出现Left issues in folder: #3022 Test results Total: 21 Passed: 21 Failed: 0 missed: 0 Left issues in folder: #3022 Cases in JSON but not found in folder: no more场景二JSON 中配置了错误 id或目录中缺少对应用例目录。结果中会出现Cases in JSON but not found in folder: #12345 Test results Total: 21 Passed: 21 Failed: 0 missed: 0 Left issues in folder: #2855 Cases in JSON but not found in folder: #12345场景三存在失败用例。Failed计数非零细节写入issues_tests.log Test results Total: 22 Passed: 21 Failed: 1 Left issues in folder: no more Cases in JSON but not found in folder: no more5.4 失败日志的解读失败详情会以固定格式追加到issues_tests.log格式定义见 run.py写入逻辑见dump_error_log()。例如 Failing issue id: 2945. run with command_lists: [./build/iwasm-default-wasi-disabled, --heap-size0, -f, to_test, .../issues/issue-2945/iwasm_fast_interp_moob_unhandled.wasm] exit code (actual, expected) : (1, 0) stdout (actual, expected) : (Exception: out of bounds memory access, Exception: out of bounds memory access) 这条日志告诉我们issue-2945 的实际退出码为 1、期望为 0说明运行虽然抛出了正确的Exception: out of bounds memory access但进程退出码与断言不符——这正是需要人工判定的回归失败信号。该用例对应的 JSON 配置可在 running_config.json 中找到期望ret code为 1、输出Exception: out of bounds memory accessREADME 中的日志示例恰好展示的是配置修改前的失败状态。六、真实用例速览从配置反推 bug 形态通过结合 running_config.json 与issues/目录可以快速理解这套框架实际守护的 bug 类别下表全部基于当前仓库已存在的配置与用例类别典型 issue期望行为说明内存越界2857 / 2858退出码 1输出Exception: out of bounds memory access验证越界访问以异常形式抛出而非崩溃除零异常2946 / 2948退出码 1输出Exception: integer divide by zerofast-interp 下除零必须被正确捕获整数溢出2947退出码 1输出Exception: integer overflow防止 double free 类内存破坏非法模块2863 / 3130 / 3137退出码 255输出WASM module load failed: ...畸形 wasm 应优雅报错而非触发 sanitizer 堆溢出错误返回值2955 / 2956退出码 0输出特定 i64 值修复指令计算结果错误类 bug错误异常2949 / 2950 / 2951 / 2952退出码 0无异常输出修复本不该抛异常却抛出的 bug禁止 SIGSEGV3090 / 3122退出码 0 或 1绝无unhandled SIGSEGV/ ASan SEGV内存安全底线守护浮点语义3062退出码 0输出nan:f32修正 fast-interp 的浮点结果错误表访问越界3021 / 3023退出码 1输出Exception: out of bounds table accessbulk memory 相关指令如table.init的边界检查GC 用例315101 / 315102退出码 0输出in specttest.print_i32(4)GC 特性下的确定性输出验证这些用例名称也极具自描述性如iwasm_fast_interp_moob_unhandled.wasmfast-interp 未处理的越界内存访问、iwasm_fast_interp_div_zero_double_free2.wasm除零引发的二次释放、iwasm_jit_without_exception.wasmJIT 未抛异常等命名即标注了引擎 模式 问题类型便于快速定位。七、从零接入新 issue 的完整流程综合以上内容为 WAMR 添加一个新的 BA issue 回归用例的完整步骤为准备用例文件拿到能够稳定触发该 bug 的 wasm通常来自 issue 附件或 fuzz 报告确认其可复现创建目录运行./helper.sh issue编号批量则传两个参数zip 用例加-x生成issues/issue-编号/并把 wasm 放进去确认构建配置若现有 7 个运行时变体已覆盖所需模式fast-interp / fast-jit / llvm-jit / classic-interp / aot 及是否启用 WASI则无需改动否则在build_wamr.sh末尾用build_iwasm CMake 变量 运行时名称追加新变体然后./build_wamr.sh重新编译编写运行配置在running_config.json的test cases数组中新增条目按用例形态选择仅 iwasm仅 wamrc 编译wamrc iwasm 组合三种模板填写runtime、file、mode、options、argument以及expected return中的退出码、stdout 断言与描述同一批同类用例可合并ids并使用通配符file回归验证./run.py或./run.py -i 编号定向验证确认Passed计数符合预期、Left issues in folder与Cases in JSON but not found in folder均为no more若有失败结合issues_tests.log中的实际退出码与 stdout 核对断言是否正确可选弃用处理若因 spec 变更确认用例应废弃将目录移入issues-deprecated/并将配置中deprecated置为true。结语BA Issues 回归测试框架的价值在于低门槛、强断言、可追溯一个 wasm 文件 一行 JSON 配置即可把一次线上事故或 fuzz 发现固化成为持续守护 WAMR 各执行模式解释器、多级 JIT、AOT与内存安全的自动化防线。对于希望为 WAMR 贡献代码或保障自身 wasm 运行时质量的开发者而言掌握这套工作流就等于拥有了为每个历史 bug 上保险的标准化方法。相关脚本与全部历史用例均可直接在 lib/wasm-micro-runtime-WAMR-2.4.1/tests/regression/ba-issues 目录中查阅与复用。【免费下载链接】fluent-bitFast and Lightweight Logs, Metrics and Traces processor for Linux, BSD, OSX and Windows项目地址: https://gitcode.com/GitHub_Trending/fl/fluent-bit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考