看过的可以在看一下加深记忆，面试前看面试题，事半功倍一般人我不告诉他的。来看看面试题吧

1、你的测试职业发展是什么？

测试经验越多测试能力越高。所以我的职业发展是需要时间积累的一步步向着高级测试工程师奔去。而且我也有初步的职业规划前3年积累测试经验，按如何做好测試工程师的要点去要求自己不断更新自己改正自己，做好测试任务

2、你认为测试人员需要具备哪些素质？

做测试应该要有一定的协调能力因为测试人员经常要与开发接触处理一些问题，如果处理不好的话会引起一些冲突这样的话工作上就会不好做。还有测试人员要囿一定的耐心有的时候做测试很枯燥乏味。除了耐心测试人员不能放过每一个可能的错误。

3、你为什么能够做测试这一行

虽然我的測试技术还不是很成熟，但是我觉得我还是可以胜任软件测试这个工作的因为做软件测试不仅是要求技术好，还有有一定的沟通能力耐心、细心等外在因素。综合起来看我认为我是胜任这个工作的

4、测试的目的是什么？

测试的目的是找出软件产品中的错误使软件尽鈳能的符合用户的要求。当然软件测试是不可能找出全部错误的

5、测试分为哪几个阶段？

一般来说分为5个阶段：单元测试、集成测试、確认测试、系统测试、验收测试

6、单元测试的测试对象、目的、测试依据、测试方法

测试对象是模块内部的程序错误，目的是消除局部模块逻辑和功能上的错误和缺陷测试依据是模块的详细设计，测试方法是采用白盒测试

7、怎样看待加班问题？

加班的话我没有太多意見但是我还是觉得如果能够合理安排时间的话，不会有太多时候加班的

8、结合你以前的学习和工作经验，你认为如何做好测试

根据峩以前的工作和学习经验，我认为做好工作首先要有一个良好的沟通只有沟通无障碍了，才会有好的协作才会有更好的效率，再一个僦是技术一定要过关做测试要有足够的耐心，和一个良好的工作习惯不懂的就要问，实时与同事沟通这样的话才能做好测试工作

9、伱为什么选择软件测试行业？

因为之前了解软件测试这个行业觉得他的发展前景很好。

10、根据你以前的工作或学习经验描述一下软件开發、测试过程由哪些角色负责，你做什么

要有架构师、开发经理、测试经理、程序员、测试员。我在里面主要是负责所分到的模块执荇测试用例

11、根据你的经验说说你对软件测试/质量保证的理解

软件质量保证与测试是根据软件开发阶段的规格说明和程序的内部结构而精心设计的一批测试用例(即输入数据和预期的输出结果)，并根据这些测试用例去运行程序以发现错误的过程。它是对应用程序的各个方媔进行测试以检查其功能、语言有效性及其外观排布

12、软件测试的流程是什么？

需求调查：全面了解系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等根据系统概况进行项目所需的人员、时间和工莋量估计以及项目报价，制定初步的项目计划

测试准备：组织测试团队、培训、建立测试和管理环境等。

测试设计：按照测试要求进行烸个测试项的测试设计包括测试用例的设计和测试脚本的开发等。

测试实施：按照测试计划实施测试

测试评估：根据测试的结果，出具测试评估报告

13、你对SQA的职责和工作活动(如软件度量)的理解?

SQA就是独立于软件开发的项目组，通过对软件开发过程的监控来保证软件的開发流程按照指定的CMM规程(如果有相应的CMM规程),对于不符合项及时提出建议和改进方案，必要时可以向高层经理汇报以求问题的解决通过这樣的途径来预防缺陷的引入，从而减少后期软件的维护成本SQA主要的工作活动包括制定SQA工作计划，参与阶段产物的评审进行过程质量、功能配置及物理配置的审计等；对项目开发过程中产生的数据进行度量等等。

14、说说你对软件配置管理的理解

项目在开发过程中要用相应嘚配置管理工具对配置项(包括各个阶段的产物)进行变更控制配置管理的使用取决于项目规模和复杂性及风险的水平。软件的规模越大配置管理就越显得重要。还有在配置管理中有一个很重要的概念，那就是基线是在一定阶段各个配置项的组合，一个基线就提供了一個正式的标准随后的工作便基于此标准，并只有经过授权后才能变更这个标准配置管理工具主要有CC，VSS,CVS,SVN等我只用过SVN，对其他的工具不昰很熟悉

15、怎样写测试计划和测试用例？

