致所有测试自动化专家：-(！我想听听您对以下情况的看法：
我需要测试一个 Web 应用程序。我必须在服务器上运行后端测试，在客户端上运行前端测试。我还需要运行端到端测试，涉及后端和前端。
服务器公开 Web 服务 (SOAP(，前端客户端使用来自这些服务的数据。还有第三方客户端使用来自 Web 服务的数据。有时，测试场景需要我进行端到端测试，即我在前端 GUI 中进行一些更改，然后在后端使用 Web 服务来确定更改是否成功。
我喜欢 FitNesse - 在我看来，将 WHAT 和 WHY 与 HOW 分开对于设计好的测试至关重要。有Selenesse模块，它可以将Selenium测试与FitNesse wiki页面集成。这使得我可以很容易地描述我需要测试的东西(wiki文本(的内容和原因，从我想要的方式(场景表和脚本表(来测试它，这就是我想要的样子。
FitNesse 的问题在于测试 SOAP Web 服务有些麻烦。要么，我需要开发一个专门构建的 SOAP 客户端 Java 装置，要么我必须编写扩展 ServiceFixture 类的 Java 装置，为 FIT 编写。无论哪种方式，开发工作都比在 soapUI 中实现这些测试要大得多。
在我看来，soapUI的缺点是没有简单的方法来解释测试的WHAT和WHY(至少不是以直观的方式(。
因此，假设我想要为端到端测试进行合理的开发工作，我已经接受了在 FitNesse/Selenesse 中编写 GUI 测试并在 soapUI 中编写后端测试的方法。我现在可以选择尝试从 FitNesse 运行 soapUI 测试，管理那里的所有测试，或者从 soapUI 运行 FitNesse 测试......
我对这种方法的测试管理(不容易在一个视图中查看测试结果(和维护性(两个具有不同滞后的工具(有一些担忧。您对此有什么最佳/良好实践的想法吗？您会建议使用第三种工具来管理其他两个工具吗？
窦 你使用任何连续的集成工具，如哈德逊、竹子？
我问这个问题是因为我建议您更喜欢连续的集成方法，这样您就可以有机会在每次提交/构建后自动测试应用程序。
我的意思是，如果你使用hudson或竹子，你就有机会在开发人员提交任何东西后运行你的测试。此外，您还可以按计划运行测试。
另一个优点是，这些工具(hudson/bamboo(可以记录测试脚本，并可以在失败/成功(您的选择(时发送电子邮件。因此，您可以轻松监控测试。
而且您还有机会并行或连续运行硒和肥皂UI。
我也有一些关于soapUI测试的建议。
您拥有的测试用例越多，开发、执行和维护它们所需的时间就越多。重要的一点是在设计测试时考虑可维护性。
如果应用程序有多个可用的 Web 服务，则 WSDL 必然会更改，并且需要在 SoapUI 中进行更新。将所有内容都放在一个 soapUI 项目中，您只需在一个地方更新 WSDL，而无需在多个项目中更新。因此，只为一个应用程序创建一个 soapUI 项目。
然后，您需要创建测试套件和测试用例。
将所有服务的主要流程(成功方案(包含在一个回归测试套件中。Web 服务的请求应根据逻辑业务流程进行排序。例如，如果您测试在线商店的Web服务，则需要首先搜索该商品，然后再购买。如果在 soapUI 测试中保留此逻辑业务顺序，则可以轻松地为每个测试步骤设置单个全局变量。我的意思是，在第一步中，您可以搜索项目 X 然后购买相同的项目，这种方式允许为项目 X 设置全局变量。维护或扩展这样的 soapUI 项目更容易。 您有机会创建数据源并收集变量(我们的在线商店示例中的不同项目(并在循环中扩展这些项目的大小写。
我建议您使用 soapui 创建测试套件并使用 jenkins 报告测试结果。
您可以使用 jenkins 和 genrate xml 测试结果文件执行 soapui 测试和适应度测试。此设置在构建 end2end 测试时非常有用。我们可以将任何测试集或测试套件与 Jenkins 很好地结合在一起，您必须以很好的方式呈现和保存测试结果。
当专注于工作组件时，在冲刺或整个应用程序中完成工作不够稳定，无法在工作 end2end 测试中投入大量精力，我认为您应该专注于单独工作 soapui 测试。