测试工程师面试常见问题整理.docx

测试工程师面试常见问题整理.docx

《测试工程师面试常见问题整理.docx》由会员分享，可在线阅读，更多相关《测试工程师面试常见问题整理.docx（18页珍藏版）》请在冰豆网上搜索。

测试工程师面试常见问题整理

01.为什么要在一个团队中开展软件测试工作？

软件测试概念：

在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估的一个过程：

测试的目的：

是想以最少的人力，物力和时间找出软件中潜在的各种错误与缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患以及带来的商业风险。

因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。

在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。

软件测试生命周期1）计划 2）分析，3）设计，4）构建，5）测试周期，6）最后测试和实施，7）实施后。

02. 您在以往的测试工作中都曾经具体从事过哪些工作？

其中最擅长哪部分工作？

我曾经做过web测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。

最擅长的是功能测试

03.您所熟悉的软件测试类型都有哪些？

请试着分别比较这些不同

测试类型有：

功能测试，性能测试，界面测试。

功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。

是把测试对象看作一个黑盒子。

利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。

采用黑盒技术设计测试用例的方法有：

等价类划分（有效/无效等价划分）、边界值分析、错误推测、因果图和综合策略。

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

负载测试和压力测试都属于性能测试，两者可以结合进行。

通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。

压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。

而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。

同时界面如同人的面孔，具有吸引用户的直接优势。

设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流.

区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。

性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。

界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？

做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试。

4．您认为做好测试用例设计工作的关键是什么？

白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果 ？

（补充）

黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。

不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题 （补充）

05. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

黑盒测试：

已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。

软件的黑盒测试意味着测试要在软件的接口处进行。

这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。

因此黑盒测试又叫功能测试或数据驱动测试。

黑盒测试主要是为了发现以下几类错误：

1、是否有不正确或遗漏的功能？

2、在接口上，输入是否能正确的接受？

能否输出正确的结果？

3、是否有数据结构错误或外部信息（例如数据文件）访问错误？

4、性能上是否能够满足要求？

5、是否有初始化或终止性错误？

测试方法，根据需求指定的测试计划和测试用例来测相应的功能和性能

---------------------------------------------------------------------------------------------------------------------------

白盒测试：

已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

软件的白盒测试是对软件的过程性细节做细致的检查。

这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。

通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。

因此白盒测试又称为结构测试或逻辑驱动测试。

白盒测试主要是想对程序模块进行如下检查：

1、对程序模块的所有独立的执行路径至少测试一遍。

2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。

3、在循环的边界和运行的界限内执行循环体。

4、测试内部数据结构的有效性，等等。

5.数据引用错误 ² 数据声明错误 ² 运算错误 ² 比较错误 ² 控制流程错误 ² 接口错误

² 输入/输出错误 ² 其他检查 ² 其他检查

常用测试方法：

所谓插桩，就是借助往被测程序中插入操作，来实现测试目的的方法。

（如常常加入打印语句，看执行后的效果是否为我们希望的结果），以及junit测试

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。

通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

单元测试是由程序员自己来完成，最终受益的也是程序员自己。

可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。

执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

------------------------------------------------------------------------------------------------------------------------------

集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。

它的最简单的形式是：

两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。

从这一层意义上讲，组件是指多个单元的集成聚合。

在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。

方法是测试片段的组合，并最终扩展进程，将您的模块与

其他组的模块一起测试。

最后，将构成进程的所有模块一起测试。

-------------------------------------------------------------------------------------------------------------------------------

系统测试是将经过测试的子系统装配成一个完整系统来测试。

它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。

（常见的联调测试）

系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

-----------------------------------------------------------------------------------------------------------------------------

验收测试是部署软件之前的最后一个测试操作。

验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

验收测试是向未来的用户表明系统能够像预定要求那样工作。

经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

06.测试计划工作的目的是什么？

测试计划工作的内容都包括什么？

其中哪些是最重要的？

软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。

借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

所以其中最重要的是测试测试策略和测试方法（最好是能先评审）

07.您认为做好测试计划工作的关键是什么？

1.明确测试的目标，增强测试计划的实用性，编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。

因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确

2．坚持“5W”规则，明确内容与过程

“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。

利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。

3．采用评审和更新机制，保证测试计划满足实际需求测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。

4.分别创建测试计划与测试详细规格、测试用例应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。

测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

08.您所熟悉的测试用例设计方法都有哪些？

请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

1．等价类划分

划分等价类:

等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:

测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:

有效等价类和无效等价类.

2．边界值分析法

边界值分析方法是对等价类划分方法的补充。

测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

3．错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法.错误推测方法的基本思想:

