作为基线搞
可以将包大小检查场景扩展为包静态检查,加入 debug 开关是否关闭等常用的发布前需要检查的配置的校验,进而扩展测试场景
他俩之间本身只是协议的区别,接口测试个人认为测的是接口内部的实现,不关乎协议
现在不存在 ssl 了,都是 tls
待遇呢?
已发,请查收,谢谢~
不错啊
想去
个人认为,有几点是肯定可以确定的,否则就是实现不太合理:
web,h5,native 归根结底都是不同的 client 罢了,一般共用一套 server,其实重点逻辑应该在 server 端的测试,但实际上我们往往忽略了 server 端的测试。赞楼主善于总结和分享的精神
楼主说得很在理,我们也在坚持做 review,但发现收效甚微。大多都是规范类问题,很少有逻辑问题,很鸡肋的样子,怎么破?
wanglei~
学习了一个新的异常测试场景,依赖服务异常测试,楼主在异常测试领域挖得挺深,但确实归类有点凌乱,感觉大的分类上可以从前端 UI 和后端服务两个点进行切入,然后进一步细分
nonono,你没选货
好文,值得细品
啥可以的?
这个要手动不停敲回车看数据变化吧?为什么不用 jconsole 或 jvisualVM 等可视化的实时 JVM 监控工具呢
我以前负责分享这块的业务测试,简直是噩梦,目标三方多不说,场景也多,是否安装,安装了是否登录,再加上因被微信屏蔽而设计的曲折的分享路径,每次都要手工一个人回归,因为经常出现问题,那叫一个酸爽,没有找到合适的自动化方案能覆盖分享和回流的相关 case,看到这个帖子的标题好激动,期待看到好的具体解决方案
base 上海?没有西安?
算一下手工做和自动化做所耗的人力资源差值就是自动化的价值了
神一般的职位
不错的职位
这个框架在新浪微博什么时候开始用起来的呢?
还是需要把接口说明文档先补起来,否则无法全面测试接口