我个人建议不要校验数据库
理由：为开发这次改了 A 表，你校验 A，如果开发后面除了改 A，也改了 B 表，而你仍然只校验 A，那么 B 没校验就算漏测，所以干脆不要校验数据库，直接校验接口业务逻辑即可。

综上，该接口需要校验的部分如下，欢迎喜欢校验数据库的拥趸来喷我，在线应战！
1.判断接口返回了 success，且 id 不为空
2.另外的业务肯定有用到这个 id，用这个 id 去发送该业务的 get 请求，看返回的内容是不是刚才添加的内容

和我工作内容差不多，一起努力
向你学习

我的造数平台界面，
我是一个不喜欢思考的人，一个产品如果需要我做太多的思考，我会放弃使用
也不喜欢别人用我的产品还需要动用智力

你接口校验 只校验 部分字段么，我都是全量校验，生怕漏掉一个

我都是我一个人做，所以不存在 “花费了巨大的人力物力”

复盘，对齐，持续赋能

看着这种文章，就吃不下饭

期待，先关注一波

现在这个年头，谁还面纯测试😂

太赞了

1.相同部分的写到配置文件里，比如各种 url
2.不同的部分写到具体的测试用例脚本里，

String org = "";
if (环境1 ){
  org = "a";
}
if (环境2 ){
  org = "b";
}
if (环境3){
  org = "c";
}

简单粗暴直观好用

精准测试？

嗯嗯，你完全理解了我的意思，哈哈
我确实没说 itest 有问题

“接口测试的准备数据要用 UI 自动化来准备 ”
这句话的意思是 前置条件准备比较复杂，比如有一个用例，
用例：正常用户登录，输入用户名密码，能登入系统

但是在登录的时候，要校验 用户名背后管理的各种信息，比如
1.用户名没有被禁用
2.用户名在有效期以内
3.用户名对应的商家有上传营业执照，且营业执照在有效期以内
4.用户名有缴纳消费者保障费用
5.一些其它信息等。。

以上条件都符合才能正常登录，当然也可以通过接口来准备这一大坨预制条件，，只是比较麻烦，还不如走一遍 UI 自动化来的方便，不知道你们怎么准备这一大坨预置条件的？

额，就是准备用你们开发的 itest work

嗯嗯，分离的话倒是可以考虑下

因为系统比较古老，并不是像现在的前后端分离，不过也可以理解为接口，毕竟无非都是 GET POST 接口，只是工作量太大，字段稍微变动一下，接口维护工作量也大，所以还不如用 UI

数据库稍微一变，也要跟着变，都不简单

说的很有道理，但是我没有时间去研究底层逻辑，能解决当前问题就好

经历了动辄 测试平台，动辄 postman

全是古代的那种 http 请求，这个算接口不？

mock 工作量太大，而且数据有依赖，比如参数 A 对应的店铺，必须上传了营业执照且文件存在

就是玩儿，CSRF 和 jmeter 没有直接关系
我记得 jmeter 还有 selenium 插件来着，你怎么不用 jmeter 来操控 selenium？
就是玩儿

打印出来，每天背一遍