从一开始就没办法白剽吧，各个行业各个公司的情况差的太多，测试的粒度周期因素完全没有可参考性，就算工具本身能直接用也不代表思考的过程可以省略的啊。

至少我自己看论坛没觉得最近干货变少吧，后面东西少的原因，我觉得是因为整体大家水平上来之后，不再讨论特别细节和马上就能上手的东西了吧

觉得很多公司 30+ 的人不要的逻辑很可笑，从整个人口普查的结果来看，18-35 岁的人口占比高一点的地区也只有 20% 左右，这其中还包括不做计算机和学历不够的；然后 2020 年出生的人口就比 2019 年出生的人口少了 15%。

30+ 不要按道理只能是一个特别短时间内的现象吧，不然到后面你哪里有人可以招的，说句不好听的，摆出这个规定就是在说自己公司最多开 3 年了，那这个年纪有这个本事的人干嘛非得来一个这么短命的公司，之后简历都不好写。

个人的学习路线：
网易公开课的 MIT 线性代数，尤其要利用这门课把很多单词混熟，后面会方便很多；
再就是吴恩达老师的机器学习和深度学习

练手的话是 TensorFlow，因为资料非常丰富群也很多，而且符号什么的和前面的课程是一致的

当然这个是我自己利用空余时间自己玩的，说来惭愧我也没搞明白应该怎么应用，因此没办法说我自己就是对的或者合适的，仅供参考

AI 的门槛正在降低，并不是学不学的会的问题，而是学会之后怎么用的问题，现在很多公司炒 AI 只是概念：

比如，很多公司的"AI 测试"只是运用了 Sikuli 进行了图像识别，具体怎么优化、怎么设计测试策略和目标、怎么提高产品的质量完全没有概念，结果每次 CI 的时候一大堆的图片需要上传，还有每一次需求都是天文数字的工作量，然后就是无论测试多少遍 BUG 一点都没有减少，除此以外根本没有提升；

然而，更悲剧的是，哪怕其中有灵光的下狠心把图像算法优化了，发现图像识别和自然语言变成公共的基础服务了。

对于这个领域不熟悉的测试，尤其不是大厂的测试，根本得不到信息，盲目学完然后盲目碰壁盲目失望这个是最有可能的，建议这个阶段还是稳扎稳打修炼基本功，有时间把线性代数好好补补，了解一下常用的框架，在常见的 AI 应用方向里面挑一个仔细研究一下，别太盲目跟风。

通过类加载器去获取

先调整好心态，多数时候未必自己就完全不行，只是简历上没有戳中用人单位的兴趣点，我的房东小我几岁小学没毕业，到我租到他的屋子的时候人家还有二十一套装修好散好味没租出去的，学历虽然是一道坎但并非绝对的。

整理一下七年间的得失，想清楚自己能忍到什么程度，按这个标准，在简历中适当迎合一下人家公司的业务需求就行。

感谢，我发现我对共性这个点理解偏了，基础服务类包括运营支撑之类的平台抽到中台是一个合理的考虑，之前我见过一个把上下紧密依赖的业务公共服务抽到中台的案例，结果是底层服务频繁迭代，导致上层业务进度和沟通成本失控，缺陷在业务下游被放大；汇报线也混乱，上游业务的运营策略要依赖中台的资源，结果导致中台和业务没办法协同，互相推责任，整体效率低下

感谢分享，很有用，不知道我的理解对不对，我举一个脑补的测试部门的 OKR 实例大家帮忙看看：

本周关注的任务：
P1: 上月所有版本问题回溯分析
P1: 本周版本回归
P1: xx 工具分享

OKR 当前状态：
目标：提高发版质量
关键结果：线上资损率 25%（2500/10000）
关键结果：月均缺陷率
关键结果：持续改进措施覆盖率（版本覆盖率：37/50，资损覆盖率：1900/2500）
关键结果：人员技能提升（新工具推广 3/12 团队）

