企业官网建设流程全解析

CANN graph-autofusion 测试开发实战指南：SuperKernel 与 Autofuse 组件 UT/ST 全流程

【免费下载链接】graph-autofusionGraph-autofusion 是一个面向昇腾（Ascend）芯片的轻量级、解耦式组件集合，旨在通过自动融合技术加速模型执行。 目前已开源 SuperKernel 组件和 Autofuse 组件，未来将持续开放更多自动融合相关模块。项目地址: https://gitcode.com/cann/graph-autofusion

导读

本文是 CANN graph-autofusion 开源仓库（包含 SuperKernel 与 Autofuse 两大自动融合组件）的测试开发技术指南，系统讲解单元测试（UT）与系统测试（ST）的编写规范、编译验证、运行命令、目录结构与排查方法。读完本文，你将掌握：如何用 gtest / pytest 编写符合仓库规范的测试用例，如何通过build.sh与scripts/test/run_autofuse_test.sh精准驱动任意模块的测试与覆盖率统计，如何利用 AscGraphBuilder 高效构造复杂计算图，以及如何将新测试接入 CMake/CTest 并完成端到端验证。

一、测试体系总览：两大组件、两套工具链

graph-autofusion 项目由 super_kernel 与 autofuse 两大组件构成，其测试体系同样分为两套：

• SuperKernel：Python UT/ST（pytest）与 C++ AOT UT/ST（gtest + mockcpp），统一由仓库根目录的 build.sh 驱动；
• Autofuse：涵盖 att、optimize、common、codegen、ascendc_api、ascir、py_module、e2e 等众多模块，由 scripts/test/run_autofuse_test.sh 驱动。

两套工具链均支持-u/--ut（单元测试）、-s/--st（系统测试）、-c/--cov（覆盖率）与-j<N>（并行编译线程数）等参数，但模块划分、二进制命名与 CTest 集成方式各不相同，下文分别展开。

二、测试开发完整工作流：写用例 → 编译 → 运行验证

开发完测试用例后，必须执行验证，不可跳过。标准流程如下：

Step 1：编写测试用例

按本指南后续章节的规范编写测试用例（C++ 侧见"gtest 编写规范"，Python 侧见"pytest 编写规范"）。

Step 2：编译验证

C++ 测试支持两种编译方式：

# 增量编译指定 target（推荐，最快） cmake --build build --target <test_target> -j8 # 或通过 run_autofuse_test.sh 编译运行 bash scripts/test/run_autofuse_test.sh -u -m <module> -j 8

Python 测试需先确保 CPython 扩展模块pyautofuse已编译，再运行 pytest：

# 确保 pyautofuse 已编译 cmake --build build --target pyautofuse -j8 # 运行 pytest PYTHONPATH=build/autofuse/compiler/py_module:$PYTHONPATH \ python3 -m pytest autofuse/tests/ut/python/<test_file>.py -v

pyautofuse模块由 autofuse/compiler/py_module/ 提供，暴露ascir、Autofuser、CodeGen等接口（详见 pyautofuse.cpp）。

Step 3：运行测试并确认结果

# C++ 运行指定用例（gtest_filter 精确筛选） ./build/<path_to_binary> --gtest_filter="<TestClass>.<TestName>" # C++ 运行整个 target ./build/<path_to_binary> # Python 运行指定类/方法 python3 -m pytest <test_file>::<TestClass>::<test_method> -v

必须确认以下全部通过：

• 编译无错误
• 测试全部 PASS（无 FAIL、无 ERROR）
• 无新增 warning（关注-Werror相关）
• 无超时或死循环

三、测试运行命令详解

3.1 SuperKernel（build.sh）

SuperKernel 测试统一使用仓库根目录的 build.sh 驱动，支持的模块定义在SUPPORTED_MODULES变量中（源码见 build.sh），包括superkernel、autofuse_framework、autofuse_ascendc_api、autofuse_e2e：

# Python UT sh build.sh -u --module=superkernel --impl=py # Python ST sh build.sh -s --module=superkernel --impl=py # C++ UT (AOT) sh build.sh -u --module=superkernel --impl=cpp # 带覆盖率 sh build.sh -u --module=superkernel -c

