测试报告写着新版本，打开后却出现已经删除的函数；流水线显示测试完成，下载的报告仍是上一轮结果。这类问题往往与工作目录复用、结果选择错误或归档路径有关。在LDRA Testbed中，报告生成时间、工具版本和被测软件版本需要分别记录，单独修改报告文件名，无法证明结果属于哪个构建。

　　一、testbed怎么设置测试报告的版本标识

　　版本标识可以通过构建清单与原始报告绑定。清单记录被测对象，Testbed报告保存分析和测试结果，两部分一起归档，便于后续核对。

　　1、确定本轮测试使用的版本信息

　　①在开始分析前，记录源码提交号、构建编号、构建配置和目标平台；存在未提交修改时，同时保存修改内容。

　　②将这些信息写入报告包的版本清单或交付封面，分别注明源码版本、构建版本及报告修订号。

　　③动态测试还应记录实际加载的可执行文件及其校验值，保留对应编译日志。

　　例如，同一提交分别生成Debug和Release构建，两者不能只用提交号区分。报告中的LDRA工具版本说明使用了哪个测试工具，也不能替代被测软件的构建编号。

　　2、选择正确的分析结果生成报告

　　①在LDRA Launcher的【Existing Analysis Results】区域选中本轮分析的文件或集合，双击【TBreports】。

　　②进入【Source】，核对并选择需要生成报告的文件或集合。

　　③在【Reports】中检查源文件列表，勾选需要的集合级、文件级输出，再选择相应报告。

　　④点击【Generate Report(s)】，打开生成结果，核对报告中的文件和测试内容。

　　报告来源选错时，即使输出目录按新构建命名，里面仍然会是旧结果。生成前应把源文件路径与本轮构建清单对应，不能只看集合名称是否熟悉。

　　3、为报告包设置独立标识

　　①用项目名称、构建编号和测试轮次命名归档目录，例如“控制模块_Build248_Run02”。

　　②将原始报告、版本清单、分析日志及测试执行记录放入同一报告包；单元测试同时保存对应测试用例文件。

　　③交付文档需要版本号时，在封面或版本清单中记录报告修订号，并注明对应构建。

　　报告修订号用于区分文档修改，测试轮次用于区分执行批次。仅补充说明时可以修订交付记录；重新执行测试后，则应保存新的运行记录，避免两种变化混在一起。

　　二、testbed报告关联到错误构建版本如何校正

　　发现关联错误后，先保留当前报告和日志，再判断是标识写错、报告取错，还是实际测试对象就错了。不同情况需要重新执行的范围并不相同。

　　1、检查是否只是归档标识错误

　　①将报告中的文件、函数和测试用例，与本轮构建记录逐项对应，确认分析输入及执行对象。

　　②比较版本清单中的提交号、构建编号和可执行文件校验值，查找复制旧清单后未更新的内容。

　　③如果结果确实来自目标构建，只是归档名称或清单写错，修正交付记录并登记原因，保留原始报告。

　　例如，报告内容来自Build248，压缩包名称却写成Build247，可以校正归档信息。但如果报告中仍有旧版本特定的函数，就需要继续追查结果来源。

　　2、检查是否发布了旧报告

　　①回到【TBreports】→【Source】，重新确认所选结果，再检查报告生成日志及实际输出位置。

　　②查看发布脚本是否复制了固定目录中的历史文件，或使用通配符同时收集了多个构建的报告。

　　③使用TBpublish时，检查发布集合是否混入此前生成的报告，归档后重新整理本轮发布内容。

　　④重新打开最终交付包，核对入口页面和内部报告，确认没有继续指向旧目录。

　　TBpublish可能把指定文件或集合此前生成的报告一并发布。因此，新生成了一份报告，并不代表发布包中的其他内容都已更新。覆盖率报告、回归报告和代码审查报告应分别核对。

　　3、检查实际测试的程序是否正确

　　①对照编译日志，确认测试程序由目标源码和构建配置生成，检查是否复用了其他目录中的目标文件、库或测试驱动。

　　②核对下载日志及目标设备启动信息，确认设备运行的是本轮测试程序，而非上一次烧录的版本。

　　③检查回收的执行数据是否属于本次运行，是否误用了旧数据文件或其他设备的结果。

　　④修正输入后，按受影响范围重新分析、插桩、构建和执行测试，再生成报告。

　　如果实际运行的是旧程序，修改报告标题无法补救。静态分析结果正确、动态测试对象错误时，也应分别处理，不能因为部分报告有效，就把整个报告包都标为新构建结果。

　　三、校正后如何验证报告与构建重新对应

　　校正完成后，可以选取本次构建中一处已知变化作为核对点，再检查最终归档。这样能确认结果内容与标识同时更新。

　　1、用已知代码变化核对报告内容

　　①从提交记录中选择一个新增、删除或修改的函数，确认它属于本轮分析和测试范围。

　　②在新报告中查找该函数，检查文件路径、代码内容及相关测试结果是否与目标提交一致。

　　③动态测试存在可观察变化时，对照本轮执行日志验证，不要只比较通过率或覆盖率百分比。

　　两个构建可能得到相同的通过率。数字相同不能证明报告复用，数字不同也不能证明版本正确，仍需回到具体代码和执行记录判断。

　　2、复查流水线的归档范围

　　①将构建、测试和报告输出分别放入本轮独立工作目录，明确传递目录及结果文件，减少并行任务相互覆盖。

　　②在发布前检查构建编号、提交号和报告来源是否一致；缺少结果或执行失败时，停止发布本轮报告。

　　③下载归档包，在独立位置打开，抽查内部链接及版本清单，并记录校正后的交付位置。

　　总结

　　项目进入联调或交付阶段后，同一份源码可能经历多次构建和测试。几周后需要复现问题时，能否找回当时的程序、配置和执行记录，会直接影响排查效率。清楚的版本标识让报告具备可查的使用范围，也方便接手人员判断哪些结果可以继续采用、哪些需要重新验证。希望这些操作能帮助大家减少Testbed报告整理和版本交接中的反复核对。如果有测试配置、报告管理及结果追溯等方面的需求，欢迎联系咨询。