我司统计 BUG 就去掉了重复、设计如此、外部原因等项
1、你不可能知道这是一条脏数据,比如,一条脏数据和正常数据,他们之间的区别只是人为修改了一个字段导致,可能这个字段在前端也不会展示出来,只有开发在 debug 状态下才能发现这个字段是错误的,所以可以确认你们研发是个撒币
2、如果不是人为修改数据库导致的脏数据,是通过其他写接口导致的,那么这一定是个系统漏洞,名正言顺的 bug
直接 sonar 扫描,能扫出很多空指针,提高质量还是有效的
你这个想法,现在的电脑安卓模拟器都已经实现了
没太看懂这个 diffy 对咱们测试有啥帮助
去掉 readonly 应该还有其他地方限制,单单去掉这个属性,input 可能还是只读的
厉害,成熟的风险评估能成为测试一大助力
大赞,受益匪浅,不过有一句 “同一个代码修改他影响了 10 个接口,你是不需要 10 个接口都测的” 这里回答说只是去找出 bug 最多的接口去测并不太合适,感觉这个应该搭配接口自动化平台去做,受影响的都自动回归才是最优解
老哥能不能说说实现逻辑
解释解释什么叫深度?什么叫深。。。度。
老哥,能不能说说思路还有 web 端的
安全限制是致命的,很多不可能让你去抓生产流量的,客户信息,财务信息等都是保密的
神奇
既不想写也不懂技术,那就只能一键傻瓜式操作,目前能符合你要求的就只有流量回放平台了
楼主,有看到用 UI 自动化用例 1500+,能推出一期 Cypress 的讲解吗
今年就一次了,请问现在是否还能提交议题呢?
好想法,要是哪怕有个 demo 就好了
安全比较舒服,有专项职位,感觉性能专项比较少
精准测试,了解一下
理解非常到位,赞
不错不错,你已经悟了
没有 xpath 定位不到的元素,1、建议下个 xpath 验证插件,验证你这个 xpath 是否正确 2、添加延迟等待
建议跟公司后端保持一致,出了问题能找到很多人帮你看
最后一句已经指明要点了,个例不代表全部,现在业界能做单测的可以说是很小的一部分团队,单测写起来比写业务可能还复杂还费事的