问题描述

conversion/npu_format_cast/tests/ut/op_host/test_aclnn_npu_format_cast_l2.cpp（aclnnNpuFormatCast 的 L2 op_api UT）长期处于失效状态，具体问题如下：

1. UT 模块未启用，文件成为死代码

tests/ut/op_host/CMakeLists.txt 中的 add_modules_ut_sources 于 b5adbd049（2025-09-29，"add ut for pad ops" 合入）被注释，此后该测试文件不再编入 math_op_api_ut，约 9 个月未被编译运行。

2. fixture 未设置平台，用例跑在错误的平台上

用例按 Ascend950 / Ascend910_93 设计，但 SetUpTestCase 未调用 SetPlatformSocVersion，实际运行在 UT 桩默认平台 ASCEND910B 上（tests/ut/op_api/stub/opdev/platform.cpp 中 g_socVersion 默认值）。host 侧对 additionalDtype != -1 仅放行 RegBase(950) 平台，导致全部 950 正向用例被平台门禁误拦。

3. 大量负向用例为假阳性或期望过时

TestOneParamCase 缺少"期望报错但实际成功"的末尾断言：

• 910_93 平台的 7 个负向用例（InvalidAdditionalDtype / InvalidsrcTensor / InvalidsrcDtype 等）：非 RegBase 平台的 ND→NZ 从 init（7cf8c6081）起就没有对应参数校验，这些用例自提交之日起即为假阳性；
• 950 平台的 3 个负向用例（InvalidAdditionalDtype / InvalidsrcDtype_uint8 / InvalidsrcDtype_fp32）：随算子能力扩展（f252c6ed6 适配 hifloat8/uint8、dc103372d 支持 mxa8w4 等），UINT8 进入 950 支持列表、INT32 src 放行 INT8 additional、非量化 FP32→NZ 合法化，期望已过时。

实证：将上述 10 个用例加回当前 master 代码运行，全部报 "Expected error 161002 but all API calls succeeded"，即这些输入现在均为合法输入。

4. aclrtStream 未初始化

TestOneParamCase 中 aclrtStream stream; 声明未初始化，成功路径将野指针传入 aclnnNpuFormatCast 二段接口，存在段错误风险。

5. 平台状态污染

fixture 修改全局平台后未恢复，会影响同一 UT 二进制中后续算子的用例。

修复

见关联 PR !4486。