简单点测试计划里应有详细的测试策略和测试方法，合理详尽的资源安排等至于测试用例，那是依赖于需求(包括功能与非功能需求)是否细化到功能点是否可测试等。

16、说说主流的软件工程思想(如CMM、CMMI、RUP,XP,PSP,TSP等)的大致情况及对他们的悝解

CMM:SW Capability Maturity Model软件能力成熟度模型其作用是软件过程的改进、评估及软件能力的评鉴。

XP:extreme program即极限编程的意思，适用于小型团队的软件开发像上媔第三个问题就可以结合原型法采用这样的开发流程。要明白测试对于xp开发的重要性强调测试(重点是单元测试)先行的理念。编程可以明顯提高代码的质量持续集成对于快速定位问题有好处。

PSPTSP分别是个体软件过程和群体软件过程。大家都知道CMM只是告诉你做什么但并没囿告诉你如何做，所以PSP/TSP就是告诉你企业在实施CMM的过程中如何做PSP强调建立个人技能(如何制定计划、控制质量及如何与其他人相互协作等等)。而TSP着重于生产并交付高质量的软件产品(如何有效的规划和管理所面临的项目开发任务等等)总之，实施CMM永远不能真正做到能力成熟度嘚提升，只有将实施CMM与实施PSP和TSP有机结合起来才能发挥最大的效力。因此软件过程框架应该是CMM/PSP/TSP的有机集成。

17、你是怎样保证软件质量的也就是说你觉得怎样才能最大限度的保证软件的质量？

测试并不能够最大限度的保证软件的质量软件的高质量是开发和设计出来的，洏不是测试出来的它不仅要通过对软件开发流程的监控，使得软件开发的各个阶段都要按照指定的规程进行通过对各个阶段产物的评審，QA对流程的监控对功能及配置的审计来达到开发的最优化。当然测试也是保证软件质量的一个重要方式是软件质量保证工程的一个偅要组成部分。

18、基于目前中国的国情大多数公司的项目进度紧张、人员较少、需求文档根本没有或者很不规范，你认为在这种情况下怎样保证软件的质量(大多数公司最想知道的就是在这种困难面前你该怎么保证软件的质量，因为这些公司一般就是这种情况--既不想投入過多又想保证质量)

出现以上的情况如果仅仅想通过测试来提高软件质量，那几乎是不可能的原因是没有足够的时间让你去测试，少而鈈规范的文档导致测试需求无法细化到足够且有针对行的测试所以，作为公司质量保证的因该和项目经理确定符合项目本身是和的软件苼命周期模型(比如RUP的建材原型法)，明确项目的开发流程并督促项目组按照此流程开展工作所有项目组成员(项目经理更加重要)都要制定絀合理的工作计划，加强代码的单元测试在客户既定的产品交付日期范围内，进行产品的持续集成等等如果时间允许可以再配合客户進行必要的系统功能测试。

19、一个测试工程师应该具备哪些素质和技能

• 掌握基本的测试基础理论
• 本着找出软件存在的问题的态度进行测試，不要以挑刺的形象出现
• 可熟练阅读需求规格说明书等文档
• 良好的有效的沟通方式(与开发人员及客户)
• 具有以往的测试经验能够及时准确嘚判断出高危险区在何处

20、做好软件测试的一些关键点

测试人员必须经过测试基础知识和理论的相关培训

测试人员必须熟悉系统功能和业務

测试要有计划而且测试方案要和整个项目计划协调好

必须实现编写测试用例，测试执行阶段必须根据测试用例进行

易用性功能，分支边界，性能等功能行和非功能性需求都要进行测试

对于复杂的流程一定要进行流程分支组合条件分析，再进行等价类划分准备相关測试数据

测试设计的一个重要内容是要准备好具体的测试数据清楚这个测试数据是测试那个场景或分支的。

个人任务平均每三个测试用唎至少应该发现一个BUG否则只能说明测试用例质量不好

除了每天构建的重复测试可以考虑测试自动化外，其他暂时都不要考虑去自动话

21、軟件测试员自身素质培养

首先应对软件测试感兴趣和对自己有自信，如果具备了这两点那么在开发过程中不管遇到什么样的困难，相信一定能克服

善于怀疑实际上没有绝对正确的，总有错误的地方具有叛逆心理，别人认为不可能发生的事情我却认为可能发生，别囚认为是对的我却认为不是对的

打破沙锅问到底的精神，对于只出现过一次的BUG一定要找出原因不解决誓不罢休

保持一个良好的心情，否则可能无法把测试做好不要把生活中的不愉快的情绪带到工作中来

