Squish

很多人第一次用Squish，觉得录制很简单，点一下Record，跟着操作一遍，脚本就出来了。可真正麻烦的地方，往往不在第一遍能不能录出来，而在第二遍、第三遍以后脚本还能不能继续用。Qt官方文档把这条线说得很清楚：录制本身是从测试套件和测试用例开始的，录制过程中会自动把对象写进Object Map，后面脚本要不要好维护，很大程度上就取决于对象名、同步方式和共用代码有没有先收顺。

做Squish授权配置时，最容易弄混的不是安装程序，而是许可证模型本身。Qt官方现在把Squish的许可证模型分成三类，本地许可证、本地网络中的Squish Floating License Server，也就是FLS，以及Squish 9.2及更新版本可用的Qt License Server，也就是QLS。不同模型的配置方式完全不一样，本地许可证是把密钥直接配到客户端，本地浮动许可要让客户端连到一台运行中的许可服务，而QLS则是让客户端连接到一个许可证服务地址。所以真正开始配置前，先把当前组织到底用哪一种许可模型分清，后面的步骤才不会走反。

在Squish里，验证点并不只是“录一段脚本后顺手加一句判断”，它本质上是把界面状态、对象属性、截图或表格内容转成可重复执行的检查动作。官方文档明确说明，验证点既可以通过代码直接写，也可以通过IDE里的Verification Point Creator点选生成；而属性校验最常见的落地方式，就是用对象属性加`test.compare()`或`test.verify()`这样的验证函数来完成。

Squish录制回放不稳定，最常见的根源不是录制功能本身，而是对象名不稳、等待方式不对、以及把异步界面当成同步界面来回放。真正想把脚本跑稳，思路要从“多录几次试运气”改成“先固定对象识别，再把等待和同步点补全”，这样后面回归时才不会同一条用例今天过、明天挂。

做GUI自动化时，squish截图保存失败怎么办，squish截图路径怎么设置这类问题经常一起出现：一边是截图动作已经触发但文件没落盘，另一边是截图确实生成了却找不到保存位置。更常见的根因不在截图能力本身，而在结果目录与报告生成器的组合、运行端与被测端不在同一台机器、以及目录权限与文件名规则没统一。把截图写入链路理清，再把路径按运行方式固定下来，截图才能稳定成为可追溯证据。

Squish的结果归档如果只停留在导出一份报告，后面做回归对比、批次追溯和失败复盘都会很吃力。更稳的做法是把结果目录、报告格式、版本号和批次号一起固定下来，让同一轮执行的XML、截图、附件和JUnit结果都能落到同一套结构里。Squish官方文档也说明，测试结果可以在IDE里查看最近结果，也可以导出并重新导入，而命令行执行时可通过报告生成器把XML结果写入指定目录；若结果包含截图或附件，官方推荐按整个结果目录打包上传或保存。

做Squish自动化时，真正影响后期维护成本的，往往不是脚本怎么录，而是用例从一开始怎么收、怎么分、怎么标。Squish本身就是以Test Suite和Test Case为基本组织单元，创建用例时会在测试套件目录下自动生成对应子目录；同时一个套件里可以混用脚本型、BDD型，较新的能力里也支持和其他类型测试并存，所以前期结构如果没定好，后面越加越乱是很常见的事。

遇到Squish许可证无法识别，常见原因不是许可证本身坏了，而是许可证文件放错位置、运行Squish的账号变了、目录不可写，或你实际在用浮动许可证却还在找本地许可证文件。下面按先定位提示信息，再把许可证文件放到Squish会自动查找的位置，最后再处理CI与多用户环境的顺序来做。

很多人说的“报告没生成”，其实是把两件事混在了一起：一种是在Squish IDE里只看到【Test Results】视图，但没有导出到文件；另一种是命令行跑了用例，结果被默认写到标准输出，你以为会自动生成HTML或XML。按下面的顺序把报告来源、输出位置、生成器类型理清，再去改配置，会更快把问题收敛。

回放找不到控件和等待超时，表面像是同一类报错，根因却常分成两条线：一条是对象名不稳或对象映射过期，另一条是界面状态没到位导致对象暂时不可用。处理时别先加固定延时，而是用Squish自带的对象定位与同步机制把口径稳住，再把超时参数调到符合你们应用节奏的范围内。

