添加成功后，怎么做断言？

我们新增成功后，一般都会在第一条，这个时候，对比一下第一条数据与新增的内容是否相同。
不知道你们系统是什么样的
可以按照新增规则去找到新增的那条数据，然后去对比

像这种表单页面，查询怎么做断言？

具体是想怎样呢？
是查询后，检查查询结果是否正确吗？ 那这种情况得与接口一起测试了吧，单靠一个 ui 自动化应该是无法准确判断的吧。。。
还是原来是空列表，查询后有数据，或者原来有数据，查询后无数据呢？

我是每个页面封装了一个 page,还有业务操作逻辑，那我测试一个完整的流程的时候，是每个页面的方法完了就进行断言，还是整个业务流程结束了再断言？

这个没有要求吧，看你自己了。你也可以一个步骤写一次断言，也可以整个用例类完成后写一个断言，也可以一个用例写完写一个断言。
一般不都一个用例一个断言吗？

通过调服务端查询接口，针对返回值做断言，要做 end 到 end 的用例

页面响应断言，一般是根据页面元素做判断或者页面跳转

第一种，我们的系统，新增的也会在第一条，那我就拿添加成功后的某个元素的值与预期结果比对就可以了是吧
第二种，查询，公司没特殊要求，我觉得是，比如我通过某个字段查询，查询出很多结果，判断这些结果里有没有我要的数据
第三种，业务流程类的，那我就一个用例做一次断言

嗯，明白了，像新增的，一般会出现在页面列表的第一条数据，就那第一条数据的某个元素与预期的值进行对比，你说的页面跳转是判断 url 吗？

还要调接口吗？我的思路是，我查询某个字段，判断返回的数据里，有我需要的数据不就行了吗？

测试分层还是没有做好，在 UI 层不太需要关注数据的返回及展示，那是接口层应该去做的。对于 UI 测试来说，更关注的是页面是否能够正常展示，元素是否有变形。而不是过多的关注数据是否正确。

像这种添加成功后，怎么做断言呢？
--这类只要保证数据能被正常展示就可以，是否在第一条并不重要，我会更关注页面的分页是否有效，是否出现了翻页按钮。

还有像这种表单页面，查询怎么做断言？
--查询只要有数据展示就 OK 了，更需要关注的是查询、删除这些按钮是否有错位（比如某些字段值超长，导致页面变形）

再比如说，我是每个页面封装了一个 page,还有业务操作逻辑，那我测试一个完整的流程的时候，是每个页面的方法完了就进行断言，还是整个业务流程结束了再断言？
--断言是需要每个环节都设置的。

不要在 UI 层纠结过多的数据验证！！那是接口需要关注的。不要让 UI 做所有的事，否则你的脚本可维护性会很差

实在没办法，查询数据库与新增的数据对比喽

感谢回复，这个我确实搞混了，接口去校验数据，UI 层也校验数据了，添加那个没有刻意去校验是否在第一条，是因为添加后会在第一条展示
第一个，你说判断分页是否有效，是否有出现分页按钮，那我是判断有没有出现下图这个图标的元素出现是吧？

第二个，判断按钮是否有错位，那是，定位到按钮的元素，取出按钮中的文本，检查字段值长度是吧？
第三个，明白了，我就每一步都做断言

有个问题，如果在 UI 层不关注数据的返回及展示，那如果前端把接口请求写错了，这种 BUG，自动化就测试不出来了

app 的话，可以断言 activity 页面 appium 可以获取到的，selenium 的话 应该可以获取到 url 域名都是相同的嘛 根据后缀判断是否跳转，然后取值的话 可能还要设个等待，页面加载可能会存在网络波动导致加载失败。取值的话就根据元素

我们公司是拿 UI 展示的数据与数据库比对

明白了

你这操作，怎么看的像接口做的事

接口调错，这个是功能测试需要验证的问题，放在 UI 层，你也发现不了。因为业务逻辑的问题，UI 没办法处理，除非你的检查点设置的非常刚好。

测试分层，做好自己的事。把所有情况在一个层次上去解决，可能什么都解决不了。

我们公司是这样要求的，当然页面稳定性也是关注的，都要看

查询条件不是有个名称吗，那个名称在你添加的数据里面有的吗，有的话可以自定义个名称，存起来，然后添加完成后，查询那个名称，有的话就是添加了。每次运行就生成不一样的名称，可以加时间戳或日期 + 随机数啥的，保住执行一次是不一样的名称数据。

UI 脚本其实就是把手工的操作转化成脚本来执行，所以从这个角度出发，问题都很简单了。
1.添加是否成功：在添加动作做完了以后，会有成功提示信息（验证点 1），确认提示后页面会显示刚才添加的文本内容（验证点 2）
2.查询断言：针对的是查询这个功能，点击查询按钮后数据可以出来，那就是查询功能没问题；
3.你的页面操作，是根据测试用例来的，需要验证的也只是期望结果，没有必要都写验证。