Software Testing - UI自动化测试设计规范

向右看齐 2021-10-18 22:24 297阅读 0赞

分享一个大牛的人工智能教程。零基础！通俗易懂！风趣幽默！希望你也加入到人工智能的队伍中来！请点击[http://www.captainbed.net][http_www.captainbed.net]

### 总体规则 ###

所有模块设计均遵循POM（Page Object Model）结构，从上到下大体分为三层：

1.  用例层：编写测试用例代码的地方，调用业务逻辑层。
2.  业务逻辑层：根据业务需要，封装常用的业务逻辑（相比于Page层的业务逻辑封装，它的范围更广，有些时候是跨页面的业务逻辑，属于模块级的业务逻辑封装）。
3.  Page层：一个页面一个类，包含该页面的业务逻辑封装以及控件定义。

### 页面设计规则 ###

1.  所有导航，页面辅助控件以及会跨越多个页面的逻辑均设计为接口，在接口中提供默认实现。
2.  每个Page类只负责自己页面的逻辑。
3.  页面类的类名以Page结尾。接口（共用逻辑）不得使用Page结尾。
4.  每个页面以封装业务逻辑为主，通过参数控制调用不同的业务逻辑。无特殊情况下不要让外界知道控件的信息。
5.  所有页面逻辑皆返回特定页面对象，以保证测试用例使用fluent式API调用。
6.  除特别简单的逻辑外，所有业务逻辑的参数均使用Java Bean以及枚举封装，禁止使用基本数据类型（int、String、long等)，并按照UI实际情况设计默认值。为防止产品设计变化，所有的业务逻辑参数都由Java Bean封装。因为如果不使用Java Bean而是使用基本数据类型，那么在产品变化的时候，比如UI上多了一个必填的元素的时候，方法签名就会变化，导致所有调用此方法的调用方都要随之改变；而使用Java Bean封装的参数可以在其中直接增加一个属性并设置默认值即可。
7.  所有状态码，产品特定文案，内置类型等均使用枚举定义，并使用枚举来规范入参。
8.  模块间有数据依赖的时候，每个模块自己负责提供对外接口。

### 用例编写规则 ###

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

[http_www.captainbed.net]: http://www.captainbed.net/troubleshooter