全面详细具体
使用 code 肯定是不足的,使用 msg 的问题可以考虑不同脚本顺序下对应的不同 msg,以此做断言
--断言的使用还是需要接口响应的具体区分来做前提的,不然就是很容易出现这种响应结果无法区分具体原因或者具体正确性的情况
wait
你给他说说测试的技术域和一些招聘信息就完了,操了!现在的公司是人不是人都要求全栈!!!
顶!
济南在招吗
base 发下,这就去买房入驻
当你不知道某个位置需要干什么的时候,去面个几次就清清楚楚了
少了产品!
base
建议楼主先了解下自动化的引入参考,再实际调研下该产品是否符合准入条件或者说自动化所带来的价值是否值得,待确定这些后再去思考下自动化在产品上的最合适的具体实现方式;
最后应题:我理解的自动化就是将手动通过代码的形式来进行替代,然后集成来统一执行
有没有其他最优解,平台引入是解决现状的最佳方式吗,建议再具体定位下痛点在哪里,哪些是优先级最高的,再来考虑解决方式
真香,不过去不了上海
如果是随波逐流的学习,网上很多建议,如果是为了凸显自己价值,可以先思考下自己的长短板,如果具备发展潜力较大的长板,建议发展此项,如果没有再考虑是否以代码或者开发能力来作为自己的长板发展
要么先入后端开发再进测试,要么保持代码技术,学习业务测试能力,然后学习技术在业务上的应用,大概就这样的路
base
你就告诉我山东有没有就完了
道不同不相为谋罢了,社区只是交流平台 抗压能力有点差还是
特性和功能和功能用例的梳理方法在我看来是毫不相关的,特性和功能只是需求的引入方式不同,具体的用例梳理并没什么实质性的区别和关联
这种并行测试其实并没有啥实质性的改变,工作量没变,只是工作时间掺杂在了一起,还会互相影响,如果想靠这种方法来节省人力成本只会牺牲掉质量,并不会提高工作效率
简洁却很全面的解释,层次感很强
就我而言是不希望将限制交给他方来做的,当然问题业务上是不会出现这种场景的
个人资料设置》账号设置:可选择操作
我也是头次遇到这个问题,不确定是否该放到接口上去修改
你的解释确实符合问题点,传入转义后的值是 ok 的,但是没法保证不会传入 gbk 字符,还是说交给前后端的传输过程中进行转义