试着答一下啊。
1.都要依托。如果没有复杂的环境和复杂的问题需要解决，时间长了人就会蹉跎，面试的时候遇到了很多这样的同学，被自己一成不变的工作耽误了，在职业生涯的中早期，平台的好坏其实更取决于它能不能制造一大堆问题让你解决，成为你成长的养料，而不是普通意义上的高大上就是好公司，举个例子，前两年有一段时间总接到一个著名外企的工程师应聘，但是存在一个通病：公司平台把什么都封装了，应聘者也没有去研究怎么封装的，为什么要这么做，做了多年的"点点点"同学，虽然有准一线大厂的背景，但是能力上几乎丧失了竞争力。 但是，如果平台不错，你自己蹉跎了自己（看不到问题，不愿意解决问题），那也不行，面试时候也遇到了很多这样的同学，很多问题视而不见，这样工作多年可能和工作一年没啥区别。 还是努力能力增长-》换更有挑战，也回报更高的工作。这种正向循环最重要。

2.小公司更重视结果。小公司问题也往往十分多，你能把这些问题清晰的定义出来，给出改进指标，把收益说明白，然后做到了，很容易得到认可。实际上小公司是更容易争得话语权的，因为里边能人不多，稍微优秀一些就能体现出来。举个例子：在上家公司的时候，有个测试小伙伴就做到了一点：比产品懂业务细节，所有开发的代码做 CR，懂的所有的代码细节。慢慢的，他变成了团队中话语权最强的人，因为他总能指出别人的错误，说的特别在点子上。所以每次考核总在前边，所有团队成员都很佩服，重大产品方面决定很多都会咨询他，是否能上线基本上也是他说了算。工资自然是涨了很多。 另外一个建议是别给自己设限，别把自己只定位成测试，例如，如果自己是最懂产品的人，小公司很容易转变成产品，甚至产品总监。 有准备并抓住机会的话，小公司很容易胜出，见过很多这样的例子。

3.我觉得其实还是问题驱动，努力解决好你眼前的问题，被认可，其实就全面发展啦。一个我非常佩服的同事的一篇文章供参考：http://www.qkey.top/ce-shi-kai-fa-gong-cheng-shi-de-career-path/ （上边也贴过）我十分认同
另外从市场角度看，其实：安全测试工程师、性能测试工程师这种工种的岗位需求是很少的。原因两点：1.小公司需要人是万金油，啥都做。2.大公司全部平台化服务化了，实施没有啥技术难度，很多人依托平台很快上手。大厂，很多性能测试是开发自己完成的，调优也是开发完成的，不需要什么专职的性能测试工程师。

4.职级越高，需要懂的东西越多，因为懂得足够多才能正确决策。其实在我心中质量是所有人的事儿，“测试开发” 的定位是用自己的开发能力更好的保证系统质量。比较认同 google 团队中的职责划分，具体可以参考： https://testing.googleblog.com/2016/03/from-qa-to-engineering-productivity.html

5.不是大神，共同学习。

又被面试啦，简要答一下：
通用的思路：
基于风险的测试。测试的本质是抽样，时间资源总是有限的。要把资源用在刀刃上。先看看那个模块是干嘛的，是不是重要，如果出问题，影响面有多大？然后具体问题具体分析。如果是核心模块，会造成重大损失，那质量一定是不能丢的，抽调别的力量加强这块儿投入，把风险明确的传递给主要干系人，必要时延期项目。如果是非关键模块，识别出问题，可以做：设定一个最小实现目标，砍 feature，用运营/客服的手段补足。长效方法：自动化防护网建立，让回归的时间成本、人力投入成本低下来;在项目的初期就能够一定程度的识别这种风险，早加资源，别让这种事儿变成到了最后：一坨毛病，deadline 不变。 QA 最大的一个价值就是：像探照灯一样很早的预期到风险，并同步给主要干系人。

其实这类问题，主要是看看你以前在项目里怎么做的。实战经验非常重要，能积累很多 “土方法”。

http://www.qkey.top/ce-shi-kai-fa-gong-cheng-shi-de-career-path/ 阿里的测试最高 P 的职业路线的建议。

