前言
时光荏苒，一转眼已踏入2023年，进入金九银十，人员就业市场以往的寒冬也貌似有了转暖的迹象，身边大批的就业人员也开始了紧张的备战之中。
近几周也和多家合作公司的HR进行了沟通，发现虽然岗位就业情况较去年有所好转，但整体的需求缺口与候选人的条件选择却比19年的时候稀少与严格了许多。
许多的应聘者投出简历之后经常会遇到根本没有反馈的情况，一方面也是大批的大厂、中厂的竞争者出现，他们有着大厂背景和大项目背书，相对来说公司方面就有了更优解，另一方面经历了去年一整年的变故，许多的优势竞争者只能降低预期，这对用人单位来说性价比就更高了。
也正是因为以上的种种，博主作为一个测试管理者也常年面试各类的测试行业就业人员，也发现了形形色色的面试相关的问题，希望将自己的长久经验积累转化为博文的这种方式来帮助到更多的软件测试应聘者。
大家可以通过面试题内的一些解析再结合自己的真实工作经验来进行答题思路的提取、整理。
友情提示：硬背答案虽好，但容易翻车哦。
题目解析
01
请先做下简单的自我介绍
每个应聘者面对的第一个问题，相信大家都不会陌生，这里只说几个重点：
1、自我介绍一定要事先准备，在有效的时间内（保持在1-2分钟左右）将自己之前的职位、大致职业经历、能力特长进行描述。
2、另外一个比较有意思的是，许多应聘者在面试刚开始的时候相对会比较紧张，但只要面试进行的比较顺利，后期的紧张感也就会渐渐消失，这就导致一开始的自我介绍往往会表现的窘迫、结结巴巴，那么给到面试官的第一印象就会打折扣。
02
请介绍一下你们的测试流程
对于以上这题，能给到比较标准的答案就是：需求分析 → 概设详设测试 → 单元测试 → 集成测试 → 系统测试 → 验收测试。
但博主不建议按部就班的把这个记下来用来回答，那最多就是一个框架，这里推荐结合自己公司的真实测试活动内容来进行描述。
千万不要觉得少了其中的某一步会怎么样，也千万不要为了使流程听起来比较丰满而刻意的去编造一些自己从来没参与过的测试环节，就比如概设详设测试这块，很多公司是不会有的，你在面试过程中背了这一个流程框架，将其加入其中，一旦面试官问起无疑就是给自己挖坑，这个是面试中的大忌。
我们在日常的工作中可以进行刻意练习，身为执行人员在测试活动的整个过程中可以将每个阶段自己、团队成员、上级在做的事情进行观察与大致的记录，如果能有输出物那就最好了。
一般面试官在听到你介绍完一整个测试流程大致后，都会针对某个环节来对你进行细致提问，比如你们的测试用例评审是怎么执行的，集成测试环节中你的主要职责是什么，测试活动前期你在团队中具体负责哪些工作等等等等。
无论问题如何五花八门，只要不脱离整个流程的大致范围，相信平时如果有良好的经验累积和刻意练习，这些类似的问题都可以应付自如。
03
请你介绍一下你们公司的XXX产品/项目
这题的出现率也是高的可怕，其实对于面试官来说，检验一个测试人员的业务是否合格的其中一个标准就是应聘者是否可以完整、全面、系统的介绍清楚自己的经手的产品或项目。
这里还是奉劝大家不要抱着侥幸的心理，觉得反正不是用人单位的项目，随便说说，就算说错应该也没什么大问题。一般来说面试你的无论是一面还是二面，都会是你的直属领导，只要不是太水，面试官的技术力与业务力都会在你之上，如果是同一行业的就更不要提了。
千万不要只是宽泛的将公司产品的相关介绍与功能描述出来，最好可以将软件架构 应用场景 解决痛点 负责模块与亮点功能进行系统的介绍。
对于自家产品与项目的了解，除了在日常的测试工作中进行累积之外，可以多与项目组内的其他角色多多进行沟通，软件架构与基础功能逻辑可以找开发、产品需求与业务可以找产品、软件的弊端与一些问题可以找售后。
通过多方位的了解与信息收集，将自身对于产品业务与功能的理解进行优化，可以最后的输出物简洁的表现在简历的项目经历内。
另外有条件的话可以与团队内的其他软件测试人员进行互相的练习或在某些内部分享会进行刻意练习。重要的在就如何通过多次练习来进行语言的组织与表达。
04
请讲讲工作中你遇到过哪些印象深刻的Bug
这一题博主也曾经向许多面试者询问过，但大家通常都会把注意力放在“印象深刻”这个点上，描述出来的内容也大多是某个Bug有多难解决，定位分析了好几天都没有进展，然后通过自己的不懈努力或灵光乍现，提供了线索让开发最终解决了问题。
那么该如何回答这个问题呢？其实以博主自身的感受来说，面试者所说的这个Bug是否极为复杂、困难重重，真的一点也不重要。
大家要知道共情这个东西是很难的，你想要告诉面试官的并不是你调查这个Bug有多辛苦，对不对？我们还是要搞清楚面试时，对方提问的本质大致是什么？他真正想要考察的是什么？
其实这个面试题的本质是想要考察你作为一个测试人员，在这个Bug的全生命周期中，做了哪些工作和具体的一些内容体现。
那为什么要是印象深刻的Bug呢？印象深记忆才会保持长久，也是借此希望面试者可以完整的说出这里面的来龙去脉。
那么拉回来继续说刚才的话题，对于测试人员来说日常的Bug定位能力相较于执行才更有价值，定位Bug其实是需要我们的测试人员拥有更加全面的技能广度。
同样是一份Bug单，一份是有准确调查线索与自我推断的，另一份则是只有现象描述与期望结果的，相信广大的开发同学也是更希望拿到的是第一份Bug单。
当然除了定位肯定是不够全面的，作为测试人员，一旦发现了Bug，那基本操作就是复现 → 分析 → 记录 → 跟踪，所以日常工作中Bug的全生命周期管理是每个测试人员都需要刻意练习的内容。
同样的，在开发同学进行Debug的时候，也可以适当的去旁观一下，看看他们是如何进行Bug定位的，平时多和开发同学进行交流，学习一些相关的定位技能。
当你能把这些简洁完整的描述出来，相信Bug是否复杂，是否惊艳也已经不是什么问题了。
05
请介绍一下日常你们是如何设计测试用例的
这一块可以根据自己公司的实际情况进行描述，就不另行开坑了，另外也推荐看下公号之前的关于测试用例设计的文章。
06
如果给你一个XXX，你准备怎么测试
又是一个万年不变的面试题，虽然乍一听起来好像挺简单的，但在这题上翻车的面试者还真的不在少数。
其实这一题考察的是面试者对于被测对象的整体质量保障认知与业务快速上手能力。
无论这个XXX是任何物体，这里都有一个万能的公式去套，那就是从不同类型的测试活动去进行质量保障，这个也是遵循了软件测试的一贯理念。
举个例子，如果被测对象是一个电子秤，那么我们可以从功能性的角度去确认他的基础功能是否OK，从设计性的角度确认外观与规格是否符合需求说明，从性能的角度确认规定使用次数内是否功能是否OK，从安全性的角度确认基本的材质是否合格，切角设计是否安全，从易用性的角度确认液晶屏亮度与数字字体是否OK等等等等。
这里只提及了大致的回答思路，真正的面试过程中碰到了这题，我们需要在这思路的基础上对每个类型的测试项进行细分，可不能粗略的回答大概用什么测试类型去确认。
07
请说一下APP产品与WEB产品测试的区别
这题我们可以从以下几个方面去进行切入，首先从软件架构来说APP为C/S架构，WEB为B/S架构。
针对不同的架构形式，我们的测试方式与关注点也是不同，APP因为需要投放应用市场，迭代的速度与频率不会像WEB这样频繁，相反由于WEB的自身特性，无论是任何的代码改动都可以快速的通过前端代码发布进行迭代，也正因为这样，如果是在正式环境中进行回归，WEB产品的回归要求与时效性要远高于APP。
同时区别与其两者的软件架构，APP需要验证客户端侧的安装与升级、卸载等功能方面，而WEB则无需。
从兼容性方面来说，APP注重各类主流机型的适配，WEB注重各类浏览器的适配。性能方面的关注点也大不相同，APP需要对手机的功耗、网络流量、CPU、内存进行关注。
WEB则需要对页面响应速度、FCP、LCP、FID、 TTI等各类指标进行观察。至于弱网相关的测试其实更倾向于APP产品侧。