关键参数说明（与 build.sh 的 usage 一致）：

3.2 Autofuse（run_autofuse_test.sh）

Autofuse 使用 scripts/test/run_autofuse_test.sh 驱动。注意：Autofuse 编译默认并行度无限制，在多核机器上可能导致 OOM，建议加-j 8。

# Framework UT（att + optimize + common + codegen + py_module） sh build.sh -u --module=autofuse_framework -j 8 # AscendC API UT sh build.sh -u --module=autofuse_ascendc_api -j 8 # E2E ST sh build.sh -s --module=autofuse_e2e -j 8

脚本内部通过case ${MODEL_NAME}分发到各模块构建函数（run_autofuse_test.sh），主流程依次执行：编译 ascgen-dev → 拷贝 graph_metadef 动态库 → 构建并运行 UT/ST → 可选覆盖率统计（run_autofuse_test.sh）。

3.3 run_autofuse_test.sh 模块名完整列表

UT 模块（-u -m <module>）：

ST 模块（-s -m <module>）：

示例：

bash scripts/test/run_autofuse_test.sh -u -m common -j 8 bash scripts/test/run_autofuse_test.sh -u -m optimize -j 8 bash scripts/test/run_autofuse_test.sh -s -m backend -j 8

其余参数与 build.sh 一致，包括-c/--cov（需环境已安装与 gcc/g++ 版本匹配的 lcov、gcov、genhtml）、--ascend_install_path（默认/usr/local/Ascend/ascend-toolkit/latest）与--ascend_3rd_lib_path（默认./output/third_party），详见 run_autofuse_test.sh。

四、测试目录结构

4.1 SuperKernel

super_kernel/tests/ ├── conftest.py # pytest 配置，自动标记 ut/st（仅 super_kernel 有） ├── fixtures/ # 共享 pytest fixtures ├── utils/ # 测试工具函数 ├── ut/ # Python 单元测试 ├── st/ # Python 系统测试 │ └── scenarios/ └── aot/ # C++ AOT 测试 ├── ut/ # C++ 单元测试 (gtest + mockcpp) │ ├── main.cpp # gtest main() 入口 │ ├── test_sk_*.cpp # 测试文件 │ └── stub/ # Mock/Stub 头文件 └── rdv/ # 设备端验证测试（见"RDV 设备端测试"章节）