你很可能会遇到短板。短板是：可能无法让团队变成一个技术型团队，来应对越来越多挑战。如果公司转型，会比较痛苦。
谈一谈我的观察。在多年前，有很多离岸的测试中心，印度的 infosys ，文思、东软的测试外包兴盛年代会有大量这样的机会。但是离岸外包测试的岗位这几年在大幅度收缩。传统企业也在转型，同研发过程结合越来越紧密的 QA 的工作范畴大了很多，技能要求也在逐步加强。只掌握黑盒技术的 TL 无法带领团队很好应对现有的挑战，所以这样类似的职位是会不断萎缩的。这是大趋势。

能够知人善用，找专业的人来补充技术的短板，自己 own 起整个质量解决方案是一条路，我见过一些成功案例，一些管理型的 TL 能够走到比较高的位置，也能把团队带的很好。不过它有几个前提：1.你能搞的定领导，他只信任你，认可你。如果你的领导只关注结果，你又能搞的定结果，这是走得通的。2.你能搞定底下的小伙伴，他们愿意这样跟着你干，技术好，综合能力强的人愿意甘于你下（长期下来这点挺难的，如果你无法正确作出技术决策，无法给底下小伙伴方向上的引领，人家凭什么服你，开心的长期跟你干？）3.大团队的历史：你跟团队长期奋战，一同成长，团队飞速发展，你被顶到了那个位置（如果空降，只有所谓的纯管理能力，还是挺难的，我没有见过这样成功的例子）。4.持续补足自己的技术短板，不见得是具体的怎么撸代码，而是要了解业界主流技术，他们能解决的问题，长处短处，你的团队是否需要他们，团队里谁可以撑起来。5.对你所在公司的业务要全通，尤其是 IT 系统需要支撑的业务要精通（不多说，这点很重要）。6."技术管理"能力真的行（什么是技术管理能力，可以参考底下那本书）。

推荐的书：成为技术领导者 最近去世的大师温伯格写的，系统性论述。我是几年前读的，对我一直影响很大。

可以实现个 chrome extension 开源：）

跟被测物同语言最好。

1. interop 不会有坑。
2. 开发能读懂，沟通不会有坑。
3. 如果是单元测试或者结合很紧的接口测试可以跟生产代码放在一起。加入 CI 经常跑，保持有效性。

不同团队差异很大的。整体的导向是让开发承担更多质量活动，提高开发测试比。

推荐的就是那本 The little black book on Test Design

要求的确不低，这算是行业挑战吧。但价钱是好价钱。根据我的了解，好的测试开发比普通测试工程师高出不少，甚至比普通开发工程师工资都会高。30k+ 每月的 base 在一、二线的公司都是可以能够拿到的，部分人的薪水是是 4xk，甚至更高。对于一个工程师来说，真的很不错啦。

我司的薪水没有得到授权，不敢乱说。但网上应该有不少讨论了，可以参考一下的。如果是 P7 及以上，相当有竞争力。

kubernates 基本已经一统江湖。 要考虑一下技术延续性和生命力。没人维护，萎缩的东西，碰上卡了你的东西都没人管，填坑成本就太大了。

加油：）以前有个同事学水土保持的，通过自学现在也做的不错。工作后的成长其实比大学四年更重要。我本科学的数学，大学毕业的时候连个简单的小网站也写不出来，第一份工作写 JSP,头三个月被折磨死了，后来也挺过来过来了，后续的具体知识其实大部分是自学的。

https://testerhome.com/topics/16397 在这个帖子回答了 “ 如果让你去测试一个你完全不熟悉的系统，你会怎么办？” 这个问题的参考答案。

试着再回答另外两个吧：

如果测试时间不够，你会怎么办？

仍然没有标准答案，但我比较满意的点会有：

