😏作者简介：博主是一位测试管理者，同时也是一名对外企业兼职讲师。
📡主页地址：🌎【Austin_zhai】🌏
🙆目的与景愿：旨在于能帮助更多的测试行业人员提升软硬技能，分享行业相关最新信息。
💎声明：博主日常工作较为繁忙，文章会不定期更新，各类行业或职场问题欢迎大家私信，有空必回。

 
 

1. 接上回

  我们接着上次的内容继续来整理与解析一些比较高频的测试行业面试题，大家可以通过面试题内的一些解析再结合自己的真实工作经验来进行答题思路的提取、整理。友情提示：硬背答案虽可，但容易翻车哦。

 
 

2. 题目解析

 

2.1 请介绍下你比较熟悉的Linux命令

  这个可以说是非常基础的一题了，但就博主的了解，有不少的测试就业人员不熟悉甚至没接触过过Linux命令，大家也不用惊讶，介于很多小厂或私人公司的规模与前期流程习惯，测试环境搭建与维护会被运维一并管理，也有些甚至没有独立的测试环境，更多的是被DEV或UAT环境所替代，这也就导致了测试人员在整体的测试活动中无需关心测试环境的相关事宜，对于Linux命令没有接触也貌似就变得顺理成章了。但对于测试人员来说不能熟练的使用Linux命令一定是比较致命的，所以在我们的日常工作中无论是独立搭建测试环境，还是对服务侧进行各类测试、日志查询、后端问题定位都会要求我们掌握一定的Linux命令。那么对于Linux命令我们的测试人员需要掌握到什么程度呢？在这里我给大家一个建议，最好的方法根据你的公司业务来进行度量，如果你自身对Linux有兴趣那当然是最好，如果只是工作需要，那对于这块还是从实际的工作内容入手，比如公司的产品后端使用的是什么版本的Linux、不同的平台命令会有细微的不同；独立搭建整套的测试环境，这个也是必须掌握的；安装OS时最好是选择命令行界面的，跳过GUI，强制自己使用命令完成所有的操作；如果英文底子不行的话，建议适当提高一下英文的读写能力，对后期的Linux操作绝对是有益处的；将日常的命令学习累积与输出，学习一些shell知识，将一些固定操作变为脚本执行。

  只需要养成日常的有意积累，要回答这类问题不难，毕竟命令这块不是什么创造性问题，描述的时候只需要注意不要讲命令相关的参数过于扩展即可，另外如果可以配合实际的工作中场景来描述命令的用法那就更好了。

 
 

2.2 工作中使用过什么测试管理软件

  这里的测试管理软件指的就是我们测试人员在整个测试活动环节中对于需求、计划、用例、缺陷进行管理的软件工具，测试人员可以通过这些软件来对整个测试活动的各个环节进行结果的监控与管理，简单来说就是用来提升测试效率的有效工具。

  对于这样的开放性问题，无论我们使用过哪些软件或工具，哪怕是自研的，我们都可以有条理的对管理软件的功能与场景进行总分总的结构来进行介绍，但需要注意的是这些毕竟不是我们做过的产品与项目，描述不要太过详细。总分总的结构大致可以分为：1. 将所有环节会用到什么软件进行概要介绍；2. 抽出自己比较熟悉的某一环节来进行重点铺开，结合真实工作场景来描述日常的测试管理工作内容；3. 最后收一下尾，描述使用管理软件可以如何提升该环节内的工作效率。另一方面，在日常工作中我们对于测试管理软件的使用方法与其内的一些要素或快捷操作可以进行一定的熟悉，相信在回答这题的过程中会起到一些意想不到的效果。

 
 

2.3 请介绍一下TCP与UDP两者的区别

  很经典的一题，标准答案这里就不详说了，各大搜索引擎都有。这里想说的是另一个比较常见的现象，就是有部分的测试人员其实对网络基础知识的掌握比较弱，一般来说把上面一个问题的答案记一下就能轻易的答出。但一旦面试官稍微深入询问一点点就马上会暴露出问题，大家试想一下，能清楚区分出两大协议区别的人却搞不清楚在7层模型的哪一层，你们是否相信面试者在日常的工作中有真实的接触经验。

  还是那一句话，虽然我们在日常的工作中对于网络传输协议的认知是比较抽象的，但这并不妨碍我们有效并的学习相关的知识。另外不单单局限于TCP与UDP，其实对于OSI 7层模型的一些基础知识我们多多少少都需要掌握一点，身处软件行业除了软件工程的相关知识之外，网络就是一个绝对的大头了。独立完成测试任务对于每个测试人员来说都是基础中的基础，谁也不想因为产品缺陷问题涉及到网络就直接躺平吧，更不用说现在的产品基本设计多端，App、Web都是常见到不行的产品形态，没有相关的知识简直就是寸步难行。

  说了那么多，其实这题还是可以使用那个万金油套路，基础知识+场景结合。了解了题目相关的基础知识之后，将两者的特性进行学习与理解，在日常工作中结合测试场景来熟悉。答出了基础面知识，我们就可以得到一半的分数，另外一半可以描述我们做过的项目或产品为何要使用此类协议，突出协议特性与产品的应用场景是良好结合的。 如何选择这个和技术架构与选型有关，我们可以适当弱化或一语带过，突出业务面才是我们需要表现的主要目标。

 
 

