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

分享一个大牛的人工智能教程。零基础！通俗易懂！风趣幽默！希望你也加入到人工智能的队伍中来！请点击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层中。