很多人看到C/C++test单元测试失败，第一反应是去翻测试代码，结果越看越乱。真正更稳的做法，是先把失败分成两类，一类是断言失败，说明测试跑到了校验点但结果和预期不一致；另一类是测试错误，说明执行过程中就已经异常中断。Parasoft的结果查看逻辑本来就是围绕这两类问题展开的，核心入口在【Test Progress】、【Quality Tasks】、【Test Case Explorer】和【Console】这几处，先把入口看对，后面定位会快很多。

　　一、C/C++test单元测试失败怎么看

　　单元测试失败时，不要一上来只盯红叉。C/C++test的结果视图本身就把“哪个测试失败了”“失败落在哪一行”“是断言失败还是执行报错”拆开呈现，只要按顺序往下看，通常很快就能把范围缩到具体测试点。

　　1、先看【Test Progress】里的本次执行结果

　　测试运行时，【Test Progress】会显示当前执行状态，跑完后可以直接点【Review tasks】把结果切到【Quality Tasks】。这一步的意义在于先确认本次到底是静态分析问题、单元测试失败，还是执行链路本身报错，不要把不同类别的问题混在一起。

　　2、再到【Quality Tasks】里分清失败类型

　　【Quality Tasks】会把结果按任务形式列出来，适合先看哪条测试失败、失败信息是什么、有没有堆栈线索。Parasoft还支持对某条任务右键查看触发它的Test Configuration，这对判断是不是执行配置、桩配置或运行方式导致的问题很有用。

　　3、用【Test Case Explorer】回到具体测试用例

　　【Test Case Explorer】会把失败路径整条标红，右键测试节点还能用【Show in Tasks】把相关任务带回【Quality Tasks】。这一步特别适合在一个测试套件里有多个用例同时跑时使用，因为它能先告诉你到底是哪一个case失败，而不是让你在整份结果里来回翻。

　　4、最后落到源代码行上确认

　　Parasoft文档说明，单元测试错误会根据堆栈把标记落到对应源代码行上；如果是失败但没有直接命中被测类，也会尽量落到单元测试类匹配到的首行。你可以直接双击带行号的节点，或者在编辑器里通过标记回到触发问题的位置，这样比手工搜函数名更直接。

　　二、C/C++test断言与日志如何定位

　　断言和日志是定位单元测试失败最实用的两条线。前者解决“预期和实际差在哪”，后者解决“测试执行到哪一步开始跑偏”。这两条线一起看，通常比只看一条失败摘要更有效。

　　1、先用断言本身的返回信息缩小范围

　　Parasoft的多种断言宏在失败时会直接报告expected和actual，例如整数、字符串、内存缓冲区、指针等常用比较都支持把两边值带出来。这意味着如果你看到的是典型比较型失败，第一步不是重跑，而是先看这两个值有没有明显偏差方向。

　　2、需要更多上下文时优先用带消息的断言

　　很多断言宏都有带【MESSAGE】的版本，可以在失败时附带自定义说明。这样做的价值不只是“多一行文字”，而是能把当前场景、输入分支、边界条件直接写进失败信息里，后面在【Quality Tasks】里回看时，不必再反推这条断言原本想验证什么。

　　3、想看执行过程就打开【Console】

　　Parasoft说明里写得很清楚，测试执行期间的细节会持续输出到【Console】里，运行结束后也会保留，直到你清空或下一轮测试覆盖它。如果你现在的问题不是“值不对”，而是“测试跑到哪里停了”，那【Console】通常比最终结果摘要更有用。

　　4、日志太少时把控制台详细级别调高

　　如果默认输出看不够，可以到【Parasoft】【Preferences】里的【Console】调整verbosity。官方给出的说明是，高级别会输出更多警告、命令行和执行中的违规信息，低级别则会压缩显示。定位单元测试失败时，日志太少往往不是程序没报，而是控制台级别压得太低。

　　5、需要留证据时把详细报告一起开出来

　　如果你希望把断言、任务细节和执行明细单独留存，可以到【Parasoft】【Test Configurations】里打开对应配置，再到【Execution】【Runtime】勾选【Report unit test execution details】、【Include tasks details】、【Include passed assertion details】和【Generate detailed test execution report】。这样生成的HTML或XML明细报告，会比普通结果页更适合复盘和流转。

　　三、C/C++test定位失败先查哪里

　　很多人不是不会看结果，而是没有顺序，最后把断言问题、配置问题和执行问题搅到一起。更稳的办法，是固定一条排查顺序，让每一步都只解决一个问题。

　　1、先确认失败的是哪一个测试用例

　　先用【Test Case Explorer】确认具体case，再回【Quality Tasks】看失败摘要。这样可以先把问题锁在一个最小单元里，避免在整个测试套件上盲查。

　　2、再确认是断言失败还是执行错误

　　如果是expected和actual不一致，就优先看断言本身和测试输入；如果是执行中断、堆栈跳转异常或根本没跑到断言，那就先看【Console】和源码标记。两类问题处理方法完全不同，不应混在一起。

　　3、再去核对执行配置

　　Parasoft的测试运行依赖Test Configuration，里面不仅控制测试生成，也控制执行与报告细节。定位时如果发现相同测试在不同配置下表现不一致，就要回头查是不是执行配置、运行时选项或报告选项不同，而不是直接改测试逻辑。

　　4、最后再补强断言和日志

　　当你已经找到问题段落后，再回过头给关键断言加消息、给关键路径保留控制台细节或详细报告，后面同类问题会更容易复现和复盘。Parasoft本身就支持把执行细节和断言结果纳入报告，所以这一步不是补救，而是把未来排查成本提前降下来。

　　总结

　　C/C++test单元测试失败怎么看，关键不是一看到失败就回代码海里乱翻，而是先用【Test Progress】、【Quality Tasks】和【Test Case Explorer】把失败用例、失败类型和代码位置串起来。C/C++test断言与日志如何定位，核心也不是单看一条报错，而是把expected和actual、带消息断言、【Console】输出和详细执行报告一起用起来。顺着这条线排，很多原本看上去很乱的单元测试失败，最后都会落到一个具体断言、一个具体输入，或者一段很明确的执行路径上。