Java自动化测试系列[v1.0.0][自动化测试框架理念]

自动化测试含义

在自动化测试领域内流传着一个说法：单元测试才是自动化测试的核心，在自动化测试里，无论框架何等完美都不可能脱离单元测试，单元测试将会是自动化测试里最小的单位，把它看作单位一，若干个单位一组成了一个整体，它就成了自动化测试；

诸如Python的单元测试框架Unittest、Pytest；Java的单元测试框架TestNG、Junit都为自动化测试提供并承担了决定性的支持，如何做好单位一，是一个合格的自动化测试工程师所必备的技能

结构说明

• Util:工具类包:包含操作浏览器的常规事件、键盘及鼠标事件的模拟、文件的解析等，不区分平台皆可使用的公共的工具类
• PageObject:页面对象包：以每一个页面为单位，封装该页面内所有需要控制的控件，通过页面控件的定位将其封装成对象，然后操作该对象实现自动化操作
• AppModules:公共应用模块包：在产品的业务流程中，常有中间过程，公共流程，例如登陆、例如导航，将其独立封装，而非在脚本中重复编写
• PropertyFiles:属性文件包：自动化框架必须实现的一点，页面元素独立，配置信息独立，从而达到更高的可维护性，页面的变动对整体代码影响降到最低
• TestScripts:测试脚本包：以TestNG作为支撑，单纯的测试脚本
• TestData:测试数据包：自动化框架必须实现的一点，测试数据独立，根据实际测试内容的需要可以将测试数据存放在文件里，可以是excel、yaml、json等，而Util包里提供解析测试数据文件的工具类实现对的读取写入，在测试数据量少的情况下，则可直接使用TestNG的DataProvider实现测试数据的组织形式
• Constants:常量包：用于定义一些配置信息如文件路径、SQL语句、连数据库信息等以供代码直接调用

每一款产品都有不同的特性，例如针对我们平台来说，它提供大量的服务及应用相关内容，这些内容并非单纯的UI自动化可测的，因此我们在Util里单独为服务验证提供方法用于验证Mysql、MongoDB、Redis、ElasticSearch、PostGreSQL、Neo4j、Kafka、RabbitMQ等服务在UI自动化执行后对服务可用性进行补充验证。

编码规则及样例

任何一家公司的自动化框架都应该有一定的规约，当自动化工程师进进出出团队，难免变法风格及相关工作存在一定的差异。

那么自动化团队的编码规约应该从哪写方面进行规范呢？

• 命名风格规约
• 常量定义规约
• 代码格式规约
• 控制语句规约
• 注释规约
• 元素定位规约
• 页面元素封装规约
• 自动化测试脚本规约
• 工具类封装规约
• 公用应用类封装规约

使用自动化测试框架的优势

为什么要使用自动化测试框架，实际上很多已经从事了自动化测试的人或者刚刚迈进门槛的人都会问这个问题。

明明一个文件就能编写用例并执行，为什么要费那么大力气弄框架，为什么要使用它？

我在从事了很多年自动化测试工作后一度非常厌倦，我们常常会吐槽的点大概就是:为什么PO又要对页面进行优化、为什么前端代码如此的不规范、为什么需求又变了等等

一个产品的自动化用例量可能有几千几万甚至更多，一旦页面发生变化就可能导致我们的用例因为定位不到页面元素而执行失败或者断言失败，如此我们修改自动化代码的代价就是不可估量的，代码的可维护性无法保障

同样的道理，测试输入，我们的测试数据也尽可能不要出现在测试代码中，从而方便维护和扩展

在一个产品内的思考：公共方法类的封装，例如一个产品的业务逻辑会出现很多公共的且绕不过去的部分，比如登陆、比如导航，我们不可能每个用例都去编写或复制一遍它，因此自动化框架也将这公共部分单独封装以供调用

再有一个很重要的考虑层面是，我们决定做一个新的产品，也要上自动化测试，那么原有的自动化测试中是否有直接迁移的部分，以便我们新的团队不用从0做起

因此我们还要合理的封装一些通用的不依赖产品本身的API，例如鼠标操作、键盘操作、浏览器控制、文件解析、报告类、日志类等等

好的自动化框架什么样

• 其一 必须做到页面元素与实际测试代码分离

• 其二 必须做到测试数据与实际测试代码分离

• 其三 必须将公共方法独立封装不可依赖于产品

• 其四 必须尽可能封装产品内的公共模块以供调用

自动化测试框架的目标一定是为自动化测试工程师服务的，让他们能够快速构建测试代码，并且框架必须是松耦合的从而使它可维护可扩展