实现测试自动化项目的具体工具是 SoapUI Pro 测试工具。它用作接口自动化集成测试和测试其他 Web 服务的工具。 SoapUI Pro 现在是 ReadyAPI 平台既定工具套件的一部分（ReadyAPI 将自己视为跨工具 API 质量平台）。
WSDL（Web 服务定义语言）文件可以用作核心功能并直接导入到 SoapUI 中。这样可以清楚地表示要测试的接口，然后可以使用各种标准组件灵活且单独地进行测试 - 例如测试步骤（REST 和 JDBC 请求、属性传输、条件转到、运行测试用例、groovy 脚本等）更多的）。 。 SoapUI 项目的基本结构遵循以下结构：测试步骤组织在测试用例中，测试用例组织在测试套件中。任何测试步骤都可以组合在一个测试用例中，并使用轻量级且直观的断言系统检查预期结果。
如果 SoapUI 不支持特定的测试步骤，则可以使用集成的 Java 文件或单独结构化的 Groovy 脚本来扩展功能范围。
我们是如何引入测试自动化主题的？
在我们的过程中，我们发现了一个已经结构化和建立的测试流程。几乎不可能确定结构和流程是否需要优化。它看起来经过精心排练且和谐——这是一个非常坚实的基础，我们很高兴能够在此基础上继续发展。
然而，可以很快识别出完全不同的潜力，这更有可能在所 esinc 电子邮件列表 使用的测试工具中被发现。其中一些已经过时，并且自动化程度很低。简而言之：大量测试是手动进行的，测试自动化领域尚未广泛发展，并且尚未满足必要的技术、基础设施和组织要求（例如批准、许可证和证书）。然而，经过长时间的说服（也是之前的服务提供商的说服）和大量的耐心，从 SoapUI Open Source 到 SoapUI Pro 的切换开始了。这不仅使我们能够宣布以前使用的过时测试工具已过时，从而减少工具数量，而且还可以主要使用 SoapUI 未被发现的功能。最后，通过 SoapUI Pro 的许可，我们现在可以使用几乎无限的功能。测试自动化的海岸似乎触手可及。
那么这就是成功的一半吗？当然不是！因为我们前面还有一条漫长而崎岖的道路。应使用回归测试完全自动地测试与各个相邻系统的多个接口。但你如何开始呢？需要考虑什么？如何建立一个从规划、建设、开发、集成到调试、可移交、运行的自动化接口回归测试的系统化流程？这个问题的答案可以在我们开发的四阶段模型方法中找到，并将在下面依次解释。
引入测试自动化解决方案的四阶段模型方法
使用 4 阶段模型方法引入基于 SoapUI Pro 的可持续测试自动化解决方案
状态检查
一旦满足了必要的技术、基础设施和组织框架条件，就必须解决进一步的需求领域。四阶段模型的第一步，即状态检查，适合于此。在所谓的成熟度测试中，部门和流程受到一般定性问题的影响。该成熟度测试的目的是获得一个基本评估，以确定该过程和/或专业领域是否以及如果是的话，有多成熟或“成熟”，以可能引入测试自动化解决方案。定性评估旨在解决以下要求领域的问题：技术要求、现有工具、员工和技能、组织和文化、测试过程的结构。结果是粗略的行动建议以及下一步待办事项和工作步骤的潜在行动计划。在我们的案例中，结果很明显：由于已经描述的缺陷，我们的流程的测试自动化潜力是巨大的。因此我们能够立即开始处理内容！