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

　　一、Cantata如何组织参数化测试用例与数据集

　　Cantata支持表驱动测试，用多组输入和预期输出重复验证同一段测试逻辑。组织数据时，应让每行对应一个明确场景，便于失败后定位。

　　1、按验证场景组织表驱动用例

　　①打开【Test Script Manager】，选择目标测试脚本，在用例编辑区域添加表驱动测试，确认被测函数及参数。

　　②将输入参数、预期返回值和需要检查的输出分别填入对应位置，为边界、正常值和异常值设置可识别的说明。

　　③通过【File】→【Save All】保存，再打开对应C/C++脚本，检查数据定义及调用逻辑是否符合预期。

　　④调用顺序、初始化或外部依赖行为差异较大时，拆分为不同测试用例，避免在同一张表中混入大量条件分支。

　　例如，同一函数的多个数值边界可以放在一组；涉及设备超时和恢复流程的场景，则应检查是否需要独立的前置条件。

　　2、维护CSV与脚本中的数据对应关系

　　①使用当前版本的表驱动数据导出功能，保存一份CSV样本，按其格式维护列顺序和数据类型。

　　②更新CSV后，重新执行相应导入操作，检查行数、负值、小数及空白单元格的处理结果。

　　③保存脚本，重新打开【Test Script Manager】及源码编辑器，抽查被修改的数据。

　　④将CSV与实际参与构建的测试脚本一起纳入版本管理，记录两者的对应版本。

　　CSV导入属于数据交换，不能据此认为文件已建立实时连接。除非测试代码另行实现运行时读取，修改外部CSV后仍需确认新数据已经进入测试脚本。

　　二、Cantata更新测试参数后执行结果未同步如何追踪

　　编辑器显示新值、程序执行新值、报告引用新结果，是三个需要分别确认的环节。先选一条已修改的数据追踪，比反复运行整套测试更容易定位。

　　1、检查修改是否保存到正确脚本

　　①点击【File】→【Save All】，核对当前脚本的完整位置，检查是否误改了其他项目或工作区中的同名文件。

　　②在源码编辑器中搜索新参数，确认它出现在实际使用的数据定义中。

　　③返回【Test Script Manager】，选择目标用例，检查GUI显示与源码内容是否一致。

　　④检查后续初始化和赋值语句，确认新值没有在调用被测函数前被固定常量覆盖。

　　2、检查构建是否使用更新后的数据

　　①选中目标项目，执行【Project】→【Build Project】，查看【Console】中的编译与链接输出。

　　②确认修改后的脚本或其包含的数据文件进入了本轮构建，检查生成文件的位置。

　　③怀疑增量构建遗漏依赖时，保留日志，通过【Project】→【Clean】清理目标项目后重新构建。

　　④构建失败时先处理错误，不继续沿用上一次成功生成的测试程序。

　　如果参数保存在头文件中，还应检查Makefile是否正确声明依赖。编辑器里的内容变化，不保证构建系统一定重新编译相关文件。

　　3、确认目标端运行的是本轮程序

　　①打开测试使用的运行或目标部署配置，核对可执行文件路径、构建配置及目标设备。

　　②重新下载本轮生成文件，检查下载日志，避免启动脚本仍指向旧目录。

　　③运行目标用例，在【Console】中核对执行过程及结果回收位置。

　　主机测试正常、目标板结果未变时，可优先检查下载与启动环节。重新构建完成，并不代表目标端程序已经替换。

　　4、确认查看的是新结果记录

　　①打开本轮产生的CTR结果文件，核对路径、生成时间、用例名称及执行完成情况。

　　②在结果视图中展开修改过的测试，查看具体检查项的实际值与预期值，不只比较通过数量。

　　③重新生成HTML等报告，确认报告来源是本轮CTR文件。

　　参数改变后仍然通过，可能完全正常。例如输入和对应预期输出同步调整后，通过数量可以保持不变。判断是否更新，应查看具体执行数据。

　　三、Cantata如何验证数据确实参与了本轮执行

　　结果更新链路确认后，还需要检查测试是否真正使用了每行数据，尤其是全局变量和循环中的状态。

　　1、用可追踪的数据检查初始化

　　①在【Test Script Manager】中选取一行，使用符合需求、且便于识别的输入，保存后检查对应源码。

　　②检查每轮调用前的初始化，确认表中数据赋给了实际参数或目标变量，输出检查也引用了本行预期值。

　　③涉及全局数据时，补充核对赋值和检查逻辑。Cantata表驱动测试默认并不自动建立所有全局变量的修改与验证关系。

　　④使用支持的输入记录功能或调试器确认实际值。Cantata 25.07新增的SET_TEST_INPUT宏可将输入值记录到CTR，旧版本需采用其支持的方式检查。

　　不要为了验证同步而随意修改预期结果让测试通过，应选择能够明确核对输入与输出关系的场景。

　　2、核对批次与集中报告记录

　　①保存本轮数据、脚本、构建日志和CTR，记录代码提交、目标配置及数据版本。

　　②使用Cantata Team Reporting时，检查上传所选容器、测试运行记录和产品变体标签。

　　③对比本地CTR与服务器记录；本地已更新而服务器未变化时，检查上传过程及当前筛选条件。

　　④确认修改行和其他数据行均已执行，再将本轮结果用于评审，保留旧批次供比较。

　　总结

　　处理“Cantata如何组织参数化测试用例与数据集Cantata更新测试参数后执行结果未同步如何追踪”，一份可复核的结果应能对应到实际执行的数据、脚本和目标程序。这样后续增加边界值、更换目标平台或重跑历史测试时，团队能够确认比较的是哪组条件，也能解释通过数量没有变化的原因。希望这些操作能帮助大家把数据更新落实到具体执行记录，减少在编辑、构建和报告之间反复试错。如有Cantata相关需求，欢迎与我们沟通。