我现在就是干类似这种的测试工作，因为这里没有交代清楚是什么业务，所以我也不好猜提及的前端 js API 是不是以某种形式提供给外部用户，我就分情况讨论：

1. 如果产品形态就是以 js API 的形式把能力提供给外部用户（开发者），那就代表很有必要去做这样的测试。一般对于 SDK 的基本测试方式是自己写一个测试 Demo，这个所谓的 Demo 它上面是一个个的按钮，每个按钮点击下去的效果就是调用某个 js API，然后人肉观察反馈效果以确定是否符合预期。这里面的测试用例其实就是每个按钮背后的我们提前写好的测试代码。如果不好理解，可以看看参考资料里面的 “淘宝小游戏背后的质量保障方案” 中【小程序容器】一小节。这种属于 SDK API 测试的基本操作
2. 如果这种 js API 不是产品的主要形态，而是某种次要的业务附属品，或者直接说它可能没这么重要，没必要花时间测得太细，那就直接从 UI 集成的角度去简单看看就好，或者让研发帮测试搞一点后门，提供一份测试代码给你们留底每次执行一下人肉校验结果即可

参考资料：

• https://developer.aliyun.com/article/1151889 淘宝小游戏背后的质量保障方案
• https://mp.weixin.qq.com/s/6mLhC19CzfvD2qgGzTeBXQ 【接口品质】JSAPI 多端一致性的质量保障方案

pymysql，自己手写 sql 封装，原始但方便，不过要注意防止 sql 注入问题

换个角度想，只有业务有💰，组织有这个需求，就能找到专职干这些的人啦，各司其职。有时候测试同学要兼顾业务测试和测试开发，做得没这么深也是很正常的~

嘿嘿，谢谢，其实也是部门内部想要给大家传递知识的，只要没什么敏感的或者内部的内容，都是原文发转发过来 testerhome ~

• 研发：改了哪里就要说清楚这个是基本点，要求上是研发能从代码实现角度评估出影响范围（当然事实上经常做不到，一个研发不可能了解整个项目）。这种全局组件想改就改，要不就是研发自己没有质量意识，要不就是全局组件抽象得不好和业务有耦合需要经常变更，无论哪种问题都要要求研发改正（和研发 leader 聊清楚，理论上研发 leader 也不可能不管）
• 测试：在这个场景下，如果回归测试用例先前就已经和研发团队对齐过达成共识，那在所难免，但不是说测试就没有责任的。可以从几个方向去考虑：
  1. 一是能否引入工具量化回归测试的覆盖，比如回归测试时加上覆盖率，看看是否能在合理范围内覆盖变更代码，如果不是那回归测试用例是需要再优化的；
  2. 二是做好技术梳理（要研发配合做），比如全局组件对应哪些用例，以后有人改了全局组件就要测这些用例，这些用例中有哪些是研发拿去自测的（不是研发自己随便测一下就算合格的自测）……
  3. 三当然就是自动化，如果成本可以接受的话

7 年工作经验实话说已经不短了，一般来说这个年纪的定位是团队中的业务骨干，如果能力比较强可能已经是预备干部了（重点转化为 leader 的人）。

那对于这个年限的预期是什么？

结合团队的阶段，往往伴随着未来上司的预期，一起来考虑，下面尝试给一点假设：

1. 团队起步阶段：招你进来就是需要你能准确判断业务质量风险，利用当前人力资源在顶住业务压力的前提下，持续为团队招纳新人，从而测试团队慢慢进入正规，良性吞吐需求，做好质量与效率的建设，建立人才梯队。一般这种已经把你当 leader 招进来了，随着团队扩大是非常有机会坐实成 leader 的。
2. 团队发展阶段：团队已经有 leader，对 7 年的要求是能自己带人扛事，把某块业务，或者某块质量问题从头到尾接过去做建设，对上汇报给 leader，对下带头冲锋。无论你是搞业务质量，还是搞专项测试，疑惑是工具平台测开，都是类似的要求。当然如果业务形态不一样，可能就会在带人&独立攻克问题这两个点上做一些调整，也可以是技术角色。
3. 团队成熟阶段：需要你对某个领域特别熟悉，一般招过来就是要把你之前做过且做得比较好的事情在这边重新做一次，7 年肯定也是要带人的，跟上一个阶段最大的区别是业务压力小很多，做事情可以更加专注一些。

