其他

1. 好的测试工程师应具备的素质？

沟通能力、移情能力、技术能力、自信心、外交能力、幽默感、很强的记忆力、耐心、怀疑精神、自我督促、洞察力。

2. 软件测试给你带来什么样的快乐？

测试可以给我带来很多快乐，如果测试出一个项目缺少东西，我会很高兴，因为我对自己的工作有了新的认识，也为公司做了效益；如果测试出一个项目没有问题，我也很高兴，因为同事们都在努力，大家都希望为公司做贡献，这就是一个很强大的团队，这是一件多么另人振奋的事情啊！

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

因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比 ISO 质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。软件测试在整个一个团队中占有非常重要的地位，具体来说就是测试是一个发现软件错误的过程，执行软件测试会以最少的人力和时间，系统的找到软件存在的缺陷和错误，建立起开发人员和使用者对软件的信心。

4. 你在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？

测试从事过 web 测试，后台测试，客户端软件，进行功能测试，性能测试，编写测试工具，文档的管理等，比较擅长编写测试用例和进行功能测试。

5. 请介绍一下你的项目

从几个部分来说，先项目规模，包括项目代码规模，需求规模、用例规模，工作量，进度，质量和成本，然后是整体的测试流程，然后再是角色与职责，接下来是在项目中自己的特色，比如做得最好的是、遇到最大的困难时（如何解决）、最差的是，最后是心得体会。

6. 测试过程中，遇到阻塞时，该如何推进？

功能基本可以走通但是 bug 太多

因为如果是以此为理由，打回去给开发，理由并不完全站得住。一个是大家对 bug 多的标准不一致，我们说 bug 多，开发不一定认可。这个时候我们需要针对 bug 的情况进行一下分析：

bug 集中，且可以跟其他模块切开测试发现的 bug 是集中在整个功能的某一个模块中，该模块与整个功能的其他模块可分割，可以单独测试。如果是整个功能都基本正常，只有其中的一个模块有问题，那么可以先对其他模块进行测试， bug 较集中的模块提交给开发重新对代码进行排查，待重新提测后再进行测试，对整体测试时间无影响。

bug 集中，但是跟其他模块关联性强测试发现的 bug 是集中在整个功能的某一个模块中，该模块与整个功能的其他模块关系较密切，无法单独测试。对其他模块进行测试，只打回这一个模块给开发，待开发重新代码 review 后，确认影响范围重新测试。对整体测试时间有影响，但是影响不大，需要在确认测试范围的时候花费一些时间。

bug 不聚类，多数 bug 都不是严重问题，关联性不强，bug 分散在整个功能的的各个模块，基本是因为整体代码质量不高引起的。但是 bug 都不是什么严重的问题，集中在 UI 显示等模块，这个时候测试需要全功能测试，待开发修复完 bug 后进行修复问题的二轮测试。增加二轮测试，对整体测试时间有影响。

bug 不聚类，半数 bug 都是较严重的问题，bug 分散在整个功能的的各个模块，基本是因为整体代码质量不高引起的。针对这种情况只能是全部打回去给开发，整体代码 review 后重新提测。提测时间 delay，对整体测试时间有影响。
功能实现的与策略不一致

有些时候，开发提测，产品也经过验收通过，但是到测试手里一看，实现跟需求明显是有差异的，这个时候应该怎么办？我们能做的，一定是第一时间找产品确认“开发做成这样你知道吗？”，一般会有两种结果。
- 产品认可开发的实现。
  
  如果是这种情况，我们那就让产品发需求变更，我们按照变更后的需求对功能进行测试。这种处理方法对整体测试时间基本无影响，只需要增加一个新需求确认的环节。
- 产品对开发的实现不从，一定要改回来。
  
  这种情况那就没办法了，打回去重新按照需求实现，然后重新提测吧。提测时间 delay，对整体测试时间有影响。
出现崩溃等异常完全无法继续测试下去

这种情况没什么好讨论的，直接打回去，等开发修复完全后再重新测试。但是前面已经测试过的部分，需要跟开发确认，如果修改后无影响的，可以不必再次从头开始测试。

7. 你们以前测试的流程是怎样的？

