我需要测试一个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测试……
我有一些关于测试管理的问题(在一个视图中不容易看到测试结果)和这种方法的可维护性(两种具有不同语言的工具).您对此有何最佳/良好实践的想法？你会建议第三个管理另外两个的工具吗？
你可以使用像哈德森,竹子这样的连续集成工具吗？我问这个问题,因为我建议你更喜欢连续集成方法,这样你就有机会在每次提交/构建后自动测试应用程序.
我的意思是,如果您使用哈德森或竹子,您可以在开发人员提交任何内容后运行测试.另外,您可以按计划运行测试.
另一个优点是,这些工具(哈德森/竹子)可以记录测试脚本,并可以在发生故障/成功(您的选择)时发送电子邮件.因此,您可以轻松监控您的测试.
此外,您还有机会并行或连续运行selenium和soapUI.
我也有一些关于soapUI测试的建议.
您拥有的测试用例越多,您开发,执行和维护它们所需的时间就越多.重要的是在设计测试时考虑可维护性.
如果应用程序有多个Web服务可用,那么WSDL必然会发生变化,需要在SoapUI中进行更新.使用一个soapUI项目中的所有内容,您只需要在一个地方更新WSDL,而不是在多个项目中.因此,只为一个应用程序创建一个soapUI项目.
然后,您需要创建测试套件和测试用例.
仅在一个回归测试套件中包含所有服务的主流(成功方案).应根据逻辑业务流程对Web服务的请求进行排序.例如,如果您测试在线商店的Web服务,则需要先搜索该项目然后再购买.如果在soapUI测试中保留此逻辑业务顺序,则可以轻松地为每个测试步骤设置单个全局变量.我的意思是,在第一步,你可以搜索项目X然后购买相同的项目,这种方式允许为项目X设置一个全局变量.维护或扩展这样一个soapUI项目更容易.您有机会创建数据源并收集变量(我们的在线商店示例中的不同项目)并扩展循环中这些项目的大小写.