同一条用例第一次失败，再执行却通过，测试报告该采用哪次结论？如果首次执行没有成功连接目标板，重新运行有其必要；如果程序已经返回错误数据，重跑通过仍然需要解释。围绕“testbed如何配置测试任务重试策略，testbed失败用例重跑后结果不一致如何判断”，下面以LDRA Testbed配合TBrun的测试场景为例，说明如何安排重跑，以及怎样核查前后两次结果。

　　一、testbed如何配置测试任务重试策略

　　TBrun支持将测试序列保存为TCF，并通过界面或命令行重新执行。接入流水线后，自动重试还需要结合调度脚本配置，不能把流水线的重试参数当作Testbed统一提供的菜单选项。LDRA

　　1、先划定允许重试的失败范围

　　①查看首次执行日志，区分构建失败、目标连接失败、运行中断和实际输出不符合预期。

　　②对能够确认的临时连接故障，安排恢复连接后的有限重试；编译错误、缺少文件等问题先修复配置。

　　③程序已经执行到检查点并产生错误输出时，保留用例失败记录，后续重跑作为诊断记录。

　　重试策略应写明触发条件。例如，下载程序时连接断开，可以恢复后再次下载；函数实际返回值错误，则需要追查输入、状态及代码路径。

　　2、固定每次重跑使用的测试条件

　　①保存当前TCF，记录源代码提交号、编译器版本、编译选项以及目标平台。

　　②核对用例输入、预期输出、全局变量初值和桩函数配置，避免重跑前顺手修改其中某项。

　　③规定每次尝试前的准备动作，包括终止上一次执行、恢复测试数据、重新加载程序或复位目标板。

　　④给每轮执行设置独立结果目录，保存日志和输出文件，防止第二次执行覆盖首次失败证据。

　　复位方式也要保持一致。重新启动测试进程不一定能清除目标板内存、外设寄存器或持久化数据，需要按项目使用的测试环境落实清理动作。

　　3、在调度层设置次数和超时

　　以Jenkins调度TBrun批处理为例，retry控制执行块的尝试次数，timeout控制等待上限；这些配置属于流水线。jenkins.io

　　①打开对应任务，进入【Configure】→【Pipeline】，确认脚本直接保存在界面，还是由代码仓库中的Jenkinsfile提供。

　　②将重试范围限制在已确认可以恢复的环节。例如，仅重新申请执行节点，或恢复连接后重新执行指定测试序列。

　　③明确次数含义。Jenkins的retry(2)最多执行两次，包含首次尝试；还要分别考虑单次执行超时与整项任务的总时限。

　　④保存后点击【Build Now】，进入本次构建的【Console Output】，检查实际尝试次数、清理动作和报告路径。

　　二、testbed失败用例重跑后结果不一致如何判断

　　先确认两轮执行是否具备比较条件，再调查结果为什么改变。以下方法用于定位差异，单次重跑通过不足以确认问题已经消失。

　　1、核对两次运行是否使用同一份程序

　　①比对源代码提交号、TCF版本、编译参数以及实际下载的可执行文件，必要时记录文件校验值。

　　②检查首次失败后是否重新生成驱动、调整桩函数，或者改动了预期输出。

　　③发现配置变化时，将两次执行标为不同条件下的结果，重新准备一致条件再比较。

　　只核对工程名称容易漏掉旧程序残留。构建成功后，还应确认目标端加载的确实是本轮产物。

　　2、查看实际输出和失败发生的位置

　　①打开两轮执行记录，找到同一用例的实际值、预期值、异常信息和结束位置。

　　②确认首次失败属于输出比较失败，还是程序未启动、运行中断、结果文件没有成功回收。

　　③如果程序运行正常但报告缺失，检查采集链路；如果输出值确实变化，继续检查程序状态和调用路径。

　　④对浮点比较，核对需求规定的容差及比较方式，不要为了让用例通过临时放宽阈值。

　　进程正常退出也不能单独证明测试通过，仍需检查用例检查点是否执行完成。

　　3、检查初始化和桩函数调用状态

　　TBrun的桩函数可以按调用次数返回不同数据，因此调用顺序、次数和初始化条件都可能影响测试输出。LDRA

　　①比对全局变量、静态变量、缓冲区及动态内存的初始状态。

　　②检查桩函数每次调用的返回值安排，核对重跑时调用次数是否从预定位置开始。

　　③涉及随机数据、系统时间或中断输入时，保存种子、时间条件和输入记录，再使用可控条件复测。

　　例如，桩函数被安排为首次返回忙、再次返回成功，就应检查两轮测试是否执行了相同的调用过程。

　　4、用执行顺序验证用例间干扰

　　①单独执行失败用例，记录结果；随后恢复首次失败时的完整序列和顺序，再次执行。

　　②若单独通过、放回序列后失败，检查前置用例对共享变量、文件、设备状态和外设的影响。

　　③暂时停止其他任务对同一目标板或输出目录的访问，观察异常是否仍然出现。

　　④每次只改变一个条件，记录变化前后的结果，避免同时复位、换机器和改数据后无法归因。

　　三、testbed重跑记录如何形成可复核的结论

　　调查结束后，还要说明首次失败怎样处理。报告只保留最后一次通过，会让接手人员失去判断问题是否复发的依据。

　　1、按证据填写问题结论

　　①相同条件下持续出现相同错误输出，登记缺陷并关联失败日志。

　　②确认连接或结果采集故障时，注明本轮未取得有效测试结果，修复环境后重新执行。

　　③首次失败、随后通过但原因尚未查清时，记录为结果不稳定，保留待调查事项。

　　④修改代码、用例或配置后通过，注明修改内容及验证范围，关联修改前后的记录。

　　2、分别统计用例与执行尝试

　　①每条用例使用稳定编号，每次尝试另外记录批次号、时间、执行环境及结果。

　　②统计唯一用例数量时，不把重跑次数计入新增用例；同时列出首次失败、重跑通过和持续失败的数量。

　　③修复后先验证原失败场景，再执行相关回归序列，确认修复没有影响其他用例。

　　总结

　　处理“testbed如何配置测试任务重试策略，testbed失败用例重跑后结果不一致如何判断”，交付的测试记录应当能回答一个具体问题：这次通过建立在什么条件下，原来的失败又怎样得到解释。这样到了版本评审或问题复盘时，团队才能判断结论是否适用于当前程序，也能找到需要继续调查的线索。希望这些方法能帮助大家保留有用的执行证据，让重跑结果经得起复核。如有testbed相关需求，欢迎联系我们咨询。