测试计划－测试用例设计－测试执行－测试分析报告

8. 为什么选择测试这行？

它是一个新兴的行业，有发展潜力，而且很锻炼人，需要掌握更多的技能，比做开发要更难

9. 如果时间不够，无法进行充分的测试怎么办？

使用风险分析，确定测试的重点。

由于很少有机会对一个应用软件进行所有可能的测试（包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西），对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。需要考虑下列因素：

对于该项目的用途而言，哪种功能最重要？
哪种功能对用户最明显？
哪种功能对安全影响最大？
哪种功能对用户最有用？
对客户来说，该应用软件的哪个部分最重要？
在开发过程中，该应用软件的哪个部分可以最先测试？
哪一部分代码最复杂，容易导致出现错误？
哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的？
哪一部分程序与过去项目中引起问题的部分相类似 / 有关？
哪一部分程序与过去项目中需要大量维护的部分相类似 / 有关？
需求和设计的那些部分不清楚或不容易读？
开发人员认为在应用软件中哪些部分是高风险的？
哪些问题能造成最差的发行？
哪些问题最能引起用户抱怨？
哪些测试可以容易地覆盖多种功能？
哪些测试在覆盖高风险部分的测试时使用时间最少？

10. 你是否了解以往所工作的企业的软件测试过程？如果了解，请试述在这个过程中都有哪些工作要做？分别由哪些不同的角色来完成这些工作？

软件测试部门配合系统分析人员软件需求分析讨论，并根据需求说明书制定《项目测试计划》，编写测试用例，建立测试环境。软件测试人员负责软件开发部门的新产品测试及原有产品的升级测试，负责软件问题解决过程跟踪，负责软件开发文档开发工作的规范化及管理开发部门的产品文档，制作用户手册及操作手册，负责产品的上线测试，监督软件开发过程的执行，提高产品质量。需求人员连同系统分析人员 & 测试人员开会讨论需求。系统分析人员写出需求分析说明，并连同系统分析人员 & 测试人员 & 需求人员开会讨论可行性。系统分析人员写出详细设计说明书，程式人员编码，给出系统流程图。交与测试人员，测试人员给出 Bug 统计表。

11. 你所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）

有功能测试，性能测试，可靠性测试，安全性测试，负载测试，压力测试，安装 / 卸载测试，启动 / 停止测试，兼容性测试，互连测试，文档测试，恢复测试，回归测试，可使用性测试，容量测试。功能测试只对软件的功能是否满足用户需求来做测试。性能测试需要和压力和负载测试联合起来。

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

优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但测试需要的基本技能我有信心在工作中得以发挥。

13. 你在测试中发现了一个 bug，但是开发经理认为这不是一个 bug。你应该怎么做？

首先，将问题提交到缺陷管理库里面进行备案。然后，要获取判断的依据和标准：

根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；

如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；根据用户的一般使用习惯，来确认是否是缺陷；

与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；

合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并由上级做出决定。

14. 你是如何制定时间进度表的？

首先确定三个大的时间段项目开始时间项目结束时间开发转系统测试时间，在根据测试各个阶段的工作量和项目资源制定计划、设计、执行、评估、验收阶段的时间。设计和执行的时间一般较多。

15. 介绍一下整体项目流程

公司将测试分为了五个阶段：计划、设计、执行、验收、评估。

在测试计划阶段我们主要工作是编写测试计划对项目做一个整体的规划其中进度的安排、人力物力的分配、总体测试策略的制定和风险的评估比较重要。设计阶段我们主要是编写测试策略和测试用例。在执行阶段，当我们拿到开发转过来的版本以后，首先是安装测试环境，然后执行用例。发现缺陷我们会提交缺陷报告，然后交给开发人员进行修改，之后进行循环测试！至于说具体系统测试会循环多少轮，是根据项目实际情况和版本的质量来决定的。在评估阶段我们主要是编写测试总结报告，其中对测试过程的总结和版本质量的评价要体现在测试总结报告里面最后就是软件的验收，验收阶段我们会和客户一同进行产品的最后检查！

16. 你是如何制定测试过程中的时间进度表的？

