2022年马上开始了,3、4月份正是跳槽的季节。小编总结了面试的细节,这份热乎乎、滚滚烫的面经分享给大家,希望对大家有所帮助。

 

 

面试形式

 
 

问题式

 

由招聘者按照事先拟订的提纲对求职者进行发问,请予回答。其目的在于观察求职者在特殊环境中的表现,考核其知识与业务,判断其解决问题的能力,从而获得有关求职者的第一手资料。

专场式

 

由公司组织专场招聘会,由公司面试官代表对多位甚至大量应聘者进行海选,从中选出符合公司要求的多位应聘者进行之后的面试,此方式适用于对应聘者的初筛。例如:校招专场。

压力式

 

由招聘者有意识地对求职者施加压力,就某一问题或某一事件作一连串的发问,详细具体且追根问底,直至无以对答。此方式主要观察求职者在特殊压力下的反应、思维敏捷程度及应变能力。

随意式

 

即招聘者与求职者海阔天空、漫无边际地进行交谈,气氛轻松活跃,无拘无束,招聘者与求职者自由发表言论,各抒己见。此方式的目的为:于闲聊中观察应试者谈吐、举止、知识、能力、气质和风度,对其做全方位的综合素质考察。

情景式

 

由招聘者事先设定一个情景,提出一个问题或一项计划,请求职者进入角色模拟完成,其目的在于考核其分析问题、解决问题的能力。

 

综合式

 

招聘者通过多种方式考察求职者的综合能力和素质,如用外语与其交谈,要求即时作文,或即兴演讲,或要求写一段文字,甚至操作一下计算机等等,以考察其外语水平,文字能力,书法及口才表达等各方面的能力。

 

 

面试种类

 
 

个人问题

 

一、个人面试

 

1)一对一的面试

 

适用范围:规模小的机构、职位较低。

 

(2)主试团的面试(多对一)

 

适用范围:较大机构 ,如考核公务员 现场打分。

 

个人面试又称单独面试。指主考官与应聘者单独面谈,是面试中最常见的一种形式。

 

面试由公司组织专场招聘会,由公司面试官代表对多位甚至大量应聘者进行海选,从中选出符合公司要求的多位应聘者进行之后的面试,此方式适用于对应聘者的初筛。例如:校招专场。

集体面试

 

集体面试主要用于考查应试者的人际沟通能力、洞察与把握环境的能力、组织领导能力等。在集体面试中,通常要求应试者做小组讨论,相互协作解决某一问题,或者让应试者轮流担任领导主持会议,发表演说等。

 

无领导小组讨论是最常见的一种集体面试法。

 

综合面试

 

以上三种方式的综合,由主考官通过多种方式综合考察应试者多方面的才能 。

方式:事先定题,以自由交谈相互交融的方式 。

渐进式面试

 

人太多时 ,先初次面试即筛选面试以了解个人背景及谈吐与应对能力为主要目的,然后二次面试以及三四次面试,视职位高低定。

 

注意:大型公司在招聘员工时都会有一套比较正规的程序。
 

一般来讲,分为五个阶段:简历筛选、笔试、初次面试、高级经理面试和最后的Offer。

 

 

软件测试面试题总结模板

 
 

请做一下自我介绍

各位面试官好,我xxx,来自xxxxxx年出生,20187月毕业于xxx学院,我具有2的软件测试经验,我在上家公司主要做功能测试,从事一个网站的建立项目,因为个人发展原因,今天来到贵公司面试。

你对上一家公司如何评价

我的上家公司环境蛮不错的,整个项目组的成员都很团结,氛围很浓郁,遇到不懂的问题我能够和同事们进行沟通,但是考虑到我自身发展的因素,我还是被迫辞职了

你都会哪些技能

会mysqlSQLserver数据库技术,Linux的基本命令和环境部署,了解Python语言,这些我之前在大学和公司都有学过这些东西,文档管理工具SVN,缺陷管理工具禅道等都在平时工作中学习过Jmeter测试工具等

介绍一下你上一个项目

