Squish脚本在本地的软件里能跑通，其实只能说明单机环境没大问题，如果真的要把脚本放到实际项目里面，通常都是需要接入到Jenkins、或者是TeamCity、Azure DevOps这些自动化的持续集成平台里面的，这样就能在每次项目构建好之后自动去跑测试，还能把生成的报告结果给存下来；其实关于Squish怎么接入，还有日志怎么去看的问题，最核心的并不是说简简单单把命令往流水线里一放就行了，而是要把运行时候的环境、测试套件放在哪里的路径、最后报告要什么格式，还有失败时候的返回码，这些零碎的东西全部都得配置明白才行。

关于Squish断言检查的添加方法，以及结果不稳定时的解决对策，自动化脚本虽然可以进行按钮的点击和内容的输入，但是这只能证明测试流程被跑通了，功能的最终结果是不是正确并不能被保证；所以在开展自动化测试的时候，断言检查是不能被缺少的；通常所说的Squish断言，其实更多的是指验证点，也就是把某个对象属性、表格数据、截图或者界面状态拿来检查，看看它们是不是和预期一样；关于如何把断言添加进去，以及结果不稳定要怎么处理，重点并不是要把检查点加得越多越好，而是测试人员要把它们加在关键的位置上，那些经常发生变化的内容需要被避开。

当录制的脚本慢慢变多以后，那些反复出现的登录操作、打开页面的行为、清理数据的步骤以及等待控件出现的逻辑，维护起来就会变得越来越费劲；要说清楚Squish里面的共享脚本该怎样重复使用，以及它被导入之后为什么又不起来了作用，最关键的一点，就是要把那些公共的函数给存放到合适的目录下面，并且还要在用例的脚本里明确地把它加载进来。按照Squish官方的说明文档，共享脚本可以被安置在测试套件下的shared/scripts这个目录里面，也能作为Global Scripts拿给多个测试套件去共同使用。

随着自动化脚本运行的时间越来越长，遇到的问题不能仅仅依靠日志来进行猜测，此时，了解Squish脚本的断点怎么调试，以及调试时变量值怎么查看，就变得很重要了，这些事情通常需要从Squish IDE的调试运行功能开始，根据Squish官方的文档说明，Squish IDE是支持对测试脚本进行调试的，而且还可以结合断点去检查正在运行中的被测软件的对象状态，这样对于找出对象识别方面的错误、等待超时的问题，还有分支判断上的失误，都会很有帮助。

在Squish里做OCR，识别错并不一定说明OCR引擎本身坏了，更常见的情况是语言提示没给对、识别区域放得太大，或者界面文本的渲染方式和默认放大参数不匹配。Qt官方文档写得很清楚，Squish默认依赖Tesseract做OCR，而且Tesseract需要单独安装；同时，OCR相关函数本身就提供了`language`、`scaleFactor`、`searchRegion`、`timeout`这些参数，说明官方本来就把语言、缩放和识别范围当成影响结果的关键因素。

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

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

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

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

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