确定项目开始、截止和转测试的时间，然后根据我们的经验去合理划分这五个阶段的时间，在设计和执行阶段比重比较大

17. 测试工作进行到一半时，发现时间不够，你是如何处理的？

先看加班、加人能不能解决，如果不行就找重点，提出优先级高的用例执行
向上级申请加派测试员
和客户协商，推迟产品的发布时间

18. 怎样保证你所负责的模块通过了测试？

首先是了解用户的需求，设计好的测试用例，严格的进行用例的评审，认真的执行测试用例，对自己提交的 Bug 进行详细的描述。反复测试增强测试的准确性，通过冒烟回归随机测试挖掘缺陷提高测试工作质量，把各个模块整体运行发现未曾出现的错误，完善测试用例。

19. 软件测试人员和测试组长的职责分工

普通测试人员：

创作相关的测试计划和测试案例识别可自动测试的区域
参与组内的测试计划和测试案例以及测试脚本分析工作
手动或自动测试
按照需求规格说明查证并验证各项功能发现并报告 bug，跟踪其状态
初步评估 bug 对产品其他部分的影响

测试组长：

确定测试的策略评估 bug 对用户的影响跟踪关键 bug 状态
管理测试工作和对象的资源参与面试新人
交流状态和存在问题，并驱动问题的解决促进组内的交流

20. 如果你是测试组长你是如何对项目及组员进行管理的？

首先要充分了解要测试的项目，参考开发文档同时与开发人员及时沟通，要对产品十分的熟悉。员工方面多与员工沟通，了解员工的擅长的工作，根据员工擅长的工作进行分配，能力强的多分配，这样可以说测试工作快速稳定的进行！最终的测试工作就会一帆风顺！

21. 什么时候开始搭建测试环境？由谁搭建？如何进行产品的集成？

测试开始之前搭建测试环境由测试工程师搭建，产品的集成由开发人员完成

22. 你所做的项目中采用了哪些测试方法？进行回归测试吗？

功能测试
界面测试
安装测试
性能测试
进行了回归测试，一般在缺陷修复之后进行验证的过程中进行回归测试

23. 上级如何检查你的工作？

查看项目周报

开周例会

24. QA 是如何检查你的工作的？

检查项目过程及文档

参与周例会

25. 在你所做的项目中有需要测试的项目过程吗？有，请介绍

有啊，我们在 XXX 项目中都进行了测试。

在测试过程中，我们先根据用户需求进行测试计划，编写测试用例，在开发部完成项目并进行产品集成，交由配置管理员纳入配置库之后，我们从配置库签出安装包，搭建测试环境，开始进行测试，测试过程中我们提交缺陷，开发人员修复缺陷，直到所有缺陷修改完毕，做测试总结。最终完成测试过程。

26. 怎样保障你所负责的模块通过了测试？

仔细分析需求，制定测试计划与策略，详细编写测试用例因实际情况合理修改并执行，进过严格的评审，总结出真实测试报告。

首先在设计阶段要保证所设计的用例的覆盖率，发现缺陷的能力；在提交缺陷报告时要对缺陷进行详细确切的描述，方便开发人员进行修复；修复后认真进行回归测试，直到产品符合用户需求。

通过反复测试来增强测试的准确性
还可以通过冒烟、回归、随机测试来挖掘冒烟发现的缺陷，提高测试工作的质量
把各个模块整体运行时来发现未曾出现的错误
完善测试用例

27. 你是如何了解到你说项目中的成员？

在项目立项公告中

28. 是否成立了独立的测试组？测试人员在项目中测试的职责？

是。验证需求是否正确实现、发现软件中存在的缺陷、确认软件缺陷被修复。

29. 测试结果分析如何？如何产生和被记录？

在项目测试之后，我们对缺陷进行了统计分析，并生成了测试报告文档。在此次项目中所有的缺陷都已修复并关闭。所有的缺陷都记录在缺陷管理工具中，并导出了缺陷报告

30. 认为软件测试过程中较常见的困难是什么？如何有效克服这些困难？（根据自己实际测试中遇到的情况来写的）