我的上一个项目是上海融巧科技有限公司网站项目,主要做的是一个关于该公司的网站模块的测试,主要有六大模块如首页、课程介绍、融巧咨询、学员天地、关于我们等,首先我们的开发、测试和业务人员与客户进行沟通,了解需求,业务人员编写需求规格说明书,之后进行讨论总结出评审后的需求说明书,然后项目经理派发任务给开发和测试人员,开发根据需求规格说明书和设计说明说进行开发工作,之后进行单元测试,我们测试则进行测试计划的设计、评审、测试用例的设计,之后开发完成开发工作,并且搭建好测试环境之后我们首先进行冒烟测试,测试主要功能是否完备环境通不通,之后进行案例的执行,执行过程中做好测试记录,并且用缺陷管理工具禅道对缺陷进行发现、记录、跟踪,一轮测试完成后进行第二轮和第三轮的回归测试,之后编写测试总结和报告。

介绍下你们的项目流程与测试流程

(1)接到项目后,由项目经理、产品经理、开发经理、测试经理和客户进行沟通,分析需求,由产品经理编写需求文档,编写之后进行需求评审,看看有没有不能完成或者有必要增加或修改的地方

 

(2)审过后,由需求人员把需求文档细化成需求规格说明书,由项目经理编写项目计划并分配任务,开发人员根据需求说明书、设计说明书进行软件开发,然后开发人员进行单元测试。这时我们测试人员了解客户需求,根据需求规格说明书编写测试用例之后对测试用例进行评审,在评审中注意有无遗漏或有误的地方,修改案例

 

3)测试用例评审ok后,这时开发人员也开发好了,搭建好测试环境,我们首先进行冒烟测试,看看软件关键功能可不可以正常用,环境通不通。然后我们根据测试用例进行测试,在测试过程中遇到bug后,用缺陷管理工具禅道记录bug,并根据缺陷生命周期跟踪bug,回归通过后关闭缺陷

 

4)所有测试执行后,缺陷也关闭了,然后测试人员编写测试总结报告,完成后到运行维护阶段。

介绍下你们的测试流程

首先会召开需求分析会议,参加人员有产品(或者叫业务)、开发和测试,主要是探讨需求需要的一些功能点,完了之后,开发就排期进行开发,我们就根据主管写出来的计划、分配到的任务编写测试用例,写完之后会进行用例评审,需要修改的就修改整理形成最终的用例版本,之后开发人员将软件开发完成并部署到SIT测试环境后,我们会依据测试用例来执行测试,测试过程中,对于发现的BUG提交到缺陷管理工具禅道,并跟踪bug状态直至关闭,首轮测试完后开始进行回归测试或者第三轮回归测试(回归几轮都是根据具体的可用测试时间来决定的,一般我们都是回归测试一轮就结束)最后测试完成后编写测试报告。

什么是系统测试

系统测试是指针对软件产品系统进行的测试,是做完单元测试和集成测试后进行的测试,总体包含功能测试与非功能测试。功能测试是验证软件系统功能是否实现系统需求规格的测试过程,而非功能测试是验证系统是否在实现功能测试的基础上,测试系统的容错性、稳定性、异常处理能力,以及高强度输入的处理能力、可用性、性能等是否符合用户要求的测试过程。

你认为你的优点和缺点分别是什么

我的优点是执行力比较好,上面下达的任务我能按部就班的完成,有比较好的责任感,会将一件事认真负责的做下去,遇到困难不会退缩,会想法设法询问有经验的同事查找资料等方法去解决,我有良好的团结协作意识,对于一个共同完成的项目会将自己的事情主动做好,并且也协助同事做好他的事情,发现一个问题会紧追不舍,我的文档整理能力也比较强,缺点就是本人技术水平有限,不能完全独自一个人解决所有的问题,这点自己会在以后的工作中和业余时间通过不断学习来改进我的方法和技术

黑盒测试和白盒测试的区别

(1)黑盒测试也称功能测试,通过测试来检测每个功能是否都正常使用,测试中把程序看成一个黑盒子,在完全不考虑内部程序结构和特性的情况下 ,执行测试。黑盒测试是以用户角度,从输入数据与输出数据的对应关系出发进行的测试。 缺点是:发现不了本身设计或规格说明的问题。黑盒测试设计测试用例的方法包括:等价类划分法、边界值分析法、判定表法、因果图法、正交法、错误猜测法等

