在使用Squish工具开展自动化测试的过程中，多数操作者在初期阶段均会首先应用录制功能，该方式的上手速度较快，其能够直接将鼠标点击、键盘输入以及菜单选择等日常动作转化为代码脚本，然而通过录制生成的脚本，并不能够直接投入到长期且稳定的运行当中。针对Squish测试脚本的录制与回放异常排查，其核心要点并不在于“完成录制”这一动作本身，而是在于录制结束之后，操作者需要将零散的脚本重新整理，使其转化为具备可维护性的测试用例。

　　一、Squish测试脚本的录制流程

　　在开展脚本录制工作之前，操作者需要对测试套件、AUT（被测应用）的配置情况以及整体的运行环境进行确认，确保各项参数没有出现疏漏；Squish IDE在默认状态下，会调用相对应的squishserver配置，以此来执行录制与回放操作，如果服务配置、AUT路径或者启动参数存在错误，在后续的录制环节中，系统可能无法正常拉起目标应用程序。

　　1、创建测试套件与测试用例

　　操作者在进入Squish IDE界面后，需要先将Test Suite（测试套件）建立起来，随后在此套件的下方将Test Case（测试用例）创建完成；当测试用例建立完毕，操作者可以点击该用例旁边的【Record】按钮，此时录制流程正式启动；此处存在一个需要注意的细节，即如果测试用例内部已经存在了既有脚本，再次点击录制按钮，原有的脚本则有可能会被覆盖替换；倘若操作者仅仅是希望在已有脚本的中间部分添加一段操作，使用【Record Snippet】功能来插入片段则更为稳妥。

　　2、依据真实业务流程对AUT进行操作

　　当录制状态开启后，操作者应当依照人工测试的既定顺序来对软件进行操作，其具体动作包括打开窗口、输入账号、点击按钮、切换页签以及选择菜单等；在录制的过程中，操作者不应盲目乱点，同时应当避免进行与测试目标毫无关联的操作，因为这些多余的动作都会被系统写入脚本内部，在后期的清理工作中会带来较多麻烦。

　　3、录制结束后对Object Map与脚本内容进行检查

　　Squish在对测试用例进行录制时，系统会将访问过的各类对象全部记录到Object Map当中，并且会为这些对象保存symbolic name（符号名）与real name（真实名）之间的映射对应关系；在脚本中被直接观测到的对象名称通常较为简短，而真正被系统用于查找控件的依据，则是Object Map内部所存储的属性组合。

　　二、Squish测试脚本回放异常的排查手段

　　在面对回放异常的情况时，操作者不能够仅仅将目光局限在最后一行的报错信息上；在很多情况下，真正的错误根源发生在前面的步骤中，例如页面未能成功跳转、弹窗没有如期弹出，或者数据尚未加载完毕，这些情况都会导致后续的对象无法被系统识别；因此，排查人员应当顺着测试日志，向着前期的步骤进行逆向追溯。

　　1、确认异常类型与出错的具体位置

　　当系统回放失败之后，操作者应当首先将Test Results或者Test Log打开，借此来确认该故障究竟属于对象无法寻获、断言失败、脚本语法错误，还是属于AUT启动失败；如果问题被判定为对象无法寻获，Squish在执行waitForObject超时之后，界面上可能会弹出Object Not Found的对话框，该提示窗口会把查找失败的对象名称以及相关的错误信息展示出来。

　　2、对象无法寻获时对属性进行重新抓取

　　对象识别失败属于自动化测试中发生频率较高的常见问题；操作者可以借助Object Spy工具，对当前界面上的对象进行重新拾取，并且将新抓取到的属性与Object Map内部的real name进行细致比对；Squish在执行录制或者利用Spy拾取对象的时候，系统会自动将对象名生成出来，该对象名有可能是由多属性组合而成的real name，也有可能是具备层级关系的对象名。

　　3、对等待时机与页面所处状态进行检查

　　有些回放异常的产生，并不是因为对象名称出现了错误，而是由于脚本执行查找的动作过早。在进行人工操作时，测试人员会根据经验自然地等待页面显现，然而脚本却只会机械地立刻执行下一步骤；例如，在点击登录按钮之后，页面还没有完成跳转，脚本便已经开始寻找主界面的按钮，此时系统就会产生对象不存在的报错。

　　三、录制脚本结束后需核对的其他要点

　　录制操作在本质上仅仅是生成了一份脚本的初稿，在后续的工作中，操作者还需要将这份初稿整理成能够反复投入执行的正式用例；特别是在进行回归测试的时候，脚本在单次运行中不报错，并不能代表其在下周依然能够稳定跑通，许多异常情况的发生，实际上都是由于录制后的脚本没有经过精细化整理而导致的。

　　1、将固定数据转化为可维护的数据

　　在录制期间所输入的账号、文件路径、搜索词以及表格内部的数据，往往会被系统直接写入到脚本代码之中。如果这些数据在后期面临变动，较好的处理手段是将它们提取出来并转化为变量，或者将它们统一放置在外部的测试数据文件里；通过这种方式，当后续需要更换运行环境、切换测试账号或者变更样本数据时，操作者便不需要在脚本的各个角落进行到处修改。

　　2、补充必要的测试检查点

　　在测试过程中，仅仅录制点击与输入等动作是远远不够的，脚本能够顺利跑完流程，并不直接等同于软件的功能完全正确。操作者应当在测试的关键节点上，手动添加Verification Point（验证点），例如对对象的属性进行检查、对文本内容进行核对、对截图进行对比，或者对界面所处的状态进行判定；Squish工具支持操作者在录制的过程中，或者在脚本调试运行到特定位置之后插入检查点，以此来辅助判断界面是否达到了预期指标。

　　3、区分“重新录制”与“局部修正”的处理界限

　　当脚本在回放中遭遇失败时，并不建议操作者将整条测试用例进行推倒重录。因为整条用例的重新录制，极其容易在系统中生成重复的对象映射关系，并且容易将原本已经过人工整理和优化的代码进行覆盖；更为合理的做法是，操作者应当对失败的步骤进行精准定位，随后仅对出现问题的对象名、等待条件或者局部操作进行修改；只有在确实存在新增业务流程的情况下，操作者才需要利用Record Snippet功能来补录一小段局部的操作。

　　总结

　　基于以上分析，针对Squish测试脚本的录制方法以及回放异常的排查流程，其核心的关键点在于将录制动作视为自动化测试的起点，而不能将其当作最终的完结产物；在录制阶段，操作者应当保证业务流程的干净与准确，在录制结束之后，则需要对Object Map、等待逻辑、测试数据以及检查点进行逐项的核对；当回放遇到异常时，操作者应当先对日志进行查看，进而去判断问题究竟是出在对象、时机、脚本本身还是运行环境上，依照这样一个顺序开展排查，后续的脚本维护工作才能够变得相对轻松一些。