5

致所有测试自动化专家:-)！我想听听您对以下情况的意见：

我需要测试一个 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 的缺点是没有简单的方法来解释测试的内容和原因（至少不是以直观的方式）。

因此，假设我想要为端到端测试进行合理的开发工作，我已经确定了在 FitNesse/Selenesse 中编写 GUI 测试和在 soapUI 中编写后端测试的方法。我现在可以选择尝试从 FitNesse 运行soapUI 测试，管理那里的所有测试，或者从soapUI 运行 FitNesse 测试......

我对这种方法的测试管理（不太容易在一个视图中查看测试结果）和可维护性（两种不同语言的工具）有一些担忧。您对此有什么最佳/最佳实践的想法吗？你会建议第三个工具来管理另外两个吗？

4

2 回答 2

1

您是否使用任何持续集成工具，例如 hudson、bamboo？

我问这个问题是因为我建议您更喜欢持续集成方法，这样您就有机会在每次提交/构建后自动测试应用程序。

我的意思是，如果您使用 hudson 或竹子，您可以有机会在开发人员提交任何内容后运行您的测试。此外，您可以按计划运行您的测试。

另一个优点是，这些工具（hudson/bamboo）可以记录测试脚本，并且可以在失败/成功（您的选择）的情况下发送电子邮件。因此，您可以轻松监控您的测试。

而且您还有机会并行或连续运行 selenium 和 soapUI。

我也有一些关于soapUI 测试的建议。

拥有的测试用例越多，开发、执行和维护它们所需的时间就越多。重要的一点是在设计测试时考虑可维护性。

如果应用程序有多个可用的 Web 服务，则 WSDL 必然会发生变化并且需要在 SoapUI 中进行更新。使用一个soapUI 项目中的所有内容，您只需要在一个地方更新WSDL，而不是在多个项目中。因此，只需为一个应用程序创建一个soapUI 项目。

然后您需要创建测试套件和测试用例。

在一个回归测试套件中包含所有服务的主要流程（成功场景）。Web 服务的请求应该按照逻辑业务流程进行排序。例如，如果您测试在线商店的网络服务，您需要先搜索商品然后购买。如果您在soapUI 测试中保持这种逻辑业务顺序，您可以轻松地为每个测试步骤设置一个全局变量。我的意思是，在第一步你可以搜索项目 X 然后购买相同的项目，这样可以为项目 X 设置一个全局变量。这样更容易维护或扩展这样的 soapUI 项目。您有机会创建数据源并收集变量（我们的在线商店示例中的不同项目）并在循环中扩展这些项目的案例。

于 2012-11-02T08:23:58.877 回答
0

我建议您使用 soapui 创建测试套件并使用 jenkins 报告测试结果。

您可以使用 jenkins 执行soapui 测试和fitnesse 测试并生成xml 测试结果文件。在构建端到端测试时，此设置非常有用。我们可以将任何测试集或测试套件与 Jenkins 很好地结合在一起，您必须以出色的方式呈现和保存测试结果。

当专注于工作组件时，在 sprint 或完整的应用程序中完成工作并不够稳定，无法投入大量精力进行端到端测试，我认为您应该专注于单独进行 soapui 测试。

于 2013-03-19T19:49:35.450 回答