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

　　一、Squish录制怎么开始

　　真要把录制跑顺，先不要急着直接点录制按钮。更稳的顺序，是先建好Test Suite，再建Test Case，最后再开始录制。官方教程写得很明确，录制不是直接落在一个临时脚本里，而是录到现有测试用例中，所以前面这两层要先站稳。

　　1、先新建Test Suite

　　官方教程说明，进入Squish IDE后，要先通过【File】【New Test Suite】创建测试套件，再在向导里选择工具包、脚本语言和AUT。很多人觉得这一步只是填目录，其实它决定了后面对象识别方式、脚本语言和整套测试资源的落点，不能省。

　　2、再新建Test Case

　　Squish的录制是录到测试用例里的，不是点一下Record就自动生成一套独立工程。官方教程里给了两种常见方式，一种是【File】【New Test Case】，另一种是在Test Suites视图里直接新建Script Test Case。建好以后，测试用例目录和对应脚本文件就会一起生成。

　　3、然后再点Record开始录制

　　官方教程写得很直白，点测试用例右侧的【Record】以后，Squish会连接到squishserver，隐藏IDE，并打开Squish Control Bar。这个阶段你在AUT里的操作，就会被记录成测试步骤。所以真正开始录制的标志，不只是脚本编辑器打开了，而是Control Bar已经起来，AUT也进入了可交互状态。

　　4、录制时顺手把对象先走一遍

　　这一点很实用。官方Object Map文档明确提到，录制过程中，Squish会自动创建或复用Object Map，并把本次访问到的对象加进去。官方还建议，如果后面准备手写脚本，最快的办法之一就是先录一个dummy test，把需要用到的对象都碰一遍，这样Object Map会先被填起来，后面写代码会轻很多。

　　二、Squish录制脚本可维护性怎么提高

　　脚本可维护性，不是录完以后再补救的东西，而是录的时候就已经开始决定了。Qt官方文档里最核心的一条线，就是让脚本尽量依赖Symbolic Name和Object Map，而不要在脚本里到处写真实对象属性。对象一旦改名、层级一旦变化，只改映射表和少数公共代码，后面的脚本才不会整片失效。

　　1、优先用Symbolic Name，不要到处写Real Name

　　官方教程专门解释了Symbolic Name的意义。录制出来的对象通常会以`names.`开头的变量形式出现在脚本里，这些变量背后对应的是Object Map中的真实属性集合。这样做的好处很直接，应用对象名字变了时，你改的是映射，不是整套脚本。维护性最值钱的地方，往往就在这里。

　　2、Object Map要尽量收成稳定名字

　　官方文档明确说，Object Map的目的就是把对象名集中维护，避免同一个对象名在脚本里重复出现很多次。真到项目里，更稳的做法不是让录制器生成什么名字就照单全收，而是录完以后回头整理Object Map，把明显依赖窗口标题、层级过深或者太临时的名字收成更稳定的符号名。这样后面界面小改时，脚本不会一下子断一大片。

　　3、同步不要只靠录制时的固定等待

　　这一点特别重要。官方同步文档说明，录制时可以通过设置让脚本插入基于时间的`snooze`语句，但更适合长期维护的方式，是用条件等待和对象等待。官方API里明确写到，`waitForObject`是手写脚本中的标准做法，而`waitFor`则适合轮询某个条件是否成立。说白了，时间等待只能凑合跑通，条件等待才更适合长期维护。

　　4、重复动作尽量抽到Shared Scripts里

　　官方教程和共享脚本文档都提到，Squish支持Shared Scripts和Global Scripts，用来放测试套件之间可复用的公共代码。这个能力对维护性很关键，因为登录、打开页面、初始化数据、关闭窗口这类动作，一旦每个用例都录一遍，后面改一次就得找很多地方。把公共动作先抽出来，脚本会短很多，后面也更好改。

　　三、Squish录完以后先整理哪几处

　　很多人录完第一遍脚本就直接拿去跑，短期当然也能用，但后面一旦界面变一点、对象层级改一点，维护成本就会很快上来。更稳的做法，是录完以后先做一轮“整理”，而且重点不用铺太大，先整理最影响后面维护的那几处。这个思路和官方文档里对Object Map、同步点、共享脚本的分层设计是一致的。

　　1、先整理Object Map

　　录制出来的第一版Object Map往往能用，但不一定好用。官方文档说明，Object Map可以在IDE里编辑，也可以检查对象是否仍然存在。实际工作里，第一轮最值得花时间整理的，就是把明显不稳定的对象名先收掉，把后面会反复用到的对象先改成容易看懂、容易复用的符号名。

　　2、再把硬编码等待替成对象等待或条件等待

　　如果脚本里录出来很多固定停顿，后面最容易出问题的通常也是这里。官方同步文档已经明确区分了基于时间的同步和更稳的条件同步，所以录完以后回头清一遍等待逻辑，往往比急着补断言更值。脚本要想不脆，先把同步做稳。

　　3、把重复步骤抽成公共函数

　　如果两三个测试用例里都已经出现了同一段操作，比如启动、登录、进入某页面、保存退出，那就不该继续留在各自脚本里。官方共享脚本文档本来就是为这件事准备的。录制只是起步，真正进入可维护状态，通常都要经过这一步整理。

　　4、最后再补验证点

　　官方教程提到，验证点既可以在录制时插进去，也可以在录完以后再补，常见形式包括属性验证、表格验证、截图验证和视觉验证。更实际的做法通常不是一边录一边塞很多验证，而是先把流程录顺，再回头补关键检查点。这样脚本会更干净，后面改起来也不容易把动作和断言搅在一起。

　　总结

　　Squish录制真要用得住，重点从来不是第一遍能不能录出来，而是录完以后有没有把对象名、同步方式和重复步骤先收顺。起步时先建Test Suite和Test Case，再点Record正常录一遍，这一步不难。难的是录完以后别急着交差，先整理Object Map，再把固定等待换成条件等待，再把重复动作抽到Shared Scripts里。这样做下来，脚本就不只是“录过”，而是后面真改界面、真加用例时还能继续维护。