Bug 的重现问题：有些 Bug 只是偶尔出现的，根本就不知道具体需要什么条件才能重现 Bug。解决方法：将不能重现的 Bug，利用截图的方式记录下来。并说明一系列的操作步骤
Bug 的更新：旧的 Bug 修改好之后，很多时候会引发更多 Bug 的出现。解决方法：对更新的功能模块重点的测试之后，再重新测试和更新的功能密切的模块，会不会产生新的 Bug
与开发人员的沟通和对业务流程理解的分歧，经常缺少需求文档。解决方法：根据需求说明书和 Bug 情况，多多和开发人员进行交流

31. 在实际项目中你是如何做测试计划？

在做计划之前，我们要先了解这个项目的大致情况：比如测试的是什么产品？是新程序还是维护升级的？是独立程序还是由多个小程序组成的？产品的质量目标是什么？

产品的功能需求和性能指标必须得到所有人的一致认可。为了深入了解项目，测试人员应该及早介入项目，对工作量的大小、时间点的安排作出了解。

32. 你所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用

等价类划分
边界值分析法
错误推测法
因果图方法

有黑盒和白盒两种测试种类，黑盒有等价类划分法，边界分析法，因果图法和错误猜测法。白盒有逻辑覆盖法，循环测试路径选择，基本路径测试。

例子：在一次输入多个条件的完整性查询中。利用等价类划分法则和边界分析法则，首先利用等价类划分法，可以一个或多个结果是 OK 的测试用例，然后确认多个 NG 的测试用例，然后利用边界值分析法，可以对结果分别是 OK 和 NG 的测试用例进行扩展和补充。

33. 你认为做好测试用例设计工作的关键是什么？

明确测试的目标，增强测试计划的实用性
坚持“5W”规则，明确内容与过程，'what''why''when''where''how'
采用评审和更新机制，保证测试计划满足实际需求
分别创建测试计划与测试详细规格、测试用例

盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题

34. 在你以往的工作中，一条软件缺陷（或者叫 Bug）记录都包括哪些内容？如何提交高质量的软件缺陷（Bug）记录？

检测时间，系统环境，硬体环境，严重程度，程式版本，确认人，功能模块，问题描述，详细操作步骤，是否会重现。

问题描述和详细操作步骤要尽可能的详细。Bug 应该尽量用书面语，对与严重程度比较高的缺陷要在相同环境下在测试一遍。

35. 你在五年内的个人目标和职业目标分别是什么？

从现在起的五年之内，我希望能够在一个很好的职位上待几年，而且最好有一次晋升，然后就期待着下一步。不管是向上提升，还是在企业内横向调动，对我个人来说，我希望找到一家企业——一家愿意做相互投入的企业——待上一段时间。

36. 怎样做出自己的职业选择？

在上大学四年级前的那个夏天，我决定集中精力在某一领域谋求发展。尽管我是学商业的，但是我不知道自己最终会从事哪一行业的工作。我花了一定的时间考虑自己的目标，想清楚了自己擅长做的事情以及想从工作中得到的东西，最后我得出了一个坚定的结论，那就是这个行业是最适合我的。

37. 离职原因

每次面试必问的问题大概就是离职原因，建议不要提到上家公司不好或者是领导不好这些比较消极的原因，可以给面试官一些无关痛痒的原因比如想找一个离家近的公司或者因为搬家了上一家公司离家太远不太方便等。不管你离职的真正原因是什么都要回答积极的方面。

38. 面试官一般会问，您还有什么想问的吗？

一般分几种情况：

第一种是双方满意，先表示感谢，然后积极主动的提问，比如，确认是否有复试及时间，刚才面试中自己有哪些不足（表现你的上进心）
第二种情况是双方感觉一般般，自己感觉很 low, 基本的套路是，先表示感谢，坦白地说对自己今天表现不是非常满意，还可以表现得更好，还想得到这个机会，询问面试官能否给一些建议（表现出你的学习意愿）
第三种情况是面试情况非常糟糕，这种情况下，也要先表示感谢。基本的思路是，分两种情况
1. 面试官人不错技术很好，表达你的学习意愿和想进公司的意愿
2. 面试官技术不太好，但是人很差，不尊重人，什么也不说，直接走人

其他