从描述看,有一种情况非常符合,就是代理,如果代理对请求放行,但是对服务端响应劫持了不放行,那么对于服务端来说已经正常处理并返回了,你从服务端是排查不到问题的,而客户端又收不到响应
又到年底了,该如何优雅的拒绝小伙伴们的涨薪需求,实在是没办法,又挺了一年部门没裁员
上周遇到过同样问题,我是换了很多的源才解决,猜测常见的国内源暂时出现了些问题,导致 docker 最终还是用默认的然后报错,不是配置或者要重启啥的这么常见的问题
长期要看,短期也要看,四个月还没过试用期,合同是三年及以上?合同上有没有约定试用期?
如果试用期被开,大概率是没有赔偿的,那就要看试用期约定是否合法
除了向前辈学习外,我认为当前最重要的事情是转正,小公司可能没有人关注你的转正时间
我理解问题 1 和 3,都可以通过接口测出来,3 这类问题比较多的话,需要定规范,让前后端开发都应该有这种意识,接口返回数据过多应该分页或做其他处理
如果你是仅仅是要使用 OCR,那么我建议你直接调腾讯 or 百度的 OCR 接口,每个月都有免费额度,拿你这个图片来看效果很好,如果你要研究 OCR 技术就当我没说。
应届,7.5k,入职三天,buff 都拉满了,就要求搭自动化框架,要么你的 leader 不靠谱,要么就是你想的复杂化了
比如我部署一个 metersphere,也可以叫搭建了自动化框架,它确实可以做一些自动化测试
录制脚本,脚本进行修改,其他设备自动化执行,跟你说的没啥本质区别吧?
只不过不是实时的而已,实时同步有必要吗,只会让问题更多更复杂
第一步,举例的这些容易发现的问题,都可以用静态分析工具来做,会很快
我觉得带宽不同,是导致接口响应不一样的主要原因,你可以两个客户端各只请求一次看一下响应时间,接口响应应该也会有差距,但没这么大;然后这种带宽要求高的接口压测,我理解应该以跑满服务端带宽为目标,因为真实的用户场景下,是非常多的客户端,客户端的带宽是不会跑满的。要跑满服务端带宽,压力机带宽应该大于等于服务端带宽(这要求较高,当然楼上也说了可以估算出来的 )