做平台和用平台不是一波人，从来都是这样，习惯就好。
就看做平台这波人会不会尽快去找用平台的人拿到反馈然后赶紧迭代了

需要开发的专项测试工具一般是指什么：

1. 特定业务场景才适用的工具 —— 比如基于这些工具在特定网络协议上再做一层封装才能在业务上使用
2. 需要针对某些指标项钻研得更深 —— 比如工具中有些指标项欠缺，而业务中刚好需要
3. 需要和公司平台打通的工具 —— 把工具能力集成到公司内部的体系，打通数据收集存储展示 ……

如果想自己真的算有能力开发这样的工具，应该如何学起：
我的方法可能比较低效，找别人的源码就是一顿看，一切从抄袭开始，抄着抄着随着知识储备提升你就会意识到当前方案的问题，然后找到更好或者更适合自己需求的实现方案，然后再做一遍（在别人看来你就是在搞轮子，大家一样质疑你，就像这个帖子一样 ）

我的老板一句话概括：对内不同业务方向，把控线下到线上全流程质量风险对应的质量建设；对外沟通研发产品运营，及时获取各种产运研动向以不停给大家输入。

活挺抽象，时间也比较碎片，老板更多是务虚而不是务实，但是务虚也有务虚的价值，不是每个人都有务虚的毅力和能力（想想你一天到晚都在开会，你开会得保证有意义，会后零散时间还要沟通、想规划、把关下属工作）。这些都依赖有前期大量务实的沉淀和思考。

从目标触发去考虑你要做什么事情。

• 如果公司对 app 安全性要求并不高，而且历史上也没出过什么太严重的安全问题，那可能：
  1. 公司 app 的安全性也许还挺高，找安全问题的空间不大
  2. 公司根本不太在意 app 的安全，在现阶段不会有多大投入

这种情况总结起来就是，你也没必要把这个东西研究得多深，有个结果交付给上司就行了。

• 如果公司对 app 要求很高，我建议还是直接找乙方做安全测试，安全领域真的很深，我以前在外围简单涉猎过，这些东西如果不花大量时间实践是没结果的

按匹配度排序，如不匹配则逐级下降：

1. 完全一样业务的业界测试团队的质量工作
2. 业务不完全一样但是依然处于同一个大领域的业界质量工作
3. 业务不一样，领域也不一样，但是要做的事情和你们想做的事情接近的质量工作（比如都是要做覆盖率、都是要做接口/UI 自动化）

第 1 和第 2 点基本上到手就能直接参考；第 3 点需要你们已经有建设目标才能找，结合楼主说的【不知道应该关注哪些内容】，我理解就是没有明确的建设目标。如果楼主所在业务内部交流本身也没提什么特殊的建设，那就先当做是常规业务去建设就好了。至于常规业务一般建设什么，这个网上很容易搜索到。

个人观点：

1. 211 的优势更大，一本和二本在面试筛选时虽然有区别，都其实也都是本科。而 985、211 这些显然是第一批被筛选出来的
2. 进 211 如果专业不理想，前一到两年要刻苦学习随时准备转专业，越早转过去理想专业越好
3. 电气不清楚，电子信息、计算机方向我理解就是出来做程序员，写代码是门手艺，在校写得越多能力越强，所以老师并不重要，最好能混进去学校的 xxx 计算机实验室跟着老师做项目，不行就自学（我自己也算是半个自学），还是讲究实践

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

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