• 跳出这个问题，讲如何从初期避免测试时间不够，以前有过很成功的案例是很好加分项。
• 懂得基于风险的测试，估算时间，设计测试策略，把最有限的时间分配在项目风险最大的地方。这是项非常重要的能力（有专业知识，请参考 ISTQB 教程）有非常成熟的形式化方法，也有非常多的实战 checklist（做过大项目的人肯定能够讲出不少条）。
• 清晰让主要干系人随时知道现在项目的状态，特别是质量情况，未来可能的走势，大概什么可能达到发布状态。 QA 是一个夜间走山路汽车的大灯，他的职责就是最有效的发现项目所有的大坑，并明确的告诉司机（项目主要干系人）。这里面隐含着对沟通能力的考察，也隐含着对风险管理的能力的考察。
• 一定的项目管理能力，如何让团队对现状，对现在的项目计划是否能够有效进行下去有一个清晰的认识，并且引导团队 work smart 搞定挑战。你不一定是 TL，在系统测试阶段，从某种意义上 QA 就是项目 Leader。在关键时刻，项目的成败，重要决策是否能够被做出，与负责项目的 QA 有重大关系。
• 软技能：推动能力，ownership，协调能力，抗压能力，能否激励团队，给团队信心等等。
• 如果应聘者谈到以前工作，可能会追问，考察其它知识点。
• 只能回答出 “加班呗”，而没有其他思路的人，大概率只能 pass 了。虽然接受加班一般用人单位都比较喜欢，但没有展示出任何 QA 应有的能力，技能上肯定是不合格了。

你平时会使用那些测试设计方法？

主要考察做测试设计的时候是否靠谱。思路是否开阔，是否收过专业训练，是否积累了自己的一套方法。仍然没有标准答案。

• 如果只能讲出：我会等价类，边界值，然后。。。。我想想。。。想不出来了。 。。 如果再简单引导，还是无法给出更多内容，大概率会被 pass（很多应聘者都会这样）。
• 如果你觉得你没有听懂这个问题，反问我，我会给你加分。
• 如果你熟练掌握等价类、边界值、判定表、状态图转化、组合测试等通用方法，并能够举出一个例子来，我会给加分（最基本的东西用了）。
• 如果能够给出基于被测物详细分析做测试设计的案例，我会给加很多分。
• 有固定套路的人（例如 可以使用 基于 guide word 的测试设计 ）会加分。
• 能够讲出自己一套方法论，并且有明确案例支撑的人会大大加分。
• 能够结合自己工作侃侃而谈并说到点上的人（虽然显得比较散），也会给加分。
• 测试设计本质上要回答两个问题：你的测试设计是有效的么？（是否经过测试就靠谱了，覆盖率是？）你的测试是高效的么？（是不是能够用不太多的用例高效找出主要问题，这在大规模项目里非常重要） 再往大里讲讲，“测试设计” 不仅仅包含了一些简单的方法的使用，还包含了过程活动、质量意识在里边。不展开说了，有兴趣的同学可以参考这本书The little black book on Test Design 通读 5 遍，同时把他引用的所有链接全看了。再跟你的工作联系起来，再不断的翻过来调过去揣摩、实践里边的方法，半年后，你看测试会有比现在深太多的认识。别人问你测试设计，你能给他讲 1 天。你的工作也会发生本质改变。

还是那句话，面试主要还是考察平时的工作经验积累、思考积累、解决问题的能力的积累。

哈哈，我感觉自己被面试啦，希望我的回答你满意。btw，如果觉得非常对路，欢迎投递简历到我这里啊。缺小伙伴缺的厉害。

你这种回答我会加分啊。然后我会追问你以前有没有遇到这种情况，你做了什么来从一定程度上扭转这类问题。如果有很好的实践，你大概率是我的菜。 ：）

发现论坛一个小 bug，编辑栏里的序号是 5，贴出来变成了 1.

1.这个问题是一个开放性的问题，适合不断加入上下文来追问。那个面试官的模式很像我。😀。
2.有上下文的持续追问是能够检验应聘者对问题有没有深入理解、简历上过去工作经历有没有水分的非常好的做法。如果只是了解皮毛，简历注水非常严重，被追问几句必然败下阵来，并且留下非常不好的印象（不诚实）。
3.回到这个具体的问题，从这个问题出发的考察点有几个：是不是具备快速学习能力？是不是有很好的获取知识的套路（测试的过程本质上是一个学习的过程）？是不是有很强的探索精神？是不是有很强的沟通能力？是不是有不错的总结能力？
这里并没有标准答案，但一定是有考察点的。
4.如果你的回答里有明确的亮点，一定会加分，加分比较多，胜出的几率就很大。举几个加分的亮点的例子：
a.我会先去直接操作和观察被测物。（比直接奔向需求要加分很多，想一下，你实际工作中，快速理解一个东西靠的是什么？肯定不是先读文档，且不说这些文档是不是能够正确的描述被测物）
b.我依托原来的工作经验，讲出了十几种信息来源，而不是只能讲出需求：同类产品，说明书，直接操作、观察被测物，原有版本，找产品经理，找开发，找销售，运维，客服，找用户，公司知识库，历史邮件，会议纪要，原来的各种文档，代码，google，相关法规，行业标准。。。。 能够有效开动脑筋，从各种地方获取信息帮助测试的人会让人眼前一亮。 只能讲出依照需求，说不出其它的人基本上会被 pass。
c.讲出原来几天搞定了一个从来没有经手过的系统的测试，并经受住追问，不管路子多野，多山寨，也会是加分项。
d.能讲出克服的一个具体困难点的例子，并经受住追问，也会是加分项。

