Squish脚本在变多以后，测试用例就不能一个个散着放了，像登录、查询、新增、删除、导出、异常提示这些流程，如果全部堆在一个目录里面，前期可能还得看懂，后期一跑回归测试就很轻易会变乱。所以说，Squish测试套件怎么管理以及Squish测试套件执行顺序怎么调整，这些事情的重点不是要把用例的数量做多，而是要把套件的结构、共享的资源、标签的分组还有执行的顺序先理好。

　　一、Squish测试套件怎么管理

　　在Squish里面，Test Suite其实可以看成是一组测试用例的外层盒子，根据官方文档的说法，测试套件就是一组Test Case的集合，它们通常放在一个共同的父级文件夹里面，而且带着一个叫suite.conf的配置文件；在套件里面还会有一个shared/目录，是用来放很多个用例都要共用的脚本或者数据的，一个套件虽然可以包含不同类型的测试用例，但是脚本语言只能选择一种。

　　1、按功能模块拆分测试用例

　　操作人员进入【Test Suites】视图以后，就可以在当前的测试套件下面新建Script Test Case、BDD Test Case或者是MBT Test Case了，在实际的项目里面，不要把所有的操作都录制到一个用例里，比较好维护的做法是按照业务模块把它们拆开，比如搞成tst_login、tst_add_user、tst_search_order、tst_export_report这种。Squish的Test Cases面板，就是专门用来管理当前套件下面的这些测试用例的。

　　2、把公共脚本和测试数据放到共享目录

　　有很多用例都会用到登录、退出、清理数据、创建基础数据这些相同的动作，要是每个脚本都去复制一份的话，后面一旦修改了账号或者登录流程，就得四处去改。更合适的办法是把公共的方法放到【Test Suite Resources】或者shared/目录里面，然后再到测试脚本里面去引用它。Squish文档里面也写了，Test Suite Resources是用来存整个测试套件共享资源的，共享的脚本可以通过source(filename)来使用。

　　3、用标签和说明区分用例用途

　　用例变多了以后，光靠名字可能就不太够用了，大家可以在【Test Suite Settings】里面的Test Case Information中，给脚本类的测试用例填写summary、description还有Tags。标签可以用来区分冒烟测试、回归测试、订单模块、导出模块这些东西；后面用命令行执行的时候，也可以按照标签来筛选出一批用例。

　　二、Squish测试套件执行顺序怎么调整

　　关于测试套件执行顺序怎么调整，这得看具体的使用场景，如果大家只是在IDE里面跑，那就可以通过Test Suites视图里面的用例列表和勾选状态来控制；如果是用命令行或者持续集成来执行，那就得看suite.conf、--testcase、--skip-testcase还有--tags这些配置了。

　　1、在IDE里调整用例选择和执行范围

　　在【Test Suites】视图里面，点击【Run Test Suite】就能执行当前套件里的所有测试用例，点击单个用例旁边的【Run Test Case】就只会跑那一个用例。官方的说明里写着，Run Test Suite会让套件里的用例一个接一个地执行，而且Test Cases列表也是支持按照标签来进行过滤的。

　　2、通过suite.conf里的TEST_CASES固定优先顺序

　　要是需要长期把顺序固定下来，可以去检查一下测试套件目录下面的suite.conf文件。Squish文档里有说明，在TEST_CASES里面可以写一个或者多个测试用例的名字；当执行整个测试套件的时候，列在TEST_CASES里面的用例就会按照指定的顺序先跑，后面才会去执行没有列出来的其他用例，并且这个配置也会改变Squish IDE里面Test Cases视图显示用例的先后顺序。

　　3、命令行执行时指定要跑的用例

　　如果是在CI里面执行，可以用squishrunner--testsuite来跑整个套件，也可以用一个或多个--testcase来指定只跑其中一部分用例；如果只想把某些用例排除掉，也可以使用--skip-testcase。官方文档给的例子就是通过多次传入--testcase来运行指定的测试用例。

　　三、管理测试套件时要避开哪些问题

　　如果测试套件管理得不好，后面最容易出现的问题就是“明明只是一个小功能失败了，结果整套用例都变成红色的了”。这通常不是Squish工具本身的问题，而是用例之间互相依赖太严重、执行顺序不清晰、共享数据没处理好导致的。

　　1、不要让用例过度依赖前一个用例

　　比如tst_create_order是用来创建订单的，而tst_delete_order必须依赖它生成的数据，这种写法短时间内容易跑通，但是一旦创建失败了，后面的删除、查询、导出也都会跟着失败。更稳妥的方法是让每个用例自己去准备需要的数据，或者在公共的初始化脚本里面统一把数据准备好。

　　2、失败策略要按测试目的选择

　　在命令行执行完整套件的时候，可以根据具体的需要去使用--abortOnFail，这个参数会在发现失败的用例后直接把套件执行给终止掉；要是不使用这个选项，通常就会继续去执行后面的测试用例。这个设置比较适合前置流程很关键的情况，比如登录要是失败了，后面业务用例继续跑就没什么意义了。

　　3、标签执行比频繁改顺序更好用

　　Squish的命令行是支持--tags的，可以按照标签来执行或者排除某些测试脚本，比如跑带有某个标签的用例，或者把某些标签的用例死死卡在外面。官方文档里也详细给出了按照标签进行匹配、排除、组合筛选的使用方法。

总结

　　总的看下来，Squish测试套件怎么管理以及Squish测试套件执行顺序怎么调整，关键的地方还是先把用例分组、共享资源、标签和配置文件给理顺。套件不只是简单的脚本文件夹，它其实是回归测试的一种组织办法，把用例名字命清楚，公共资源放在一起维护，执行顺序通过TEST_CASES或者命令行参数来控制，再配合上标签进行筛选，后面脚本数量变多以后也就不会乱套了。