Software Testing - UI自动化测试设计规范
分享一个大牛的人工智能教程。零基础!通俗易懂!风趣幽默!希望你也加入到人工智能的队伍中来!请点击http://www.captainbed.net
总体规则
所有模块设计均遵循POM(Page Object Model)结构,从上到下大体分为三层:
- 用例层:编写测试用例代码的地方,调用业务逻辑层。
- 业务逻辑层:根据业务需要,封装常用的业务逻辑(相比于Page层的业务逻辑封装,它的范围更广,有些时候是跨页面的业务逻辑,属于模块级的业务逻辑封装)。
- Page层:一个页面一个类,包含该页面的业务逻辑封装以及控件定义。
页面设计规则
- 所有导航,页面辅助控件以及会跨越多个页面的逻辑均设计为接口,在接口中提供默认实现。
- 每个Page类只负责自己页面的逻辑。
- 页面类的类名以Page结尾。接口(共用逻辑)不得使用Page结尾。
- 每个页面以封装业务逻辑为主,通过参数控制调用不同的业务逻辑。无特殊情况下不要让外界知道控件的信息。
- 所有页面逻辑皆返回特定页面对象,以保证测试用例使用fluent式API调用。
- 除特别简单的逻辑外,所有业务逻辑的参数均使用Java Bean以及枚举封装,禁止使用基本数据类型(int、String、long等),并按照UI实际情况设计默认值。为防止产品设计变化,所有的业务逻辑参数都由Java Bean封装。因为如果不使用Java Bean而是使用基本数据类型,那么在产品变化的时候,比如UI上多了一个必填的元素的时候,方法签名就会变化,导致所有调用此方法的调用方都要随之改变;而使用Java Bean封装的参数可以在其中直接增加一个属性并设置默认值即可。
- 所有状态码,产品特定文案,内置类型等均使用枚举定义,并使用枚举来规范入参。
- 模块间有数据依赖的时候,每个模块自己负责提供对外接口。
用例编写规则
- Case中涉及UI上创建的实体名称,比如项目、数据、模型、用户等都需要使用随机名称。不能使用固定名称,以防一个环境多次运行的时候因为名称冲突而失败。
- Case中不准许出现页面元素信息,所有页面元素的封装和业务逻辑的封装要写在Page层中。
还没有评论,来说两句吧...