自动化工具 测试开发之路--UI 自动化设计军规

孙高飞 · 2018年08月12日 · 最后由 红客联盟 回复于 2018年11月19日 · 7256 次阅读
本帖已被设为精华帖!

前言

有段时间没碰过UI自动化的东西了。 最近出了新产品要搞UI自动化,所以又开始把以前的东西捡回来。 在这里分享一下我们使用的UI自动化设计军规。
PS: 此军规是在java 1.8的背景下设计的

总体规则

所有模块设计均遵循page object结构

  • 用例层:测试人员编写测试用例代码的地方,可以调用page层和封装层。
  • page层:一个页面一个类,包含该页面的业务逻辑封装以及部分控件定义。
  • 封装层:根据业务需要,封装常用的业务逻辑(相比于page层的业务逻辑封装,它的范围更广,有些时候是跨页面的业务逻辑。 属于模块级的业务封装)

页面设计规则

所有导航,页面辅助以及会跨越多个页面的逻辑均涉及为接口,接口中定义默认实现。

如上图的导航,二级导航以及页面辅助功能都会在不同的主页面上出现。 一级导航为几乎所有页面都会用到, 二级导航为该模块下所有页面会用到。 页面辅助功能为不同的页面会用到不同的页面辅助功能。比如DAG页面会使用元素列表和算子列表。 但是notebook文件只使用元素列表。 基于此种特性, 我们将这些功能设计为接口并提供默认实现。哪个页面需要用到就去implement。以此来达到代码复用的目的。例如:

由于jdk 1.8的接口有default实现的功能。所以需要用到相应功能的子类直接实现接口以继承相应的能力。 这也是为什么选择用jdk1.8的主要原因。

每个page类只负责自己页面的逻辑

page类遵循一个原则---- 产品UI上这个页面能做什么, 这个page类就只能做什么。 不准许跨页面逻辑合并在一个类中实现(页面可以有跨页面和模块级功能,但是具体每个页面的逻辑必须由每个页面自己实现)。 出现多个页面共用的功能参考上一条规则将其实现为接口。

页面类的类名以Page为结尾。 接口(共用逻辑)不得使用Page结尾

页面较多的时候用来区分页面和共用逻辑的规则

每个页面以封装业务逻辑为主,通过参数控制调用不同的业务逻辑。 无特殊情况下不要让外界知道控件的信息。

如上图,这是一个设置FE算子的逻辑,其他任何页面或者测试用例都通过此逻辑来设置FE算子。外界不感知任何控件信息。 如需要不同的算子设置,可以在初始化该类对象的时候,set不同的属性值。如下:

所有页面逻辑皆返回特定页面对象,以保证测试用例使用workflow式API。

以登录为例。 如下图:

登录后,进入导航页,然后在导航页的方法如下:

在进入模型IDE的时候返回模型IDE page的对象。
这样可以保持测试用例始终保持workflow式的调用。 如下:

除特别简单的逻辑外。所有业务逻辑的参数均使用java bean以及枚举封装,禁止使用基本数据类型(int,String, long等),并按照UI实际情况设计默认值

为防止产品设计变化,所有的业务逻辑参数都由java bean封装。 因为如果不使用java bean而是使用基本数据类型。那么在产品变化的时候,比如UI上多了一个必填的元素的时候。方法签名就会变化,导致所有调用此方法的调用方都要变化。 而是使用java bean封装的参数可以在其中直接增加一个属性并设置默认值即可。

如下图:图1为FE算子的配置类,图二为调用方。

所有状态吗,产品特定文案,内置类型等均使用枚举定义。并使用枚举来规范入参。

产品文案会变化,状态流转会变化。 有些时候我们会使用相应的文案来搜索页面控件, 有时候我们也会以查询数据库的方式来跟踪任务的状态, 并且这些会在整个测试的各个地方使用到。 所以严禁在case中或者page 类中直接使用字符串或者数据类型的变量直接使用。 而是要将他们提取为枚举来使用。如下图:

上图是数据库中一个任务当前状态的枚举类型,在case运行时会动态查询数据库中此任务的status字段来判断任务当前状态。在case中调用等待任务完成的时候,需要传入此枚举表示这个用例期望这次任务的结果是哪种状态,如下图表示期望dataload 运行成功。 当然也有些case会期望任务失败。

模块间有数据依赖的时候。每个模块自己负责提供对外接口。

比如测试模型中心或者预估服务的时候,首先必须要有模型事先产出。而产出一个模型需要在模型IDE中执行很复杂的步骤,跳转多个页面。 那么模型IDE负责对外提供一个封装了所有逻辑的简单接口对外使用。 例如:

ModelIDE负责提供modelFactory,调用方只需要传递一个模型训练算法的默认配置就可以产出相应算法的模型出来。 至于里面如何创建project和dag, 使用什么数据,怎么抽取特征等等都不是调用方关心的。 他们只要一个模型出来,至于这个模型怎么出来的逻辑,不要暴露给调用方。

所有业务逻辑使用@Step标注进行标记(allure 的特性).

用例编写规则

每个case都必须使用Features,Stroies, Title 标注来为case添加report 信息(我们使用的是allure这个report框架), 根据情况可以添加Description标注。

具体如下:

case中涉及UI上创建的实体名称,比如项目,数据,模型,用户等都需要使用随机名称。 不能使用固定名称。 以防一个环境多次运行的时候因为名称冲突而失败
case中不准许出现页面元素信息,所有页面元素的封装和业务逻辑的封装要写在page层中

结尾

到这里差不多了,主要是一些设计上的规范,剩下的什么命名规范之类的就不讲了。 下一次更新一把UI自动化中常用的设计模式。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 18 条回复 时间 点赞

果断收藏先~

UI自动化的技能、实现门槛不高,主要还是ROI,这是很多公司搞不起来的主要原因。

收藏学习

赞一个,全能呀

思寒_seveniruby 将本帖设为了精华贴 08月13日 21:16

$(ByText("立即登录")).click()这个$是怎么玩的?

AngryTester 回复

这个是selenide的方法, 就是个以$ 命名的方法,然后用static import引入过来的而已

孙高飞 回复

噢噢 多谢解答

期待下一篇的设计模式讲解

大神,问你一个问题,没有实际项目的情况下,没有实际应用下,如何深度掌握测试相关的技术,举例:接口测试

我问问 回复

在没有实际应用的前提下, 深度掌握 是不太可能的。 技术的深度取决于遇到问题的复杂度。 如果连问题都没有遇到过~~ 那就没什么深度造诣了

多谢分享,学到一种新的UI自动化思路。

感觉自己的虽然在做页面自动化但是和这个模型比起来简直差太多了,虽然有些地方不太理解。但是还是受到了很多收益,感谢

学习成本太高 对开发要求有点高 自动化 主要的体现应该在易用性和可维护性以及稳定性上面 可维护性体现在 对象 数据 和业务的抽离。

我目前也在做基于PageModel模型的自动化框架,但是用的技术比较基础,没啥技术含量,但是我也觉得LS的朋友说的也有一定道理,UI自动化主要的体现应该在易用性和可维护性以及稳定性。

学习一下

红客联盟 python 常用 UI 自动化设计模式总结 中提及了此贴 11月15日 15:54

期待pageobject模式有深入讲解,pageobject提了一下概念没有完整代码解释还是有点雾里看花的感觉,网上百度的都是两层封装,很少有三层封装。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册