换了测试数据，重新运行却与旧报告不一致，问题未必出在输入数值上。预期输出、桩函数和执行环境的变化，也会影响测试。下面以LDRA Testbed配合TBrun的单元测试为例，说明数据版本管理和历史结果追溯方法，英文菜单按所用版本核对。

　　一、testbed怎样管理测试数据集版本

　　TBrun将测试用例组织成序列，可保存为测试用例文件TCF。管理版本时，应将它与对应源码、配置和报告关联保存。

　　1、把测试序列保存为独立版本

　　序列名称相同，不代表里面的测试内容没有变化。正式使用过的数据应保留原件。

　　①在TBrun中选中目标序列，核对包含的函数、用例数量及用例名称。

　　②使用序列保存或导出功能生成TCF，存入本次版本目录，保留修改前的文件。

　　③新增边界值、修改预期结果或调整执行顺序时，另存新版本，记录修改内容及原因。

　　④将输入文件、初始化代码及手写桩代码一并归档，检查是否存在指向个人目录的外部引用。

　　2、用版本库固定数据和源码的对应关系

　　只在文件名里写日期，难以确认同一天多次修改的先后关系。下面以Git管理为例。

　　①将TCF、相关配置及外部测试数据纳入版本控制，提交前检查文件是否齐全。

　　②执行git rev-parse HEAD，记录对应的源码提交；执行git status--short，检查未提交修改。

　　③数据与源码分库管理时，分别记录两边的提交标识，并在测试记录中写明对应关系。

　　④为已确认的测试版本建立标签；后续修改产生新提交，保留原标签指向。

　　3、连同执行资料一起归档

　　TCF保存的是重跑用例所需的测试信息，不能代替编译器、目标机和全部外部依赖的记录。

　　①保存LDRA工具版本、编译器版本、编译选项、宏定义和头文件路径。

　　②记录主机、目标机或仿真器运行方式，以及目标板型号、固件和相关运行库版本。

　　③测试结束后，将报告、构建日志和原始执行输出放入本次任务目录，注明使用的数据版本。

　　二、testbed更换数据集后历史结果无法复现如何追溯

　　先保存当前工作目录，再从一条有差异的用例查起。不要急着更新预期结果，否则会失去比较依据。

　　1、确认加载的是历史数据

　　重名TCF、旧快捷方式或工作区路径变化，都可能让实际加载的文件与记录不一致。

　　①从版本库取出历史TCF及配套文件，放入独立目录，检查文件内容或校验值。

　　②在TBrun中加载该文件，核对序列、用例数量和目标函数，避免仅凭序列名称判断版本。

　　③比较历史报告中的用例信息，查看是否缺少初始化步骤、外部数据或附加代码。

　　2、检查预期结果和桩函数

　　两次都显示通过，并不能证明实际输出相同；预期值调整后，通过条件也可能已经改变。

　　①在【Test Case】中选中异常用例，对照历史版本检查输入、预期输出及比较条件。

　　②打开【Stub Management】，核对桩返回值、调用次数、调用顺序和附加执行代码。

　　③在【Global Variables】中检查相关全局变量设置，确认初始化内容与历史版本一致。

　　④对比原始实际输出与历史输出，分别记录“程序输出改变”和“判断条件改变”。

　　3、恢复对应源码和编译配置

　　相同数据运行在不同代码上，不能用于判断历史结果是否能够复现。

　　①在独立工作区检出历史源码提交，恢复对应头文件、依赖库和生成文件。

　　②对照构建日志，核对编译器、优化选项、宏定义、数据类型和链接输入。

　　③函数接口发生变化时，检查参数映射及结构体布局，不直接把旧用例套入新接口。

　　4、重新生成并执行测试驱动

　　更换数据后只查看已有报告，或继续运行旧可执行文件，都可能混淆本次结果的来源。

　　①在历史环境副本中选中目标序列，点击【Run Driver】→【Generate Driver】。

　　②点击【Run Driver】→【Build Driver】，查看编译、链接是否成功，核对生成文件路径。

　　③点击【Run Driver】→【Execute Driver】，确认实际执行的是本次生成的程序。

　　④点击【Run Driver】→【Process Driver Output】，保存新输出及报告，检查执行时间是否对应本次任务。

　　5、排查顺序和外部状态

　　同一用例单独执行与放在整段序列中执行，可能受到不同的全局状态影响。

　　①分别运行异常用例和原始完整序列，比较差异是否仅在连续执行时出现。

　　②检查静态变量、全局变量、文件内容和目标机状态，按历史测试约定恢复初始条件。

　　③涉及随机数、时间、通信或传感器输入时，核对种子和输入记录；资料缺失时，注明暂时无法严格复现。

　　三、testbed历史结果复查后怎样保留追溯记录

　　差异查清后，记录应能说明比较了什么、差别在哪里，方便其他人接着核查。

　　1、保存每次复查的输入与结论

　　追溯记录需要保留失败尝试，不能只留下最后一次通过的报告。

　　①建立复查记录，填写历史任务、数据版本、源码版本和本次任务编号。

　　②每次只调整一项待核查因素，保存对应日志，记录结果是否随之改变。

　　③将差异归入输入、预期值、代码、构建环境或执行状态，并写明确认依据。

　　④找不到历史输入或环境资料时，列出缺失内容及已完成的核查，不将近似结果标为完全复现。

　　总结

　　希望这篇关于“testbed怎样管理测试数据集版本，testbed更换数据集后历史结果无法复现如何追溯”的内容能帮到大家。软件项目持续推进，人员交接和需求调整都很常见，过去的工作能否被理解，会影响后续协作的效率。把资料保留清楚，是对已有投入的珍惜，也让团队处理问题时多一份依据。日常积累未必立刻显出作用，到了复查、交付或维护阶段，往往能省下不少沟通时间。如果有LDRA Testbed软件选型、配套模块或版本方面的需求，欢迎联系我们进一步了解。