不清楚你需要解决什么问题，看起来是在纠结什么链接方式来控制手机。

反正手机不就是有线链接就是无线，还能有第三种办法吗😂……

如果你追求稳定，那就不要用无线链接，有线链接都不是 100% 稳定，无线只会更低；如果实在无法解决有线链接不方便的问题（或许你可以想办法克服这个问题），那就只能妥协接受无线链接不稳定的影响，在你做的事情上去考虑链接不稳定这个因素所带来的掉线问题

不知道行不行，我自己没试过：headless chrome，用点代码开即使个浏览器对象去访问你这个视频

不能全部替代，但是可以部分替代。
关键是这玩意儿不用人介入，就算它只能跑部分回归，很大的优点也是想什么时候跑就什么时候跑

https://www.china-sga.com/sga/resource/standard.html
网页上方导航栏，选择【工作组】，找到你感兴趣的组点击跳转，就可以看到【申请加入】的按钮。

实话实说，10 年经验下，这个简历里的内容含金量略少，从技术角度上看，现在想要抢救难度已经非常高了。如果进一步发展机会，可以尝试一下去有十个人的测试团队里做骨干然后带带人尽快转型。

个人猜测，楼主对这一行应该没执念，业余时间应该还算多，我的发展建议是尽快找到属于自己的副业，利用时间多去做一些其他的收入来源尝试。这个年纪不要继续在技术上死磕花时间了，即使一两年内补回来一些技术，也很难拿到性价比高的收益，还不如先用这份工作的收入苟着，来培养另一个收入渠道来得现实与划算。

切忌用战术上的勤奋，来掩盖战略上的懒惰。

曾经写过类似的博文，供楼主参考：再谈 Code Review

借楼发广告，需要内推随时联系我~ 微信号 zingphoy，邮箱 huangxinhuan@bytedance.com，校招社招都要！备注 testerhome 简历

我现在就是干类似这种的测试工作，因为这里没有交代清楚是什么业务，所以我也不好猜提及的前端 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/#/

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

二维码过期了😭

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

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

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

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