1. 追问就会转到其它问题，考察点会结合你的反馈变更。 比如那个问题：如果项目进度很赶呢？ 我的理解是要考察你有没有 “迭代” 的工作思路。 如果回答给出了快速上手的正确方法，给出了通过迭代，一边学一边加深理解，一边给出质量反馈的思路，肯定会是加分项。

6.一般能有五六个亮点，你胜出的几率就很大了。

我的思路大概是这样。

面试的初衷还是要在一个时间段内（1 小时）尽量了解应聘同学的各方面是不是适合这个岗位。应试会有些用。但最关键还是平时的积累和思考。

good luck。

是博弈，不同企业上下文不一样，所以答案也不一样。

thanks，我一会儿去校对一下。😄写的挺糙，没校对就发了。

这两本。 里面很多技能还是值得掌握的。高级测试经理，里边有一些方式和方法可能不合适你所在的企业，但是一些框架性的知识和意识可以活学活用的。

小伙伴们别叫大佬啊，当不起的。

https://testerhome.com/topics/16329 看到了匿名吐槽的这个帖子。

请相信我，真的不是故意挑三拣四。好多面试到的技能真的是岗位需要。在大厂，系统都会很庞大，但迭代丝毫不会比小厂慢，甚至更快，稳定性的要求上也十分苛刻。“既要、又要、还要” 带来的挑战真正在里边工作的人才会体验到。就算你是把牛刀，也不会 over qualified。因为，很多时候你可能有机会，或者不得不去杀恐龙。。。

35 岁现象的确有的。但也不是那么绝对，市场对能力高的应聘者是饥渴的，提高自己还是王道啊。如果 35 岁了，面试的时候给人的感觉能力上跟入行两三年的小伙伴一样，就会非常尴尬了。

年龄歧视现象哪里都存在，前几天米国一堆应聘者体诉讼谷歌年龄歧视了，只能期待整体劳资关系变得更好。作为个体，在这点上没法直接改变什么，最能控制的就是提高自己的竞争力了。

再有，就是自己的预期了。高端职位本来就是稀少的，养家的职位还是有的。不停的努力，不停的寻找机会吧。

我也 35+ 啦。如果换工作的话，真没有信心说一定会比现在的工作要好，但养家糊口还是行的。

多聊一句：现在 IT 总体大环境还行，但也许整体近期会下行，所以，如果有比较稳定的工作，看准好机会前，不要冒险。

掏心窝子的话。给你点赞。

泛质量领域：）哈哈。google 把做这个工程师叫做 SETI software engineer in Test and Infrastructure，也是从测试工程师派生出来的。

效率低是对这个领域不熟悉啊，努力学习吧。 等你把 jira 的很多 restapi 记得很熟了，二次开发的套路也熟悉了，发现就像跟以前写业务代码一样，变成日常了。
btw，做 IT 基本上哪个岗位压力都不小啊。各自有各自的苦，活少钱多有前途的工作肯定有别的 trade off 或者隐性成本。 要不你爹厉害，给你安排个垄断部门，别人图你爹权势；你爹不够厉害，能送礼，你的钱多活少的成本转嫁给了你爹；也许领导贪图你美貌，你可能要受骚扰... 互联网 IT 的工程师大部分都是老老实实地搬砖，挣辛苦钱。 其实本质上是堂堂正正的用劳动换钱，行业溢价也在，已经好过很多人了。不用太苦恼。
好的职业路径，其实 IT 的各职业工种都有的啊，天花板也都挺高的，一线互联网公司的资深测试开发工资还是非常可观的。
送了碗小鸡汤，希望有帮助，加油吧。