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

　　一、Squish共享脚本的复用方法

　　共享脚本这种机制，它比较适合用来存放那些公共的操作步骤，并不是要把每个用例里头的业务判断全都一股脑儿塞进去；就拿登录、退出、打开某个固定的功能模块、等待弹窗冒出来、去读取配置信息，以及通用的断言来说，这些东西都是可以单独抽出来变成函数的。

　　1、先创建出共享脚本

　　首先要把共享脚本给建立起来，在Squish开发界面的【Test Suites】视图里面，找到【Test Suite Resources】这一项，然后点击【New Test Resource】，这样一个新的脚本文件就会产生了，建立了以后要给它换上一个能看出意思的名称，比如common.py、login.js或者ui_helper.py；官方文件里也同样讲到，可以通过【File】→【Import Test Resource】这样的菜单操作把现成的脚本给导进来，并且要把Import As这个选项设成Script才行。

　　2、放在合适的范围里

　　如果某个脚本仅仅只是为了让一个测试用例去使用，那把它放在这个用例自己的目录里就可以；但要是想让它被整个测试套件所共用，那就要把它搁在套件下面的shared/scripts目录里。当确实有好几个测试套件都需要共用一份脚本的时候，再去考虑启用Global Scripts，Global Scripts能影响到的面要更广一些，官方也提示说这是个进阶一些的功能，刚上手的人不要很随意地去用它。

　　3、在用例当中把脚本加载好

　　共享脚本可不是只要放到那里就能自己产生效果的，通常的做法，是要在测试的脚本当中写上一句加载的命令，假如用的是Python或者JavaScript，就可以采用source(findFile("scripts","common.py"))这种形式的语句，把它给加载进来了之后，那些定义在里面的函数才能够被正常地调用。Squish的文档里说明，findFile这个功能是用来给共享脚本定位的，source则会去执行对应的文件，这样文件里的函数和变量就能够在当前的脚本中变成可用的了。

　　4、函数的名字要保持稳定

　　公共函数在起名字的时候要做到让人看出它的用途，比如login_as_admin表达的是以管理员身份登录，wait_main_window表达的是等待主窗口出现，clear_test_data则是清除测试数据；像step1、doit、clickButton这种太笼统的叫法就不要再用了，不然到了后期需要多人一起维护的时候，就很难去判断这个改动会影响多大的范围。

　　二、Squish共享脚本导入后为什么不起作用

　　共享脚本在导入了以后却没有发挥作用，常碰到的原因并不是脚本的本身坏掉了，而是在导入的位置、加载的方式、文件的扩展名或者函数可用的范围上出了差错，首先得检查Squish是不是已经识别到了这个脚本，然后再去看看测试脚本有没有真正去用到它。

　　1、导入的时候把类型给选错了

　　在通过【File】→【Import Test Resource】的途径去导入的时候，一定要注意将Import As设置到Script上面，要是错误地把它当成测试数据给导入进去了，它虽然有可能在资源的列表里出现，但是却不会按照脚本的那种方式被别人使用。

　　2、存放的目录出现了差错

　　假如这个脚本是想让整个测试套件来复用的，那就要放在shared/scripts这个目录底下才行，要是被搁在了某一个具体的测试用例目录里面，那么别的用例就很有可能找不到它了；手动去复制文件的时候也要注意目录的层级结构，不要把地方给错弄成了shared/script或者testdata这类目录。

　　3、漏掉了source调用

　　共享脚本是不能自动注入到用例里去的，如果一个用例的开头位置，并没有去写source(findFile("scripts","common.py"))这类的加载语句，然后却在后面直接就去用那些公共函数了，那么运行的时候就会冒出来函数没有被定义，或者根本没有反应的状况；要是用的是Ruby语言去写脚本，依照官方的说明就应该去用require，而不是source。

　　4、脚本语言和它的扩展名不一致

　　假如测试套件选定了Python语言，那就不要把一个JavaScript写成的脚本导进来以后又直接去调用，文件的后缀名、里面的语法规则，还有函数定义的写法，都必须和测试套件所选的语言保持一致，要不然即便在开发工具的界面里头能看见那个文件，到了跑起来的时候也照样会报出错误。

　　三、Squish共享脚本该怎么验证

　　共享脚本被调整过了之后，可不要一上来就去跑全部的用例；更妥当的做法是先拿一个功能最少的简单用例，去验证加载成不成功、调用正不正常、返回值是否对，还有异常能不能被正确处理，等到确认这些公共的函数都已经稳定下来了之后，再把它推广到更大的范围里去。

　　1、先写一个尽可能小的调用

　　在一个测试用例里面只是去加载共享脚本，然后就只调用里头一个特别简单的函数，让它去打印一行日志，或者是返回一个固定的值，如果这个小用例能够顺利地跑下来，那就基本能够说明路径和加载的方式是可靠的。

　　2、查看运行过程中的日志

　　当运行失败的时候，要去看Squish的Test Results里面所报出的错误位置，要是提示说找不到文件，那么多半是findFile里面的参数给得不对、文件名出了错，或者目录本身存在问题；要是提示说函数没有被定义，那多半是source这条指令并没有顺利执行成功，又或者把函数的名字给写错了。

　　3、检查所依赖的那些文件

　　如果共享脚本在内部又去用到了别的对象名称、测试数据，或者配置文件和第三方的模块，那就还得去检查一下，看这些被依赖到的东西是不是也都放在能被访问到的位置上；公共的脚本能够成功加载上来，可不代表它里头所依靠的所有东西都能够顺顺当当地被使用。

　　4、把它纳入版本管理

　　shared/scripts目录、Global Scripts所在的目录以及对象映射文件，这些都是应当被列入版本管理范围内的，当有多个人一起对公共函数做了修改的时候，要把每一次变更的内容和原因给记清楚，要不然的话，公共函数上一个看起来不起眼的改动，没准儿就会牵连到一大堆的测试用例。

　　总结

　　总体上看，Squish共享脚本到底要怎么去重复使用，以及它导入以后为什么又不起作用，围绕的其实就是目录、加载还有作用域这三样东西；在一个套件内部进行共用，要把它放到shared/scripts下面去，如果是想让好几个套件一块儿共用，那就要很谨慎地去动用Global Scripts；在导入的环节得把类型选成Script，到了用例里面则要依靠source和findFile来完成明确的加载。要是导入以后没能起效，那就顺着导入类型、目录位置、加载语句写了没写、脚本语言是不是对得上，还有依赖文件是不是都到位了这几个方向，一项一项地去排查，这种查错的方法，比起一遍一遍地重新去录脚本要稳当得多。