第八节002 robotframework实战

       点击查看更多内容集合

         上一节完成了新增，编辑的自动化用例设计，本节继续，完成查询功能用例设计，以及一个稍微复杂场景的用例设计

        查询页面测试方法编写与用例设计：

从上图需求可以看出，我们要输入x号，选择状态进行查询，同时要断言，查出来的数据是否准确

页面方法设计如下图：

方法设计完成后，我们要设计测试用例：

search_001: 输入准备好的姓名，选择启用状态，点击查询，断言列表搜索出来的x号确实与这个名字对应

这个应该会有个思考点的：是否有必要进行用例的独立性设计？是否可以相互依赖呢？【开放性命题，本人习惯性会设计独立，但是以本案例来说，搜索型的功能，我们是可以通过clear=true来，不用每个case独立应用一个driver，用一个driver就可以完成若干个用例】

search_002: 选择未启用，输入准备好的姓名，点击查询，断言搜索出来的内容，其中x号与这个名字是匹配的

其他用例就不展示了，都是输入不同的参数，进行校验。

-------------------------------------画个横线，进行标识完成了查询功能的测试----------------------------------

其他页面的方法这里也都不赘述了，与上述的方法设计类似，下面我们再讲解一个复杂一点的，新增课程考勤

        从上述页面，我们可以想到，我们最少也要设计7个方法来进行，分别针对每个输入或选择字段的方法，输入时间的方法，选择考勤对象的方法，选择考勤状态的方法，选择刷卡考勤状态的方法，选择考勤激励红花的方法（这个可以图中看出来，我们最好是再写三个方法，分别针对准时，迟到，缺卡），选择消息推送对象的方法，还有一个供测试用例调用的方法，下面开始一个个设计

输入考勤时间方法：根据用户的输入，进行输入框的输入

选择考勤对象方法：点击下拉框，然后根据用户输入选择，然后再点击下拉框，把这个下拉框给收起来

选择考勤状态方法：先点击icon ，把下拉框给展示出来，然后选择启用或未启用

选择刷卡状态的方法：要判断用户是否传入了内容，没传入就默认，不做操作，传入就点击以下这个开关按钮

选择考勤激励方法，调用了选择准时奖励，选择迟到惩罚，选择缺卡惩罚三个方法，我们把入参设计成了list的形式，用户只需要输入类似1 2 3 或者 2 2 3 就可以

选择推送对象的方法，用户的入参是了个列表，我们方法拿到列表后，进行循环操作

发布规则方法，供测试用例中调用，我们可以看到我们设计了6个入参

选择准时奖励，选择迟到惩罚，选择缺卡惩罚三个方法：先判断用户输入的数字是多少，然后点击对应的红花奖励按钮

方法设计完成后，就是设计我们的测试用例了，如图，我们通过数据驱动的形式，不同的入参，区覆盖我们设计的功能测试用例

注意case12：断言是采用多条件的形式进行的断言，目标其实就是为了增加脚本的健壮性

到此，我们的用例自动化测试用例就设计完了

四、冒烟测试阶段

    产品提测后，我是直接启动了UI自动化脚本进行冒烟测试，毕竟是冒烟测试，所以我建议冒烟测试脚本的第一次执行，一定要注意观察执行过程。

    观察过程执行过程中是否有错误发生，因为首次跑的话，方法设计不规范，不健壮，就会导致脚本自身出问题，或者断言写的不好，最终从报告上也捕获不了有用的信息，虽然我们有截图与录制屏幕，但是由于断言写的不好，问题看起来也是不方便的，所以执行过程我们可以用眼睛观察执行过程，有错误的地方，我们记下来，再去找日志截图或视频，最终将问题反馈到开发。

    本次迭代，自动化冒烟中发现的问题有如下：

eg:选中导出没有看到导出文件【选中导出-search_02】用例发现的问题

eg:添加职工后，界面未调用list接口刷新【编辑职工-edit_01】用例发现的问题

eg:输入错误格式手机号，再次添加输入正确后，仍然提示手机号格式错误【新增职工add_xx】用例发现的问题

.......

还有一些，就不一一列举，证明了一个点，就是UI自动化测试是可以发现bug,并且在发现bug的同时，解决了测试一直要做重复性工作的问题，更多的精力与能力应该用到探索测试，性能测试，接口测试，用户体验测试等上来~

由于冒烟阶段我们主要是测试主流程是不是通过，一些正向功能是不是正常，所以这里我们执行的用例，要执行主流程的用例，如何标识呢？其实我们在用例设计的时候，把每个用例打上标签tag就可以了，比如我用master来标识主流程，核心功能正向用例，那我们执行时候，指定标签tag就可以。其他的更多逻辑在回归测试阶段再进行