未来四周计划：
推动所有团队的版本回溯
工具推广应用
检查预防措施执行情况

状态指标：
缺陷率持续下降
人员单位产出增加

部门架构上的划分问题并不是可以一笔带过的程度了：

1. 中台和业务线业务重叠的部分责任如何划分？
2. 业务线和中台都要快速迭代，但是中台的升级本身就会给业务线带来影响，如何能保证项目选择和快速交付的战略能够执行下来？
3. 这个组织架构在结构上并不属于项目型架构，也不属于职能型架构，矩阵的划分上不仅有权责交叉还有业务领域的重合，怎么保证在执行组织级策略的时候，干系人之间能达成一个平衡，纵向的资源整合如何操作？

可以设置跳过这个文件，在 exclude path 里面，但是这个方法是治标不治本的，完全无法预测这个类里面的方法什么时间维护过，会不会有数据类型的问题，遇到 JAVA 11 的新的安全策略会不会有代码编译失败等等等等问题。

建议，如果是这个文件彻底不改了，类似于金融行业很多的 Fortran 工具类，直接打成二进制文件，也可以避免因为 JDK 升级导致的编译失败。
如果还打算改的话，把风险暴露出来给相关的干系人，让开发那边给出整改的建议。

你可以考虑我们公司，我们需要各种骚气测试

30 岁，多多少少有一些沉淀了，无论是技术上还是阅历上；我个人认为在这个时间点，需要优先考虑的不再只是自己的能力基线问题，而是如何把自己的能力变现了，说直白了就是如何用自己的能力和阅历去服务和成就更多人，下面几个方面是我看到别人做的：

1. 测试框架和工具的开发
2. 共性问题的总结和流程的优化
3. 方案的产出
4. 辅助新员工提升
5. 对外支持，比如投标方案质量保障的可行性、咨询方案中灾备和实施等方案的问题、客服反馈的问题中的共性问题如何提高解决和应对效率分析等等
6. 理论的学习，主要是项目管理和质量管理的，工科的技能在解决具体问题是有效果的，但是如果放在更宏观的角度去思考的时候，比如这个项目要保证上线不出问题需要多少人力、怎么协调资源、采用什么样的技术、会出现哪些问题以及应该分配多少资源应对等等

关于创业，我个人认为在这个时间给出这个建议是把你往火坑推了，先去市场看看自己能拉到多少投资，然后再看看这个业创不创的起来

你说的是热部署了吧，我记得这方面的资料还挺多的啊

感觉哈，无论你下一步打算辞还是不辞，先和你的领导好好聊聊，你为什么想走，你在意的点在哪里，你对下家的期望，发牢骚就行，但是注意找个没人的场合，你的领导既然过问你请假了，证明人家并不是完全不关注你，好好说明一下，不然很多有责任心的人会压力很大，觉得自己的领导风格甚至为人是不是有问题。

该走不该走这个问题，问你自己就行，如果是薪资问题我建议选择走，因为这个问题在多数情况都是不可调和的，即便给你涨了，你在同事和领导这里都很难和之前一样的信任关系，这么一个工作环境没多久你还是会想走的。

家庭问题啊、生活问题啊这些也属于不可调和的矛盾，建议准备走吧。

如果是其他问题的话，我建议你至少留半年到十月再打算了，比如上面说的，不规范问题，这个不是你换地方能解决的。全行业多数公司都这样，主要原因还是职业歧视，开发门槛比测试高，经理以上级别晋升环境又比测试好，开发有进度压力的时候，凭什么听你的，这个情况只要你还是测试，多数情况无解。只能找你的领导商量，解决不了至少把苦水吐出来。

真心觉得忍不了，先报个班静下心不管是开发技能还是产品技能，学完看看内部转岗的机会再走，不然你的简历投开发或产品都没人看。

首先建议和产品沟通，根据业务的重要性把用例的优先级划分出来，把最关键的 I/O 点做自动化覆盖，放到持续集成去

然后根据开发的技术方案逐层往下覆盖，其中关键的业务方法和工具类要求开发必须有单元测试保障

