从描述看，有一种情况非常符合，就是代理，如果代理对请求放行，但是对服务端响应劫持了不放行，那么对于服务端来说已经正常处理并返回了，你从服务端是排查不到问题的，而客户端又收不到响应

又到年底了，该如何优雅的拒绝小伙伴们的涨薪需求，实在是没办法，又挺了一年部门没裁员

上周遇到过同样问题，我是换了很多的源才解决，猜测常见的国内源暂时出现了些问题，导致 docker 最终还是用默认的然后报错，不是配置或者要重启啥的这么常见的问题

长期要看，短期也要看，四个月还没过试用期，合同是三年及以上？合同上有没有约定试用期？
如果试用期被开，大概率是没有赔偿的，那就要看试用期约定是否合法
除了向前辈学习外，我认为当前最重要的事情是转正，小公司可能没有人关注你的转正时间

我理解问题 1 和 3，都可以通过接口测出来，3 这类问题比较多的话，需要定规范，让前后端开发都应该有这种意识，接口返回数据过多应该分页或做其他处理

如果你是仅仅是要使用 OCR，那么我建议你直接调腾讯 or 百度的 OCR 接口，每个月都有免费额度，拿你这个图片来看效果很好，如果你要研究 OCR 技术就当我没说。

应届，7.5k，入职三天，buff 都拉满了，就要求搭自动化框架，要么你的 leader 不靠谱，要么就是你想的复杂化了

比如我部署一个 metersphere，也可以叫搭建了自动化框架，它确实可以做一些自动化测试

录制脚本，脚本进行修改，其他设备自动化执行，跟你说的没啥本质区别吧？
只不过不是实时的而已，实时同步有必要吗，只会让问题更多更复杂

第一步，举例的这些容易发现的问题，都可以用静态分析工具来做，会很快

我觉得带宽不同，是导致接口响应不一样的主要原因，你可以两个客户端各只请求一次看一下响应时间，接口响应应该也会有差距，但没这么大；然后这种带宽要求高的接口压测，我理解应该以跑满服务端带宽为目标，因为真实的用户场景下，是非常多的客户端，客户端的带宽是不会跑满的。要跑满服务端带宽，压力机带宽应该大于等于服务端带宽（这要求较高，当然楼上也说了可以估算出来的 )

这话说的，谁在测试行业有远大理想吗

你这个太麻烦了，找个 docker-compose 方案，就只需要 从 “d.进入 grafana 官网查找模板 ID” 开始就完成搭建了，例如：
version: '2'

networks:
monitor:
driver: bridge

services:
prometheus:
image: prom/prometheus
container_name: prometheus
hostname: prometheus
restart: always
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml

- ./node_down.yml:/usr/local/etc/node_down.yml:rw

ports:
- "9090:9090"
networks:
- monitor

alertmanager:
image: prom/alertmanager
container_name: alertmanager
hostname: alertmanager
restart: always

volumes:

- ./alertmanager.yml:/usr/local/etc/alertmanager.yml

ports:
- "9093:9093"
networks:
- monitor

grafana:
image: grafana/grafana
container_name: grafana
hostname: grafana
restart: always
ports:
- "3000:3000"
networks:
- monitor

node-exporter:
image: quay.io/prometheus/node-exporter
container_name: node-exporter
hostname: node-exporter
restart: always
ports:
- "9100:9100"
networks:
- monitor

cadvisor:
image: google/cadvisor:latest
container_name: cadvisor
hostname: cadvisor
restart: always
volumes:
- /:/rootfs:ro
- /var/run:/var/run:rw
- /sys:/sys:ro
- /var/lib/docker/:/var/lib/docker:ro
ports:
- "8899:8080"
networks:
- monitor

试试无头浏览器

是为什么决定放弃了 UI 自动化和性能两大块呢

怎么看出来没有线程池，从 5000 这个数字举例可能不太合适，我意思是说需要监控服务端线程，当服务端线程数与发起的线程差距比较大，再去找原因嘛，这里就涉及到线程池设置、压力机问题等等。

监控服务端 Java 虚拟机，jdk 自带有监控工具 jconsole，起了 5000 个线程，那服务端也增加了这么多活动线程，说明压力正常传到了服务端。

https://testerhome.com/topics/35981

同样认为 Jenkins 是最合适的，就你的需求完全没必要折腾一个前端页面，而且 Jenkins 能做类似的很多事情

做过一段时间的 app 测试，当时也是接的这些个广告，首先我觉得单独测试广告 SDK 没必要，那是 SDK 提供商他们的活，要测试的是你们集成的有没有问题。

当初我们有一个重点测试项是风控策略，比如新用户三天内是没有广告的，这种逻辑都是自家开发的需要重点测试。

用商业的云真机平台？ 你的痛点在于写的脚本要适配不同的设备才能跑，这一点云真机平台应该可以解决才对

没覆盖是一方面，而且从申请加班的页面看是没有搜索词和分页的，接口有这两个参数比较奇怪。猜测这个接口不只是申请加班用，加班列表页可能也是调这个接口，接口设计本身就不太合理，不过这种内部系统质量要求本身就不高。按场景设计接口用例我觉得是可以的，要增加一下列表页查询场景的测试用例

如果你可以把执行人工测试的那台被远程控制的电脑作为自动化执行机器，那么跟一般的自动化没有任何区别； 能远程桌面但不能传文件？也不能连外网搭环境？

如果你想着用你眼前的电脑作为执行机，我觉得你说的方案都不行

注意你的 docker 容器处在一个比较特殊的状态 removal in progress，按这个关键字搜到了很多相似案例，比如：

https://blog.csdn.net/weixin_44602651/article/details/118103297

个人看法：
1、从现象分析，这个列表数据大概率是从服务端获取的，而且不是只请求一次，挂在当前界面，也会实时请求，考虑抓包定位一下 ？ 更高效的方式是问一下客户端开发
2、从业务上考虑这个实时请求是否有必要？当然大概率是需要的
3、搞清楚了数据到底是如何获取的，然后抛开客户端，去测试一下数据获取是否有异常比如接口测试
4、数据来源测了之后，再考虑一下客户端是否需要更完善的异常处理，这个也要结合业务，比如这个列表数据实时获取失败的时候，能不能不刷新？