五、回归测试阶段

    作为测试人员我们都知道，针对手机，邮箱，姓名，查询输入框等的输入型逻辑测试用例是非常多的，我们通过数据驱动就可以完美解决了，本次迭代中，新增职工，修改职工，重置密码，查询功能，等输入框的用例，我们是全覆盖的；就将测试人员从这种简单的重复性逻辑测试中给解放出来了，更多的去进行比如上传的并发测试，按钮的多次点击测试，页面的性能测试等探索性测试。

下面给大家列一下自动化测试覆盖的场景，这样子大家会更有直观的感觉

模块	用例	描述
新增职工	add_001	输入姓名10个汉字
	add_002	输入姓名20个汉字
	add_003	输入姓名21个汉字
	add_004	输入空值:${EMPTY}
	add_005	输入带字符的姓名：塔塔穆斯坦.迪丽热巴.凡尔赛
	add_006	输入纯英文：Stronger Faster Bester
	add_007	输入空格：${SPACE}
	add_008	选择男
	add_009	选择女
	add_010	输入手机号：11111111111
	add_011	输入10位手机号：1825845069
	add_012	输入手机号：中文字符
	add_013	输入手机号：英文字母
	add_014	输入手机号：不输入，${EMPTY}
	add_015	输入手机号：输入12位手机号
	add_016	手机号：正确手机号
	add_017	邮箱：不输入${EMPTY}
	add_018	邮箱：78458@
	add_019	邮箱：@gmail.com
	add_020	邮箱：正向
	add_021	邮箱：新建两次一样的邮箱
编辑职工	edit_001	校验，修改页面，带入的显示内容是否正确
	edit_002	修改姓名，其他不变
	edit_003	修改手机号，其他不变
	edit_004	修改邮箱，其他不变
	edit_005	修改存在的手机号
	edit_006	修改存在的邮箱
	此处可以省略亿条用例，理论上是要测试完新增时候一样的用例的
职工查询功能	search_001	查询：选择启用 输入姓名
	search_002	查询：选择未启用，输入姓名
	search_003	查询：全部，输入姓名
	search_004	查询：选择启用 输入乐号
	search_005	查询：选择未启用,输入乐号
	search_006	查询：全部，输入乐号
重置密码	setpwd_001	重置密码：不填写，点击确认
	setpwd_002	重置密码：输入8个空格
	setpwd_003	重置密码：xy1234 \ \ 6个字符
	setpwd_004	重置密码：输入qweasdqwe \ 纯英文
	setpwd_005	重置密码：输入986374637 \ 纯数字
	setpwd_006	重置密码：输入a12341234 \ 符合规则的密码
	setpwd_007	重置密码：输入‘凡尔赛的传说’ \ 输入中文
	setpwd_008	重置密码：输入‘*&%*%&%*%’ \ 输入纯特殊字符
	setpwd_009	重置密码：输入‘xy@123789’ \ 带有特殊字符
新增考勤状态	add_course_001	考勤时间：10
	add_course_002	考勤时间：空值
	add_course_003	考勤时间：60
	add_course_004	考勤时间：61
	add_course_005	考勤时间：0.99
	add_course_006	考勤时间：1
	add_course_007	考勤时间：59
	add_course_008	考勤时间：空格${SPACE}
	add_course_009	考勤时间：字符串abcd
	add_course_010	考勤时间：1/3
	add_course_011	考勤时间：
	add_course_012	考勤状态open
	add_course_013	考勤状态close
	add_course_014	刷卡状态关闭
	add_course_015	奖励：2 2 2
	add_course_016	奖励：1 2 3
	add_course_017	消息推送对象：校长
	add_course_018	消息推送对象：教务
	add_course_019	消息推送对象：老师
	add_course_020	消息推送对象：校长，教务，老师
	add_course_021	考勤时间：2.11

    上述用例共计63个，按照1分钟一条用例来算，如果手动执行，执行完以上用例要用63分钟，30秒一条，要用32分钟，中间我们做了那么多重复工作，有没有覆盖过，连我们自己都不知道了。

    同时考虑到频繁的构建发布，有bug要修改发布，换了个环境等，我们的用例都要重新执行，这个时间都要翻倍的。

    但是实际测试过程中我们是不是会经常发出这种疑问 “我测试时候明明是好的呀~” 所以，证据呢？或者我可以直接说你上线前回归测试没覆盖到，事实也确实如此~~

六、发布阶段

 发布阶段就执行我们打好的主流程标签即可

七、总结

     一方面在测试中产生了积极的影响，因为要测试其他逻辑，新建的功能必不可少；同时我们是持续集成，构建的频率是非常高的，需要回归的次数也就增多，有了脚本，大可提效（偷懒）很多。

    另一方面在测试后，也就是发布阶段的回归测试中，确保回归率，与效率回归。

点击查看更多内容集合