很多团队刚开始用Squish时，最容易乱掉的不是录制按钮怎么点，而是工程一多以后，测试套件、公共脚本、对象库和测试数据全堆在一起，后面谁也说不清哪个目录该放什么。按Squish当前官方文档的组织方式来看，一个测试套件本身就有很明确的骨架，套件根目录里有suite.conf，测试用例各自有独立子目录，套件级共享内容放在shared下面，公共对象库和共享脚本也有固定位置。顺着这套原生结构去整理，后面的维护成本会小很多。

Squish结果管理如果只停留在IDE里看一眼，后面做回归对比、缺陷复盘和CI归档都会很乱。更稳的做法是把导出动作、报告格式和保存路径一次定成统一口径，让本地调试、命令行执行和流水线产物都能对上同一套规则。Squish本身同时支持IDE里的结果导出，也支持通过squishrunner生成多种报告格式，但不同格式对附件、目录和保存方式的要求并不一样。

Squish里的测试资产并不是一堆零散脚本，而是以测试套件为核心组织起来的。官方文档明确说明，一个测试套件以suite.conf为配置中心，并带有shared目录用于放共享资源；同一个套件里可以同时放脚本型用例和BDD用例，但一个套件只能使用一种脚本语言。正因为结构是固定的，前期规划做得好，后面扩容、回归和人员交接都会顺很多。

Squish远程执行失败时，最容易被忽略的是执行链路并不是只有一台机器在跑，通常是控制端在发起执行，目标端的Squishserver负责驱动AUT与回传对象信息。只要远程Squishserver没有真正对控制端放行，或端口被防火墙拦住，你在IDE里看到的就会是连接失败、执行卡住、或跑到一半断开。

团队把squish跑起来不难，难的是规模一大就开始乱，套件越来越多却找不到入口，用例越写越长还互相拷贝，回归一跑就是一夜，失败也说不清是环境还是脚本。要把这件事做顺，核心是先把测试套件的边界和目录定死，再把用例按层级和流水线节奏拆开，最后用一套复用机制把对象、数据与公共步骤收进同一处，后续新增模块才不会把旧结构冲垮。

在Squish里，对象映射失效最常见的原因，不是工具突然找不到控件，而是对象原来依赖的属性变了，比如标题文字变了、父对象层级变了、类名或某个动态属性变了。Squish官方文档对这件事讲得很清楚，对象映射本质上是Symbolic Name和Real Name的对应关系，脚本真正依赖的是Symbolic Name，执行时再用Real Name里的属性去查找对象。所以一旦控件属性变化，真正该修的通常不是脚本主逻辑，而是对象映射里的识别条件。

Squish激活失败，先不要只盯着“激活码对不对”，更要先分清这次走的是哪条授权链。Qt现在对Squish这类QA产品的许可证获取，已经纳入Qt License Service这一套流程里；官方排障文档也明确写到，用户在启动Qt或QA产品，比如Squish时，如果取不到有效许可证，问题往往会落在Qt License Service、Qt License Server、代理、防火墙、本地证书或服务配置上。换句话说，激活失败很多时候不是单一点故障，而是整条授权链里某一环没打通。

在Squish里看日志，先要分清你要看的到底是哪一类信息：一种是测试执行结果日志，主要看用例是否通过、失败点在哪、哪一行脚本触发了问题；另一种是工具自身的调试日志，主要用于排查Squish IDE、squishserver、squishrunner与AUT挂接过程中的异常。把这两类入口分开理解，后面读结果会清楚很多。

Squish对象识别不准，通常不是工具突然失效，而是对象名里混进了易变属性，或者界面刷新、时序和对象层级发生了变化。处理这类问题，最有效的路径不是反复重录脚本，而是先把对象识别规则改稳，再把属性选择口径固定下来，这样后面的脚本维护量会小很多。

做“squish与Jenkins集成怎么做，Jenkins触发squish任务怎么配置”，先把执行节点、Squish安装、任务触发跑通，再补报告与红灯规则，排错会省很多力。