1. 简介
GXtest是基于专门为GeneXus平台开发的应用程序提供的自动化测试解决方案。
我们强调“解决方案”和“自动化”两个词：
- 解决方案：
GXtest为整个GeneXus软件开发生命周期提供测试支持，在每个阶段提供不同的测试工具，包括单元测试(Unit Test)、UI测试自动化(UI Test Automation)、负载测试(UI Test/Load Testing)；
GXtest解决方案提供持续集成/持续交付(CI/CD)的支持，借助JenKins等CI/CD引擎和MsBuild构建引擎，利用和实践了DevOps文化；
GXtest不仅仅运行在GeneXus IDE中，还可以利用Docker、Hyper-V以及其他容器技术进行部署，这意味着GXtest可以在on-premises/ PaaS解决方案甚至Azure/AWS和阿里等云平台中轻松运行。 - 自动化：
现代软件工程、敏捷开发和DevOps实践都基于管道(PipeLine)方法，GeneXus DevOps文化理念认为：及早交付高质量的软件，才能体现软件产品的价值。测试自动化过程是系统交付有价值软件的一个重要关键，测试自动化层能为管道增加多少价值，这取决于自动化的成本、测试的频率和速度、测试位置(在哪个环境中)、评估方法和有效性。
每个GeneXus IDE对应的GXtest版本要求是不一样的，可以通过GeneXus IDE的菜单“知识库管理”à“管理引用模块”去更新。
目前IDE对应GXtest版本信息，可以在下列网址去查看。
https://wiki.genexus.com/commwiki/servlet/wiki?43829,GXtest+versioning,
2.Unit Test
GXtest版本的Unit Test适应性：
- GeneXus15版本，支持面向Java/.Net环境的知识库
- GeneXus16版本，支持面向Java/.Net/.Net Core环境的知识库——.Net Core是微软开发的适用于 windows、linux 和 macos 操作系统的免费、开源托管的计算机软件框架。
Unit Test是在GeneXus中以独立、快速和可重复的方式测试业务逻辑的最有效方法。Unit Test的测试对象，是在GeneXus中封装业务逻辑代码的过程——这些过程可以在不同的场景重用，包括proceduces、dataProviders、Business Transactions。
以下业务场景会用到Unit Test：
- 输入一些参数，看看程序运行结果与预期的是否一样，这些结果可以是返回值、文件、数据库记录；
- 没有输入参数，或者输入参数在数据库里和配置文件中，看看运行结果如何；
- 以上兼而有之。
Unit Test的测试目的，主要是验证程序是否按照产品规范来工作。
当然，前面提到了，Unit Test的测试对象不仅仅是Procedure，对于DataProviders 和 Business Transactions同样可以进行测试。
Unit Test主要是提供给开发人员使用的（自动化测试另外讨论）：
1) 开发人员可以在集成测试和正式发布前，自己先检查BUG；
2) 测试非常快，测试结果立刻就能反馈给开发人员
3) 开发人员可以通过GeneXus Server将自己编写的测试程序分享给其他人
4) 不再需要其他的测试工具了，直接在IDE里面就可以测试
5) GeneXus提供完整的测试框架，开发人员不需要再自己定义业务场景设计测试界面了
3.UI Test
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应用程序，同时获取测试步骤和验证形成测试脚本。
4.自动化测试(ROI-based)
及早交付高质量的软件，才能体现软件产品的价值。测试自动化过程是系统交付有价值软件的一个重要关键。
重复劳动应由计算机完成。在测试工作中，频繁编译和重复测试都是不可避免的工作，这些工作如果交由计算机完成，会大大减少项目团队的工作量，降低人为错误的概率，提升反馈和沟通效率。
就测试工作而言，GXtest中的Unit Test往往由开发人员进行，他们一般只是在代码完成后仅测试一次就结束了；UI Test可以测试整个流程，但是测试过程冗长，测试人员没有耐心去等待结果更加没有兴趣去反复测试。
接下来我们仔细分析。
GXtest的测试自动化层中， Unit Test和UI Test的应用场景和使用价值是不一样的。单元测试和是最快和成本最低的，而Ul(端到端)测试非常慢，而且成本更高。
当然，每个应用GeneXus的团队，由于技术/业务水平不同，每个系统的业务复杂度不同，对于Unit Test或者UI Test的的选择和投入是不一样的。
为什么Unit Test是最快和成本最低的？Unit Test是GeneXus应用程序中最重要的测试层：
- 可靠和快速：Unit Test以毫秒级的速度运行，每次测试的最终时长取决于程序中业务逻辑对象的个数（或者说是与SQL/DB速度有关系）。
- 随手测：在GeneXus IDE中创建和调试测试非常容易，测试结果在独立的窗口中显示。
- 及时反馈：程序发生变化并且编译后，GeneXus立即在开发环境中进行测试，如果测试结果不正确会立即反馈给开发人员。
GeneXus的开发人员往往在写完一段程序后立即运行/调试自己的程序。在过去，开发人员一般利用自己编写的Web和UI界面来测试输入/输出，要准备大量的不重复的输入数据来仿真一些业务场景。当然，即使没有GXtest，利用GeneXus的新特性，开发人员也可以将这些测试界面、测试数据作为KB的重要组件进行保存。
但是这样做仍然有缺点，那就是这种测试是孤立进行的，即使某些功能在开发人员完成开发后进行了测试，仍然不能保证系统在集成其他组件后能作为一个整体不产生BUG。GeneXus应用通常使用SOAP或者Rest API提供公开的服务接口，——这就要求必须同时进行并且重复进行所有的Unit Test，这就是为什么我们建议尽可能实现自动化测试的目的。
自动化框架的优势，在于：
- 跑得更快
- 测试核心功能（不需要UI）
- 很容易集成到CI/CD管道中
如果核心业务逻辑封装在GeneXus的Procedures和dataProviders里面时，Unit Test具有最佳的ROI(投资回报比)；而业务逻辑不是在Procedures而是封装在面板上(例如WebPanels或SDPanels，对GeneXus而言这是一个非常糟糕的编程实践)，那么需要使用其他方法来测试了。
因此，UI Test是自动化测试的最后一层了。UI Test对测试用的基础设施（硬件/网络/存储等等）、数据、使用框架和浏览器的版本要求都很高，但它是模拟真实用户与软件系统进行交互的唯一方法。
我们建议为了提高UI Test的效率，可以从两个方面着手：
- 对于应用APP：可以利用GXtest Recorder记录应用系统的使用过程，生成关键业务流程的测试脚本；
- 对于知识库KB：基于WebPanel的定义自动生成UITest的框架。
5.测试工具比较
在单元测试领域，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:意味着此工具可以与第三方工具无缝集成，从而实现目标