把TESSY接进CI，真正要解决的是两件事，第一件是让TESSY在无人值守环境里稳定跑起来，第二件是把结果变成CI能识别的通过与失败，并且能把报告自动归档。只要你把测试工程的可还原性、命令行执行链路、账号与许可、结果门禁这四块一次做实，后续不管你用Jenkins还是GitLab CI，流程都能长期复用。

　　一、TESSY与CI怎么集成

　　集成的主线是先把可执行的测试工程准备好，再用TESSY的无界面运行方式把执行动作放进CI任务里，最后把环境和许可问题提前处理掉，避免跑到一半才发现跑不起来。

　　1、先把TESSY测试工程做成可还原的版本库内容

　　在开发机上先确保工程交互式执行是正常的，然后把测试工程按可恢复方式保存并提交到版本库，CI侧只需要拉取仓库就能还原整个工程到工作区，这一步是后面自动跑的前提。

　　2、在TESSY里准备批处理脚本文件TBS把执行范围固定下来

　　进入TESSY测试工程后打开批处理定义界面，创建一个TBS文件，把要执行的测试对象和要生成的报告都写进TBS，并把报告输出目录设在工程根目录下的固定路径，报告名不要带日期时间这类可变字段，方便CI做稳定匹配。

　　3、把概览报告加入TBS作为CI判定的统一入口

　　只跑测试不等于CI能判定失败，因为单个测试失败并不会自动中止整次执行，你需要在TBS里生成概览类报告，然后让CI去分析概览报告中失败或未执行的条目，才能形成可重复的门禁规则。

　　4、选定执行方式优先走tessyd加tessycmd的无界面链路

　　在CI节点上用tessyd启动无界面实例并加载PDBX工程文件，再用tessycmd连接实例，执行还原动作和执行TBS动作，最后断开连接并关闭实例，这条链路是官方文档中用于CI的典型方式。

　　5、把CI节点的运行账号与用户目录问题前置处理

　　以Jenkins为例，如果服务默认跑在系统账号下，往往不具备TESSY测试需要的标准用户环境，建议为CI服务或Agent准备可正常登录的账号，并确保其用户目录可用，例如%APPDATA%与%USERPROFILE%这类目录能正常访问，否则测试执行容易失败。

　　6、如果使用Jenkins优先考虑TESSY插件减少脚本维护量

　　在Jenkins里进入【Manage Jenkins】到【Manage Plugins】安装插件文件后，再到【Global Tool Configuration】添加TESSY安装路径，在【Configure System】里配置许可证服务器信息，随后在Job里添加【Run TESSY standard test】构建步骤并填写PDBX与TBS路径，这种方式可以自动处理启动关闭与失败清理，适合长期维护。

　　二、TESSY与CI集成后怎么让任务自动跑

　　自动跑要做到两点，一是让任务在代码变更时自动触发，二是让任务在任何节点上都能稳定复现同一结果。你把触发条件、工作区还原、执行命令、结果门禁、报告归档这五步固化后，自动跑就不再依赖个人手工点击。

　　1、把触发方式分成提交触发与定时触发两条线

　　提交触发用于分支提交或合并请求场景，让单元回归跟着变更走，定时触发用于夜间全量回归或覆盖率全量统计，GitLab CI这类流水线支持按事件与按计划运行，你只要把两类触发都配上，就能兼顾及时性与完整性。

　　2、在任务开始阶段强制清理工作区避免残留污染结果

　　在CI任务的第一步启用工作区清理，确保每次运行从干净目录开始，然后再执行拉取代码与还原测试工程，避免上一次生成的数据库、报告或中间文件影响本次结论，尤其是并行跑多分支时更明显。

　　3、把执行阶段拆成启动实例、还原工程、执行测试、关闭实例四个动作

　　启动阶段只负责拉起tessyd并加载工程文件，还原阶段执行restore类动作把工程恢复到当前工作区，执行阶段只跑TBS，关闭阶段做disconnect与shutdown并把日志复制到工作区，拆开后更容易定位失败发生在环境、工程还原还是测试本身。

　　4、用概览报告加XSLT转换把结果变成CI可判定的失败

　　执行完后用tessycmd的xslt能力对概览报告做转换或摘要输出，把概览报告里的失败与未执行条目转成CI能识别的JUnit格式或等效判定输出，再把该步骤设置成失败即构建失败，这样你的门禁就不会停留在人工看报告。

　　5、把许可证不足与环境异常做成可识别的失败类型

　　如果遇到许可证不足，建议把tessyd的返回码与日志作为单独分支处理，例如新版本中提到tessyd对无许可证情况提供了专门的退出码含义，你在CI里就能区分是测试失败还是资源不足，从而决定是重试、排队还是直接失败。

　　6、把报告发布与归档做成固定目录与固定规则

　　在TBS里把报告输出目录固定到工作区内的某个路径，CI侧把该目录作为构建产物归档，同时发布JUnit测试报告并开启附件发布能力，让CI界面能直接跳回原始TESSY报告，这样开发和测试复盘问题时不需要再去服务器里翻文件。

　　三、TESSY报告归档与失败门禁怎么做

　　很多团队做到能跑就停了，后面最容易出问题的是报告散落、门禁口径漂移、同一个问题重复出现。把归档结构和门禁规则写成团队共识，并把它变成流水线的一部分，才算把TESSY自动化真正用起来。

　　1、把报告按一次运行一个目录的方式组织但保持稳定入口文件名

　　目录可以按分支名与构建号区分，便于追溯，但概览报告与JUnit输出文件名保持固定，CI侧就能用同一条规则去抓取与展示，避免因为文件名变化导致发布步骤失效。

　　2、把失败门禁拆成三条硬规则并写入流水线检查

　　第一条规则是存在未执行测试即失败，第二条规则是存在失败测试即失败，第三条规则是报告生成或转换失败即失败，这三条都可以通过概览报告与XSLT转换步骤实现，避免有人只看通过率忽略未执行项。

　　3、把问题日志作为同级产物归档方便快速定位

　　在CI任务里把TESSY执行日志与problems类日志统一复制到工作区并归档，一旦失败可以先看日志再决定是否需要打开详细报告，定位时间会明显缩短。

　　4、对多节点并行跑加入一致性约束避免同用例不同结论

　　把编译器版本、包含路径、宏定义、目标配置统一固化在版本库或CI变量中，节点上只按同一份配置展开，这样并行跑多个变体时结论才可比，减少环境差异导致的偶发失败。

　　5、把一键重跑与手动触发保留为兜底但不改变门禁口径

　　允许开发在CI界面点【Rebuild】或手动触发流水线用于排查偶发环境问题，但门禁规则不因为手动触发而放宽，确保主分支合入的质量口径始终一致，避免把自动化变成形式。

　　总结

　　TESSY接入CI的关键是先把测试工程做成可还原资产，再用tessyd与tessycmd在无界面模式下执行TBS，并用概览报告建立统一的结果入口。要让任务自动跑，就把触发条件、工作区清理、执行链路、结果门禁、报告发布归档固化到流水线里，同时把账号环境与许可证异常前置处理，最终让每次提交和每次定时回归都能自动出结论、自动留证据、自动可追溯。