列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例.例如,在单元测试时曾列出的许多在模块中常见的错误.以前产品测试中曾经发现的错误等,这些就是经验的总结.还有,输入数据和输出数据为0的情况.输入表格为空格或输入表格只有一行.这些都是容易发生错误的情况.可选择这些情况下的例子作为测试用例

4．因果图方法

前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

09. 请以您以往的实际工作为例， 详细的描述一次测试用例设计的完整的过程。

就说最近的这次网站功能的测试吧

首先：

得到相关文档（需求文档和设计文档），理解需求和设计设计思想后，想好测试策略（测试计划简单点就OK了），考虑到测试环境，测试用例，测试时间等问题。

第二步：

设计测试用例，测试策略是：

把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：

这次的网站的输入数据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处理的，有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。

处理过程中，会经历3个步骤，网站才算完成了它的任务。

有3个步骤呢，就可以分别对  这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多50个用例。

界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示。

第三步：

搭建测试环境（为什么这个时候考虑测试环境呢？

因为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需要web服务器（Apache,tomcat），不过这次

需求呢，网站部分只用到了tomcat，所以只要有tomcat即可

第四步：

执行测试

10. 您以往是否曾经从事过性能测试工作？

如果有，请尽可能的详细描述您以往的性能测试工作的完整过程。

是的，曾经做过网站方面的性能测试，虽然做的时间并不久（2个月吧），当时呢，是有位网站性能测试经验非常丰富的前辈带着我一起做。

 性能测试类型包括负载测试，强度测试，容量测试等

负载测试：

负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。

   强度测试：

 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况

容量测试：

确定系统可处理同时在线的最大用户数

在网站流量逐渐加大的情况下，开始考虑做性能测试了，首先要写好性能测试计划，根据运营数据得出流量最大的页面（如果是第一次的话，一般是首页，下载页，个人帐户页流量最大，而且以某种百分比），

关注服务器的CPU使用情况，内存使用情况，服务器上线文切换平率，服务器磁盘读写速度，已经磁盘内存情况

关注客户端响应时间，关注客户点操作成功情况，关注客户端操作失败情况，关注客户端发起的并发是处理情况等，连续操作处理情况，

11. 您在从事性能测试工作时， 是否使用过一些测试工具？

Loadruner:

就用了破解版的lodarrunner进行测试

12. 您认为性能测试工作的目的是什么？

做好性能测试工作的关键是什么？

性能测试的概念-

在正常，峰值以及异常负载条件下，测试系统的各项性能指标；通过自动化的测试工具模拟进行。

性能测试的目的

1）评估系统的能力----测试中得到的负荷和响应时间数据可被用于验证所计划的模型的能力，并帮助作出决策。

2）识别体系中的弱点----受控的负荷被增加到一个极端水平，并突破它，从而修复体系的瓶颈或薄弱的地方。

3）系统调优---重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。

检测软件中的问题，长时间的测试执行可导致程序发生由于内存泄漏引起的失败，揭示程序中的隐含问题或冲突。

4）验证稳定性，可靠性---在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。

关键是对需求的理解能力，以及对性能测试要用的工具的掌握程度，要会用性能测试工具，以及对性能测试结果的分析能力，以及对性能调优要能给出自己的建议能力，这些都比较重要。

13. 在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？

如何提交高质量的软件缺陷（Bug）记录？

（bug的生命周期）

测试条件：

软件（平台、版本等）、硬件配置；重现步骤：

如何让开发人员重现你提的BUG。

测试现象/结论、分析、建议等；

这几条是最主要的。

此外，还应当尽量包括：

重要度、紧急度、BUG产生阶段（需求、设计、实现、文档）。

Bug的生命周期：

起始--发现BUG-提交BUG--修复BUG--回归BUG—关闭BUG--结束

14. 您以往所从事的软件测试工作中，是否使用了一些工具来进行软件缺陷（Bug）的管理？

如果有， 请结合该工具描述软件缺陷（跟踪管理的流程）。

在云计算的时候使用的是Bugzilla；

过程是：

根据测试用例测试软件，发现Bug过后，用测试经理分配的Bugzilla账号登陆Bugzilla，然后到bug提交界面。

找到测试功能目前的版本号，以及功能点，查看现在已经提交的Bug里面有没有类似或者相同的Bug,没有的话，把发现的Bug提交进去，提交的时候好像要填bug描述，重现步骤（测试步骤），bug类型，严重级别，以及目前bug的状态，提交的时候当然是状态新建等信息，提交过后告知测试组长，然后等待bug被处理，如果处理过后，有bug处理人员修改Bug的状态，以及解决方案和解决描述，等待其他功能测试完成过后，开发组会给一个修复Bug的版本，进行回归测试，如果bug问题解决，则关闭bug，并在bug的时候记录回归测试的结果。