2.4 请描述一下你所理解的软件测试

  这个题目的答案又是一个众说纷纭的局面，无论答案的来源是什么，博主这里推荐的就是在提前准备、累积、沉淀、总结。理解这个字眼本来就是很感性的，固然别人的理解很到位，很形象，但那毕竟是别人的，拿来借鉴本身没有什么错。我们进入软件测试行业的动机与目的虽然各不相同，无论你是向往还是被迫，都改变不了你当前身为测试从业人员的事实，所以我们在自己的职业道路上抽出一些时间来思考这个问题，也就变得顺利成章了。如果有条件也可以和身边的团队成员或圈子内的其他测试人员讨论下这个问题也不失为一个良策。

 
 

2.5 如何对一个页面做测试

  和之前的物体测试类似，可以从功能、界面、性能、易用、兼容、安全等方面来进行切入。但以上这些类似的回答过于宽泛，也很难提起面试官的兴趣，所以在对方提出这样的问题之后，我们可以反过来问对方一个问题：该页面是类似什么功能或业务的页面？这样做的好处有2，第一，我们可以准确的对问题进行定位，更有针对性的给出回答，而且面试官大概率会给出他们公司产品的相关某个页面，这个也是为什么在面试前推荐从搜索引擎里好好的熟悉下用人单位的业务信息与产品介绍等信息。第二，给面试官留下印象，回答问题其实和接收工作任务一样，在执行工作之前有针对的确认目标是非常有必要的，这样的下属也是身为管理层比较愿意看到的。那么我们在回答这题的时候就可以将以上的几个测试维度进行有效的展开，颗粒度细致到某一个功能也不会显得唐突。

 
 

2.6 当你提出的缺陷开发不承认怎么办

  不得不说，绝大部分的测试人员都有碰到过这样的问题，其中牵扯的不单单是做事层面的问题，当中也会掺杂人的因素在内。这题考察的就是应聘者身为测试最基本的事务协调与沟通能力，虽然答案根据各自经历的不同而有所变化，但大的基调是不变的，客观描述、理性沟通、意见交换、有效推进、达成一致，这里要注意，所说的内容一定要真实，如果真的没有碰到诸如此类的情况，宁愿说没有也千万不要瞎编，容易翻车。对于此类问题的回答，我们可以有条理的将工作中碰到的几类场景进行逐条描述，先讲真实碰到的情况，此时如果面试官追加了情景，这里可以按照自己的想法进行补充，但如果是没有把握的部分，绝对不能乱讲，作为测试，谨慎的做事行为最好能养成，测试人员的一个重要的作用是承上启下，其工作内容连接着诸多部门。能否用客观的数据与证据来证明自己所开出的缺陷属实，并且正确的传达至开发人员，这对每个测试人员来说都是度量其专业技能是否合格的标准之一。

 
 

2.7 请描述一下冒烟测试的目的

  这题相对来说比较的简单，基本做过冒烟测试的人员都知道其中的目的。冒烟测试一般是放在集成测试之前，也就是开发做完单元测试之后，提交测试版本给到测试团队的时候。测试拿到提测版本后，一般都会先进行冒烟测试，验证提测版本的基础与被测功能是否存在重大缺陷，简而言之也就是判断当前提测版本是否进入集成测试与投入既定测试人力与资源的必要。冒烟测试的执行内容通常也会由测试团队将日常的测试用例中P0与P1级别的用例抽出组成专门的冒烟测试用例，来进行快速执行。当然如果能使用自动化或CI来替代手工执行就更好了。

 
 

3. 一些后话

  在博主接触过的很多测试人员中，的确有一些人员的沟通能力较为薄弱，无论是线上的信息沟通还是先下面对面的语言表达，时常会出现词不达意、逻辑不通、繁复啰嗦的情况出现。在这里，博主还是推荐广大的测试从业者重视起沟通表达这一块，虽然现在很多人认为工作只是打工，不用在意任何人的看法，来公司也不是交朋友的，但有一说一，这个论点和博主的看法是不矛盾的。提升表达沟通本身就是提升自己的核心竞争力，会说和不会说完全就是两种不同的局面，面对领导、面的同事、面对下属，你所表达的意思是否正确的传达给了对方，这个是很重要的。很多测试人员终日忙碌于测试执行工作中，忽视了沟通表达的重要性，认为测试执行的好，软件功能稳定就是工作结果成功的表现，殊不知真正到了需要沟通表达，需要展现自己价值的时候却只能仓促的用只言片语来进行组织和表达，故而丢失了大量的晋升、跳槽的机会。

  而在其中面试亦是如此，也是真正需要你在极短的时间内展示自己的价值的形式之一，此时的你如果拥有大量有价值的技能，但却无法正确的传达给面试官，最终换来的也无非只是面试落选的结果，毕竟千里马很多，伯乐却少得可怜。所以在我们长期积累总结自己的硬技能的同时，软技能的提升也是必不可少，开口这件事本身不难，难就难在我们的内心把这件事看做是一个难关，正所谓事在人为，休言万般皆是命。