• 好的,谢谢。我之前在想不做这个地方,但是考虑到手动测也不容易 ,因为列表行数很多。所以想着用自动化。

  • 前端有一个页面显示了列表的总条数,而且点击后会转到列表页,用不用去看列表中的数据是否和前一页中的统计数一致呢?

  • 我也是您说的方法一,问题是如何保证每一次滚动,滚动后的页面元素正好是滚动前的元素后面的元素?

    不然会统计到重复或者遗漏元素,而且由于列表会出现相同的文本,所以无法以文本作标记。

  • 是的,发现划出去就定位不到了,是不是这样比较难实现?

    滚动到最后,可以通过再往下拉,如果还是和当前页面一致,则不再划动。但是总的来说,这样做非常耗时间。所以目前比较迷茫的两个点:
    1.这个功能需要放到自动化测试里面吗?如果放,有没有比较简单的方法可以实现的?

    2.这个功能如果要手动测试中检查,好像也很不简单,因为列表可能有 60 多条,人一个一个去看也不现实。

  • 确实重启 app 后,感觉测试时间也增加了

  • 这样子,之前提到了后置操作,前置操作,但是确实没有看到过准确的描述,所以不知道指的是重启 app,不好意思。

  • 谢谢,我会好好构思一下用例的编写的。 @qiuhengxing @xglh0901

  • 比如说 一个可以增删查改的功能,比如新建微博,编辑微博,删除微博等等, 编辑和删除无法避免的会用到新建微博后的微博数据,我现在的做法是将微博新建后,保存在文件中,但是如果微博新建时挂掉了,编辑微博时用例可能会受影响

    您的意思是这几个用例的开始时,都用接口查一遍微博数据,然后用接口返回的数据而不是文件中的数据吗?
    我有点纠结的地方是:这样子的 ui 测试结果受接口数据的影响,有时候,新建微博虽然成功(即接口真的有返回),但是实际上断言微博被创建成功时失败了,我应该相信自动化测试的结果还是相信接口数据返回的结果?

  • 请问如何保证用例的独立性呢?

    就以上面提到的例子:

    后续进行其他测试,测试完更换头像后,进行搜索测试,如果前面的测试正常通过了,在前面一个用例的末尾,我会从挂件商城 -> 个人微博页 -> 我的页面,会返回两次,但是如果前面的用例挂在中间页面(个人微博页)了,我本来只需要返回一次,但是返回两次就回到桌面了,这个情况也是会出现的。

    这种情况的后置处理,我应该在 teardown 中返回一次,还是返回两次呢?

  • 谢谢,我的重跑机制是失败了之后马上重跑,所以有时候导致重跑必定失败,我会去试着改变重跑机制的,您的思路很启发我。