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

确实啊，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. 三当然就是自动化，如果成本可以接受的话

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

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

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

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

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

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

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

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

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

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

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

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

https://asciiflow.com/#/