上述的事情记得要整理出文档，给出定性和定量的指标，比如：

1. 资损表
2. 与开发确认的需要覆盖的路径、在设计文档有没有体现、对应模块责任人是谁
3. 定期汇报覆盖率和单元测试覆盖场景抽查的结果
4. 重构的改动量和需求改动量的比较

以上，如果不能直接汇报给老板，最起码要汇报给 HR 或者和绩效相关的部门
如果遇到技术上层管理不执行的情况，至少会有人帮你推动

。。。很正常，很多开发都是有 KPI 指标的，尤其还有不怕死的赶在业务最繁忙的时间整个框架升级重构的。。。
然后还有一个离奇的动机是技术总监为了跳槽之前有好的资历。。。

还有很多团队打着敏捷、快速迭代的牌子，完全不测试就往外放的

总体来说~有权力管这个事的人没时间或者没有办法读懂这些代码
然后不少设计文档写的和需求、产品设计完全没关系，没办法落实到非常细致的管理，一般也就到项目进度和一些粗的质量指标上

05 年我在淘宝买个手机都能成为奇闻；十几年下来，淘宝没怎么变：你依然没办法买前看到真机，出问题依然扯皮扯不清……但是大家买手机方便了，淘宝也为一大堆卖手机的提供了就业机会，为什么～因为大家对这个商业模式有了信任，商业活动才能开展下去，公司才能盈利，大家才能就业。

技术再怎么更新，至少目前为止社会生产关系依然没有变，经济依然源于交换。当今产品同质化严重，没有特色根本无法存活，没有测试作质量的保障，你怎么让你的客户放心去安装下载。

没什么更想做的、自己在其他方面没有人脉、好多公司管理问题一堆、对现在公司的业务还做不到随便把我扔出来都能独当一面

以上几个问题我觉得都足以让一份工作持续很多年~

前提是自我认知，你得知道你在市场上到底值多少

。。。这个话说的怎么就这么招仇恨呢

亲眼见过某大型互联网企业，4 年时间连基础的测试用例都没有，自动化环境都没有，在高谈阔论全链路的，发版本运营和实施都不敢沾手。。。

选择样片进行特征编码提取了，采样的话，如果只是要验影音同步的问题，取码流较大的两端的两点就够用了

技术和学历的自信很难在短时间内培养起来，建议：

一个是从有熟人的渠道找找：就像你之前遇到的项目经理跑路的事情，很多公司都经历过也很害怕，所以有一些机会比起能力更愿意交给知根知底的人；

另一个是趁这个机会多认识人，可行的办法包括：多主动去找猎头聊天，多参加展会和你感兴趣的沙龙（注意没有美国时间给你感概人家技术和产品多牛逼，这是你的短板，先认识人，尤其是你聊的来的人），多参加公益活动，更加广撒简历（注意不要造假，找工作的过程本身是雇佣双方建议信任关系的过程，能力只是判断这个活能不能交给这个人的一个参考，实际上多数工具和流程完善的大公司，很多工作基本都是按部就班，能力反而不那么重要了）

再一个是深入了解你感兴趣的公司，包括：这个公司的股东结构，这些股东还有什么别的公司，这个公司近几年主要对外的市场宣传活动，这个公司卖的什么产品，找了谁帮忙卖，广告偏向什么人群什么地区（基本可以知道这个公司的大致销量范围和主要竞争对手），这个公司的产品生产依赖什么（IT 一定要依赖人，看看人家招聘的渠道、招聘的投放时长、招聘公告的门槛和写法与实际业务的关联度可以大致知道这个公司的 HR 部门的专业度和人品、用人策略、缺人的程度以及缺人的方向）

我自己也是底子不好的情况，当时 08 年金融危机也遇到过类似的情况，以上是我自己总结在当时的情况下采取的活动中肯定能对自己有用的策略。

