一、RF WEB端自动化测试环境
-
- 必要的库:SeleniumLibrary FakerLibrary AutoRecorder SikuliLibrary
备注:分享的时候要讲清楚这些库是干嘛用的,在代码上演示下
-
- 必要的知识点:RF如何自定义变量(列表,字典);RF如何设计For循环
-
- 必要的思想:学会封装关键字,让用例足够灵活,足够健壮,足够简洁不臃肿
-
- 必须要有的辅助工具:xpath的编写技巧,以及官方文档:http://robotframework.org/SeleniumLibrary/SeleniumLibrary.html#library-documentation-top
-
- 必要的驱动:谷歌的驱动,火狐的驱动
二、需求分析,测试点提取
-
- 需求一:考勤管理(PC端)
-
1 新建考勤规则
-
2 考勤规则统计
-
- 需求二:学校管理,包含创建学校,教务登录,导入学生
-
1 创建学校
-
2 教务登录-首次修改密码
-
3 教务管理-导入学生(Sikuli方案实现)
-
备注:提取测试点,要分类,操作性的测试点,校验类的测试点。要分重点,用例的重要性与优先级,核心功能优先,主流程优先
三、框架设计,结构分层
测试用例区(主要对用例进行分类管理)
-考勤用例区(或者再分类管理,比如公共变量区等)
-case001
-case002
-请假用例区
-case001
-case002
-学校管理用例区
-case001
-case002
公共组件区(封装的都是公共的常用方法)
-public_resource.robot
-关键字一
-关键字二
-关键字三
页面元素区
-需求名或迭代名
- 页面一(这个就相当于一个对象)
- 变量(就如对象的属性,如某个按钮,字段,主要用来存储路径位置信息)
- 方法 (就如对象的方法,有针对整个页面的,也有针对某个按钮的)
外部组件区
-thired_reource.robot(这里可以封装下自己写的py辅助测试方法)
-关键字一
-关键字二
成品其实就是下图所示:
因为涉及到很多项目信息,这里只展示部分;其实这里就是告诉大家,设计分层的思想。只要领悟到这个,就足够了。
四、开始编码实战
谨记:自动化测试编码一定一定要写好备注
-
测试前
1 目录建好后,可以封装一些我们常用的方法,封装不是简单的照搬,而是一方面统一方法的内部命名,即使三方的方法有改动,我们只要改自己的方法就可以,而不是去代码中每个方法都改掉。另一方面,常用的方法可以若干个方法封装到一起,降低后期编码的重复性,臃肿性。
如下图:打开浏览器,放大浏览器,执行速度,断言+截图几种方法封装成一个方法
2 目录设置好之后,要抽出页面--->抽出页面的属性--->编写这些属性的各种方法,如抽出输入框,编写针对输入框的点击,输入,粘贴,复制等方法。这里的思想就是,属性的位置信息并不重要,也不影响我们的编码进行,这就是测试驱动,变量而已,我们随时可以定义他,这个时候专注于方法的编写
3 开始编码
案例实际运行与讲解,一步一步进行(本次内容案例代码是之前进行内部分享培训的时候写的真实案例,只贴出部分核心流程代码)
涉及到for循环的编码(循环创建学校,导入学生等都涉及)
循环创建学校(上图对应代码)
进入新建学校页面
FOR ${index} IN RANGE 10
新建学校
letalk_wait_until_page_contains_elements //*[@id="fSchoolListForm"]/div[1]/div/div/a[1]
click Element //*[@id="fSchoolListForm"]/div[1]/div/div/a[1]
END
与原生JS交互模块的编码(创建考勤规则处涉及)
-
[Arguments] ${input_starttime} ${input_shouldtime} ${input_endtime} #下面动作是输入开始时间 Click Element ${start_time_attendences} #点击开始时间输入框 SeleniumLibrary.Input Text ${start_time_attendences} ${input_starttime} #输入开始时间 letalk_wait_until_page_contains_elements ${time_click.start} #等待确定按钮的出现 Click Element ${time_click.start} #点击确定按钮 #下面动作是输入应到时间 Click Element ${should_time_attendences} SeleniumLibrary.Input Text ${should_time_attendences} ${input_shouldtime} @{confirm1} Get WebElements ${time_click.should} Execute JavaScript ARGUMENTS @{confirm1} JAVASCRIPT arguments[1].click(); #下面动作是输入结束时间 Click Element ${end_time_attendences} SeleniumLibrary.Input Text ${end_time_attendences} ${input_endtime} @{confirm2} Get WebElements ${time_click.end} Execute JavaScript ARGUMENTS @{confirm2} JAVASCRIPT arguments[2].click(); sleep 2
断言(内容非常多,因为UI是可视化,断言在前期显的没那么重要,断言对于后期持续集成非常重要,之后会在实战中学会如何断言的,前期就先别关注了)
-
测试中
补充元素定位路径信息
冒烟测试执行:没错,我们在提测前就把自动化给写好了,补充完元素定位信息,你的代码应该是可以快速跑起来的,冒烟测试主流程完全可以自动化去执行。
挑选bug,并用例化(持续集成,迭代太快了,一个新增请假功能,每次CI CD后,我都要去验证下,因为经验上来说你也不知道开发改的东西会影响什么,每次出的问题都不一样,所以非常有必要把这块给用例脚本化)
-
测试后
根据测试中经验持续的增加用例的脚本化
五、测试报告与测试分析
1 生成report(汇总展示),log(具体的执行过程),output.xml(数据组织者,我们无需关注)
2 生成webm格式视频文件,会嵌套在web报告中
这就是进行一次完整的WEB UI自动化测试,你需要思考的内容。虽然文章没有贴出来具体的代码,在于想要给大家传递一个思想:分层设计
另外其实总结下来就是:
1 设计自动化的目录机构
2 在公共组建区封装一些常用的方法,比如打开浏览器,进入到某个页面,点击某个元素等
3 分析需求,抽取出来页面方法与属性
4 最后在用例区调用这些方法,通过传入不同参数,轻松实现用例的快速覆盖。
按照以前分享的经验呢,新手其实还是对于一些细节是疑惑的,掌握思想,比掌握细节更重要,细节后面会慢慢都会涉及到的。