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

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

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

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

是的，发现划出去就定位不到了，是不是这样比较难实现？

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

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

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

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

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

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

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

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

就以上面提到的例子：

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

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

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