RFS的常用思路

简单的做个记录：

1. 基本框架的搭建：

　　- 一个层用于页面控件的关键字封装（比如表单控件的处理，列表的处理等）

　　- 一个层用于系统常用功能操作的封装（立足于整个系统的，比如登陆，查询，业务参数，文件的上传下载等）

　　- 一个层用于系统的自动化用例实现

　　如图：

      

 2. 三层结构的思路：

　　默认分为三层来进行处理，类似于积木块的方式，这也是关键字的好处。

　　- L1层：场景层，这里是对场景进行设计和管理，简单的说就是 模块 - 测试套件 - 测试用例。测试用例就是可执行的，设计好的场景。

        传入的参数在场景层进行维护，就是说只有执行用例的时候才会传入参数，但用到的参数会从页面层-功能层进行设定。

        场景层尽量不要出现底层的关键字，比如click element，close browser之类的。

        场景层需要进行用例的校验

　　- L2层：功能层，是对具体页面的功能进行维护。

　　  功能层尽量也不要出现底层的关键字

　　  功能层是多个页面层关键字的组装，也包括校验。参数可以在功能层设定好

　　-L3层：页面层，是对页面里面的元素进行关键字的维护，是最小颗粒度

　　  一般一个功能会有多个页面组成，单一元素的页面可以依据功能的大小自己来设计是否拆成更小的颗粒度页面。比如有个页面有多个页签，每个页签还有多个功能，此时可以考虑每个页签都做成一个页面的关键字。

　　  页面层需要的参数都需要在页面层定义好。比如有个Name的参数，功能层需要用到，在功能层也需要定义一个Name的参数，这样在场景层传入的时候，会逐层的传递下来。

 

转载于:https://www.cnblogs.com/polestark/p/5809177.html