1、在做接口自动化的过程中，参数的数据应该从哪里来比较好。是写死（这种切换一下环境就不能用了，不太好对吧？），还是从数据库里提取？（那如果数据库里有脏数据，会造成测试接口返回信息不准确吧？）

参数数据主要来源肯定就是你的用例设计，其他来源都是补充。补充来源可以是线上流量（access log 里面可以抽取）、可以是埋点上报、也可以是数据库数据。但是关键问题是补充来源的数据是否全部可行，要加什么筛选标准，肯定不是随便一条数据就能拿来直接用，一方面有些数据涉及用户隐私安全，一方面有些数据不完整，一方面有些数据根本没权限拿，所以很多时候最关键的就是搞明白筛选标准和你的测试范围，不是万能的。
【是写死（这种切换一下环境就不能用了，不太好对吧？）】没看懂你说的写死是什么意思，是人为确定的参数？为什么切一下环境就不能用呢？能不能按照不同环节做兼容？还是说你的环境本身就有问题？

2、如果是动态数据，比如需要上一个接口查询商品，下一个接口添加购物车。如果上一个接口出问题，那么下一个接口也跟着出问题。这种接口传参怎么样比较好呢？

上个接口出问题用例应该直接报错结束吧，没什么特别的方法。上游你的控制不稳定，自然就不用想着下游能好过。这个解决的下手点不在于接口怎么传参，而是确定前置条件有无满足

3、请问你们已经落地的接口自动化，是在测试环境跑还是预发布、生产环境呢？因为感觉做出来只在测试环境跑，发现不了线上的问题。整个接口自动化意义不大。

全量用例是在测试环境跑，我们内部的预发布约等于生产环境，生产环境只跑很小一部分，而且都是读接口。在线上跑写接口就是给业务加脏数据污染，纯纯地坑研发，不仅可能发现不了线上问题，甚至可以引入问题让别人排查半天。这里的建议是把思路打开一些，发现线上问题除了接口自动化（巡检）外还有很多，比如监控、用户反馈跟进，更牛逼一点可以是舆情监控等手段

4、如果在线上跑接口自动化，涉及到钱的接口，要怎么去跑呢？

基本原则是涉及到钱就别在线上去跑自动化，出问题就是事故，老老实实线下自动化或者线上手工验证，不差那么点工作量。一方面钱相关的一般是线下有 mock，自动化会比较安全倒还好，但是线上没有 mock，第三方支付也很少会给你在线上开这样的测试口子，所以就别去较劲，要是自动化把别人的接口打挂了还要担责；另一方面，如果线下测完了没问题，线上还出问题，我觉得可以想想为什么两者的结果不一致，再去尝试排除这些差异点，至少保证己方是没责任的。建议先了解一下依赖的财经支付方在线上有什么限制再考虑

这三角关系很乱，我没看懂为什么研发部门老大会问为什么不解决延期处理问题，ta 是在问产品还是在问测试？

解决问题的到底是测试还是产品还是研发？

研发老大跑来问测试为什么不解决延期处理问题，我怎么感觉他思路有点清奇。不知道是问题里写错了还是咋样

看不懂问题

单纯拉个开源项目就是一顿看，效率很低，建议有目的性地看。
比较实际的，testerhome 上不是有一些开源测试平台吗，这些咱也熟悉，你就看他们的代码，想了解哪个功能的实现就看哪个。
这样很快就有感觉了，主要训练到一些全局搜索、调用关系猜测、常规模块实现思路等基本技能。
看多了，有些操作就如同肌肉记忆一样，实现什么功能需要考虑什么细节。

• 好
  • 全局效率更优，专业的人做对口的事情，不容易被其他事情分心
  • 不同团队的职能更加单一更容易管理
  • 需求集中到工具部门，可以从全局决策集中投入人力搞，同时工具的收益更容易被量化
• 坏
  • 破坏整体技术氛围，有综合诉求的人才会加速流失
  • 工具部门无法以同样优先级支持不同业务线的特殊需求，所以更倾向于选择通用需求或者核心部门的需求去做，一方面通用就是不好用，另一方面总有业务线的需求不受待见

具体要看公司发展到什么阶段，要 case by case 分析。如果公司只是很早期的阶段，这样做无可厚非，因为人本来就少，业务线内部重复建设再浪费一些人力确实在 CTO 眼里是不合适的。如果是其他阶段，说法又不一样了。

观感：内容写得很丰满，但是看不到重点，整体偏罗列没组织，给人的感觉是什么都做但是什么都做不深，是事情的参与者而非主导者，含金量打折。

修改意见：

1. 「内容做减法，一些常规的工作可以直接删掉，或者合并在一起」
   • 如 xx1 项目的 1、2、3、4 点，典型如【负责编写测试计划文档】，【负责编写测试结果分析总结文档】，这些都是测试同学最基本的工作，写和没写区别不大，建议删除 2、3、4 只留 1。要是真的不想删就合成一句话，如果最终合并成诸如【负责同测试团队共同构建测试各阶段质量规范标准的定义、编写测试计划文档、编写测试结果分析文档】，当我没说……
2. 「项目经历中做好分类，每一个项目中突出一个重点」
   • 明确区分出 主导 和 参与 的区别，突出你主导的东西，如果全都是你主导的话，那这 3 年经验应该胜过不少 5 年的人。首先需要把事情分类，粗的类别可以是【业务测试】和【自动化】，细的类别可以是【流程规范】、【质量卡口】、【线上监控】、【xxx 自动化】等，这些就自行分类好了；然后突出主导的事项，项目中给出持续时间，肯定有些项目长有些项目短，到时候面试也重点引导面试官往你主导的比较熟悉的工作去问，对你也是有利的，不然问到不熟悉的一下子问死了。另外，技能列表也要做分类归纳。
3. 「数据导向去阐述项目，做到心里有数」
   • 这个是加分项，对于 3 年的同学没有数据导向的思维也不意外。要呈现的感觉是：发现问题 -> 数据上阐述问题（如测试代码覆盖率很低，只有 xx%）-> 数据下钻细化，确定子任务的数据预期（如测试代码覆盖率低，可能拆分为缺失用例补充、冗余用例优化、手工用例自动化等不同提升方式）-> 每种方式贡献了多少数据，为什么会有这样的贡献 -> 最终收益结果。介绍的时候可以这么去介绍，简历上不需要写得这么详细，这个只能自己思考怎么去呈现了。

字节的后端 golang 就是默认语言，不过后端测试对 golang 的掌握度也没有特别要求，毕竟实话实说还没去到帮研发改 bug 的程度

全世界的大厂都在搞 ChatGPT 竞品，但个个都是半成品，一两个月 rush 出来的东西怎么跟正版比

云手机是指模拟器那种？下面就当是模拟器来回答。

没大规模使用过，但是可以确定模拟器无法替代真机，因为模拟器在底层的接口支持和真机不一样，也就会导致部分模拟器上会出现的问题在真机上根本不存在，而真机会有的问题模拟器又测不出来。

有部分场景可以考虑使用模拟器：

1. 核心场景 UI 自动化、性能防劣化等，有明确固定的测试场景，重复一样的测试操作
2. 和平台底层接口、显式样式等无关的功能验证
3. 真的没钱买这么多真机，模拟器是在设备上去扩展部署的，成本低弹性高资源利用率高