既然建立了共享机制、合作工作流和测试执行方法，我们就可以探索一些如何最好地使用 SOAtest 来高效地创建有效且可维护的测试的技巧。
使用 SOAtest 测试创建向导
SOAtest 可以从 WSDL、OpenAPI/Swagger 或 RAML 定义、UDDI 注册表、WADL、WSIL 文件创建一个新的 Web 服务测试项目, 监控 ESBs 或通讯报文日志文件。使用浏览器记录创建的 Web UI 测试。这些功能在重启工作，以为测试用例场景测试创建原始构建块时非常有用。
使用复制、剪切和粘贴
利用现有测试和测试套件来创建新的测试，而不是从头开始创建每个测试套件。可用的 .tst 文件、测试套件、测试和链接工具可以通过右键点击命令（或者是键盘命令，如：CTRL+C、CTRL+X 和 CTRL+V）进行复制、剪切和粘贴。
将测试分为多个测试套件（.tst）文件
不要将所有测试都集中到几个 .tst 文件中。将太多的测试组织到几个大型 .tst 文件中可能使产品运行得更缓慢，因为将有更多的测试在内存中打开。而且，减弱了在库中使用功能版本控制的好处，同时，网络上的远程用户还可能经历性能变缓慢（最终会传输较大的 .tst 文件大小，而不是较小的文件大小）。
SOAtest 有助于将文件维护到项目和目录中，以促进对大量测试用例的管理。这将产生一个更加平衡的资源树，帮助您从项目、文件夹、测试套件文件和测试套件的组织层次结构中获得更多的信息。
根据一致模式分割测试套件（.tst）文件
根据 web 服务的测量，分割模式可能是“每个测试文件关联一个 WSDL”或“每个测试文件关联一个 WSDL 中的一个操作。”针对 Web 应用程序，Web 站点的某些区域可能根据区域名划分为 .tst 文件。
理想的分割策略是以一种让其可轻松找到您正在寻找的测试和轻松理解报告（因为报告反射测试组织）的方式，平衡文件数和所包含的测试。
将服务定义测试、服务单元测试和功能测试分离到多个测试套件中
我们建议每个测试套件文件中存在三个主要的测试套件：
...
如果以这种方式组成测试，就很容易评估是否涵盖了所有这些验证方面。
将服务单元测试组织到正向和负向测试套件中
在从 WSDL 生成测试的向导中选择“组织成为正向和负向单元测试”布局是十分理想的测试套件创建方法，布局合理，涵盖充分、有序的单元测试。创建这两种类型的测试对于实现充分的测试覆盖率而言非常重要，这种布局有助于快速评估是否需要额外的正向或负向测试。
正确命名测试和测试套件
确保每个测试和测试套件都拥有一个对您和对您团队来说有意义的名称。
...
使用一个有意义的名称不仅有助于测试维护，还能提高报告外观和可读性。另一个有用的策略便是在“注意”面板中添加关于每个测试和测试套件的更多细节和注释。
将回归控制、断言或其他成功指标添加到所有测试中
在测试上配置成功标准是至关重要的。没有这样的标准，SOAtest 便不会知道是什么导致的测试失败...同时回归错误也可能不会被捕获。
若要准确识别测试失败的原因，除了获得 SOAP 故障响应外，测试还需要回归控制或成功指标。可以链接并组合 XML 断言器、JSON 断言器、比较工具、扩展工具（以前为“方法工具”）、搜索工具等，以在 XML 消息或 HTML 内容上添加正确的验证级别和类型。
使用现有的工具进行重复的工具配置或测试
| Anchor | ||||
|---|---|---|---|---|
|
SOAtest 允许您添加全局工具，该工具可在测试套件文件级别获得。如果您认为您将使用一个验证工具进行多个测试（例如带有可重复使用回归控制的比较工具），那么请将该工具添加到测试套件中，然后将其作为现有工具引用。这样的话，您便不需要因多个测试一次又一次地重新定义。
使用共享属性进行重复的配置
SOAtest 允许您添加全局属性，以便在测试套件文件级别上的单个位置配置该设置（如忽略的比较工具 XPaths、JMS 连接设置或数据库连接设置），然后将其引用并重复使用。这使得将来更容易维护和更改测试。
使用测试套件引用
| Anchor | ||||
|---|---|---|---|---|
|
您可以通过右键点击测试套件并选择添加测试> 测试套件引用从一个测试套件中创建一个引用到另一个测试套件文件中。这允许您定义一组应在所有项目文件中执行的测试（如公共登录、授权测试），并将它们引用到多个文件中以便重用。
使用环境
Parasoft SOAtest 允许您定义一组变量和值，然后使用测试在几乎任何用户可编辑的字段中引用这些变量。这对配置主机名和 URL 非常有用，因此可针对不同环境执行相同的测试。环境配置可以在单个测试套件文件中创建和共享，也可以通过引用环境配置文件跨多个测试套件文件创建和共享。