随着自动化脚本运行的时间越来越长，遇到的问题不能仅仅依靠日志来进行猜测，此时，了解Squish脚本的断点怎么调试，以及调试时变量值怎么查看，就变得很重要了，这些事情通常需要从Squish IDE的调试运行功能开始，根据Squish官方的文档说明，Squish IDE是支持对测试脚本进行调试的，而且还可以结合断点去检查正在运行中的被测软件的对象状态，这样对于找出对象识别方面的错误、等待超时的问题，还有分支判断上的失误，都会很有帮助。

　　一、Squish脚本断点怎么调试

　　在正式开始断点调试之前，应当先保证脚本不是在普通的Run模式下被执行的，因为普通的运行只会把最终的结果给输出来，只有采用了Debug运行的方式，才能够在设了断点的地方把代码给停下来。

　　1、打开测试用例脚本

　　首先我们要在Squish IDE里面打开测试套件，然后进入到对应的测试用例中，并从里面找到它的脚本文件，这些文件可能是test.py、test.js、test.pl或者test.tcl；接着要把那些容易出错的代码位置提前找出来，像clickButton、waitForObject、mouseClick、test.compare这些操作的周围，往往就是问题容易发生的地方。

　　2、设置断点

　　接着是设置断点，在代码编辑器的左边行号那一块点一下，留意那个地方会出现一个断点标记，然后记得把脚本保存好；断点最好放在准备做对象操作的那一行前面，这样停下来了之后就能很方便地去查看对象名字、变量当时的值，还有执行时候的上下文情况，另外要小心不要将断点设置在空行上、注释行里面，或者是那些不会实际跑到的分支里头。

　　3、用Debug方式运行

　　我们要用调试的方式来运行脚本，做法是先选中需要的测试用例，然后去点击界面上面的【Debug Test Case】按钮，或者是其他调试功能对应的按钮；当脚本执行到事先设好的断点位置时就会自动暂停下来，整个界面也会切换到与调试相关的视图里面去，在这个时候不要关闭被测程序的那个窗口，因为该程序还正处在当前的测试状态之中。

　　4、使用单步调试

　　在暂停之后，就可以使用单步调试的那些按钮了，比如Step Over、Step Into，还有Step Return，用它们来一行一行地执行代码；对于普通的对象操作，选择Step Over这个按钮一般就够了，假如你想要进入到自定义函数里面去看看它内部的逻辑，那就得改用Step Into了，在进行单步执行的同时，必须注意去观察测试窗口的状态，这样才可以确认脚本发出的动作和界面给出的反应是不是一致的。

　　二、Squish脚本调试时变量值怎么看

　　关于查看变量值这件事，主要就是依靠Variables这个视图窗口来进行，按照官方文档给出的说明，Variables视图是放在Test Debugging Perspective这个透视图里面的，在它的视图里面会显示出测试脚本里的变量、被测程序的对象，还有和它们对应的具体数值。

　　1、打开变量视图

　　当断点被命中以后，我们就要去查看显示在界面上的【Variables】窗口；要是它没有直接出现，可以在Squish IDE里面先把界面切换到Test Debugging Perspective这个调试透视图，或者通过菜单里【Window】→【Show View】这样的操作来找到变量视图。

　　2、查看局部变量

　　在看局部变量的时候，因为脚本停在了断点那里，所以Variables里面就会显示出当前这个作用域下的所有变量，这些变量可能包括了对象的名字、循环所用的计数、函数的参数，还有返回值以及字符串里头的内容等等；如果碰到分支判断的地方不正确了，第一个要做的就是去检查那个参与判断的变量，看它当前的值是不是和事先预想的一致。

　　3、展开对象属性

　　假如遇到的变量是一个被测程序里的对象，那么它是可以被展开的，展开了之后就能看到关于这个对象的更多详细信息了；像这个对象当前是不是存在的，它的各个属性值有没有发生过变化，以及它携带的文本内容是不是空的，这些情况全都能看到；很多次waitForObject失败的问题，实际原因就是对象的名字虽然写对了，但是它实际的属性已经跟当初录制的时候完全不一样了。

　　4、用控制台临时验证

　　有时候还可以利用控制台来做一些临时的验证工作，在比较新的Squish版本里面，当脚本在进行调试的时候，是支持使用Live Script console这个功能的，只要断点被命中了，就可以在调试器的旁边去执行一些简短的脚本语句，用这个办法来临时性地检查一下变量怎么样了、对象正不正常，或者某个表达式算出来的结果是什么；这样做特别适合用来快速地确认某一个对象的查找表达式到底能不能把正确的结果给返回来。

　　三、Squish断点不生效怎么排查

　　当出现了断点不生效的情况，先别一上来就去怀疑是不是这个IDE本身出了问题，首先应该检查的，是看脚本到底有没有真正执行到设了断点的那一行代码那里。

　　1、确认使用Debug运行

　　要先把运行的模式确认清楚，如果是点到了普通的Run上去运行的话，那么断点是肯定不会按照调试的那种方式来停住的，这时需要重新去选择Debug Test Case，然后再来运行一次。

　　2、确认代码路径会执行

　　接着要确认一下代码执行的路径是不是真的会经过那个地方，要是把断点放到了if的分支里面、异常捕捉的分支里面，或者是循环的内部，一旦触发这些分支的条件没有满足，脚本自然也就不会在那个地方停下来了；所以刚开始可以先试着把断点安放在main函数那里，或者是测试开头的位置，这样就能先确认整个调试的链路是能够正常工作的。

　　3、确认脚本文件是当前用例

　　还需要保证当前使用的脚本文件，正是对应到正在执行的那个测试用例的，因为有时候可能出现这样的情况，手里在改一个被复制出来的脚本，但实际让Squish起跑的时候，运行的却是另一个完全不同的Test Case；所以最好检查一下在测试套件树形目录里显示的脚本路径，和实际要跑的那个用例，它们之间是不是能够对得上的。

　　4、确认异常没有提前中断

　　最后也要确认，在跑到断点之前，脚本有没有被什么错误提前就给中断了，比如因为对象找不到而报错，或者是等待超时了，又或者是代码本身的语法有错误，一旦在前面就停下来了，它肯定不会继续往后走到那个断点；所以得先去看一下Test Results里面的结果，还有Log输出的一些信息，把这些挡在前面的错误先清理干净。

　　总结

　　总的来说，如果要弄清Squish脚本的断点该怎么调试，还有调试的时候变量值要怎么去看，那么操作的顺序一般就是先在脚本的行号边上把断点设置好，接着用Debug的运行方式把测试用例给启动起来，等到断点被命中了之后，再利用单步调试的功能和Variables视图去查看那些变量、对象，还有它们对应的具体数值；要是断点没有生效，重点要排查的就包括了运行的模式、代码实际走的路径、脚本文件本身，还有在前面就已经出现的报错信息，通过这样一套方法来排查问题，比起单单依靠分析日志要来得更加直接一些，同时也更容易就能定位出脚本到底是在哪一步被卡住了。