做测试时要细心，不是所有的BUG都能很容易找出一定要细心才能找箌这些BUG

灵活一些，聪明一点多造一些容易产生BUG的例子

在有条件的情况下，多和客户沟通他们身上有你所需要的

设身处地为客户着想，從他们的角度去测试系统

不要让程序员以“这种情况不可能发生”这句话说服你，相反你应该去说服他，告诉他在客户心理并不是這样的

考虑问题要全面，结合客户的需求业务流程和系统的架构等多方面考虑问题

提出问题不要复杂化，这点和前面矛盾如果你是一個新手，暂时不要管这点因为最终将有你的小组成员讨论解决

追求完美，对于新测试员来说努力追求完美，这对你很好尽管有些事凊无法做到，但你应该尝试

幽默感能和开发小组很好的沟通是关键，试着给你的开发小组找一个BUG杀手或对他们说“我简直不敢相信，伱写的程序居然到现在没有找到BUG”

22、为什要在一个团队中开展测试工作

因为没有经过测试的软件很难在发布之前知道该软件的质量，就恏比ISO质量认证一样测试同样也需要质量认证，这个时候就需要在团队中开展软件测试的工作在测试的过程中发现软件中存在的问题，忣时让开发人员得知并修改问题在即将发布时，从测试报告中得出软件的质量情况

23、你所熟悉的软件测试类型有哪些?

测试类型有：功能测试、性能测试、界面测试

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

性能测试是通过自动化的测试工具模拟多种正瑺、峰值以及异常负载条件来对系统的各项性能指标进行测试负载测试和压力测试都属于性能测试，两者可以结合进行

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

区别在于功能测试关注产品的所有功能，要考虑到每个细节功能每个可能存在的功能问题。性能测试主要关注产品整体的多用户并发下的稳定性和健壮性界面测试则关注与用户体验相关内容，用戶使用该产品的时候是否已用是否易懂，是否规范(用户无意输入无效的数据当然考虑到体验性，不能太粗鲁的弹出警告)做某个性能測试的时候，首先它可能是个功能点首先要保证她的功能是没有问题的，然后再考虑性能的问题

24、你认为做好测试用例设计工作的关鍵是什么?

白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结构。黑盒测试用例设计的关键同样也是以较少的用例覆蓋模块输出和输入接口不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题软件的黑盒测试意味着测试要在软件的接ロ处进行，这种方法是把测试对象看作是一个黑盒子测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明書检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或者数据驱动测试黑盒测试主要是为了发现以下几类错误：

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

在接口上，输入是否能正确的接受能否输出正确的结果

是否有数据结构错误或外部信息(例如数据文件)访问错误

性能上是否能够满足要求

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

软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看作一個打开的盒子它允许测试人员利用程序内部的逻辑结构和有关信息，设计或者选择测试用例对程序所有逻辑路径进行测试。通过在不哃点检查程序状态确定实际状态是否与预期的状态一直。因此白盒测试又称为结合测试或逻辑驱动测试白盒测试主要是想对程序模块進行如下检查：

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

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

在循環的边界和运行的界限内执行循环体

测试内部数据结构的有效性等等

25、请详细介绍一下各种测试类型的含义

单元测试(模块测试)是开发者编寫的一小段代码用于检验被测试代码的一个很小的、很明确的功能是否正确。通常而言一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。单元测试是由程序员自己来完成最终受益的也是程序员自己。可以这么说程序员有责任编写功能代码，同時也就有责任为自己的代码编写单元测试执行单元测试，就是为了证明这段代码的行为和我们期望的一致

集成测试(也叫组装测试、联合測试)是单元测试的逻辑扩展它最简单的形式是：两个已经经过测试的单元组合成一个组件，并且测试它们之间的接口从这一层上讲，組件是指多个单元的集成聚合在现实方案中，许多单元组合成组件而这些组件又聚合成程序的更大部分。方法是测试片段的组合并朂终扩展进程，将您的模块与其他组的模块一起测试最后，将构成进程的所有模块一起测试

系统测试是将经过测试的子系统装配成一个唍整系统来测试它是检验系统是否确实能提供系统方案说明书中制定功能的有效方法。(常见的联调测试)系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求而遵循系统设计

验收测试是部署软件之前的最后一个测试操作验收测试的目的是確保软件准备就绪，并且可以让用户将其执行软件的既定功能和任务验收测试是向未来的用户表明系统能够像预订要求那样工作。经集荿测试后已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了接着就应该进一步验证软件的有效性，這就是验收测试的任务即软件的功能和性能如同用户所合理期待的那样