“这个问题为什么没测出来？！”

在实际场景下，尤其是快速迭代的产品，你很难在需求测试阶段就完全保证自动化建设跟上脚步，所以实操下来经常自动化是后置建设的，或者在需求测试之后在花一些时间来完善这样。

这样也是因为，不是所有需求都有自动化的必要，给一些时间再观察。

接口自动化核心目的不是在于省你集成回归测试的时间，而是做测试左右移节省服务端变更发布时的测试成本，以及做一部分线上巡检。

所以这里这里的【没有我想象中的（代替回归测试）那么有效】在出发点上就已经走偏了。前端和后端本身就是分离的，你这里应该解决的是前端自动化测试的问题，或者说集成测试（用户视角）的问题，常规方案就是 UI 自动化。

基本原则：技术只是工具，它的价值由被其所解决的问题定义。

迁移一下，测试开发的价值就是被其所支持的业务决定，而好的业务（价值高的业务），不可能对一个测试开发只有代码能力上的要求。

俺马上奔三了，身边的测试同学还比较稚嫩（绝大多数小于 96），研发同学家里小孩都有上小学的了

https://asciiflow.com/#/

恒温是在杭州/北京远程带？还是也去郑州？

二维码过期了😭

最屌的是现场编一个，而且容易圆回来

反正我自己确实不会去记忆（也没办法记忆）任何一个十分具体的问题，因为上下文太多，一个问题过了两个星期你让我在交流的时候当场说都没法把细节说满，何况还在面试这种时间很紧张的环节，稍加思考片刻就觉得要被否决。
至于那种做过整体复盘很完善很深刻的，往往又和公司的各种内部平台耦合，太多背景知识要解释，也不知道说出来合不合适。

哦，那确实不一样，如果都问到什么兴趣爱好这种和工作不直接相关的问题，就已经是面试尾声了，反正马上就会结束

可能是因为现在真的比过去更卷，也没以往那么有吃苦耐劳的风气吧。或许也有一些宏观因素？比如各种红利正在消失（人口、房地产），上升通道开始收缩等等……

基本方法大概是先和上级对齐你的角色定位，明确 ta 对你的产出预期，就确定基本的试用期考核方向了（如果上级连招你进来要干嘛 ta 自己都不知道，那我建议赶紧换个上级）。

下面枚举一些可能性吧，问得太泛也就只能回答得泛一些，肯定是不全的，仅供参考：
从整体来说，高级质量工程师的目标都是围绕着【支撑需求交付、提高测试环节效率、保证线上严重质量问题数低于 xx 个】去开展的。那么从一些大方向来说可以有：

1. 测试环节效率：流程规范、各种专项测试……
2. 测试左移：自动化技术、流程卡点……
3. 测试右移：线上监控、故障响应与容灾演练……

上面只是一种大方向的分类，你还可以从线下线上这样去分类展开，也可以从业务 1、业务 2、业务 3 这样的分类去展开

还有有这样的说法么？
感觉这个问题像开盲盒一样，如果我是面试官可能不会选择问这个问题，主要是日常 bug 太多，怎么还记得来什么广度深度 。除非有刻意做过这方面的总结，但是做过这类总结好像又不能代表什么

隔行如隔山，好多问题连看都看不懂

明确地说，除非有特殊要求，否则不会。
不然这个工作量招多少人都不够……实际上大多数版本之间的差别非常小，还是得聪明地减少工作量

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

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

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

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

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

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

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

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

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

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

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

看不懂问题