Matter 集成测试工具全解析TestEventTriggers、NamedPipes 与 nlFaultInjection 故障注入实战指南【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeip本文系统梳理 connectedhomeipMatter SDK为集成测试提供的一组关键测试工具——TestEventTriggers测试事件触发、NamedPipes命名管道与 Fault Injection故障注入。它们分别用于在认证测试中模拟难以手动执行的设备动作如触发烟雾报警、在 CI 中自动替代人工操作如按键、以及在客户端测试中注入难以自然出现的错误路径。阅读本文后你将掌握这三类工具的接入方式、调用链路与源码级实现原理能够在自己开发的 Matter 应用与测试用例中正确使用它们。核心原则在尽可能深的代码路径注入错误在深入工具细节之前必须先明确使用这些测试工具的第一原则注入错误的位置应当尽量选择能覆盖最多代码路径的点。以采用 ClusterLogic 模式 的集群为例正确的做法是把错误注入在尽可能靠近驱动层driver layer的位置而不是在服务器端server捕获错误后再模拟失败。这样被测试的代码路径才是真实业务路径测试结果才有意义——错误在底层被注入后会沿着真实的调用链一路向上传播服务器、交互模型层乃至客户端都能以真实路径验证各自的错误处理逻辑。TestEventTriggers认证测试中的事件触发用途与使用限制TestEventTriggers 用于测试在认证certification测试中难以实际执行的 DUT 交互例如触发烟雾报警、模拟极端环境事件等。由于这类操作往往会真实地改变设备状态甚至带来危险文档明确强调两点约束务必克制使用These should be used sparingly!——它不是常规测试手段而是针对难以覆盖场景的补充工具认证测试之外必须关闭——所有 TestEventTriggers 都需要在非认证场景下被禁用避免生产/常规测试环境中留下可被任意触发的后门。工作机制TestEventTriggers 通过General Diagnostics通用诊断集群中的TestEventTrigger命令启动。命令携带两个关键参数test key测试密钥用于鉴权防止未授权触发。目前大多数设备使用一个默认 key但特定设备可以按需覆盖通过DoesEnableKeyMatch实现自定义校验trigger code触发码uint64_t类型的编码向设备请求执行某个具体动作。从 General Diagnostics 集群实现 可以确认其底层校验逻辑IsTestEventTriggerEnabled()会调用testEventTriggerDelegate-DoesEnableKeyMatch()用全零的 16 字节 key 与设备配置的 key 比对——如果设备仍使用全零默认 key说明触发功能未配置真实密钥此时判定触发未启用起到保护作用GetTriggerDelegateOnMatchingKey()会先校验传入 enableKey 的长度是否为TestEventTriggerDelegate::kEnableKeyLength即 16 字节不匹配直接拒绝。也就是说任何 TestEventTrigger 调用都会先经过密钥长度 密钥内容双重校验只有与设备注册的 enable key 一致的请求才会被分发到真正的 handler。使用方法使用 TestEventTriggers 只需三步从TestEventTriggerHandler派生自己的处理器类实现HandleEventTrigger函数签名virtual CHIP_ERROR HandleEventTrigger(uint64_t eventTrigger) 0;通过TestEventTriggerDelegate::AddHandler注册到委托中。这三个步骤对应的核心类型全部定义在 TestEventTriggerDelegate.h 中其设计要点包括TestEventTriggerHandler继承IntrusiveListNodeBase因此可以以侵入式链表方式被多个 handler 串联管理TestEventTriggerDelegate::HandleEventTriggers()的默认实现会遍历所有已注册 handler逐个调用其HandleEventTrigger()直到某个 handler 返回CHIP_NO_ERROR为止如果全部返回错误则最终返回最后一个错误默认初值为CHIP_ERROR_INVALID_ARGUMENT。若需要更特殊的调度行为可以完全覆写此方法AddHandler/RemoveHandler/ClearAllHandlers提供了运行时的注册与注销能力还提供了开箱即用的SimpleTestEventTriggerDelegate它在 RAM 中持有 enable key通过Init(ByteSpan enableKey)注入密钥要求长度恰好等于 16 字节否则返回CHIP_ERROR_INVALID_ARGUMENT并用DoesEnableKeyMatch()做常量时间安全的比对。参考示例EnergyEvseTestEventTriggerHandler社区推荐的经典实现是 EnergyEvseTestEventTriggerHandler。该 handler 位于 energy-evse-server 集群中演示了如何把 trigger code 解码为具体的设备行为例如让 EV 充电桩进入某种测试状态是理解trigger code → 设备动作映射的绝佳范本。NamedPipes用命名管道在 Linux 应用上模拟手动操作用途NamedPipes 用于在Linux 应用上触发动作主要服务于 CI 集成测试。任何测试中需要人工完成的动作例如按一下按钮都应该有对应的 NamedPipe 动作从而让整个测试流程可以在 CI 中无人值守地自动运行。工作机制与使用方法命名管道的使用方式如下从NamedPipeCommandDelegate派生委托类实现OnEventCommandReceived(const char * json)函数——注意参数是 JSON 字符串即命令以 JSON 形式传入实例化并启动一个NamedPipeCommands对象传入上面实现的委托和一个文件路径基础名base name在应用运行期间向(baseName)_pid命名的文件写入内容即可触发对应动作。关于第 4 步需要特别说明管道文件名带有进程号后缀因此在多进程/多实例场景下测试端需要知道目标应用的 PID 才能定位到正确的管道文件。Python 测试中的接入在 Python 测试中访问命名管道所需的 app-pid 可以通过--app-pid命令行标志传入测试框架据此拼接出实际的管道文件路径。仓库内的实现佐证原文档引用的examples/platform/linux/NamedPipeCommands.h在当前仓库中位于子模块/依赖中但仓库内 all-devices-app 的命名管道实现 完整呈现了这一模式的现代形态Dispatcher类继承NamedPipeCommandDelegate覆写了OnEventCommandReceived(const char * json)它在内部持有NamedPipeCommands mNamedPipeCommands成员并提供Start(const char * fifoPath)/Stop()来启动/停止对 FIFO 的监听与清理引入CommandTranslator命令翻译器机制每个 translator 通过GetActionNames()暴露它支持的动作名集合RegisterTranslator/EnsureTranslatorRegistered将动作名注册到分发表DispatchJson()负责把收到的 JSON 命令解析并路由到对应 translator。这印证了委托接口 JSON 命令 动作分发是当前仓库命名管道功能的标准架构新增设备类型时只需实现对应的 translator 并注册动作名即可。测试用例参考RVC Clean ModeRVC Clean Mode 测试用例 TC_RVCCLEANM_2_1.py 展示了在真实 Python 集成测试中如何使用命名管道——它是学习测试端如何通过管道驱动 DUT 执行清扫模式等动作的完整范例。Fault Injection运行时注入条件错误路径用途Fault injection 用于在运行时注入条件性代码路径例如人为制造错误。它对于客户端测试尤其有价值可以验证客户端对某些在正常工况下极难触发的错误路径网络丢包、会话繁忙、消息损坏等的错误处理是否健壮。框架与编译开关当前使用的故障注入框架是nlFaultInjection。其工作方式为通过一个宏注入故障代码路径若编译时关闭该功能宏会被替换为no-op空操作完全不产生代码对应的构建选项是chip_with_nlfaultinjection。这一点在 CHIPFaultInjection.h 中有最直接的体现当CHIP_WITH_NLFAULTINJECTION未定义时CHIP_FAULT_INJECT、CHIP_FAULT_INJECT_WITH_ARGS、CHIP_FAULT_INJECT_MAX_ARG全部被定义为空仅当该宏开启时才展开为nlFAULT_INJECT(...)等真实调用。因此故障注入对发布构建是零开销的。故障管理器Manager体系nlFaultInjection 允许应用定义多个 manager。SDK 内建三个Manager覆盖层次适用场景System系统层src/system定时器、系统事件等底层故障Inet网络层src/inetUDP 收发、套接字相关故障CHIP系统层之上src/lib及所有集群所有新的集群开发都应使用 CHIP其中 CHIP 故障管理器定义于 lib/support/CHIPFaultInjection.h也是日常集群开发中打交道最多的一个。预置的故障点Fault IDCHIPFaultInjection.h通过 X-Macro 风格枚举CHIP_FAULTS_ENUMERATE集中定义了 38 个内置故障点及其数值 ID节选如下ID 值枚举名含义0kFault_AllocExchangeContext使 ExchangeContext 分配失败1kFault_DropIncomingUDPMsg丢弃收到的 UDP 消息2kFault_DropOutgoingUDPMsg在消息层丢弃发出的 UDP 消息3kFault_AllocBinding使 Binding 分配失败12kFault_IMInvoke_SeparateResponses对两条 InvokeRequest 命令分两条响应返回13kFault_IMInvoke_SeparateResponsesInvertResponseOrder两条 InvokeResponse 按请求相反顺序返回14kFault_IMInvoke_SkipSecondResponse响应两条命令但丢弃第二条响应17kFault_CASEServerBusy对 CASE_Sigma1 响应 BUSY 状态18–27kFault_CASESkip*/kFault_CASECorrupt*CASE 握手各字段的省略与破坏34–37kFault_ClearInMemoryAllocated*Streams等视频/音频/快照流与相机属性相关故障源码中通过static_assert固化了多个 ID 的取值如 12、13、14、15、16、32–37因为测试计划与自动化代码依赖这些固定数值。同样重要的是文件头注释明确警告修改此枚举时必须同步更新 Python 模块src/controller/python/matter/fault_injection/__init__.py中的CHIPFaultId枚举保证 C 与 Python 侧 ID 一致。添加新的故障注入代码路径为新增一个故障注入点只需两步在CHIPFaultInjection.h的CHIP_FAULTS_ENUMERATE宏中添加新的X(名称, ID)项注意避开已有 ID在希望发生故障的代码位置插入CHIP_FAULT_INJECT(aFaultID, aStatements)宏——当该故障被启用时执行aStatements未启用时不产生任何代码。官方示例代码原文档给出的CASEServer::OnMessageReceived示例展示了最小用法——在会话繁忙判断前注入故障把busy强制置为 trueCHIP_ERROR CASEServer::OnMessageReceived(Messaging::ExchangeContext * ec, const PayloadHeader payloadHeader, System::PacketBufferHandle payload) { MATTER_TRACE_SCOPE(OnMessageReceived, CASEServer); bool busy GetSession().GetState() ! CASESession::State::kInitialized; CHIP_FAULT_INJECT(FaultInjection::kFault_CASEServerBusy, busy true); if (busy) { // ... 后续繁忙处理逻辑 } }在真实源码中该模式被大量使用并且还提供了两个更高级的宏CHIP_FAULT_INJECT_WITH_ARGS(aFaultID, aProtectedStatements, aUnprotectedStatements)区分持锁/不持锁执行的分支aProtectedStatements在持有 Manager 锁时执行aUnprotectedStatements在不持锁时执行适合多线程安全要求高的场景CHIP_FAULT_INJECT_MAX_ARG(aFaultID, aMaxArg, ...)若该故障尚未存储参数则自动把aMaxArg存入故障记录供后续参数化故障如报文头 fuzz 的FuzzExchangeHeader使用。Fault Injection 集群0xFFF1FC06故障注入已经通过一个制造商特定manufacturer-specific集群在 SDK 中贯通可通过标准集群机制在测试中开关故障注入。该集群 ID 为0xFFF1FC06其数据结构定义见 fault-injection-cluster.xml服务端实现在 fault-injection-server.cpp。示例应用可以编译进该集群用于客户端侧的认证测试与集成测试。集群先定义了FaultType枚举值名称对应 Manager0x00Unspecified—0x01SystemFaultchip::System::FaultInjection::GetManager()0x02InetFaultchip::Inet::FaultInjection::GetManager()0x03ChipFaultchip::FaultInjection::GetManager()0x04CertFault—集群提供两条客户端命令FailAtFaultcode 0x00——确定性触发参数如下与原文档一致TypeFaultType选择故障所属 Manager通常使用FaultType::kChipFault0x03Idint32u与你在CHIP_FAULTS_ENUMERATE中设置好的故障 ID 对应NumCallsToSkipint32u先正常运行的次数NumCallsToFailint32u在跳过NumCallsToSkip次之后命中故障注入条件的次数TakeMutexbool控制对故障注入 Manager 的访问面向多线程系统。False即可。在 服务端实现 中可以看到其处理细节GetFaultInjectionManager(type)把FaultType映射到 System / Inet / CHIP 三个 Manager随后调用faultInjectionMgr-FailAtFault(id, numCallsToSkip, numCallsToFail, takeMutex)若传入非法输入返回InvalidCommandManager 不存在返回Failure当编译期未开启CHIP_WITH_NLFAULTINJECTION时命令直接返回UnsupportedCommand。FailRandomlyAtFaultcode 0x01——随机触发参数为TypeFaultType同上Idint32u故障 IDPercentageint8u以百分比表示的概率。服务端会对percentage 100的情况返回InvalidCommand。值得注意的是集群 XML 中两条命令的访问控制均为rolemanage意味着调用方需要具备管理权限。原文档同时给出了认证测试的安全建议对于认证测试推荐使用第二个非 DUT 控制器secondary, non-DUT controller来操作该集群即让测试端而非被测试设备自身去启停故障注入。小结三类工具的分工与选型工具触发方式典型场景关键开关/参数TestEventTriggersGeneral Diagnostics 集群TestEventTrigger命令test key trigger code认证测试中难以手动执行的动作enable key默认 16 字节全零必须认证测试外关闭NamedPipes向(baseName)_pid文件写入 JSON 命令Linux 应用的 CI 自动化替代人工操作--app-pid、文件路径 base nameFault InjectionnlFaultInjection 宏 Fault Injection 集群0xFFF1FC06命令客户端错误处理测试、协议异常路径chip_with_nlfaultinjection构建开关、FailAtFault/FailRandomlyAtFault三者共同遵循同一原则把测试动作/错误注入在覆盖最多真实代码路径的位置。TestEventTriggers 适合模拟事件NamedPipes 适合模拟人工操作Fault Injection 适合模拟故障组合使用即可在 CI 与认证环境中获得对设备行为的完整可控性。深入阅读 TestEventTriggerDelegate.h、CHIPFaultInjection.h、fault-injection-cluster.xml 与 TC_RVCCLEANM_2_1.py可以进一步掌握这些工具的完整接入细节。【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeip创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Matter 集成测试工具全解析：TestEventTriggers、NamedPipes 与 nlFaultInjection 故障注入实战指南
Matter 集成测试工具全解析TestEventTriggers、NamedPipes 与 nlFaultInjection 故障注入实战指南【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeip本文系统梳理 connectedhomeipMatter SDK为集成测试提供的一组关键测试工具——TestEventTriggers测试事件触发、NamedPipes命名管道与 Fault Injection故障注入。它们分别用于在认证测试中模拟难以手动执行的设备动作如触发烟雾报警、在 CI 中自动替代人工操作如按键、以及在客户端测试中注入难以自然出现的错误路径。阅读本文后你将掌握这三类工具的接入方式、调用链路与源码级实现原理能够在自己开发的 Matter 应用与测试用例中正确使用它们。核心原则在尽可能深的代码路径注入错误在深入工具细节之前必须先明确使用这些测试工具的第一原则注入错误的位置应当尽量选择能覆盖最多代码路径的点。以采用 ClusterLogic 模式 的集群为例正确的做法是把错误注入在尽可能靠近驱动层driver layer的位置而不是在服务器端server捕获错误后再模拟失败。这样被测试的代码路径才是真实业务路径测试结果才有意义——错误在底层被注入后会沿着真实的调用链一路向上传播服务器、交互模型层乃至客户端都能以真实路径验证各自的错误处理逻辑。TestEventTriggers认证测试中的事件触发用途与使用限制TestEventTriggers 用于测试在认证certification测试中难以实际执行的 DUT 交互例如触发烟雾报警、模拟极端环境事件等。由于这类操作往往会真实地改变设备状态甚至带来危险文档明确强调两点约束务必克制使用These should be used sparingly!——它不是常规测试手段而是针对难以覆盖场景的补充工具认证测试之外必须关闭——所有 TestEventTriggers 都需要在非认证场景下被禁用避免生产/常规测试环境中留下可被任意触发的后门。工作机制TestEventTriggers 通过General Diagnostics通用诊断集群中的TestEventTrigger命令启动。命令携带两个关键参数test key测试密钥用于鉴权防止未授权触发。目前大多数设备使用一个默认 key但特定设备可以按需覆盖通过DoesEnableKeyMatch实现自定义校验trigger code触发码uint64_t类型的编码向设备请求执行某个具体动作。从 General Diagnostics 集群实现 可以确认其底层校验逻辑IsTestEventTriggerEnabled()会调用testEventTriggerDelegate-DoesEnableKeyMatch()用全零的 16 字节 key 与设备配置的 key 比对——如果设备仍使用全零默认 key说明触发功能未配置真实密钥此时判定触发未启用起到保护作用GetTriggerDelegateOnMatchingKey()会先校验传入 enableKey 的长度是否为TestEventTriggerDelegate::kEnableKeyLength即 16 字节不匹配直接拒绝。也就是说任何 TestEventTrigger 调用都会先经过密钥长度 密钥内容双重校验只有与设备注册的 enable key 一致的请求才会被分发到真正的 handler。使用方法使用 TestEventTriggers 只需三步从TestEventTriggerHandler派生自己的处理器类实现HandleEventTrigger函数签名virtual CHIP_ERROR HandleEventTrigger(uint64_t eventTrigger) 0;通过TestEventTriggerDelegate::AddHandler注册到委托中。这三个步骤对应的核心类型全部定义在 TestEventTriggerDelegate.h 中其设计要点包括TestEventTriggerHandler继承IntrusiveListNodeBase因此可以以侵入式链表方式被多个 handler 串联管理TestEventTriggerDelegate::HandleEventTriggers()的默认实现会遍历所有已注册 handler逐个调用其HandleEventTrigger()直到某个 handler 返回CHIP_NO_ERROR为止如果全部返回错误则最终返回最后一个错误默认初值为CHIP_ERROR_INVALID_ARGUMENT。若需要更特殊的调度行为可以完全覆写此方法AddHandler/RemoveHandler/ClearAllHandlers提供了运行时的注册与注销能力还提供了开箱即用的SimpleTestEventTriggerDelegate它在 RAM 中持有 enable key通过Init(ByteSpan enableKey)注入密钥要求长度恰好等于 16 字节否则返回CHIP_ERROR_INVALID_ARGUMENT并用DoesEnableKeyMatch()做常量时间安全的比对。参考示例EnergyEvseTestEventTriggerHandler社区推荐的经典实现是 EnergyEvseTestEventTriggerHandler。该 handler 位于 energy-evse-server 集群中演示了如何把 trigger code 解码为具体的设备行为例如让 EV 充电桩进入某种测试状态是理解trigger code → 设备动作映射的绝佳范本。NamedPipes用命名管道在 Linux 应用上模拟手动操作用途NamedPipes 用于在Linux 应用上触发动作主要服务于 CI 集成测试。任何测试中需要人工完成的动作例如按一下按钮都应该有对应的 NamedPipe 动作从而让整个测试流程可以在 CI 中无人值守地自动运行。工作机制与使用方法命名管道的使用方式如下从NamedPipeCommandDelegate派生委托类实现OnEventCommandReceived(const char * json)函数——注意参数是 JSON 字符串即命令以 JSON 形式传入实例化并启动一个NamedPipeCommands对象传入上面实现的委托和一个文件路径基础名base name在应用运行期间向(baseName)_pid命名的文件写入内容即可触发对应动作。关于第 4 步需要特别说明管道文件名带有进程号后缀因此在多进程/多实例场景下测试端需要知道目标应用的 PID 才能定位到正确的管道文件。Python 测试中的接入在 Python 测试中访问命名管道所需的 app-pid 可以通过--app-pid命令行标志传入测试框架据此拼接出实际的管道文件路径。仓库内的实现佐证原文档引用的examples/platform/linux/NamedPipeCommands.h在当前仓库中位于子模块/依赖中但仓库内 all-devices-app 的命名管道实现 完整呈现了这一模式的现代形态Dispatcher类继承NamedPipeCommandDelegate覆写了OnEventCommandReceived(const char * json)它在内部持有NamedPipeCommands mNamedPipeCommands成员并提供Start(const char * fifoPath)/Stop()来启动/停止对 FIFO 的监听与清理引入CommandTranslator命令翻译器机制每个 translator 通过GetActionNames()暴露它支持的动作名集合RegisterTranslator/EnsureTranslatorRegistered将动作名注册到分发表DispatchJson()负责把收到的 JSON 命令解析并路由到对应 translator。这印证了委托接口 JSON 命令 动作分发是当前仓库命名管道功能的标准架构新增设备类型时只需实现对应的 translator 并注册动作名即可。测试用例参考RVC Clean ModeRVC Clean Mode 测试用例 TC_RVCCLEANM_2_1.py 展示了在真实 Python 集成测试中如何使用命名管道——它是学习测试端如何通过管道驱动 DUT 执行清扫模式等动作的完整范例。Fault Injection运行时注入条件错误路径用途Fault injection 用于在运行时注入条件性代码路径例如人为制造错误。它对于客户端测试尤其有价值可以验证客户端对某些在正常工况下极难触发的错误路径网络丢包、会话繁忙、消息损坏等的错误处理是否健壮。框架与编译开关当前使用的故障注入框架是nlFaultInjection。其工作方式为通过一个宏注入故障代码路径若编译时关闭该功能宏会被替换为no-op空操作完全不产生代码对应的构建选项是chip_with_nlfaultinjection。这一点在 CHIPFaultInjection.h 中有最直接的体现当CHIP_WITH_NLFAULTINJECTION未定义时CHIP_FAULT_INJECT、CHIP_FAULT_INJECT_WITH_ARGS、CHIP_FAULT_INJECT_MAX_ARG全部被定义为空仅当该宏开启时才展开为nlFAULT_INJECT(...)等真实调用。因此故障注入对发布构建是零开销的。故障管理器Manager体系nlFaultInjection 允许应用定义多个 manager。SDK 内建三个Manager覆盖层次适用场景System系统层src/system定时器、系统事件等底层故障Inet网络层src/inetUDP 收发、套接字相关故障CHIP系统层之上src/lib及所有集群所有新的集群开发都应使用 CHIP其中 CHIP 故障管理器定义于 lib/support/CHIPFaultInjection.h也是日常集群开发中打交道最多的一个。预置的故障点Fault IDCHIPFaultInjection.h通过 X-Macro 风格枚举CHIP_FAULTS_ENUMERATE集中定义了 38 个内置故障点及其数值 ID节选如下ID 值枚举名含义0kFault_AllocExchangeContext使 ExchangeContext 分配失败1kFault_DropIncomingUDPMsg丢弃收到的 UDP 消息2kFault_DropOutgoingUDPMsg在消息层丢弃发出的 UDP 消息3kFault_AllocBinding使 Binding 分配失败12kFault_IMInvoke_SeparateResponses对两条 InvokeRequest 命令分两条响应返回13kFault_IMInvoke_SeparateResponsesInvertResponseOrder两条 InvokeResponse 按请求相反顺序返回14kFault_IMInvoke_SkipSecondResponse响应两条命令但丢弃第二条响应17kFault_CASEServerBusy对 CASE_Sigma1 响应 BUSY 状态18–27kFault_CASESkip*/kFault_CASECorrupt*CASE 握手各字段的省略与破坏34–37kFault_ClearInMemoryAllocated*Streams等视频/音频/快照流与相机属性相关故障源码中通过static_assert固化了多个 ID 的取值如 12、13、14、15、16、32–37因为测试计划与自动化代码依赖这些固定数值。同样重要的是文件头注释明确警告修改此枚举时必须同步更新 Python 模块src/controller/python/matter/fault_injection/__init__.py中的CHIPFaultId枚举保证 C 与 Python 侧 ID 一致。添加新的故障注入代码路径为新增一个故障注入点只需两步在CHIPFaultInjection.h的CHIP_FAULTS_ENUMERATE宏中添加新的X(名称, ID)项注意避开已有 ID在希望发生故障的代码位置插入CHIP_FAULT_INJECT(aFaultID, aStatements)宏——当该故障被启用时执行aStatements未启用时不产生任何代码。官方示例代码原文档给出的CASEServer::OnMessageReceived示例展示了最小用法——在会话繁忙判断前注入故障把busy强制置为 trueCHIP_ERROR CASEServer::OnMessageReceived(Messaging::ExchangeContext * ec, const PayloadHeader payloadHeader, System::PacketBufferHandle payload) { MATTER_TRACE_SCOPE(OnMessageReceived, CASEServer); bool busy GetSession().GetState() ! CASESession::State::kInitialized; CHIP_FAULT_INJECT(FaultInjection::kFault_CASEServerBusy, busy true); if (busy) { // ... 后续繁忙处理逻辑 } }在真实源码中该模式被大量使用并且还提供了两个更高级的宏CHIP_FAULT_INJECT_WITH_ARGS(aFaultID, aProtectedStatements, aUnprotectedStatements)区分持锁/不持锁执行的分支aProtectedStatements在持有 Manager 锁时执行aUnprotectedStatements在不持锁时执行适合多线程安全要求高的场景CHIP_FAULT_INJECT_MAX_ARG(aFaultID, aMaxArg, ...)若该故障尚未存储参数则自动把aMaxArg存入故障记录供后续参数化故障如报文头 fuzz 的FuzzExchangeHeader使用。Fault Injection 集群0xFFF1FC06故障注入已经通过一个制造商特定manufacturer-specific集群在 SDK 中贯通可通过标准集群机制在测试中开关故障注入。该集群 ID 为0xFFF1FC06其数据结构定义见 fault-injection-cluster.xml服务端实现在 fault-injection-server.cpp。示例应用可以编译进该集群用于客户端侧的认证测试与集成测试。集群先定义了FaultType枚举值名称对应 Manager0x00Unspecified—0x01SystemFaultchip::System::FaultInjection::GetManager()0x02InetFaultchip::Inet::FaultInjection::GetManager()0x03ChipFaultchip::FaultInjection::GetManager()0x04CertFault—集群提供两条客户端命令FailAtFaultcode 0x00——确定性触发参数如下与原文档一致TypeFaultType选择故障所属 Manager通常使用FaultType::kChipFault0x03Idint32u与你在CHIP_FAULTS_ENUMERATE中设置好的故障 ID 对应NumCallsToSkipint32u先正常运行的次数NumCallsToFailint32u在跳过NumCallsToSkip次之后命中故障注入条件的次数TakeMutexbool控制对故障注入 Manager 的访问面向多线程系统。False即可。在 服务端实现 中可以看到其处理细节GetFaultInjectionManager(type)把FaultType映射到 System / Inet / CHIP 三个 Manager随后调用faultInjectionMgr-FailAtFault(id, numCallsToSkip, numCallsToFail, takeMutex)若传入非法输入返回InvalidCommandManager 不存在返回Failure当编译期未开启CHIP_WITH_NLFAULTINJECTION时命令直接返回UnsupportedCommand。FailRandomlyAtFaultcode 0x01——随机触发参数为TypeFaultType同上Idint32u故障 IDPercentageint8u以百分比表示的概率。服务端会对percentage 100的情况返回InvalidCommand。值得注意的是集群 XML 中两条命令的访问控制均为rolemanage意味着调用方需要具备管理权限。原文档同时给出了认证测试的安全建议对于认证测试推荐使用第二个非 DUT 控制器secondary, non-DUT controller来操作该集群即让测试端而非被测试设备自身去启停故障注入。小结三类工具的分工与选型工具触发方式典型场景关键开关/参数TestEventTriggersGeneral Diagnostics 集群TestEventTrigger命令test key trigger code认证测试中难以手动执行的动作enable key默认 16 字节全零必须认证测试外关闭NamedPipes向(baseName)_pid文件写入 JSON 命令Linux 应用的 CI 自动化替代人工操作--app-pid、文件路径 base nameFault InjectionnlFaultInjection 宏 Fault Injection 集群0xFFF1FC06命令客户端错误处理测试、协议异常路径chip_with_nlfaultinjection构建开关、FailAtFault/FailRandomlyAtFault三者共同遵循同一原则把测试动作/错误注入在覆盖最多真实代码路径的位置。TestEventTriggers 适合模拟事件NamedPipes 适合模拟人工操作Fault Injection 适合模拟故障组合使用即可在 CI 与认证环境中获得对设备行为的完整可控性。深入阅读 TestEventTriggerDelegate.h、CHIPFaultInjection.h、fault-injection-cluster.xml 与 TC_RVCCLEANM_2_1.py可以进一步掌握这些工具的完整接入细节。【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeip创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