2)白盒测试是基于代码的测试,白盒是指盒子是可视的,清楚内部是如何运作的,白盒测试人员要全面了解程序内部逻辑结构、对所有的逻辑路径进行测试。 常用的白盒测试用例设计方法有:语句覆盖法、判定覆盖法、条件覆盖法、判定条件覆盖法、路径覆盖法

Bug的生命周期

录入缺陷后,测试人员应该跟踪一个缺陷的整个生命周期,从new到closed的所有状态包括new、open、fixed、rejected、delay、closed和reopen这些状态。

 

提交缺陷到缺陷管理工具,这时缺陷的状态是new。当确认是bug后,打开缺陷,此时缺陷状态为open,并且指派给相应的开发人员。开发人员进行修改把缺陷状态置为fixed修改状态,修改好后等待测试人员回归测试。如果开发人员认为不是bug有权拒绝修改把缺陷状态改为rejected。如果开发人员认为暂时不需要修改或暂时不能修改,则延后修改,缺陷状态为delay。修改状态的bug经过测试人员复测通过后,则关闭bug,状态为closed。如果复测不通过,则重新打开bug这时的缺陷状态是reopen,等待开发人员重新修改。

app测试与web测试的最大的异同在哪里?

相同点:同样的测试用例设计方法;同样的测试方法;都会依据原型图或者效果图检查UI;测试页面载入和翻页的速度、登录时长、内存是否溢出等;测试应用系统的稳定性

不同点

app的中断测试来电中断、短信中断、蓝牙、闹钟、插拔数据线、手机锁定、手机断电、手机问题(系统死机重启)

 

app安装卸载全新安装、升级安装、第三方工具安装、第三方工具卸载、直接删除卸载消息推送测试、手机授权测试、前后台切换、网络环境(wifi/2G/3G/4G/无网络)

 

兼容性测试web项目考虑不同浏览器的兼容;app需要考虑手机不同操作系统、不同机型、不同屏幕等web自动化测试工具较常用QTP,而手机自动化monkeymonkeyrunner

你们的bug是怎么管理的?对于复现概率不高的bug是怎么处理的?你下一次测试的时候对于这样的bug点是怎么做的?

公司有缺陷管理平台来进行管理,我们用的是禅道。关于复现率较低的bug,在实际工作中采取的是全部上报,但是我会在标题中注明重现率低或偶现。在工作中我们如果有时间的话可以多费些心思在重现bug上面,学会分析可能产生的原因,同时在发现bug后第一件事情就是要将证据保留下来,截图,错误信息等等,这些及有助于证明这个bug的存在,也有助于bug的重现,所有这些应该培养成习惯。

您以往的工作中是否曾开展过测试用例的评审工作?如果有,请描述测试用例评审的过程和评审的内容。

您以往的工作中是否曾开展过测试用例的评审工作?如果有,请描述测试用例评审的过程和评审的内容。

有开展评审工作。评审的过程及内容(以会议评审来讲):

(1)编写评审计划

(2)评审材料准备好(主要是测试用例)

(3)提前发布评审通知(OA通知、邮件、或者讨论组发布信息), 同时将评审材料发送给评审组成员,以节约沟通成本

(4)召开会议评审;针对评审用例检查清单,评审过程中收集相关人员的反馈信息(即问题记录清单),并在此基础上进行测试用例更新,直到评审通过5)评审结束后,测试负责人出测试用例评审报告给到相关人员;评审结果经项目经理同意确认。

描述软件测试活动的生命周期?

测试周期分为计划、设计、执行、评估、验收。其中:计划:对整个测试周期中所有活动进行规划,估计工作量、风险,安排人力物力资源,安排进度等;设计:完成测试方案,编写测试用例,从技术层面上对测试进行规划;执行:搭建测试环境,执行测试用例,遇到问题提交bug并跟踪解决验证;评估:记录测试结果,进行测试分析,完成测试报告。验收:用户进行验收,我们会出用户手册、操作指引,公司有严格的评审流程,以保证每一步输出的有效性。

缺陷报告处理流程

测试人员提交缺陷报告后,由开发经理分配缺陷报告给相应开发人员,开发人员处理缺陷报告,处理完成测试人员进行回归测试,复测通过则提交复测通过报告,最终由测试经理关闭缺陷报告