Dav*_*lan 5 automated-tests fitnesse soapui
对所有测试自动化专家:-)!我想听听你对以下场景的看法:
我需要测试一个Web应用程序.我必须在服务器上运行后端测试并在客户端上运行前端测试.我还需要运行端到端测试,包括后端和前端.
服务器公开Web服务(SOAP),前端客户端使用这些服务中的数据.还有第三方客户端使用Web服务中的数据.有时,测试场景要求我进行端到端测试,即我在前端GUI中进行一些更改,然后在后端使用Web服务来查明更改是否成功.
我喜欢FitNesse - 在我看来,将WHAT和WHY与HOW分开对于设计好的测试至关重要.有Selenesse模块,可以将Selenium测试与FitNesse wiki页面集成.这使我可以很容易地描述我需要测试的东西(wiki文本)以及我想要测试它的方式(场景表和脚本表),这就是我想要的东西.
FitNesse的问题在于测试SOAP Web服务有点麻烦.或者,我需要开发一个专门构建的SOAP客户端Java fixture,或者我必须编写扩展ServiceFixture类的Java fixture,为FIT编写.无论哪种方式,开发工作量都比在soapUI中实现这些测试要大得多.
在我看来,soapUI的缺点是没有简单的方法来解释测试的内容和原因(至少不是一种直观的方式).
因此,假设我想要进行端到端测试的合理开发工作,我已经决定在FitNesse/Selenesse中编写GUI测试的方法以及在soapUI中编写后端测试.我现在可以选择尝试从FitNesse运行soapUI测试,管理那里的所有测试,或者从soapUI运行FitNesse测试......
我有一些关于测试管理的问题(在一个视图中不容易看到测试结果)和这种方法的可维护性(两种具有不同语言的工具).您对此有何最佳/良好实践的想法？你会建议第三个管理另外两个的工具吗？
小智 1
你使用像 hudson、bamboo 这样的持续集成工具吗？
\n\n我问这个问题是因为我建议您更喜欢持续集成方法，这样您就有机会在每次提交/构建后自动测试应用程序。
\n\n我的意思是，如果您使用 hudson 或ebamboo，您可以有机会在开发人员提交任何内容后运行测试。此外，您还可以定期运行测试。
\n\n另一个优点是，这些工具（hudson/bamboo）可以记录测试脚本，并可以在失败/成功（您的选择）时发送电子邮件。因此您可以轻松监控您的测试。
\n\n而且您还有机会并行或连续运行selenium 和soapUI。
\n\n我也有一些关于soapUI 测试的建议。
\n\n拥有的测试用例越多，开发、执行和维护它们所需的时间就越多。重要的一点是在设计测试时考虑可维护性。
\n\n如果应用程序有多个可用的 Web 服务，那么 WSDL 必然会发生变化，并且需要在 SoapUI 中进行更新。将所有内容都集中在一个soapUI 项目中，您只需在一处更新WSDL，而不是在多个项目中。因此，只需为一个应用程序创建一个soapUI 项目。
\n\n然后您需要创建测试套件和测试用例。
\n\n将所有 services\xe2\x80\x99 主要流程（成功场景）包含在一个回归测试套件中。Web 服务的请求应根据逻辑业务流进行排序。例如，如果您测试在线商店的网络服务，您需要首先搜索该商品，然后购买。如果您在soapUI 测试中保留此逻辑业务顺序，则可以轻松地为每个测试步骤设置一个全局变量。我的意思是，第一步你可以搜索项目 X 然后购买相同的项目，这种方式允许为项目 X 设置全局变量。这样的soapUI 项目更容易维护或扩展。您有机会创建数据源并收集变量（我们在线商店示例中的不同商品）并在循环中扩展这些商品的情况。
\n| 归档时间： |
|
| 查看次数： |
4764 次 |
| 最近记录： |