综合楼上观点，分情况讨论可能是这个样子：

1. 如果你能确保上游服务稳定，如上游服务变更少，逻辑简单等，可以偷懒省去 mock 的环节直接测，我们默认上游没问题，在测试的时候一并观察上游返回是否符合预期即可 —— 相对来说，省了 mock 成本，但是在校验时有额外的心智负担
2. 如果你无法确保上游服务稳定，如上有服务变更频繁，逻辑复杂，可能有更复杂的依赖，这种为了测试效率考虑还是走 mock，如果直接测，一旦出问题要排查半天是哪里的问题，长期来看效率可能是负向 —— 相对来说，有 mock 成本，mock 了之后就可以尽量去转化为接口自动化测试

大多数情况下，大家可能都是按照 1 去操作，有些业务形态真的复杂，那就只能 2，这些工作省不了。

一般系统设计接口是稳定的，如果频繁变动接口（mock 轻易就 break），我觉得可以质疑研发的接口设计水平。所以不太需要考虑 mock 要经常维护的问题。如果你能预见这个接口它就是因为业务迭代肯定会频繁变动，好像也没更好办法，因为你的被测服务可能也要跟着变动，那时候你也要被叫过来测试。这种情况先和研发探讨一下再做决定

找一份靠谱的工作，还是熟人介绍或者找猎头推荐比较方便

想学，但是每天卷到很晚，下班回到家可能就快 11 点了，很难强迫自己再学点什么了 😭 终究还是欲望不够强烈

昨天刚好看完雷军的《小米创业思考》，深深感慨能力强的人是如何不受任何外力束缚有非常变态的毅力和自控力去做事情，另外从书里也认识到商业化的一些基本考虑（如文中提到的供应商、成本计算、营收预期等）。感觉自己好菜

同意，测试配合协助解决问题，其实也是在解决问题。

如果精力时间允许，可以帮助开发缩小排查范围，这何尝不是在努力解决问题？有些工作，不是测试做就是开发做，它总得需要有人做。而最后找到有 bug 的代码再修复，只是解决问题的环节之一，甚至都不是最后环节（因为你还得复验，上线……）。

不要和开发站在对立面，只能说尽量追求统一的共识为更好的产品交付效率和产品质量去做努力吧

1. 评估这个问题带到线上的严重性，看是否需要阻塞发版先在线下复现修复了
2. 让开发在可能的复现路径上埋更多日志以及监控，以便后续复现出来有更完整的证据链，或者第一时间从线上感知到问题发生尽早接入

其实需要的考虑的问题就是：

1. 是否严重到阻塞上线，不上线的损失是什么？
2. 如果线上问题复现，能否第一时间监控到，能否更高效地定位与修复
3. 最后才是线下测试需要改进的环节

曾经我也像你这么看待过 “架构师”，直至到后来我做抽象的事情多了一些，部分理解开始改变，其实觉得那些听起来天马行空虚无缥缈的建议也没有错，问题是当时的自己并没有跟 ta 同一层次的理解深度，又或者是 ta 的表达没有考虑到我的理解水平，最后相互都觉得水平好低……

还是多从自己身上去找原因吧，一切建议都应该虚心听讲，甭管建议是否恶臭，关键是换位思考、空杯心态。可以保留自己的判断，但不能一听到别人的意见就直接否决。

哎，这个时代是这样的了，不是你卷我就是我卷你，或许咱们可以用以前的思维，管它叫 “勤奋” 吧。毕竟咱们又不是什么学习效率爆表的硬核大佬，比不了学习效率就只能比学习时长。这个也是长远来看保证未来生活能过得好一些的重点投资项

确实啊，IT 行业，讲究的自驱力我感觉比很多行业要高，因为它的更新迭代速率会很快，另一方面又有大量新生劳动力加入行业。现在门槛也开始慢慢升高，如果不自驱，可能有一天会成为低性价比员工然后被清扫出行业

可能没有你想象中那么晚，大多数时候 11 点就差不多了。主要是晚上时间可以调节一下，有时抽 20 分钟跑跑步再回来继续补 20 分钟工作（或者下班回家继续搞），整体来说也不算很差。不过确实累，精神上是高压状态。

我已经高强度加班接近一个月了，依然保持着热情（但是这个状态其实不太健康，身体上的）。

重复项目重复测试咱们就把它理解为单纯的工作量，而热情就留在自我提升上。我自己的办法是 “每天有固定的时间留给自己去做提升”，真的很重要！！！虽然最近忙起来导致这块时间被压缩了，但还是得有。

如果每天全部时间都是在搞重复的测试，那你在怎么挖掘都没有热情，因为你每天都是过得一样的，谁能不恶心

cookie 做登录态维持已经是很古老的机制了，现在的系统很多都是自己以 cookie 之外的其他方式去做登录态维持，比如 header 里面的某一个字段，或者其他什么特殊信息识别，它不一定放在 cookie 里面。你需要问问后台开发

我的年终总结也是从 2 月份写到 6 月还没发

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

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

如果你追求稳定，那就不要用无线链接，有线链接都不是 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. 三当然就是自动化，如果成本可以接受的话