Cantata

单元测试执行完成，报告里却只有一个覆盖率百分比，找不到未执行的分支，也看不出哪些用例贡献了覆盖。这类报告用于日常查看还算方便，交给评审人员时就会遇到问题。Cantata的覆盖率采集、结果展示和报告生成分属不同环节，缺少明细时，要确认数据有没有采到，再检查报告是否选对了范围。

测试程序已经编译通过，下载到板卡却无法启动；换了部署配置，执行时又像是跑了旧程序。遇到这些情况，要把构建、下载、启动和结果回传分别核对。Cantata的目标部署包含配套的库和配置选项，编译器路径正确，只解决了其中一部分。真正需要对齐的是：本次生成了什么程序，由哪套脚本加载，又在哪个环境中执行。

测试已经运行，覆盖率却仍显示未达标，先别急着增加用例。Cantata的覆盖目标由覆盖规则集确定；规则集选错、目标数值填错，或者查看结果时筛选了错误的构建变体，都可能让结果与预期不一致。下面按设置、核对、调整的顺序操作。

Cantata执行单元测试或集成测试后，可以继续查看代码被测试用例实际执行到什么程度。覆盖率结果并不只有一个百分比，还会按语句、判定、条件、MC/DC等不同指标分别统计。测试已经运行成功，但覆盖率里少了某些函数、某些源码文件没有数据，或者多个测试脚本的结果没有合在一起时，先分清是代码没有执行到、插桩范围缺失，还是当前查看的覆盖数据没有选全，处理起来会清楚很多。

Cantata测试脚本可以在主机环境中编写，再使用目标编译器构建为适配目标板的测试程序。真正影响执行成败的环节不只是脚本本身，还包括部署库、下载方式、启动命令和结果回传通道。处理Cantata怎么执行目标板测试Cantata目标板测试结果回传失败如何排查，需要把构建、下载、运行和结果收集拆开检查。

数据表已经改过，重新查看报告却还是原来的结果，问题不一定出在结果窗口。参数可能尚未写入测试脚本，也可能构建或下载阶段仍在使用旧文件。处理“Cantata如何组织参数化测试用例与数据集Cantata更新测试参数后执行结果未同步如何追踪”，可以沿数据表、脚本、可执行文件和结果记录逐段核对，找到变化停在哪一步。

Cantata怎么导出测试结果？先找到测试运行后生成的CTR结果文件，再根据用途生成便于阅读的报告。Cantata支持HTML、XML、RTF等报告格式；CTR文件则保留了原始测试记录。若导出失败，先判断是没有生成结果，还是已有结果却无法生成报告。

Cantata测试脚本要和被测代码一起编译、链接，才能生成可运行的测试程序。因此，原工程能编译成功，Cantata测试却无法运行时，先看编译日志停在哪一步：找不到头文件、链接失败和程序启动失败，检查的位置并不一样。下面以Cantata的Eclipse界面为例说明。

Cantata做C/C++单元测试时，被测函数经常会调用硬件驱动、通信接口、操作系统函数或其他尚未纳入测试范围的模块。直接把这些真实依赖一起编进测试程序，测试环境会变得很难控制。Cantata可以用Stub模拟外部调用，也可以用Wrapper截获真实函数调用，在测试用例里指定返回值、检查传入参数和控制不同调用次数对应的行为。测试桩已经生成却出现返回值不对、调用次数不匹配或测试程序仍进入真实函数时，可以从桩类型、调用实例和接口定义几个位置查起。

Cantata AutoTest可以从C/C++源代码中分析可执行路径，并按照选定的结构覆盖目标自动生成测试脚本和测试向量。处理“Cantata AutoTest怎么生成测试用例Cantata AutoTest生成的用例覆盖率不足是什么原因”时，不能只看生成了多少条用例，还要确认源码模型、覆盖规则、函数调用控制和测试运行环境是否完整，否则用例能够执行，覆盖率仍可能停在目标值以下。

