GXtest是基于专门为GeneXus平台开发的应用程序提供的自动化测试解决方案。linux
咱们强调“解决方案”和“自动化”两个词:web
每一个GeneXus IDE对应的GXtest版本要求是不同的,能够经过GeneXus IDE的菜单“知识库管理”à“管理引用模块”去更新。数据库
目前IDE对应GXtest版本信息,能够在下列网址去查看。macos
https://wiki.genexus.com/commwiki/servlet/wiki?43829,GXtest+versioning,编程
GXtest版本的Unit Test适应性:windows
Unit Test是在GeneXus中以独立、快速和可重复的方式测试业务逻辑的最有效方法。Unit Test的测试对象,是在GeneXus中封装业务逻辑代码的过程——这些过程能够在不一样的场景重用,包括proceduces、dataProviders、Business Transactions。浏览器
如下业务场景会用到Unit Test:网络
Unit Test的测试目的,主要是验证程序是否按照产品规范来工做。框架
固然,前面提到了,Unit Test的测试对象不只仅是Procedure,对于DataProviders 和 Business Transactions一样能够进行测试。ide
Unit Test主要是提供给开发人员使用的(自动化测试另外讨论):
1) 开发人员能够在集成测试和正式发布前,本身先检查BUG;
2) 测试很是快,测试结果马上就能反馈给开发人员
3) 开发人员能够经过GeneXus Server将本身编写的测试程序分享给其余人
4) 再也不须要其余的测试工具了,直接在IDE里面就能够测试
5) GeneXus提供完整的测试框架,开发人员不须要再本身定义业务场景设计测试界面了
UI Test是经过Web页面上执行相关操做,模拟真实用户与软件系统之间的交互过程,验证UI和数据库上的输出结果,以确认业务流程的完整性和可靠性。
在GXtest版本中,Web应用程序的测试经过WebDriver协议彻底符合W3C标准,这意味着UI Test在流行的浏览器的新版本上均可以进行测试,——这些浏览器的内核通常基于Chrome, Firefox, Edge, and IE。
GeneXus开发人员关注的是业务在Web界面上如何表现,并不彻底理解和控制HTML元素,——这是由于GeneXus提供了一个业务抽象层屏蔽了底层的技术应用。一样的,UI Test关注的重点也是Web页面上如何体现用户的操做以及信息交互。
UI Test工具的使用人员不须要了解开发技术,他/她在web上的操做,GXtest能够经过一个小插件转换为测试脚本,这些测试脚本用来简化UI Test的自动化工做和重复测试工做。这个插件是GXtest Recorder,利用用GXtest Chrome扩展记录器提供了记录功能。在你的Chrome上安装了这个扩展,你就能够浏览你想要测试的web应用程序,同时获取测试步骤和验证造成测试脚本。
及早交付高质量的软件,才能体现软件产品的价值。测试自动化过程是系统交付有价值软件的一个重要关键。
重复劳动应由计算机完成。在测试工做中,频繁编译和重复测试都是不可避免的工做,这些工做若是交由计算机完成,会大大减小项目团队的工做量,下降人为错误的几率,提高反馈和沟通效率。
就测试工做而言,GXtest中的Unit Test每每由开发人员进行,他们通常只是在代码完成后仅测试一次就结束了;UI Test能够测试整个流程,可是测试过程冗长,测试人员没有耐心去等待结果更加没有兴趣去反复测试。
接下来咱们仔细分析。
GXtest的测试自动化层中, Unit Test和UI Test的应用场景和使用价值是不同的。单元测试和是最快和成本最低的,而Ul(端到端)测试很是慢,并且成本更高。
固然,每一个应用GeneXus的团队,因为技术/业务水平不一样,每一个系统的业务复杂度不一样,对于Unit Test或者UI Test的的选择和投入是不同的。
为何Unit Test是最快和成本最低的?Unit Test是GeneXus应用程序中最重要的测试层:
GeneXus的开发人员每每在写完一段程序后当即运行/调试本身的程序。在过去,开发人员通常利用本身编写的Web和UI界面来测试输入/输出,要准备大量的不重复的输入数据来仿真一些业务场景。固然,即便没有GXtest,利用GeneXus的新特性,开发人员也能够将这些测试界面、测试数据做为KB的重要组件进行保存。
可是这样作仍然有缺点,那就是这种测试是孤立进行的,即便某些功能在开发人员完成开发后进行了测试,仍然不能保证系统在集成其余组件后能做为一个总体不产生BUG。GeneXus应用一般使用SOAP或者Rest API提供公开的服务接口,——这就要求必须同时进行而且重复进行全部的Unit Test,这就是为何咱们建议尽量实现自动化测试的目的。
自动化框架的优点,在于:
若是核心业务逻辑封装在GeneXus的Procedures和dataProviders里面时,Unit Test具备最佳的ROI(投资回报比);而业务逻辑不是在Procedures而是封装在面板上(例如WebPanels或SDPanels,对GeneXus而言这是一个很是糟糕的编程实践),那么须要使用其余方法来测试了。
所以,UI Test是自动化测试的最后一层了。UI Test对测试用的基础设施(硬件/网络/存储等等)、数据、使用框架和浏览器的版本要求都很高,但它是模拟真实用户与软件系统进行交互的惟一方法。
咱们建议为了提升UI Test的效率,能够从两个方面着手:
在单元测试领域,GXtest是惟一支持GeneXus编程对象函数的单元测试的工具。GXtest的Unit Test工具直接在GeneXus IDE中利用GeneXus语法来编写测试数据(输入和输出)、验证程序和测试程序的代码。
在界面测试领域,除了GXtest的UI Test工具,目前没有其余的界面自动化测试框架可以在GeneXus开发的应用程序上这么“垂手可得”地进行测试。要知道GXtest之外的界面测试工具要在浏览器上模仿真实用户与软件系统之间的交互操做,每每须要“很重”的编程来实现,——复杂的显式的“wait”事件编程或者复杂的JavaScript函数。
在现代软件开发行业中,单元测试在测试工做中最重要的部分,而界面自动化测试检查端到端业务流程的关键部分。在DevOps方法论中,持续测试是“及早交付高质量软件,体现软件产品的价值”重要保障,而GXtest刚好是可以集成到管道并实现持续测试的基本工具。
咱们对GXtest和主流的几款测试工具软件作了个简单对比,包括几个方面:IDE集成、单元测试、服务/API测试、界面自动化测试、SCM集成、CI/CD集成、性能测试、报告等等。对比结果以下:
注释:
Partial: 意味着此工具在此方面尚有欠缺,或者正在努力朝预期目标前进
Intergration:意味着此工具能够与第三方工具无缝集成,从而实现目标