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

　　一、关于Squish持续集成具体该怎么去接入

　　如果想把Squish接入到持续集成里面，一般情况下通过命令行去执行squishrunner，自动化平台那边主要负责把代码拉下来、把环境弄好、把构建任务启动起来，而Squish这边，就负责把被测软件拉起来、去跑测试套件、最后把测试报告导出来；要是用Jenkins的话，其实也可以通过装一个Squish插件，把测试运行的过程直接塞进Job任务里面，这样就能用来触发测试还有看结果了。

　　1、得先把自动运行的环境给准备好

　　在用来跑自动化的机器上面，需要先把Squish这个软件安装好，然后把许可证也配置上，被测软件运行需要的那些基础环境也得准备好，还得确认那个squishserver服务是可以正常启动的；因为是带界面的自动化测试，所以一定要特别注意桌面会话的问题，尤其是像Windows的远程桌面、Linux的虚拟显示，还有VNC环境这些，要是界面会话不稳当的话，脚本运行起来可能就会找不到控件、或者是截图报错、甚至输入内容也会失败，各种问题都会出来。

　　2、通过squishrunner去把测试套件跑起来

　　平时比较常见的执行命令，一般可以写成下面这个样子：

　　squishrunner--testsuite./suite_demo--reportgen junit,report.xml

　　如果说只想单独跑里面的某一个用例，那就在后面加上--testcase；如果是想按照标签去跑一整批的用例，就可以使用--tags；要是希望在测试失败的时候，命令能返回一个不是零的错误码，就可以配合用上--exitCodeOnFail，因为只有这样，自动化平台才能看出来测试失败了，进而把这次构建也标记成失败。Squish里面的这个squishrunner工具，它支持通过--testsuite、--testcase还有--reportgen这些五花八门的参数，来控制具体要跑哪些范围，以及报告要怎么输出。

　　3、把拿到的报告交给自动化平台去识别

　　在持续集成里面，大家通常比较喜欢用JUnit XML格式的报告，因为像Jenkins、TeamCity、Azure DevOps这些平台，它们去解析这种格式都比较方便；Squish自带的junit报告生成工具，可以输出JUnit格式的XML文件，我们在命令里写--reportgen junit,reportfile.xml就可以了，而且比起以前旧版本的xmljunit，新版的junit格式在保留Squish原本的测试结构上表现得更好。

　　二、自动运行之后的Squish执行日志到底该怎么看

　　在自动化平台里面看Squish的日志，千万不能只盯着最后的“成功”或者“失败”这几个字看，真正能帮上忙的信息，通常都分散在三个不同的层次里，分别是控制台的输出、测试报告、还有附件和截图；必须要把这三块内容合在一起来看，最后才好判断到底是因为环境出问题了，还是脚本写错了，或者是被测软件的功能真的做坏了。

　　1、得先去瞅瞅控制台的输出和退出码

　　控制台的日志，主要就是去检查squishrunner这个工具有没有正常被启动起来、测试套件的路径是不是对的、有没有成功连接到squishserver、以及被测软件有没有顺利启动成功；如果命令在一开始就失败了，比如根本找不到套件、许可证过期报错、或者是服务器连不上，那其实都还没进到真正的测试步骤里面去。

　　2、然后再去看看JUnit或者XML报告里面的具体内容

　　JUnit报告里面，一般都能看到测试套件、测试用例、具体跑了多长时间、失败的信息，还有报错的堆栈这些内容；Squish的JUnit报告会把Squish自己的套件和用例，对应映射到JUnit的结构里面去，自动化平台把这些数据解析之后，大家就能在测试结果的页面上很直观地看到是哪些用例没跑过、具体卡在哪个步骤上面了。

　　3、还要去查看保存下来的截图、附件和分段日志

　　在排查这种带界面的自动化问题的时候，截图和附件是非常有用的，Squish支持在测试报告里面把附件给记录下来，有一些报告生成工具甚至还能把附件和视频的路径也记下来；平时在写脚本的时候，也可以自己多用一些日志、检查点或者是截图，把失败时候的第一现场给留存下来。

　　三、遇到自动化执行失败的时候，怎么去排查才会比较稳妥

　　Squish接入到自动化平台之后，失败的原因往往比在自己电脑上要复杂得多，所以看到失败的时候先别着急去改脚本，应该先动脑筋判断一下失败到底是发生在哪一个层面的。

　　1、先排查环境层面的问题

　　如果是发现所有的用例全部都失败了，那就要优先去检查自动化机器的环境是不是有毛病，比如是不是Squish的路径配错了、许可证不能用了、被测软件缺少了什么依赖文件、图形会话没有正常打开、端口被别的程序占用了，或者是远程的server服务连不上；像这一类的大面积失败，通常都不是某一个脚本写错了，而是整个运行环境压根就没准备好。

　　2、再去排查脚本层面的问题

　　如果发现只是个别的用例偶尔失败了，这时候再去研究对象识别、等待条件、测试数据或者是断言的问题；因为自动化机器的运行速度通常比我们自己的电脑要慢一些，很多在本地自己电脑上能跑完的脚本，到了自动化机器里，就会因为页面加载太慢而报错，遇到这种情况，千万别简单粗暴地在里面加一个时间很长的sleep死等，更好的办法是去写代码等待具体的对象冒出来、等待按钮变成可以点击的状态，或者等待表格里的数据全部加载完。

　　3、在报告层面要把历史的结果给留存好

　　持续集成这个东西的价值，其实并不在于只跑那么一次测试，而是可以把多次执行的结果放在一起进行对比；所以比较建议在每次构建跑完之后，都把JUnit XML文件、完整的控制台日志、失败时候的截图，还有关键的附件都给留存备份。这样的话，要是发现某一个用例从某一个版本开始就一直持续失败，大家就能倒回去查一查，到底是产品功能改了、还是环境变了，又或者是脚本太久没维护所以没跟上变化。

总结

　　总的来说，关于Squish怎么接入自动化，以及日志怎么去看，这里的关键就在于要把squishrunner的命令、报告的输出格式、失败时候的返回码，还有自动化平台的解析规则，全部放在一起来进行配置；在刚开始接入的时候，要先保证自动化机器能够稳稳当当地把被测软件给启动起来，然后再让Squish去输出JUnit或者XML格式的报告；等到后面看日志的时候呢，就按照控制台、测试报告、截图附件这三个层次一步一步去分析，这样排查问题起来，肯定要比只看一行失败提示要明白得多。