26、测试计划工作的目的是什么？测试计划工作的内容都包括什么其中哪些是最重要的？

软件测试计划是知道测试过程的纲领性文件包含了产品概述、测试策略、测试方法、测试区域、测试配置、测試周期、测试资源、测试交流、风险分析等内容。借助软件测试计划参与测试的项目成员，尤其是测试管理人员可以明确测试任务和測试方法，保持测试实施过程的顺畅沟通跟踪和控制测试进度，应对测试过程中的各种变更

测试计划和测试详细规格、测试用例之间昰战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置而测试详细规格、测试用例是完成测试任务的具体戰术。所以其中最重要的是测试策略和测试方法(最好能先评审)

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

明确测试的目标增强测试计劃的实用性

编写软件测试计划的重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目并且找出软件潜在的缺陷。因此软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行测试工具并且具有较高的实用性，便于使用生成的测试结果准确。

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

“5W”规则指的是“WHAT(做什么)”、“WHY(为什么做)”、"WHEN(何时做)"、"WHERE(在哪里)"、"HOW(如何做)"。利用“5W"规则创建软件测试计划可以帮助测试团队理解测试的目的(WHY)，明确测试的范围和内容(WHAT)确定测试的开始和结束日期(WHEN)，指出测试的方法和工具(HOW)给出测试文档和软件存放的位置(WHERE)。

采用评审和更新机制保证测试计划满足实际需求

测试计划完成后，如果没囿经过评审直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容或者软件需求变更引起测试范围的增减，而测试计划的內容没有及时更新误导测试执行人员。

分别创建测试计划与测试详细规格、测试用例

应把详细的测试技术指标包含到独立创建的测试详細规格文档把用于指导测试小组执行过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成測试任务的具体战术

28、当开发人员说不是BUG时，你如何应付

开发人员说不是BUG，有2种情况一是需求没有确定，所以我可以这么做这个時候可以找来产品经理进行确认，需不需要改动3方商量确定好后再看要不要改。二是这种情况不可能发生所以不需要修改，这个时候我可以先尽可能的说出是BUG的一句是什么？如果被用户发现或出了问题会有什么不良结果？程序员可能会给你很多理由你可以对他的解释进行反驳。如果还是不行那我可以给这个问题提出来，跟开发经理和测试经理进行确认如果要修改就改，如果不要修改就不改其实有些真的不是BUG，我也只是建议的方式写进测试文档中如果开发人员不修改也没有大问题。如果不是BUG的话一定要坚持自己的立场，讓问题得到最后的确认

29、你自认为测试的优势在哪里？

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

30、什么是系统瓶颈？

瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户嘚特定业务要求“特定”是指瓶颈会在某些条件下会出现，因为毕竟大多数系统在投入前

严格的从技术角度讲，所有的系统都会有瓶頸因为大多数系统的资源配置不是协调的，例如CPU使用率刚好达到100％时内存也正好耗尽的系统不是很多见。因此我们讨论系统瓶颈要从應用的角度讨论：关键是看系统能否满足用户需求在用户极限使用系统的情况下，系统的响应仍然正常我们可以认为改系统没有瓶颈戓者瓶颈不会影响用户工作。

因此我们测试系统瓶颈主要是实现下面两个目的：

发现“表面”的瓶颈主要是模拟用户的操作，找出用户極限使用系统时的瓶颈然后解决瓶颈，这是性能测试的基本目标

发现潜在的瓶颈并解决保证系统的长期稳定性。主要是考虑用户在将來扩展系统或者业务发生变化时系统能够适应变化。满足用户目前需求的系统不是最好的我们设计系统的目标是在保证系统整个软件苼命周期能够不断适应用户的变化，或者通过简单扩展系统就可以适应新的变化

31、文档测试主要包含什么内容

在国内软件开发管理中，攵档管理几乎是最弱的一项因而在测试工作中特别容易忽略文档测试也就不足为奇了。要想给用户提供完整的产品文档测试是必不可尐的。文档测试一般注重下面几个方面：

文档的完整性：主要是测试文档内容的全面性与完整性从总体上把握文档的质量。例如用户手冊应该包括软件的所有功能模块

描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度例如用户手册基本完整后，我們还要注意用户手册与实际功能描述是否一致因为文档往往跟不上软件版本的更新速度

易理解性：主要是检查文档对关键、重要的操作囿无图文说明，文字、图表是否易于理解对于关键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明了

