自动化测试被放进持续集成的流水线里面去跑之后，慢慢就会发觉，真正容易出问题的往往已经不是测试脚本写得对不对了，而是更多集中在运行的环境、文件存放的路径、执行时的权限，还有被测程序本身是怎么被启动的这个方面上。要说清楚对Squish和Jenkins的集成工作到底应该怎样去配置，以及在Jenkins上面的任务跑失败了以后又该怎么去排查，这里面最核心的一个事情，就是需要让Jenkins能够稳稳当当地把squishrunner这个运行器的命令给调用起来，同时还必须保障squishserver服务、存放测试案例的套件、被测的应用程序，以及用来放置测试报告的目录，都能够被当前这台负责执行任务的节点机器正常地访问到。实际上，Squish这个工具是支持通过Jenkins里创建的任务来跑测试的，在这个过程里头，squishrunner会专门负责去执行测试的脚本，并且和squishserver之间进行通信。

　　一、怎样去配置Squish和Jenkins的集成

　　在Jenkins里头配置Squish的时候，刚开始先不用急着去写出那些特别复杂的流水线脚本，一个比较推荐的做法，是先到Jenkins的执行节点机器上面，用手动敲命令的方式把整个流程给走通了，然后才把这个已经验证过的命令放到任务的配置页面里面去。

　　1、要确认好执行节点上面的环境

　　在用作Jenkins节点的那台机器上，需要先把Squish这个软件给装好，并且逐一去确认它的授权许可是正常的，被测的应用程序和测试套件也都可以使用，运行时所依赖的那些库文件也都不缺；如果使用的是Windows操作系统的节点，就要额外留意桌面会话的状态和操作权限的问题，要是Linux系统的节点，那就得去检查显示环境、字体文件、依赖库以及文件的可执行权限是不是都已经设置妥当了。

　　2、接着是去配置工具的路径

　　进入到Jenkins任务的【Configure】界面里面以后，我们在构建步骤的部分，可以去添加一个【Execute Windows batch command】或者【Execute shell】的步骤，接着要做的事情，是把Squish安装目录底下bin文件夹的那个路径，添加到系统的PATH环境变量里面去，或者图省事的话，也可以直接用绝对路径的方式去调用squishrunner这个程序，但是有一件事情要注意，就是不能去依赖人工在登录系统后留下的那些临时的环境变量。

　　3、再往下是编写具体要执行的命令

　　比较常见的那种执行命令，可以写成类似squishrunner--testsuite后面跟测试套件路径，然后再带一个--local参数的形式，这个--local参数所起的作用，是让程序去启动一个本地的squishserver来执行测试，这种用法在单机节点的场景下很合适；要是你的环境里用的是外部的server，那就需要先把squishserver给跑起来，然后再让runner去连上它执行，在Squish的命令行帮助文档里头，也对testsuite、testcase这类常用的参数做出了说明。

　　4、最后一定不要忘记保存测试的结果

　　每次构建都应该被分配一个独立的结果存放目录，比如可以在workspace目录下面创建一个叫squish-results的文件夹，等到任务全部执行完了以后，再通过Jenkins的归档功能，把生成出来的结果、日志还有截图都存起来；这么做的好处是很明显的，万一任务失败了，那么直接去看归档下来的产物就能排查问题，而不必再专门登录到测试机器上，去临时目录里面翻找。

　　二、Squish的Jenkins任务执行失败后要怎么去排查

　　一旦Jenkins上面的执行出现了失败，第一步要做的，就是先去大致判断清楚失败的发生位置，看它到底是在Jenkins调度任务的阶段，还是在Squish启动的阶段，又或者是在被测程序也就是AUT启动的时候，还是说已经进到了脚本实际运行的过程里；这个时候，可千万不能只去盯着构建页面最下面显示的那一行错误信息。

　　1、首先要去查看控制台里的日志

　　打开Jenkins的构建记录，点进【Console Output】这个选项，在里面去确认squishrunner的命令是不是真的被执行到了，要是系统提示说找不到这条命令，那多半是因为PATH的设置有问题，或者是绝对路径给写错了；如果提示的是测试套件不存在，那就需要去检查一下workspace的路径和拉取下来的代码目录是否对得上。

　　2、接下来去检查Runner和Server两边的日志

　　在Squish里面，Runner和Server的Log会把squishrunner和squishserver相关的许多信息都给记录下来，这里面包括了AUT是怎么启动的、Hook的调用情况、超时的相关信息等等，每当我们碰到被测程序启动不起来、连接建立失败、或者对象识别出现异常的时候，都需要把这类日志作为最先查看的材料。

　　3、要去确认AUT确实可以在节点上被启动

　　要知道，Jenkins服务在运行时所使用的账号，和我们平时手动登录时候用的账号是不一样的，一个人在电脑上双击能打开的程序，并不代表Jenkins服务也能够同样把它给打开；这就要求我们去检查程序的路径、工作目录、配置文件、依赖库、显示方面的权限，甚至还有杀毒软件会不会拦截，特别是在做GUI测试的时候，更要去确认执行节点是不是处在一个可交互的桌面会话里面，或者至少有一个可用的显示环境。

　　4、还要去检查测试套件的路径有没有给错

　　命令当中的--testsuite参数，它后面应该指向测试套件所在的目录，而--testcase参数后面跟的应该是用例的名称或者存放用例的文件夹，可不要错误地把它们直接指向了脚本文件本身；如果路径里面包含了空格的话，要记得在两边加上引号，在跨平台任务里，还需要留意斜杠的方向是不是正确。

　　三、Squish Jenkins任务失败以后怎么去做稳定的修复

　　任务如果是偶尔才会失败一次，那么重点就应该放到环境条件能不能被重现上头，仅仅一次失败的时候，不要急着去改动测试脚本，而是应该先把这一回产生的日志和当时的环境情况给保留下来。

　　1、把工作目录给固定下来

　　在任务的配置当中，要明确地切换到workspace目录或者测试套件的目录里面去，这样做就可以避开因为使用相对路径，导致在不同节点的机器上路径被解析出不一样结果的问题。

　　2、在构建前清理掉旧的进程

　　每次开始新的构建之前，都需要结束机器上还在残留的AUT进程和squishserver进程，这样做是为了避免端口被占用的情况发生，或者旧的窗口还挂在那里造成干扰，以及在识别对象的时候产生错乱。

　　3、增加测试结果的归档内容

　　要把测试日志、截图、HTML格式的报告，还有Jenkins控制台里输出的日志，这些东西全部都放到一起进行归档保存，这样等到失败发生以后，就可以直接把执行的步骤、当时对象的状态，还有报错出现的时间点这些信息拿来进行对照，排查起来会清楚很多。

　　总结

　　总的来讲，Squish和Jenkins的集成怎样去配置，还有Jenkins上面任务执行失败了要怎么去排查，这两件事情最要紧的一个关键，就是一定要先在执行节点的机器上，用手动的方式把squishrunner的命令给跑通了，然后再把这个命令放到Jenkins的任务里面去用；等到任务失败以后，需要按照命令的路径、测试套件的路径、squishserver的连接情况、AUT的启动环境，还有输出的结果日志，像这样一项一项地往下排查；如果我们能够把执行的命令、结果的存放目录，以及构建前的清理操作都固定下来，那么Jenkins里面的Squish任务运行起来就会变得稳定许多。