测试框架指南【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime返回 Runtime DT用例开发总纲Runtime 仓测试主要基于 gtest结合 gmock、mockcpp、公共桩和模块内 stub/data 组织用例。本文介绍现有测试框架能力帮助开发者优先复用已有设施而不是重复造轮子。测试基类绝大多数用例直接继承testing::Test并在SetUp/TearDown中完成公共初始化与清理。常见职责包括恢复默认 mock 行为创建和销毁模拟器设置和恢复全局芯片类型、device、环境变量校验并清理 mock 对象如果多个用例共享同一套初始化逻辑建议抽出统一 fixture避免重复代码。mock 框架gmock适用于已有 mock 类或接口期望校验场景常见用法包括EXPECT_CALL(...)Mock::VerifyAndClear(...)典型场景ACL 相关接口测试需要验证某个 mock 对象被调用次数和参数的场景mockcpp适用于全局函数、静态函数、成员函数替换场景仓内使用非常普遍。常见接口包括MOCKER(...)MOCKER_CPP(...)MOCKER_CPP_VIRTUAL(...)GlobalMockObject::verify()典型场景打桩dlopen/dlsym/access等系统接口打桩 driver、runtime、device 相关函数替换单例内部调用链公共桩与测试资产tests/depends/tests/depends/提供跨模块复用的公共桩新增测试前应优先检查这里是否已有可复用能力。当前主要包含ge/mmpa/profiling/runtime/slog/tdt/toolchain/模块内stub/、data/、json/很多模块会在自己的测试目录下维护专用测试资产例如tests/ut/msprof/st/stub/tests/ut/msprof/st/data/tests/ut/acl/json/tests/ut/runtime/runtime_c/stub/如果某个 stub 或数据只服务于一个模块应优先放在模块内避免污染公共目录。模拟器与辅助能力部分 ST/UT 会使用模块内现成的模拟器和数据管理能力例如SimulatorMgr()创建/销毁平台模拟器DataMgr()初始化和校验场景数据这类能力通常已经和模块场景耦合新增用例时应优先复用现有 helper不要重复实现一套新的模拟逻辑。构建接入新增测试代码后通常需要修改对应模块的CMakeLists.txt。常见接入方式包括将新文件加入UT_FILES将新目录加入add_subdirectory(...)为新可执行目标补充依赖的 stub、头文件和链接库如果新增了可通过bash tests/build_ut.sh -u target直接执行的模块还需要同步更新tests/build_ut.sh中的 target 映射。覆盖率与 Sanitizer仓内统一入口为tests/build_ut.sh# 覆盖率 bash tests/build_ut.sh -c # AddressSanitizer bash tests/build_ut.sh --asan -u runtime如果新增测试会创建大量临时文件或目录建议在本地同时跑一遍覆盖率或 sanitizer尽早暴露泄漏和残留状态问题。【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考