其中 conftest.py 通过pytest_collection_modifyitems钩子，按测试文件路径自动添加 marker：tests/ut/**下的文件标记为@pytest.mark.ut，tests/st/**标记为@pytest.mark.st，路径不在tests/下则直接抛异常。同时注册了fixtures.config与fixtures.sub_kernel两个共享 fixture 插件（super_kernel/tests/fixtures/）。

4.2 Autofuse

autofuse/tests/ ├── common/stub/ # 共享 stubs（att 模块使用） ├── depends/ # 测试依赖 stubs（共享库形式） │ ├── slog/ # 日志 stub（asc_slog_stub） │ ├── runtime/ # Runtime stub（autofuse_runtime_stub） │ ├── trace/ # Atrace stub（atrace_stub） │ ├── common/ # 通用测试工具（common_stub） │ └── securec/ # Secure C 库 stub ├── framework/ # 测试框架辅助（AscGraphBuilder 等） ├── graph_metadef/ # Graph metadef 测试工具 ├── ut/ # 单元测试 │ ├── att/ # ATT UT（独立二进制 att_ut） │ ├── ascendc/ # AscendC UT │ │ ├── api/ # AscendC API UT │ │ └── compile/ # AscendC 编译 UT │ ├── ascir/ # ASCIR IR UT（OBJECT 库，链接到 test_main） │ ├── autofuse/ # Autofuse 配置 UT（独立二进制 autofuse_utils_ut） │ ├── codegen/ # 代码生成 UT（OBJECT 库，链接到 test_main） │ ├── common/ # 通用工具 UT（独立二进制 test_common） │ ├── e2e/ # 端到端 UT（OBJECT 库，链接到 test_main） │ ├── optimize/ # 优化 pass UT（独立二进制 optimize_ut） │ ├── py_module/ # Python 模块 C++ binding UT（OBJECT 库） │ └── python/ # Python UT (pytest) ├── st/ # 系统测试 │ ├── ascir/ # ASCIR ST │ ├── att/ # ATT ST │ ├── backend_e2e/ # Backend 端到端 ST │ ├── codegen/ # Codegen ST │ │ ├── e2e/ # Codegen E2E ST（67 场景，见"E2E ST 场景"章节） │ │ ├── ascir_tool/ # ASCIR tool ST │ │ └── kernel_tool/ # Kernel tool ST │ ├── common/ # 通用 ST │ ├── optimize/ # 优化 ST │ └── python/ # Python ST └── v35/ # v3.5 架构特定测试 ├── ut/ └── st/

stub 依赖库在 autofuse/tests/depends/ 下定义，由 autofuse/tests/CMakeLists.txt 构建，例如 runtime stub 位于 autofuse/tests/depends/runtime/、slog stub 位于 autofuse/tests/depends/slog/。

五、测试目标与运行方式（二进制 + CTest 集成）

注意：att_ut、optimize_ut、test_common是独立二进制，不通过 CTest 发现，需直接执行。test_main聚合了 ascir/codegen/py_module/e2e 等 OBJECT 库形态的 UT。

CTest 命令示例

# ST 标签（有效标签） ctest --test-dir build/tests/st --output-on-failure -j8 -L att_st ctest --test-dir build/tests/st --output-on-failure -j8 -L codegen_st ctest --test-dir build/tests/st --output-on-failure -j8 -L optimize_st ctest --test-dir build/tests/st --output-on-failure -j8 -L test_common_st

六、C++ 测试编写规范（gtest）

6.1 文件命名

• test_<module>.cpp：如test_sk_common.cpp
• <feature>_unittest.cpp：如codegen_infershape_unittest.cpp

6.2 测试类命名

使用 PascalCase +Test后缀，遵循 Arrange/Act/Assert 三段式：

class SkCommonTest : public testing::Test { protected: void SetUp() override {} void TearDown() override {} }; TEST_F(SkCommonTest, TestFunctionName) { // Arrange // Act // Assert EXPECT_EQ(result, expected); }

6.3 CMake 集成

场景 1：向已有 target 添加测试文件

如果 CMakeLists.txt 使用GLOB_RECURSE（如test_common、optimize_ut），新文件会自动发现，无需修改 CMake。例如 autofuse/tests/ut/common/CMakeLists.txt 与 autofuse/tests/ut/optimize/CMakeLists.txt 即采用该模式。

如果 CMakeLists.txt 显式列出源文件，需添加：

target_sources(<test_target> PRIVATE test_new_feature.cpp)

场景 2：新增测试模块（完整流程）

1. 创建autofuse/tests/ut/new_module/CMakeLists.txt：

   file(GLOB_RECURSE NEW_MODULE_TEST_SRCS CONFIGURE_DEPENDS "*.cpp") add_executable(new_module_ut test_main.cpp ${NEW_MODULE_TEST_SRCS}) target_link_libraries(new_module_ut PRIVATE GTest::gtest GTest::gtest_main ...)

2. 修改 autofuse/tests/ut/CMakeLists.txt：

   add_subdirectory(new_module)

3. 如果是 OBJECT 库（链接到test_main）：

   target_link_libraries(test_main PRIVATE new_module_tests)

4. 可选：在 scripts/test/run_autofuse_test.sh 中添加模块分发逻辑（build_ut/build_st的case分支）。

6.4 Stub/Mock 模式

各模块 stub 模式不同：

编写新测试时，优先复用已有 stub。optimize/common/codegen 模块不需要本地 stub 目录，通过链接共享 stub 库隔离依赖。att 模块的共享 stub 头文件位于 autofuse/tests/common/stub/（如stub_model_info.h、stub_matmul_modelinfo.h）。

七、复杂图构造指导

7.1 问题背景

optimize 模块测试需要构造af::AscGraph对象，每个节点需手动设置 dtype、axis、repeats、strides、sched.axis、compute_type、ir_attr，非常冗长（30+ 行/节点）。

7.2 方案 1：使用 AscGraphBuilder（推荐）

autofuse/tests/framework/easy_asc_graph/asc_graph_builder.h 提供 fluent API，位于af::testing命名空间：

#include "framework/easy_asc_graph/asc_graph_builder.h" auto graph = AscGraphBuilder("test_graph") .AddData("x", dtype::FLOAT16, {s0, s1}) .AddLoad("load1") .AddOp<Abs>("abs1") .AddStore("store1") .Build();

从源码看，该 Builder 的方法覆盖面与真实前端对齐（asc_graph_builder.h）：

• 轴定义：Loops({sizes})批量创建循环轴；ExtraAxis(name, size)创建额外轴，用于混合 axis 组场景（如 Gather 的数据轴和索引轴）；
• 数据节点：Data(name, index, shape, strides, dtype)支持自定义 axes 与形状/步长；Scalar/ScalarData/IndexExpr覆盖标量形态——其中IndexExpr保持真实前端形态（输出视图为空），Arange输出视图由调用方显式给定（支持退化轴视图如{1, s1}/{0, 1}的前缀扩维形态）；
• 搬运节点：Load/Store支持 shape、strides、offset 组合；
• 输出与工作区：Output/Workspace完成图出口定义。

7.3 方案 2：复用已有工厂函数

test_optimizer.cpp中有多个图构造工厂函数可复用：

• CreateAscBackendGraphTwoInTwoOut()
• CreateOneNodeAscGraph()
• CreateTailPackAscGraph()

7.4 方案 3：提取共享 fixture

将常用图结构提取到 autofuse/tests/framework/ 下的共享 fixture 中（该目录还包含easy_graph/、eager_style_graph_builder/、share_graph/、device_validation/等框架辅助子目录，可按需选用）。

八、Python 测试编写规范（pytest）

8.1 文件命名

• test_<module>.py：如test_super_kernel.py
• test_<module>_<feature>.py：如test_super_kernel_option_parse.py

8.2 目录约定

仅 super_kernel 有 conftest.py 自动标记：

• super_kernel/tests/ut/下的文件自动标记为@pytest.mark.ut
• super_kernel/tests/st/下的文件自动标记为@pytest.mark.st

autofuse 没有 conftest.py，Python 测试通过 CMakeadd_test()注册，不依赖 pytest marker。

8.3 示例

import pytest class TestMyFeature: def test_basic_functionality(self): result = my_function(input_data) assert result == expected def test_edge_case(self): with pytest.raises(ValueError): my_function(invalid_input)

8.4 Fixtures

共享 fixtures 放在super_kernel/tests/fixtures/目录下，通过 super_kernel/tests/conftest.py 自动发现（仅 super_kernel）。Autofuse 的 Python 测试则直接在测试文件内定义 fixture。

九、Python + C++ 混合测试

9.1 pyautofuse 模块

autofuse/compiler/py_module/ 提供 CPython 扩展模块pyautofuse，暴露ascir、Autofuser、CodeGen等接口（C++ 实现见 pyautofuse.cpp，类型封装见 pyascir_types.cpp）。

Python 端测试（ut/python/）：

from autofuse.pyautofuse import ascir, Autofuser, AutofuserOptions, Schedule, CodeGen def test_autofuse_pipeline(): graph = construct_test_graph() options = AutofuserOptions() autofuser = Autofuser(options) result = autofuser.fuse(graph) # verify result

C++ 端测试（ut/py_module/）：

测试 CPython 扩展的内部实现，需调用Py_Initialize()和PyInit_pyautofuse()。

运行命令：

bash scripts/test/run_autofuse_test.sh -u -m codegen -j 8 # 包含 py_module UT

十、E2E ST 场景（Codegen 端到端）

10.1 添加新场景

autofuse/tests/st/codegen/e2e/ 下有 67 个 E2E 场景，每个场景使用 CMake 宏add_codegen_e2e_st_test()（宏定义与两阶段执行逻辑见 autofuse/tests/st/codegen/e2e/e2e.cmake）。

步骤：

1. 创建场景目录st/codegen/e2e/my_scenario_expect_code/

2. 创建源文件：

   • my_scenario_codegen.cpp— 生成 kernel 代码
   • my_scenario_codegen_tiling.cpp— tiling 逻辑
   • test_e2e_my_scenario_expect_kernel.cpp— 验证 kernel 执行

3. 创建CMakeLists.txt：

   add_codegen_e2e_st_test(my_scenario_expect_code TILING my_scenario_codegen_tiling.cpp CODEGEN my_scenario_codegen.cpp KERNEL_SRC my_scenario_kernel.cpp my_scenario_tiling.cpp autofuse_tiling_data.h TEST_SRC test_e2e_my_scenario_expect_kernel.cpp)

4. 在父CMakeLists.txt中添加：

   add_subdirectory(my_scenario_expect_code)

两阶段执行（对应 CTest 标签codegen_e2e_st_test1/2）：

• Phase 1：编译 codegen 可执行文件，运行生成 kernel 源码；
• Phase 2：编译生成的 kernel + 测试代码，在 Ascend 模拟器上执行验证。

十一、RDV 设备端测试（Real Device Verification）

11.1 概述

super_kernel/tests/aot/rdv/包含设备端验证测试，用于在真实设备或模拟器上验证 super kernel 算子的正确性，覆盖 RMSNorm、weight_quant_batch_matmul_v2 等算子。

11.2 目录结构

aot/rdv/ ├── tensor_list/ # 共享 tensor list 工具 ├── ops/ │ ├── interface/ # 算子调度接口（OpsInterface） │ ├── common/ # 共享 kernel 工具 │ ├── rms_norm/ # RMSNorm 算子 │ │ ├── tests/main.cpp # 测试入口 │ │ └── tests/CMakeLists.txt │ ├── weight_quant_batch_matmul_v2/ │ └── ...

11.3 编写新 RDV 测试

1. 在ops/下创建算子目录
2. 实现 kernel（.h+.asc文件）
3. 在tests/main.cpp中编写测试逻辑（分配设备内存、拷贝数据、launch kernel、验证结果）
4. 在OpsInterface中注册算子到g_sk_fun_map

11.4 运行

RDV 测试不集成到build.sh，需手动编译运行：

cd super_kernel/tests/aot mkdir build && cd build cmake .. -DENABLE_CPP_UTEST=ON make <op_test_target> ./<op_test_target>

十二、覆盖率统计

12.1 C++ 覆盖率

# 编译时启用 gcov sh build.sh -u --module=superkernel --impl=cpp -c # 使用 lcov 生成报告（由 generate_cpp_cov.sh 脚本处理） # 报告位置：build/coverage/html/index.html

Autofuse C++ 覆盖率：

bash scripts/test/run_autofuse_test.sh -u -m common -c -j 8 # lcov 数据在 build/ 下 .gcda/.gcno 文件中

12.2 Python 覆盖率

sh build.sh -u --module=superkernel --impl=py -c # 使用 pytest-cov 生成报告，配置文件为 super_kernel/scripts/sk_ut_cfg.toml / sk_st_cfg.toml # 报告位置：super_kernel/coverage/ut/html/ 或 super_kernel/coverage/st/html/

pytest-cov 的配置集中在 super_kernel/scripts/sk_ut_cfg.toml 与 super_kernel/scripts/sk_st_cfg.toml 两个文件中。

12.3 覆盖率分析

生成报告后，关注：

• 未覆盖的分支（show_missing = true配置已启用）
• 低于 80% 的文件（generate_cpp_cov.sh会列出）
• 排除项：__repr__、__main__、NotImplementedError等已配置排除

十三、常见编译错误排查（FAQ）

Q1:version.info does not exist

CANN toolkit 路径不匹配。检查/usr/local/Ascend/ascend-toolkit/latest/是否存在，或创建符号链接：

sudo ln -sf /home/developer/Ascend/cann-X.Y.Z /usr/local/Ascend/ascend-toolkit/latest

Q2:undefined symbol: _ZTVN2af11AscNodeAttrE

LD_LIBRARY_PATH未包含所有必要的共享库路径。确保包含：

export LD_LIBRARY_PATH=\ <build_dir>/autofuse/graph_metadef/graph/ascendc_ir/generator:\ <build_dir>/autofuse/graph_metadef/graph:\ <build_dir>/autofuse/graph_metadef/graph/expression:\ <build_dir>/autofuse/graph_metadef/graph/ascendc_ir:\ $ASCEND_HOME_PATH/lib64:\ $LD_LIBRARY_PATH

这与 run_autofuse_test.sh 中LOCAL_RUNTIME_LIB_PATH的构造逻辑一致，脚本内部已通过set_test_ld_library_path()自动完成设置。

Q3:opening dependency file ... No such file or directory

protobuf 编译时的依赖文件路径问题。清理 build 目录重新编译：

rm -rf build && bash scripts/test/run_autofuse_test.sh -u -m <module> -j 8

Q4: 链接时找不到-lasc_slog_stub或-lautofuse_runtime_stub

确保 CMakeLists.txt 中正确链接了 stub 库：

target_link_libraries(<target> PRIVATE asc_slog_stub autofuse_runtime_stub atrace )

这些库在 autofuse/tests/depends/ 下定义，由 autofuse/tests/CMakeLists.txt 构建。

Q5:gtest_discover_tests未生效

只有部分 target 使用gtest_discover_tests（test_main、autofuse_utils_ut、test_ascendc_api）。att_ut、optimize_ut、test_common是独立二进制，直接运行即可。

通用排查流程

1. 检查环境变量：ASCEND_HOME_PATH、LD_LIBRARY_PATH、CMAKE_PREFIX_PATH
2. 检查 CANN 安装：ls $ASCEND_HOME_PATH/lib64/libruntime.so
3. 清理重建：rm -rf build && bash scripts/test/run_autofuse_test.sh ...
4. 查看 CMake 日志：build/CMakeFiles/CMakeOutput.log和CMakeError.log

十四、测试失败排查

14.1 排查流程

1. 确认失败类型：

   • 断言失败（EXPECT_EQ等）→ 检查输入数据和预期值
   • 崩溃（segfault）→ 检查空指针、未初始化对象
   • 超时 → 检查无限循环（如SubStringReplace空from参数）

2. 检查 stub 是否正确：

   • Runtime stub 返回的 SoC 版本是否匹配预期
   • Slog stub 是否正确初始化

3. 检查环境：

   • LD_LIBRARY_PATH是否包含所有必要的.so
   • 是否有残留的.gcda文件影响覆盖率构建

4. 隔离测试：

   ./test_binary --gtest_filter="TestClass.TestName"

十五、CMake 验证清单

新增测试后，执行以下验证：

1. 编译验证：

   cmake --build . --target <test_target> -j8

   确保无编译错误。

2. 发现验证（仅使用gtest_discover_tests的 target）：

   ctest --test-dir build/tests/ut -N | grep <test_name>

   确保测试被 CTest 发现。

3. 运行验证：

   ./<test_binary> --gtest_filter="<TestClass>.<TestName>"

   确保测试通过。

4. GLOB 验证（使用GLOB_RECURSE的 target）：

   • 确认新文件在 glob 路径范围内
   • 如不在，需手动添加到target_sources

结语：从用例编写到质量闭环

graph-autofusion 的测试体系以"规范先行、工具链统一、验证闭环"为原则：SuperKernel 与 Autofuse 两套测试工具链覆盖了 Python 与 C++ 两种实现形态，从单元级（gtest/pytest）到系统级（ST）、端到端（E2E）、设备端（RDV）逐层验证自动融合的正确性。开发者只需遵循本文的工作流——按规范写用例、用build.sh或run_autofuse_test.sh驱动编译运行、通过 CTest/gtest_filter 精准定位、以覆盖率报告量化质量，即可为自动融合功能提供可靠的质量保障，并可持续将新的测试用例平滑接入仓库的 CMake/CTest 体系。

【免费下载链接】graph-autofusionGraph-autofusion 是一个面向昇腾（Ascend）芯片的轻量级、解耦式组件集合，旨在通过自动融合技术加速模型执行。 目前已开源 SuperKernel 组件和 Autofuse 组件，未来将持续开放更多自动融合相关模块。项目地址: https://gitcode.com/cann/graph-autofusion