在用Squish这个工具做自动化测试的时候，脚本可能会出问题，其实很多时候不是写脚本的逻辑搞错了，主要还是软件里的控件对象没办法被系统稳定地认出来。关于Squish对象识别怎么配置，以及Squish对象识别失败后怎么重新定位这两个问题，它的核心解决办法就是要把对象名字配置得既能起到唯一的区分作用，又不能写得太死板。

　　一、Squish对象识别怎么配置

　　系统在识别对象的时候，会在Object Map这个自带的映射表里把对象的映射关系保存下来。一般来说，一个控件对象会对应着两个名字：一个是在写脚本时能看到的符号化名字（symbolic name），另一个是由各种属性和对应数值组合起来的真实名字（real name）；当测试人员运行脚本的时候，Squish系统就会拿着真实名字里面的属性条件，去软件的内存里面挨个查找对应的控件。

　　1、先看Object Map里的对象名是否稳定

　　测试人员在打开【Object Map】界面以后，不能只看控件有没有被录制进去，还要仔细观察真实名字（real name）里面到底使用了哪些属性。

像文本（text）、标题（title）、窗体名称（caption）这类的属性虽然看起来很直观，但是它们其实是非常容易发生变动的，如果按钮上的文字会随着系统语言、软件状态或者文件名发生变化，那么直接用这些属性去让系统识别，结果就会很不稳定。

　　2、尽量使用稳定属性组合，而不是单个易变属性

　　在进行对象识别的时候，并不是把属性写得越多就越好。如果使用的属性太少了，系统就可能会同时匹配到好多个不同的控件；但要是属性写得太多了，又很容易因为其中某一个属性发生了小小的变化，从而导致整个识别条件直接失效。比较合适的做法是，测试人员把能够区分控件的关键属性保留下来，比如把控件的类型、它外层的父级容器、固定的id或者固定的name留着，然后把在软件运行过程中经常发生变化的属性给删掉。

　　3、合理使用通配符或正则匹配

　　有一些对象的属性虽然不是完全固定不变的，但是它的变化过程是有规律可循的，比如窗口的标题今天可能是“项目A-编辑器”，明天可能变成“项目B-编辑器”。遇到这种特殊情况，测试人员就可以考虑在里面使用通配符或者正则表达式，这样能让系统的识别条件变得更灵活一些。在Squish系统里，对象属性一般是要求必须精确匹配的，不过多数的字符串属性也可以选择使用精确、通配符或者正则这三种方式，只有部分特殊的属性仍然被系统硬性要求必须精确匹配，比如类型（type）、Web网页里的标签名（tagName）、以及Java语言里的基础类型（basetype）等。

　　二、Squish对象识别失败后怎么重新定位

　　当系统出现对象识别失败的情况后，我不建议测试人员直接把原来的旧对象删掉然后重新录制。因为这样做虽然表面上把眼前的错误给解决了，但是时间一长，Object Map映射表就会变得越来越杂乱，同一个按钮在表里可能会出现好几个差不多的小对象名，这给后期的脚本维护工作带来了很大的麻烦。

　　1、先用Object Spy确认对象当前属性

　　测试人员可以先打开被测的软件，然后通过【Object Spy】工具或者Pick抓取工具把那个识别失败的控件重新抓一下，接着重点对比一下这个控件现在的属性和Object Map表里原来存的真实名字（real name）有什么不同。Squish系统在没有找到明显的识别办法时，测试人员可以使用Spy工具来获取一个合适的物体名字，或者也可以先录制一段临时的测试脚本，再通过点击【Open Symbolic Name】去查看它真正的对象名字。

　　2、对比旧对象名和新对象名，保留稳定部分

　　在重新定位控件的时候，测试人员不要直接把Spy工具抓到的新真实名字（real name）一字不差地替换进去。正确的做法是，测试人员应该把旧的真实名字和新的真实名字放在一起进行对比，好好找出哪些属性是没有变的，哪些属性又是变动了的。

　　3、必要时从父级容器重新定位

　　有一些控件对象本身是没有自带那种稳定id的，特别是在面对表格里面的单元格、动态生成的列表、树状图的节点、还有弹窗里临时出现的控件时，这类对象如果直接让系统去识别就会非常困难。针对这种情况，测试人员可以先在外面定位一个比较稳定的父级对象，比如先找到主窗口、固定的面板、或者整个表格控件，接着在这个父级对象的范围圈里面去查找底下的子控件。

　　三、对象识别维护时要重点检查哪些细节

　　Squish里面的对象识别配置工作，并不是只要录制一次脚本就彻底结束了，因为项目的界面随时可能调整、控件可能会升级，这些都会对对象的定位产生影响。为了尽量减少后期脚本出现大面积报错的情况，测试人员在平时就要注意把对象名字维护得稍微干净整洁一点。

　　1、少依赖occurrence这类顺序属性

　　如果测试人员发现对象的属性名字里面出现了occurrence这个词，这通常说明Squish系统在录制的时候没有找到更好的、能够用来区分的属性，所以只能无奈地用“第几个对象”这种排队的顺序来给它进行定位。这种方式虽然能让脚本勉强跑起来，但是它一点都不稳定。只要界面上多出来一个同类型的按钮，或者少了一个控件，原有的排队顺序就会被全部打乱，脚本就会错误地点击到别的对象上去。

　　2、给动态界面增加等待和状态判断

　　有些时候系统报错说识别失败，不是对象名字取得不好，而是那个控件对象在界面上还没来得及加载出来。比如页面刚刚发生切换、数据表格还在转圈刷新、或者是弹窗的动画还没有播放结束，这个时候脚本就迫不及待地去查找对象，系统自然就会报错说找不到了。

　　3、定期清理重复对象映射

　　同一个控件如果被测试人员反复录制了很多次，Object Map映射表里面就可能会堆积出好几个看起来差不多的对象名字。这在短期内虽然看不出有什么坏的影响，但是从长远来看，会让脚本变得越来越难维护。比较好的工作习惯是，测试人员只保留一个最稳定的对象名字，然后把脚本里面那些重复生成的、多余的对象引用全部手动合并过去，最后把那些没用的映射关系彻底删掉。

总结

　　当对象识别出现失败的时候，测试人员真正应该做的事情是去动脑筋判断“它为什么会失败”：到底是对象根本就没在界面上出现，还是属性变了，或者是父级变了，又或者是匹配的范围放得太宽了。测试人员把这些原因一条条理清楚了之后，再去动手修改Object Map、调整属性内容、增加等待时间或者是从父级重新进行定位，这样操作下来，脚本的稳定性绝对会比单纯地去重新录制要高得多。