我理解问题 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 自动化和性能两大块呢