底子不好，意味着在你看来任何职位前面都有一座大山，但是反过来说也意味着你有更多的选择方向；先充分了解市场需要什么以及自己有些什么，在不同的市场，劣势很可能转化为优势，最终能决定你这把斗地主打成什么结果的，不是剩下两个人手上总共有什么牌，而是你手上有什么牌，没必要把自己绑在前端测试之类的话题给自己找郁闷

之前写的有点偏题了~

想要变成一个受欢迎的人很难，但是想要变成自己曾经最讨厌的人很容易，心里说一句话就够了：XX 也没什么了不起的，我也会啊

最近听到的一句话是这么说的：累死累活干不过写 ppt 的

这句话的潜台词可不就是：写个 PPT 有什么了不起的，我也会啊
诸如此类的多了：画个原型这么简单都做不好、接口文档怎么能出这么多错误、这么简单的 SQL 怎么能出问题、这个系统做的跟 shi 一样……

“做自动化有什么了不起，我也会啊”，“做测试有什么了不起，点点点我也会啊”……这几句话说完，估计这个人瞬间会变成我们最讨厌的人
很多事情，或许我们可以做，甚至我们还能做的很好，但是别忘了~顶着压力的并不是我们自己，包括时间、绩效、各个不同部门的要求、上司不合理的要求等等等

分享一个例子，不是我自己的但是我觉得很有借鉴的意味：之前公司的测开同事，想要推广单元测试自动生成的工具，结果完全没有起色后面离职了，我记得回访推广过的项目组听到的说法是这样的：
“代码天天变，也不给时间，我们也不想点点点啊”
“我们接口自动化也搞了挺久的，你落后就落后啊”
“框架有 BUG 是不错，我们也改了好多次了，你说我们这都是坑，你就没有了吗”

如何不要变成自己最讨厌的人，我相信看完上面的大家心里都有数了，未必我们能一下子做到完全不吐槽处处惹人爱，但是至少我们回忆起自己做过的事情的时候，不要做一个让自己都讨厌的人了

面试过程中遇到面试官和你气场不合很正常，只吸取自己能用的就行；简单一句你达不到要求这种，只能说面试官水平也不是很到位，正常情况下应该通过 HR 进行反馈，所以我个人觉得不用太往心里去；

工作 6-7 年，我觉得是资本而不应该成为负担，楼主需要整理一下你自己的成就而不是陷入对比人生这个怪圈，谋事在人但是成事在天，每个人的际遇本来就不一样，没必要去按照各种鸡汤把自己的生活搞的郁闷；

关于如何总结自己的资本的话，我自己的资历也不足，分享一点我自己的心得看看能不能参考了：
尝试着让自己去回答这几个问题：

1. 你做过的事情中，有哪些花费了特别久的时间，你下次再做能不能缩短时间
2. 你做过的事情中，有哪些你曾经觉得很有成就感的（不一定是技术方面，扩宽一些，比如你觉得你的工作能给别人带来很大帮助的，或者公司这个恶心状况能让你明白很多的），今天你回过头来看，能不能做到更好或者处理上能够让自己得到更多的利益
3. 你服务过哪些行业，有哪些你认为是共通的问题，怎么解决的，后面遇到过哪些问题，有一个刚开始创业接触这个行业的老板（非技术人员），你会从哪些地方提出建议

回答完了找个论坛或者博客记录下来，这个就是你现在的资本了

面试不对盘太正常了，但是也不建议矫枉过正一切觉得都是人家不赏识，需要透过招聘启事和电话沟通更快锁定你能给人家带来价值的这种公司，通过面试去培养自己的人脉

本人是从游戏测试转过来的，只能说关键要看你自己原来的功能测试怎么做的了

游戏测试相比 Web 和 APP，人机交互上不可预测的变量更多，因此掌握了单变量控制、逆向思维的人转其他测试反而觉得游刃有余，如果之前做过偏数学类的测试比如刚体碰撞、地图检查、追踪轨迹测试、lod 减面等等，再加上能会一个语言，转其他的测试问题不大