经常遇到的一个问题是:当我需要进行某一个功能的测试时,往往需要从 A 页面跳转至 B 页面,再跳转至 C 页面,才能测试到这个功能。
当遇到这种情况时,请教大家是怎么协调这些情况的呢?
在 web 自动化测试中,我对于每个页面都设置了它的 url,所以当用例起始时不在当前 url,则跳转至当前 url,这样保证了用例重跑的稳定,但是 app 端我直接只好把重跑撤掉了。但是还是会有前面的用例失败,后面的用例几乎全军覆没的情况。暂时没有特别好的办法。
每一条用例都是有环境准备和后置处理的,尽量保证每一条用例都是独立的,不要依赖前一项用例。
另外对于 UI 自动化来说,路径之间都是有逻辑可循的,用数据结构 - 图的方式记录 UI 节点之间的关系,跳转方式,其实可以写一套通用的页面跳转方法。
用例之间相互独立,如果有数据预置的操作,尽量用接口去操作,减少 ui 层的请求链路
首先是自动化用例的选取吧,不能什么样的用例都去搞自动化,要考虑成本的。
其次,你是怎么设置重跑机制的?导致重跑第二次执行一定会失败?我说下我这边的经验,我是全部跑完之后记录下来哪些用例时跑失败的,然后再重新跑一遍失败的用例。重跑和第一次执行的内容是毫无关联的。
让开发配合做 deeplink,通过不同的 url 可以跳转到不同的页面。
脚本/用例的复用性:应该准备一个可以重复使用的干净环境(也就是一楼二楼说的环境准备和数据预置),该环境每次准备好后,脚本都可以从头开始跑,可以多次使用,不用跑一次维护一次
脚本/用例的独立性:各脚本间相互独立,不要出现很强的耦合性,不然后期维护量巨大(大到你只能维护没时间写脚本)
请问如何保证用例的独立性呢?
就以上面提到的例子:
后续进行其他测试,测试完更换头像后,进行搜索测试,如果前面的测试正常通过了,在前面一个用例的末尾,我会从挂件商城 -> 个人微博页 -> 我的页面,会返回两次,但是如果前面的用例挂在中间页面(个人微博页)了,我本来只需要返回一次,但是返回两次就回到桌面了,这个情况也是会出现的。
这种情况的后置处理,我应该在 teardown 中返回一次,还是返回两次呢?
比如说 一个可以增删查改的功能,比如新建微博,编辑微博,删除微博等等, 编辑和删除无法避免的会用到新建微博后的微博数据,我现在的做法是将微博新建后,保存在文件中,但是如果微博新建时挂掉了,编辑微博时用例可能会受影响。
您的意思是这几个用例的开始时,都用接口查一遍微博数据,然后用接口返回的数据而不是文件中的数据吗?
我有点纠结的地方是:这样子的 ui 测试结果受接口数据的影响,有时候,新建微博虽然成功(即接口真的有返回),但是实际上断言微博被创建成功时失败了,我应该相信自动化测试的结果还是相信接口数据返回的结果?
我觉得在每次错误判断之后应该要返回到你脚本一开始执行的起点,如果是桌面就一直多按几次返回键,如果是应用首页就在回到桌面之后再进应用,不管怎么样都要确保重跑或者下一条用例跑的时候不会因为上次的异常出现问题。
感觉你这个没必要用接口去查数据吧,纯粹走页面判断就好了,这种关联性特别强的,我觉得完全可以放在一条用例里面,添加,编辑,删除,失败了也可以根据这个顺序重跑, 没必要做的特别复杂吧
比如编辑微博这个功能,需要有一条已存在的微博,这个新增微博数据通过接口来实现,不要操作 ui 层去做;如果要测试 ui 层的新增微博功能就另说了
谢谢,我会好好构思一下用例的编写的。 @qiuhengxing @xglh0901
是什么原因导致的失败?
返回什么啊返回,前置操作就是重启 app,每条用例都直接从主页开始操作
schema 跳转指定页面了解一下?
mark 一下,自己项目里重试一直没想到好办法
前面的用例挂了由前面的用例恢复环境,回到用例执行之前的入口,不要在后面的用例去判断,tear_down 要做到开始之前是什么样,结束之后就什么样。
mark 一下
mark 一下
我想问一下,怎么实现所有用例跑完之后再将失败了的用例重跑一次?我发现 pytest-rerunfailures 是一个用例失败之后马上重跑的
我尝试了,但是 allure 报告中只会出现第二次的部分错误的测试用例,不会出现所有的测试用例。如( https://testerhome.com/topics/30265 )所展示的报告。请问是我的命令哪里写的不对吗,还是这是 pytest 的一个缺陷。
这不是 pytest 的缺陷。allure 默认是只收集最后一次运行的测试结果,这个应该可以设置。
我在你那篇帖子的回复也部分有问题。
mark 一下