ISO 26262 变更验证：Parasoft 助力排查测试盲区

 安全相关代码改完，原有测试全部通过，仍不能据此判断本次变更已得到充分验证。新增的异常处理条件可能没有进入测试输入，断言也可能仍沿用变更前的预期结果。

在按 ISO 26262 开展开发的项目中，安全相关变更需要结合影响分析，重新核查验证范围。Parasoft C/C++test 与 DTP 的价值，在于帮助团队关联需求、测试结果和结构覆盖信息，定位需要补充或复查的验证依据。

一、旧用例通过，不代表新增保护条件已验证

以控制器中的转矩输出许可为例：原有逻辑检查“存在输出请求、反馈有效”，本次变更增加一条要求：

REQ-TQ-017：反馈数据年龄超过 100 ms 时，禁止输出转矩，并将输出值置零。

下面使用 C++14 表达这一变更。代码为教学示例，不来自客户项目；100 ms 为示例阈值，实际数值应由项目安全要求确定。

#include <cstdint>

struct TorqueInput {
bool requested;
bool feedback_valid;
std::uint32_t feedback_tick_ms;
std::int16_t requested_torque;
};

struct TorqueOutput {
bool enabled;
std::int16_t torque;
};

TorqueOutput evaluate_torque(const TorqueInput& input,
std::uint32_t now_ms) noexcept
{
constexpr std::uint32_t kMaxFeedbackAgeMs = 100U;

// 前提：使用同一单调递增的 uint32_t 毫秒计数器，
// 且实际经过时间小于一个完整计数周期。
const std::uint32_t age_ms =
static_cast<std::uint32_t>(now_ms – input.feedback_tick_ms);

const bool allowed =
input.requested &&
input.feedback_valid &&
(age_ms <= kMaxFeedbackAgeMs);

return TorqueOutput{
allowed,
allowed ? input.requested_torque : std::int16_t{0}
};
}

如果原有用例只测试“有效反馈下正常输出”和“无请求时禁止输出”，且反馈年龄始终为 10 ms，那么新增超时判断后，这些测试仍会通过。

这只能说明已有输入仍符合预期，不能说明“超过 100 ms 禁止输出”已经得到验证。

针对本次变更，应补充能够区分新旧行为的测试。下面使用 GoogleTest 参数化测试表达测试设计，断言同时检查输出许可和转矩值：

#include <gtest/gtest.h>
// 假定已包含上述结构体及 evaluate_torque 的声明。

struct TorqueCase {
const char* name;
TorqueInput input;
std::uint32_t now_ms;
bool expected_enabled;
std::int16_t expected_torque;
};

class TorqueGateTest
: public ::testing::TestWithParam<TorqueCase> {};

TEST_P(TorqueGateTest, MatchesSafetyRequirement)
{
const auto& tc = GetParam();
SCOPED_TRACE(tc.name);

const auto actual = evaluate_torque(tc.input, tc.now_ms);

EXPECT_EQ(tc.expected_enabled, actual.enabled);
EXPECT_EQ(tc.expected_torque, actual.torque);
}

INSTANTIATE_TEST_SUITE_P(
RequirementCases,
TorqueGateTest,
::testing::Values(
TorqueCase{"fresh", {true, true, 1000U, 120}, 1010U, true, 120},
TorqueCase{"no_request", {false, true, 1000U, 120}, 1010U, false, 0},
TorqueCase{"invalid", {true, false, 1000U, 120}, 1010U, false, 0},
TorqueCase{"at_limit", {true, true, 1000U, 120}, 1100U, true, 120},
TorqueCase{"expired", {true, true, 1000U, 120}, 1101U, false, 0},
TorqueCase{"tick_wrap", {true, true, 0xFFFFFFF0U, 120},
0x00000020U, true, 120}
)
);

其中，`at_limit` 与 expired 核查超时边界；`tick_wrap` 检查无符号计数器跨零后的时间差，本例为 48 ms。若系统不能保证上述计时前提，还需另行处理时间戳异常。

**需求关联着测试，不等于测试内容已经跟随需求更新。**完成相应集成与配置后，Parasoft DTP 可呈现需求关联的测试及结果，为工程师审查输入、边界和断言提供追溯入口。关联关系帮助找到对象，验证是否充分仍需结合需求判断。

二、分支覆盖充分，仍需检查条件是否被独立验证

上述许可判定可以写成：

allowed = A && B && C

A：存在输出请求
B：反馈有效
C：反馈年龄不超过 100 ms

如果只执行 fresh 和 no_request，判定已经出现真、假两种结果。但反馈有效性和超时条件都没有分别导致判定翻转，不能据此说明各条件的独立作用已验证。

这组对照体现了 MC/DC 所关注的条件独立影响。实际报告还需结合短路求值、工具的覆盖定义及插桩配置解读，不能仅凭测试表宣称已满足全部覆盖目标。

Parasoft C/C++test 官方文档介绍了分支、MC/DC 等覆盖度量，并支持从覆盖元素反查关联用例，以及单独查看选定用例的覆盖情况。对于本例，工程师可以据此核查：超时条件是否被有效触发、哪些测试贡献了相关覆盖，以及仍缺少哪些输入。

但覆盖充分仍不等于行为检查充分。例如，超时测试只断言 enabled == false，却没有检查 torque == 0，就可能遗漏需求中的输出清零要求。

**覆盖结果揭示执行范围，断言检查预期行为，两者需要一起审查。**覆盖指标则应依据项目适用要求与验证计划选择，不能将 MC/DC 当作所有项目的统一门槛。

真实实践方面，Parasoft 中国官网披露，中移智行于 2023 年获得 ISO 26262 功能安全产品 ASIL B 认证，并使用 C/C++test 开展静态分析、单元测试、集成测试及覆盖指标度量。该案例能够支撑测试与覆盖分析的工程应用，但未公开上述转矩逻辑或具体变更补测过程。

三、补测完成后，还要确认结果属于本次构建

补充用例后，需要重新执行测试，复查断言与适用覆盖目标。未覆盖项则应调查原因：是输入不足、环境限制，还是不可达代码，并保留处理依据。若变更影响通信、任务调度或执行器接口，还需安排相应的集成或系统测试。

验证结果也必须对应正确版本。DTP 使用构建标识组织结果，工具配置中的 build.id 用于指定该标识。同一构建下的多次测试与覆盖执行可以归集分析。

例如，可在项目工具配置中明确设置：

# 示例：由 CI 生成并写入，名称包含流水线编号和提交短哈希
dtp.project=TorqueController
build.id=TorqueController-1842-a1b2c3d

这里的命名方式是工程建议。关键是让同一被测构建的结果使用一致标识，并避免把不同代码版本归入同一构建。如果编译选项或目标配置影响被测行为，也应明确区分相关验证上下文。

对于安全相关变更，需要核查的始终是四件事：用例是否跟随需求更新、断言是否检查新增行为、覆盖是否达到适用目标、结果是否属于本次构建。

Parasoft C/C++test 与 DTP 将测试执行、覆盖分析和需求追溯连接起来，帮助团队找到并复查这些验证缺口，为 ISO 26262 合规评估保留可核查的依据。

这里是慧都科技，如需了解更多Parasoft相关信息，欢迎沟通交流~