看你描述,你的测的是业务场景耗时,那么先考虑 abc 吧,d 接口理论上没有什么业务逻辑,直接返回状态。
另外 abc 后,是会产生一个异步处理,这里是 mq 的或怎么样的,也考虑中间件的性能,别打爆了
666 期待大佬后续使用心得~
只是入门的门槛低一点吧,后续都要补回来的
听说 公 也要不是铁饭碗了
看问题,主要是要测什么?功能还是性能或者音视频质量?
是 web 端还是桌面应用?
做一个自动化平台,写数据库里
想了解一下,为什么这个问题测试时没有发现?
上线预发问题是正常的,然后怎么快速回滚或者恢复到没有问题的状态,在发布前先准备好。
然后做好线上功能的监控,一般等到用户反馈已经累计了很多问题数据了。
最后找一个用户低峰时间,并且最好的早上,遇到问题还有一下午解决,大半夜修问题太累了
暂时没有有助于测试框架
没看到目的是为什么了测什么?
安全方面,还是不要转测试了
看你目标吧
很多小公司不需要测开。。。
没有测试,也能很好
这个 bug 假设存在,会造成最大的风险是什么,如果能接受,可以优先级放低;
另外重现 bug,获取可以从数据层考虑看看,是不是首次操作缓存没生成或者接口返回时序导致的
点击发送后,去 redis 里获取就行了呢
requests 好用,自由,公司有 Jenkins 之类的定时请求就好
短信的话,问开发数据存哪里的,直接从数据源获取验证码
做平台的话,还有会一些前端语言
地点都在哪里啊
上班必须要考虑 通勤问题哈哈
无所谓,都在提倡 devops,开发 + 运维,和测试有什么关系,以后就没有测试了
第一点,听领导的
然后,那个能解决问题
其次,自己喜欢用什么就什么,没啥区别
能先给一个类似的结构吗
可以调用 windows 的 wmi,差不多可以实时获取
你到底用的是哪个线程组,就按照哪个线程组来设置
我了解的灰度是直接在代码里写的,后台通过配置来决定 app 的请求方向,比如地区,用户账户位数等等,不是靠测试或者特定的包来长久处理的