肯定要贴合业务的,和业务解耦太厉害了,要裁员的时候肯定第一个被裁,哈哈
全栈,我感觉就是啥都不精通的感觉
赞成,目前我就是在做这些事情,你们都做了哪些来提升效率?虚心请教
你这个我是赞同的,,只是我感觉活越干越少,框架啊,平台啥的都搞差不多了,不知道还需要搞些啥
自动化框架 肯定有人用啊,我目前搭建的 UI 自动化框架,还在不断的新增自动化用例脚本
只有我一个人想知道你现在薪资多少吗?
主要是想知道测试薪资瓶颈是多少
我个人建议不要校验数据库
理由:为开发这次改了 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
数据库稍微一变,也要跟着变,都不简单
说的很有道理,但是我没有时间去研究底层逻辑,能解决当前问题就好