测试已经进入某个分支，覆盖率报告却仍有未完成项；补了几个用例，条件覆盖提高了，MC/DC却没有变化。这些现象未必是统计错误，也可能是测试只触发了判定结果，没有证明每个条件都能独立影响结果。Cantata能够按代码结构、测试用例和构建变体查看覆盖数据，复核时应把具体表达式与执行记录对应起来。以下采用英文界面的视图名称，配置位置以所用版本为准。

Cantata怎么执行回归测试？关键是用当前代码重新构建并运行已有测试脚本，再把本次结果与之前的结果对照。如果执行中途停下，先确认停在构建、运行还是结果回收阶段。Cantata的测试脚本可以配合生成的Makefile批量执行，也可以通过IDE运行。

Cantata完成单元测试、集成测试或代码覆盖率采集后，可以把测试结果整理成HTML、XML等报告，也可以保留用于后续分析的测试结果文件。报告里是否带有覆盖率，不只看测试有没有执行，还要看本次测试是否做了覆盖率插桩、运行后有没有生成覆盖数据，以及报告读取的是哪一批结果。遇到功能测试结果正常、覆盖率章节却为空的情况，可以先从结果文件和覆盖数据入手，再检查报告使用的数据范围。

Cantata开始做C/C++单元测试前，要先把被测源码、原项目构建参数和测试使用的编译环境接起来。工程创建后能看到源码，并不代表测试环境已经配置好，头文件路径、预处理宏、编译器选项或目标Deployment少一项，后面生成测试脚本时就可能报解析错误，构建测试程序时也容易停下来。Cantata提供Testing Project向导，可从CMake、Make、IAR、Keil、Visual Studio等构建环境读取工程信息，配置出错时可以沿着源码位置、Build System和编译参数逐项检查。

Cantata进行C/C++单元测试时，桩函数不仅用来替代外部依赖，还能模拟返回值、修改输出参数、注入异常，并记录被测函数的实际调用过程。围绕“Cantata桩函数怎么配置Cantata桩函数调用顺序如何校验”开展测试时，需要先明确隔离边界，再为不同调用次数建立独立实例，否则测试结果很容易与真实执行路径对不上。

测试读取接口失败后的处理逻辑，桩里已经设置错误码，被测函数却仍然走成功分支；给同一个接口安排“失败一次再成功”，结果两次调用又返回相同数值。这类问题要沿着实际调用检查：程序有没有进入桩、选中了哪个实例、返回后又做了什么处理。Cantata提供Stub、Isolate和Wrapper等调用控制方式，选对控制方式后，才能准确模拟外部依赖。下面采用英文界面的常见名称，具体布局以安装版本为准。

Cantata怎么管理测试数据？测试数据修改后结果没有更新又该如何处理？先看清改动发生在哪里：测试输入、预期输出可以保存在测试脚本中；表格驱动测试还可以使用多组数据，并支持通过CSV导入、导出。修改文件后，原有测试结果不会自动变成新结果，需要确认改动已进入测试脚本，再重新构建和运行。

Cantata里的测试用例通常保存在C/C++测试脚本中，批量测试数据还可以使用表驱动测试方式管理。这里要分清两种情况：如果已有的是CSV格式的输入值、预期结果等测试数据，可以导入现有表驱动测试；如果已有的是另一套Cantata工程里的完整测试脚本，更适合把对应Test Script及关联文件迁到当前测试工程。测试用例导入失败时，问题经常出在CSV字段和函数接口对不上、测试脚本版本变化，或者原有Stub、全局数据已经和当前源码不一致。

MC/DC关注复合判定中的每个基本条件，能否在其他条件保持适当状态时独立改变最终结果。处理“Cantata MC/DC覆盖率怎么统计Cantata MC/DC覆盖缺口如何定位”时，要先启用正确的覆盖规则，再从未满足的条件组合反推测试数据，不能只看一个总百分比。覆盖率达到目标后，仍要结合需求测试和异常场景判断测试是否充分。

使用Cantata做C/C++单元测试时，工具可以先生成测试框架，但测试能否真正验证需求，仍取决于输入数据和预期结果是否合理。处理Cantata测试脚本怎么生成Cantata测试脚本中的输入和预期结果怎么填写，需要先明确被测函数的参数、全局变量、返回值和外部调用，再把每个测试场景拆成可重复执行的数据组合。