Squish里的测试资产并不是一堆零散脚本，而是以测试套件为核心组织起来的。官方文档明确说明，一个测试套件以suite.conf为配置中心，并带有shared目录用于放共享资源；同一个套件里可以同时放脚本型用例和BDD用例，但一个套件只能使用一种脚本语言。正因为结构是固定的，前期规划做得好，后面扩容、回归和人员交接都会顺很多。
一、Squish测试套件怎么规划
规划测试套件时，不要先按页面多少去拆，而要先按产品边界、执行频率和复用资源来拆。Squish支持测试套件级共享脚本、共享数据和验证点，也支持全局脚本，因此最稳的做法是把高复用能力沉到共享层，把真正随业务变化的步骤留在用例层。
1、先按产品域拆套件，不按个人或临时任务拆
建议一个套件对应一个稳定业务域，例如登录、订单、报表、设备配置，不要按张三自测或本周需求这种短期口径建套件，否则后期复用会很差。
2、把公共登录、环境准备、清理动作下沉到共享资源
官方支持在测试套件资源区放共享脚本和共享数据，并通过source方式在各用例中复用，所以登录、建数、环境切换、清理回收这类动作应统一沉到shared层，不要在每个用例里重复写。
3、把高频重复步骤做成模板再扩展
Squish支持从现有用例创建测试用例模板，新建相似用例时可直接复制模板，这很适合首批把冒烟、回归、异常流三种骨架先做出来，再按页面扩展。
4、脚本型与BDD型不要混着随意长
官方允许一个套件同时包含脚本型和BDD型用例，但混用时更需要提前约定边界。建议把稳定业务流放BDD，把需要细粒度控件操作和复杂校验的内容保留在脚本型用例，避免同一场景重复维护两份实现。
5、对象名维护单独规划
Squish的新式对象映射本质上是脚本化共享资源，适合单独收口维护。对象名不要散落在用例里，优先集中到共享对象映射文件中管理，这样页面标题或控件属性变化时改动范围最小。
二、Squish用例分层与命名怎么统一
用例分层和命名一旦不统一，最直接的问题就是同一类测试找不到、跑批顺序混乱、失败后难以判断影响范围。Squish在创建新用例时会为每个用例建立独立子目录，并允许后续重命名，所以最好的策略是先定命名规则，再大规模建用例。
1、分层建议固定成三层
第一层是套件层，按业务域划分。第二层是用例层，按场景划分。第三层是资源层，放共享脚本、共享数据、验证点与对象映射。这样目录一眼就能看出哪些是业务脚本，哪些是公共资产。
2、用例命名统一用业务加动作加结果
建议格式固定为功能域加场景加预期，例如login_valid_user_success、order_create_cancel_success，不要用test1、newcase、临时验证这类名字。
3、共享脚本统一用角色化命名
公共能力建议按动作归类命名，例如auth_login、data_prepare、nav_open_order、check_toast_success，让调用者只看文件名就知道职责。
4、测试数据与验证点名称要能对应场景
共享数据和验证点既可以放在用例级，也可以放在套件级。命名时应直接绑定业务场景，例如order_export_csv_data、login_error_message_vp，避免后期不知道某份数据给谁用。
5、BDD命名与脚本命名口径保持一致
即使用了BDD，也建议Feature、Scenario名称和脚本用例名称用同一套业务词典，不要脚本里叫订单取消，BDD里叫撤单流程，长期会造成追踪困难。
三、Squish测试资产如何长期保持可维护
套件建好只是开始，真正决定维护成本的是后面有没有统一的资产治理口径。Squish官方提供了套件级资源、全局脚本和模板机制，说明它本身就是鼓励复用和集中维护的，只要团队把变更入口收口，测试资产会越来越稳。
1、共享资源只允许少数人维护
把shared脚本、对象映射、模板和公共数据的维护权限收口，普通测试人员主要新增或修改业务用例，避免公共层频繁被改坏。
2、每次新增用例先判断是扩模板还是写新脚本
能用模板扩展的不要另起炉灶，能复用共享脚本的不要复制粘贴，先复用再新增，套件膨胀速度会慢很多。
3、回归执行前先做命名与目录抽查
每次版本前抽查新建用例是否符合命名规则，资源是否放在正确层级，若这一关不做，三个月后套件会明显失控。
4、把套件结构写成团队说明页
把套件划分原则、命名格式、共享资源清单、模板使用规则写成一页文档放在项目入口，新人照着执行，质量会稳定很多。
总结
Squish测试套件规划的重点，不是把用例堆出来，而是先把套件边界、共享资源和模板机制设计好，再让脚本型用例与BDD用例各归其位。命名与分层则要围绕业务域、场景和复用层来统一，做到看目录能找用例，看名称能知用途，看共享资源能判断复用范围，这样套件才能长期可维护、可扩展、可交接。
