有头的也行，unix 系统的话装上 xvfb 和一些字库等依赖就好了，再弄个 vnc 就能直接看了，我之前用的那些都是有头的呀，最近也用 docker 做了个 macaca-electron，也可以这样玩

谢谢思寒大大鼓励

有简单的总结过
测试：质量
测试开发：质量 + 促进生产力
质量保证大家做过测试都知道的了，促进生产力就很多东西可以说了，对应楼主的点 2

https://promotion.aliyun.com/ntms/act/group/team.html?group=BkzEkFRAUk&accounttraceid=e4d25dbe-b9f8-42e3-a334-0460a956b1d2

最近有 279 3 年的活动，赶紧入手

666，总结很溜，被点名了，共同学习，本来我也报名想去的，刚好要签约就错过了

如果有多个的场景，直接开多个命令窗口更方便，不过可能用到 desktop 上的功能的话确实可以这么做，这个 mac app 的机制

用数字作为前缀来命名，比如 01_testsuite1,02_testsuite2 ,RF 跟进 ascii 码排序

嗯，年限这种不好说，看人吧，可以提前积累一下

给你推荐一本书
https://item.jd.com/25452805052.html

1、用 http 封装 mqtt 的 api，也就是你提到的重写类，支持，做好了可以开源一下，然后用 locust 就行
2、用 locust 模拟并发请求方法，直接用 python 调 mqtt 的 api，如果是这样，其他工具也可以做

不太清楚贵公司的业务情况和客户情况，只能从我了解到的回答一下
1、版本管理是项目管理上的一个重要环节，但是每次交付对接都应该有一个明确版本吧，客户会明确用什么版本吧
2、部署架构上，要看客户用的是公有云还是私有云还是混合云，像你提到的不同客户的定制化，说到底还是钱的问题，针对不同价值的客户提供不同服务，有独立专属一个企业的版本管理，或者有通用行业的版本管理，这个时候就不是包多不多的问题，就看你用的是什么包的问题，包多对交付对接上的影响不会太大，主要是你这边怎么去梳理
3、还有一个点你看你公司提供的服务方式，高度定制的那种，说来说去还是钱，有钱再多的版本也是这么管理

puppeteer 有优秀的解决方案

你可能要意会一下老板的真意了

先回答问题 2：
题干说到场景比例，比如发送消息，有发纯文本的，有发图片的，可能都是用同一接口，假设需要模拟每 10 条消息中有 1 条或 N 条是发图片，其他都是纯文本，这个时候比例就其作用了，这个就是场景设计
问题 1：
比较明显的好处就是更好地模拟真实场景，再如是模拟有峰值的情况，比如每分钟里面有 5/6 的时间是 100 并发，有 1/6 时间是 500 并发，所以就得有业务控制了

这是我目前看到的最实在的评论，非常感谢，你能读出我现在所面临的问题，其实估计所有像我这种刚出来社会不久的小伙伴们也会面临的问题，y 值较小，都是百花齐放而蜻蜓点水，这个可以通过一个例子聊聊，在以前公司的时候，说到微服务估计我就已经把 docker 和微服务贴上标签，什么叫微服务，因为在 docker 上面搭建了好几个 RPC 应用，所以就叫微服务，呵呵，侧面反映一个问题，很多东西都是你自己以为懂了而已，其实哪里是懂，我很喜欢 A 厂的面试，这次经历我是深有体会，面试官也就是我现在的老大们，他们会刨根问底，问到答不出为止，就算自认为在某个方面很出色，了解很多，其实到最后会发现后面需要了解的，需要学习的，比现在所认为自己已经精通甚至超神的，还有很高很高的山，这篇文是我进 A 厂之前写的，现在回过头来看，我估计现在的我可以怼死那时写这篇文的我，但我仍然发现自己真的还很肤浅，深度是时间 + 努力得到的，不是一个 2、3 年就能上天的，就算是天才也不会，谢谢前辈提醒指导

方向方面结合业务来实践，找一些相似业务的成熟的测试案例来放到自己业务尝试一下

半年前听 TMQ 的线上分享看过这工具，在 windows 对 ios 带来的作用的还是挺大的，推荐！！！！

然后呢，你来教教我怎么做吧，谢谢哈
我的一切观点都是主观的，觉得有用拿去，错了，没关系，和我说说也挺好的，我也思考一下，但这个需要自己判别哈，这点判别能力一个正常的成年人都还是会有滴
如果我真能误导人，那我挺佩服自己的

不用纠结，大概理解一下就好，厂只是个代名词。关键还是人能不能做事

最近需求那么大

个人习惯，功能测试用例管输入和输出，所以断言在用例，page 管流程（方法）和页面元素（属性），这是比较面向对象的对象，当然，这个看具体要求吧，怎么方便怎么做

操作不方便，最近社区已经有很多厉害的小伙伴做了一些接口自动化测试平台，比如 httprunner，用这些更好

无数次死在 334，375，435，这几个点都是小桌子的点，其实各种自动化脚本修改还敌不过一个 post 请求对数据的修改 ，v2ex 上好多案例，楼主也可以去看看，看看有没有可以拓展一下思路滴

谢谢思寒大大，过早的赢还不代表未来的赢，历史上总有后来居上，大器晚成的案例，但自己是不甘于落后于别人，落后于时代，不管是旗开得胜，还是后来居上，有良好的形势就必须想尽一切办法保持并超越，比如这 2 年的积累纯粹是时间堆出来的，年轻的时候还吃得消，老大一些的话就死翘翘了，优化的方法必然是在相等量的时间里提高学习吸收以及产出的效率，再而降低时间成本，做更多更有价值的事，这是发展之正道，再次谢谢思寒大大，为业界很多年轻人指引道路，祝新年快乐， 工作顺利