否者，重新提交bug重复上述步骤，知道问题解决关闭bug

15.如何提高沟通的效率和改善沟通的效果？

维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？

沟通其实是一门艺术，好的沟通要懂得配合天时地利人和，根据不同人的性格选择不同的表达方式尤其重要……

16. 在您以往的测试工作中， 最让您感到不满意或者不堪回首的事情是什么？

您是如何来对待这些事情的？

又一次测有findbugs插件测试系统里面连接池泄露问题，测试完了过后连接池泄露比较多，这个肯定不能让客户知道，因为这样侧面反应我们系统存在的问题有点多，上线版本还不太稳定，测试结果一出来，我要通过QQ发送个项目经理，结果在发送的时候突然来了个电话，同时客户又发了个QQ信息过来咨询问题，结果一不小心发到客户那里去了……

17.你对测试最大的兴趣在哪里？

为什么？

最大兴趣就是能断了沟通能力和培养一些打破常规的方法思维模式，锻炼沟通能力是因为作为测试，既要和开发沟通，又要和客户沟通，还要跟项目经理，测试经理沟通，如果清楚的表达自己发现的问题，和自己觉得可行的解决方案，以及要让其他明白，而且接收，其实是一种沟通交际能力的断了。

然后打破常规思维模式的话，在做测试的时候要不仅局限于常规的问题出现的情况，要去考虑非常规情况下，会出现的异常或者情况，这让自己在生活中的思考方式或者说思维方式可以往多方面考虑。

18. 你的测试职业发展是什么？

既然决定要重新认定往一个方向发展，目前决定的测试方向，那么我觉得如果能到公司，现在做一个职业发展计划的话，应该是先进入公司测试部门，花最短的时间去了解公司的业务架构，了解平时测试的主要工作，先从自己的测试的老本行功能测试为基础开始，主动去学习一个高级工程师该学的技能知识和考虑问题的思维模式去发展，提升自己的能力，符合自己能力的薪金报酬.

19. 你自认为测试的优势在哪里？

1.进入做测试的时间早，大三就就开始做测试，对测试基础有一定了解

2.在项目上有一定的沟通能力，和对问题不仅仅是抛出问题，还有能主动去想解决问题的习惯

3.有一定的开发基础，在现场做开发，运维，和实施等经验都对我将要做的测试有一定帮助

4.学习能力比较强，包括像PS的自学，AXURE，mandmager的软件的使用都是自学的，上课或者平时根本没有人会教你，都靠自学

20. 你以前工作时的测试流程是什么？

公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。

我说下我1年来不断改正（自己总结，吸取同行的方法）后的流程吧。

需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定（出一份确定的需求文档）－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。

21. 当开发人员说不 是BUG时，你如何应付？

开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。

二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？

如果被用户发现或出了问题，会有什么不良结果？

程序员可能会给你很多理由，你可以对他的解释进行反驳。

如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。

其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。

如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

22.你为什么想离开目前的职务？

1.现在维护，驻扎客户现场，感觉不到公司企业文化，感觉不到归属感，现场两个人驻场，没有领导带或者专门的培训，对自己的提升和技能的积累到一个瓶颈。

很难提升

2.做外包感觉不稳定，万一哪天甲方和公司签合约了，自己不想回总部，那么将失去工作

3.觉得自己也飘忽不定，想在哪里买房都觉得不合适。

23.你对我们公司了解有多少？

从各种途径去了解一下姚应聘的公司吧

24.为什么我们应该录取你？

因为是安起心来的，既然决定要来，肯定是考虑好了，做了决定才来的，抱着来了就要做好，认真负责的态度而来，这个也是自己为人处世的原则，要做的事，绝对不敷衍，绝对不粗心大意，这个是对自己负责也是对别人负责。

25.单元测试、集成测试、系统测试的侧重点是什么？

前面提到过

26.设计用例的方法、依据有那些？

等价划分，边界值，错误推断，因果图法，依据：

需求分析，概要设计，详细设计等文档

27.基于WEB信息管理系统测试时应考虑的因素有哪些？

1.链接测试：

１．测试所有连接是否按指示的那样确实连接到了该连接的页面，

２．测试所连接的也面是否存在，

３．保证ＷＥＢ应用系统上没有孤立的页面．只能在集成测试阶段完成

2.表单测试：

用户给信息系统管理员提交信息时，要测试提交操作的完整性，以校验提交给服务器的信息的正确性

3.Cookies测试：

Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息．如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。

测