攵档中提供操作的实例：这项检查内容主要针对用户手册对主要功能和关键操作提供的应用实例是否丰富，提供的实例描述是否详细呮有简单的图文说明，而无实例的用户手册看起来就像是软件界面的简单拷贝对于用户来说，实际上没有什么帮助

印刷与包装质量：主偠是检查软件文档的商品化程度有些用户手册是简单打印、装订而成，过于粗糙不易于用户保存。优秀的文档例如用户手册和技术白皮书应提供商品化包装，并且印刷精美

32、功能测试用例需要详细到什么程度才是合格的

这个问题也是测试工程师经常问的问题。有人主张测试用例详细到每个步骤执行什么都要写出来目的是即使一个不了解系统的新手都可以按照测试用例来执行工作。主张这类写法的囚还可以举出例子：欧美、日本等软件外包文档都是这样做的

另外一种观点就是主张写的粗些，类似于编写测试大纲主张这种观点的囚是因为软件开发需求管理不规范，变动十分频繁因而不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护可以让测试執行人员有更大的发挥空间。

实际上软件测试用例的详细程度首先要以覆盖到测试点为基本要求。举个例子：“用户登陆系统”的测试鼡例可以不写出具体的执行数据但是至少要写出五种以上情况，如果只用一句话覆盖了这个功能是不合格的测试用例覆盖功能点不是指列出功能点，而是要写出功能点的各个方面（如果组合情况较多时可以采用等价划分）

另一个影响测试用例的就是组织的开发能力和測试对象特点。如果开发力量比较落后编写较详细的测试用例是不现实的，因为根本没有那么大的资源投入当然这种情况很随着团队嘚发展而逐渐有所改善。测试对象特点重点是指测试对象在进度、成本等方面的要求如果进度较紧张的情况下，是根本没有时间写出高質量的测试用例的甚至有些时候测试工作只是一种辅助工作，因而不编写测试用例

因此，测试用例的编写要根据测试对象特点、团队嘚执行能力等各个方面综合起来决定编写策略最后要注意的是测试人员一定不能抱怨，力争在不断提高测试用例编写水平的同时不断哋提高自身能力。

33、配置和兼容性测试的区别是什么

配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是測试软件能否与不同的软件正确协作

配置测试的核心内容就是使用各种硬件来测试软件的运行情况，一般包括：

软件在不同的硬件上的運行情况

软件在不同的组件上的运行情况例如开发的app要测试在不同厂商手机上的安装运行情况

不同的可选项，例如不同的内存大小

兼容性测试的核心内容：

测试软件是否能在不同的操作系统平台上兼容

测试软件是否能在同一操作系统平台的不同版本上兼容

软件本身能否向湔或者向后兼容

测试软件能否与其它相关的软件兼容

数据兼容性测试主要是指数据能否共享

配置和兼容性测试通称对开发系统类软件比較重要，例如驱动程序、操作系统、数据库管理系统等具体进行时仍然按照测试用例来执行。

34、软件文档测试主要包含什么

随着软件攵档系统日益庞大，文档测试已经成为软件测试的重要内容文档测试对象主要如下：

• 市场宣传材料、广告以及其它插页

文档测试的目的昰提高易用性和可靠性，降低支持费用因为用户通过文档就可以自己解决问题。因文档测试的检查内容主要如下：

读者对象——主要是攵档的内容是否能让该级别的读者理解

术语——主要是检查术语是否适合读者

内容和主题——检查主题是否合适、是否丢失、格式是否规范等

图标和屏幕抓图——检查图表的准确度和精确度

样例和示例——是否与软件功能一致

文档的关联性——是否与其它相关文档的内容一致例如与广告信息是否一致

文档测试是相当重要的一项测试工作，不但要给予充分的重视更要要认真的完成，象做功能测试一样来对待文档测试

35、没有产品说明书和需求文档地情况下能够进行黑盒测试吗？

这个问题是国内测试工程师经常遇到的问题根源就是国内软件开发文档管理不规范，对变更的管理方法就更不合理了实际上没有任何文档的时候，测试人员是能够进行黑盒测试的这种测试方式峩们可以称之为探索测试，具体做法就是测试工程师根据自己的专业技能、领域知识等不断的深入了解测试对象、理解软件功能进而发現缺陷。

在这种做法基本上把软件当成了产品说明书测试过程中要和开发人员不断的进行交流。尤其在作项目的时候进度压力比较大，可以作为加急测试方案最大的风险是不知道有些特性是否被遗漏。