用沙箱支付啊
有专门的 api
好
大多都失业了吧
我说的是软件的 gui,感觉不像 web 的
这界面是用什么写的。。
外包都要统本
让公司换体量大的 ai
hao
大城市也难,虽然岗位多点,但是人也多几倍
给用例管理平台的用例加个 tag 和唯一 id。自动化用例展示对应用例的 id
难道其他语言的 playwright sdk 就支持了吗?这个应该和语言无关吧
哎,就是个外包公司。和软通、中软之流一样,说正经也正经,说不正经也很不正经。。。。
比武汉好
一般来说测试环境用泳道隔离独立测试,然后不同的测试分支一起合到 uat 进行回归,最后再上正式环境
这不就是自测吗?把每个功能的主要用例都给开发测试,测试通过了才提测,能做到就不会存在功能没做了
好像 edge 也有一个集锦?和你这个差不多
还有个问题,agent 流输出的话,首字符开始后,后续各个字符之间的响应时间会再做分析吗?还是总的时间不超时就行?
还有一个老生常谈的问题——“拐点”。现在各种缓存、消息队列等中间件都比较成熟了,系统到达最大处理容量后 tps 一般会维持在高点附近,或者来回抖动,从图上很难看到真的 “拐” 的地方
"正确的做法应该是:第 1 秒内通过异步任务启动接口一次性触发 10 个任务后,便不再持续发压,观察系统能否在 10 分钟内完成这批任务。10 分钟后再通过异步任务启动接口启动 10 个任务,确保流水线中并发处理的任务数始终维持在 10 以内。"
这个不敢苟同,流量不一定按你所想的进来,确保系统能同时处理 10 个任务之外还得继续提交任务的,因为要验证系统的排队能力,即时不能并发处理过多的任务也要保持任务队列正常运行,或者说系统的限制功能正不正常,对应八股文中的最小线程数,最大线程数,队列长度,饱和策略等
good
像 jenkins 这种容器化的优势在哪里呢
byd 也能停业吗
怎么做的?监听到消息后怎么去和压测线程交互?