问答 接口测试时，所有场景的返回都是操作成功，这种情况怎么处理呢？
1.从开发角度讲，不把报错信息报给用户，让用户无感提升用户体验。
2.从测试角度讲，光看返回结果，无法判断是真的成功，还是假的成功。只能查表一条条数据检查。这种情况，你们都怎么处理呢？
补充一下哈：
设计是这样的，对异常情况，后端不处理。
比如满足条件时，后端会更新 db，发送通知；
不满足条件，后端不处理，于是返回操作成功。
对这种情况，你们是怎么做的呢？
对
jasminebb
回复
jasminebb
回复
对于每个系统，不同的设计，都有不同的解决方案，个人认为没有一个标准的完美的解决方案。
对于你这个问题： 后端处理成功会有两种操作：1. 更新 db, 2.发送通知.
那么就有两种判断方式:
- 读取 DB，判读数据。 2.如果可能，可以获取通知，通过通知判断结果。 ----以上的两种方法都可以封装成公共方法，减少代码冗余。
回到接口测试（自动化测试）的初衷：使用代码代替人做测试而已，那么人是怎么判断的，就可以使用代码来代替人的判断方式即可。
个人建议，仅供参考。
后端为什么不报错呢？如果后端报错了为什么前端一定要如实报错？
返回值是个 json 值的话，可以通过 json 值的内容来判断，而不仅仅是通过 status code（200？）来判断。
对
t-bug
回复
t-bug
回复
设计是这样的，对异常情况，后端不处理。比如满足条件时，后端会更新 db，发送通知；不满足条件，后端不处理，于是返回操作成功。
对
jasminebb
回复
jasminebb
回复
对于每个系统，不同的设计，都有不同的解决方案，个人认为没有一个标准的完美的解决方案。
对于你这个问题： 后端处理成功会有两种操作：1. 更新 db, 2.发送通知.
那么就有两种判断方式:
- 读取 DB，判读数据。 2.如果可能，可以获取通知，通过通知判断结果。 ----以上的两种方法都可以封装成公共方法，减少代码冗余。
回到接口测试（自动化测试）的初衷：使用代码代替人做测试而已，那么人是怎么判断的，就可以使用代码来代替人的判断方式即可。
个人建议，仅供参考。
对
t-bug
回复
t-bug
回复
嗯嗯我明白了，不同的设计都有其存在的道理，相比直观地判断接口返回，读取 DB 虽然复杂一些但也是一种值得尝试的解决方案。感谢感谢