在LDRA的工作流里，单元测试失败不是只看一个红色结果就结束，真正要看的是失败到底落在测试向量、预期结果、桩代码、运行环境，还是覆盖与结果采集这一层。LDRA官方资料把这条链讲得很清楚，TBrun负责单元与集成测试的生成、执行和管理，TBvision负责把静态与动态分析结果、覆盖率和代码结构放回源码上下文里看，而整个LDRA tool suite又把测试结果、覆盖数据和需求追踪连在一起。也就是说，失败定位不能只盯一次执行结果，要顺着执行链往回看。

　　一、Testbed单元测试失败怎么看

　　单元测试失败时，先别急着改代码，先把失败类型分清。LDRA官方资料说明，TBrun自动生成并执行单元与集成测试，测试过程中会同时带出覆盖数据和结果采集信息；另一份技术资料还提到，TBrun构建测试夹具时会基于过程调用、单元接口、参数、返回值和数据流自动生成harness与stubs。换句话说，失败不一定是被测函数逻辑错了，也可能是测试夹具、外部依赖替身或输入向量本身就没配对。

　　1、先看是执行失败还是结果失败

　　如果测试根本没有正常跑完，更像是编译、链接、目标连接或运行环境问题。要是测试能跑完，但实际结果和预期结果不一致，那才更像是功能逻辑、测试向量或桩行为的问题。LDRA官方把TBrun定义成测试执行与管理组件，而不是单纯报告工具，这说明先分清“没跑起来”还是“跑起来但没过”很重要。

　　2、再看测试向量和预期输出

　　LDRA关于单元与集成测试的公开说明提到，测试是靠test vectors驱动的，而且输入和expected outputs通常来自需求。也就是说，只要输入向量设错，或者预期结果本身写偏，测试一样会失败，而且这种失败看起来很像代码错误。先回查这一层，通常比直接改实现更稳。

　　3、再查自动生成的stubs和harness

　　LDRA官方资料明确写到，单元与集成测试的harness会基于静态分析自动构建，函数、方法、构造函数等也会自动stub。对测试失败来说，这意味着外部依赖的替身行为、返回值和调用路径都可能影响结果。特别是接口复杂、依赖多的代码，先看stub行为是否符合本次测试预期，很有必要。

　　4、最后看覆盖率与未执行路径

　　官方白皮书说明，动态分析和覆盖数据可以帮助你识别哪些路径已经被执行，哪些路径仍未覆盖。要是断言失败只出现在某条边界路径，或者一部分代码根本没被当前测试打到，那就不能只盯失败点本身，还要回头看这次测试是不是把目标路径真正跑到了。

　　二、Testbed断言与日志怎么定位

　　在LDRA的公开资料里，虽然不一定都直接用“断言”这个词去描述每一种检查，但它的单元测试机制本质上就是围绕输入、预期输出、结果采集和覆盖数据来定位偏差。LDRA官方关于单元测试的说明提到，测试向量、代码桩和结果采集都在同一条执行链里；而关于动态分析的资料又明确指出，当前测试运行会生成变量和参数使用报告，并标出对应文件和位置。对定位断言失败来说，这两层信息最有价值。

　　1、先从当前测试运行的结果采集信息看起

　　LDRA官方多处资料都提到result-capture support，也就是说，测试执行后首先要看的不是抽象“失败”，而是这次运行到底采集到了什么输入输出结果。只要把当前测试向量和采集到的结果对起来，很多失败会先暴露在数据层，而不是逻辑层。

　　2、变量和参数日志优先看当前运行上下文

　　官方文章明确提到，动态分析会生成基于当前test run的variable和parameter usage报告，而且会高亮文件和具体位置。这个信息很适合拿来排查“断言为什么没成立”，因为它能帮助你先确认关键变量有没有按预期被赋值、传递和使用。

　　3、覆盖图和流程图用来判断失败是不是卡在路径上

　　TBvision和LDRA的覆盖能力不仅给覆盖率数字，还能通过call graph、procedure flow graph和coverage reports把代码路径可视化。实际排查时，如果断言失败只在某个分支出现，或者某个分支根本没执行到，这类图形化结果会比只看一条失败记录更容易定位。

　　4、边界类失败要回看输入区间

　　LDRA的白皮书明确提到，单元测试常用于边界值和范围测试，输入边界与变量边界本身就可能暴露运行时错误。也就是说，若失败集中出现在边界值测试，不要只看断言表达式本身，更要回头查测试数据是不是刚好踩中了实现的极限条件。

　　三、Testbed失败定位顺序怎么收

　　很多团队后面定位越来越慢，不是因为LDRA工具不够，而是把测试结果、日志、覆盖和桩代码混着看。更稳的做法，是按固定顺序来。先看这次测试有没有正常执行，再看测试向量和预期输出，再看stub与harness，最后把日志和覆盖图放回源码上下文里核对。LDRA官方对工具分工本身就是这样设计的，TBrun负责执行与管理，TBvision负责结果可视化，整个工具链再把测试、覆盖和追踪连起来。

　　1、先确认执行链没断

　　测试没有真正执行成功时，后面的断言结论通常都不可靠。先分清是运行失败还是校验失败，能少走很多弯路。

　　2、再确认测试数据没写偏

　　输入向量和expected outputs都来自测试设计，如果这层有偏差，失败看起来会很像代码逻辑错。

　　3、然后确认替身和依赖没带偏结果

　　自动生成的harness和stubs本来就是单元测试的一部分，尤其是依赖复杂时，这层必须查。

　　4、最后把日志和覆盖放回源码上下文

　　变量参数使用报告、流程图和覆盖图一旦和源码位置对上，失败点通常会比单看一条测试记录清楚得多。

　　总结

　　Testbed单元测试失败怎么看，关键不是只盯测试结果是红还是绿，而是先把执行失败、结果失败、测试向量问题和依赖替身问题分开。Testbed断言与日志怎么定位，重点则是从当前运行的结果采集、变量参数使用报告、覆盖路径和源码上下文一起看。把执行、数据、替身和路径这四层按顺序收起来，Testbed里的失败定位通常会快很多。