1. 软件测试基础（P1-3）

测试基础知识的学习目标

本章的学习目标：完成下面模块(module)的学习后，将明确能做什么。

? 通过具体的例子，来描述软件中的缺陷(defect)会以什么样的方式损害个人、损害环境或者损害公司利益。

? 区分引起缺陷的根本原因及其影响之间的区别。

? 通过举例的方式说明为什么需要测试。

? 描述为什么测试是质量保证(quality assurance)的一部分，通过举例说明测试是如何来提高软件质量的。

? 认识测试的共同目标。

? 描述测试作为发现缺陷的一种手段，测试在软件开发、维护和运行中的目的，同时通过测试，可以增强对被测软件的信心并获得一些相关的信息，从而用来预防缺陷。

1.3 测试的基本原则

? 说明测试的基本原则。

1.4 基本的测试过程

再次认识从计划到测试结束过程中测试的基本活动，以及在每个活动中的主要任务（K1）。

? 认识测试的成功与否，会受测试心理因素的影响：

? 自己测试和独立测试之间的平衡；

? 认识到谦恭的沟通和缺陷反馈在测试中的作用。

1.1.1 软件系统的状况

在当今社会，软件系统(system)越来越成为生活中不可或缺的一部分，包括从商业应用（比如银行系统）到消费产品（比如汽车）各个领域。然而，很多人都有这样的经历：软件并没有按照预期进行工作。软件的不正确执行可能会导致许多问题，包括经济的损失、时间的浪费和商业信誉的丢失等等，甚至导致人身伤害和死亡。

1.1.2 引起软件缺陷的原因

所有的人都会犯错误。该错误error会成为设计的代码、软件、系统和文档中的缺陷。当存在缺陷的代码被执行时，系统就可能无法执行期望的指令（或者做了不应该执行的指令），从而引起软件失效（故障）。虽然软件、系统和文档中的缺陷可能会引起失效，但并不是所有的缺陷都会这样。

产生缺陷的原因是多种多样的：人们本身容易犯错误、时间的压力、复杂的代码、复杂的系统架构、技术的革新、或者系统之间的配合工作等。

失效也可能是由于环境条件引起的：放射、电磁辐射和污染等都有可能引起硬件的故障，或者由于硬件条件的改变而影响软件的执行。

1.1.3 在软件开发、维护和运行中测试的角色

对软件系统和文档进行严格的测试,可以减少软件系统在运行环境中的风险，假如在软件正式发布之前发现和修正了缺陷，就可以提高软件系统的质量。

进行软件测试也可能是为了满足合同和法律法规的需求，或者是为了满足行业标准。

通过测试，根据发现的缺陷，就可能发现软件系统在功能(functional)和非功能(non-functional)需求方面的缺陷，对软件质量(software

当测试发现很少或者没有发现缺陷的时候，就会对软件的质量充满信心。一个设计正确、合理的测试过程完成并顺利通过，可以降低整个系统存在问题的风险。而对测试过程中发现的缺陷进行了修正，则软件系统的质量就会提高。

我们应该从以前的项目中总结经验教训。通过分析在其他项目中发现的缺陷和引起缺陷的根本原因，我们就可以改进测试过程(process)。相继地，过程的改进又可以预防相同的缺陷再次发生，从而提高以后系统的质量。

测试应该作为质量保证的各种作业中（例如：开发标准、教育、缺陷分析）的不可或缺的一部分。

测试应该进行到哪种程度，取决于技术、产品、项目风险的水平，以及在时间和预算等方面项目上的限制。 （风险将在第5章进行详细描述）

测试需要给利益相关者提供足够的信息，帮助他们决定是否发布被测的软件或系统，是否继续进行下阶段的开发或直接将产品交给用户。

追求完全的品质，从成本的角度来看没有效果

缺陷成本：为了修正而产生的成本、产生不良结果的成本

在一般人的理解当中，测试活动只包含了运行测试，也就是执行软件。但实际上这只是测试的一部分，而不是测试的所有活动。

process)及被测系统、测试结束或总结。测试同时也包括文档的评审(review)（包括代码）和静态分析(static analysis)。

动态测试(dynamic testing)和静态测试这两种手段都可以达到相似的目标，即以提供信息来改进被测试软件系统的质量，以及改善开发和测试的过程。

- 计划、测试条件、测试用例设计

- 执行结果的Check、完了基准的验证、测试结果报告

※ 在下一节的《基本的测试流程》中，会将测试执行前的作业分为计划和设计，当作5个流程来定义。

不同的测试具有不同的测试目标：

? 获取对产品质量的信心，以及提供信息；

在软件生命周期早期进行测试用例的设计，可以帮助避免将缺陷引入代码中。同时文档的评审（例如需求文档）也可以预防将缺陷引入代码。

不同的测试阶段，需要考虑不同的测试目标。比如，在开发中的测试里，如单元测试(unit testing)、集成测试(integration testing)和系统测试(system testing)等，测试的主要目标是尽可能的发现失效，从而识别和修正尽可能多的缺陷。在验收测试（acceptance testing）中，测试的主要目标是用来确认系统是否按照预期工作，从而在系统是否满足需求方面获取信心。而在有些情况下，测试的主要目标是对软件的质量进行评估（不是为了修正缺陷），从而为利益相关人提供这样的信息：在给定时间内发布的系统版本所存在的风险。而保守测试 (维护测试maintenance testing)通常是为了验证在开发过程中的变更是否引入新的缺陷。在运行测试阶段，测试的主要目标是为了评估系统的特征，比如可靠性或可用性等。

必须明确，调试和测试是两个不同的概念。测试可以发现由于软件存在的缺陷引起的失效。而调试是一种开发活动，用来识别引起缺陷的原因，修改代码以及验证是否正确的修改了软件的缺陷。随后由测试员进行的确认测试(confirmation testing)是为了确认修改的代码已经解决了失效问题。每个活动的职责是截然不同的，即测试员进行测试，开发人员进行调试。

1.3 测试的基本原则

在过去40年中，软件测试界提出了很多的测试原则，并且提供了适合所有测试的一些共同的测试指南。

原则1 － 测试显示缺陷的存在

测试可以显示缺陷(defect)的存在，但不能证明系统不存在缺陷。测试可以减少软件中存在缺陷的可能性，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的。

原则2 － 穷尽测试是不可能的

除了小型项目，进行完全（各种输入和前提条件的组合）的测试是不现实的。通过运用风险管理(risk management)和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试。

原则3 － 测试尽早介入

在软件或系统开发生命周期中，测试活动应该尽可能早的介入，并且应该将关注点放在已经定义的测试目标(test objective)上。

原则4 － 缺陷集群性

版本发布前进行的测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的。

原则5 － 杀虫剂悖论

同样的测试用例一遍一遍重复进行测试，最后将不再能够发现新的缺陷。为了克服这种杀虫剂悖论，测试用例需要经常性的评审和修改，同时需要不断增加新的不同的测试用例来测试软件或系统的不同部分，从而发现潜在的更多的缺陷。

原则6 － 测试活动依赖于测试内容

针对不同的测试内容，进行的测试活动也是不同的。比如，对关注安全的软件进行测试，与一般的商业软件测试的重点是不一样的。

原则7 － 0缺陷的谬论

假如系统无法使用，或者系统不能完成客户的需求和期望，发现和修改缺陷是没有任何帮助的。

「所有的模式都是错误的。但是，有的模式能够起到作用」

原则上，是将现实世界抽象化、故意让很多信息欠缺。

欲将软件开发和测试这种极富多样性的活动，用几个原则来进行说明，

本身就不太可能。但是，这种原则对于理解测试的重要一面，确实有着

非常重要的作用。总而言之，工具是可以使用的。

1.4 基本的测试过程

测试最显而易见的活动是测试的执行。但是为了提高效率，在测试计划中，同样需要保留比较多的时间用于计划测试活动、设计测试用例、准备测试的执行和评估测试的状态。

基本的测试过程主要由下面一些活动组成：

? 4 评估出口准则和测试报告；

? 5 测试结束活动。

虽然上面这些活动在逻辑上是有连续的，但在整个测试过程中它们可能会重叠或同时进行。

1.4.1 测试计划和控制阶段

测试计划的主要活动是：识别测试的任务、定义测试的目的；以及为实现测试目的而决定测试作业的式样。

测试控制是持续进行的活动：通过对测试进展和测试计划之间的比较，报告测试的状态，包括与计划之间存在的偏差。测试控制包括在必要的时候采取必要的措施来满足测试的任务和目标。需要在项目的整个生命周期中对测试活动进行监控，以达到控制测试过程的目的。同时，测试计划的制定也需要借鉴以前项目测试监控活动的经验和有用信息。

测试计划阶段主要任务：

? 确定测试的范围和风险，识别测试的目的；

? 确定测试方法:测试技术、测试项(test item)、测试覆盖(test coverage)、识别和联系相关的测试团队和测试件；

? 确定测试需要的资源:人员、测试环境(test environment)和计算机等；

? 贯彻测试方针和策略；

? 计划测试分析和测试设计任务的时间进度；

? 计划测试作成、执行和验证的时间进度；

? 确定测试的结束（出口）准则。

测试控制阶段主要任务：

? 监控和记录测试进展、测试覆盖和测试出口准则的文档化；

1.4.2 测试分析和设计阶段

测试分析和设计是将抽象的测试目标转化为实实在在的测试条件和测试设计的一系列活动。

测试分析和设计阶段的主要任务：

1. 评审测试依据（比如需求、系统架构、设计和接口说明等）。

2. 识别测试条件或测试需求(test requirement)，根据测试项、详细规格说明、系统行为和结构分析得到必要的测试条件和数据。

5. 规划测试环境的搭建和确定测试需要的基础设施（infrastructure）和工具。

1.4.3 测试实现和执行阶段

测试实现和执行是将测试条件转化为测试用例、测试件的一系列活动，并进行测试环境的搭建。

测试实现和执行阶段的主要任务：

1. 测试用例的开发和确定它们的优先级，创建测试数据，描述测试的具体步骤，同时也可以准备测试用具(test harnesses)和设计测试脚本(test script)。

2. 根据测试用例建立测试套件(test suite)，以提高测试执行的效率。

3. 确认已经正确搭建了的测试环境。

4. 根据计划的执行顺序，通过手工或使用测试执行工具(test execution tool)来执行测试用例。

5. 记录测试执行的结果，以及被测软件的标识和版本、使用的测试工具和测试件。

6. 将实际结果和预期结果进行比较。

7. 对实际结果和预期结果之间的差异，作为缺陷上报，并且分析这些缺陷以确定引起缺陷的原因（代码缺陷、具体测试数据缺陷、测试文档缺陷、或测试执行的方法有错误等）。

8. 缺陷修正后，重新进行测试活动。比如通过再次执行在上个版本中失败的用例来确认缺陷是否已经被修正（确认测试）。执行修正后的测试用例或执行一些测试用例来确保缺陷的修正没有在软件中引入新的问题后或没有引起其他的缺陷（回归测试）。

テストベース、テストスイート、テストケース、テストプロシージャ：

1.4.4 评估出口准则和测试报告阶段

评估出口准则阶段是将测试的执行结果和已经定义的测试目标进行比较的活动。这个活动在各个测试级别(test level)上都需要进行。

评估测试出口准则的主要任务：

1. 将测试结果记录与测试计划作业中定义的终了基准相对比。

2. 判断是否需要进行更多的测试，或是否需要更改测试的出口准则。

3. 为利益相关者提供一个测试总结报告。

测试结束阶段从完成的测试活动中收集资料来巩固测试经验，收集测试件、影响测试的因素和其他数据。比如什么时候软件系统可以发布？什么时候项目测试结束或取消？什么时候达到里程碑？或者何时可以发布一个维护版本等？

测试结束阶段的主要任务：

? 检查提交了哪些计划的交付物(deliverable)、缺陷报告是否关闭、提交的变更记录是否仍处于开放状态、以及系统的验收文档状态等等。

? 移交测试件到维护部门。

? 分析学到的经验教训，作为将来项目和版本的参考及用来改进测试成熟度(test maturity)。

在测试和评审中使用的思想方法，与在项目分析和开发中使用的方法不同。开发员可以测试他们自己写的代码，但这与测试员职责之间是存在区别的，明白这一点，测试员的独立测试需要提供专门的工作量，并且具有以下优点：通过专业的培训和利用专业的测试资源，实现独立的测试；独立测试可以应用于任何测试级别。

一定程度的独立测试（可以避免开发人员对自己代码的偏爱），可以更加高效的发现软件缺陷和软件存在的失效。但独立测试不是完全的替代物，因为开发人员也可以高效的在他们的代码中找出很多缺陷。可以定义不同级别的独立测试：

? 测试用例由软件本身编写的人员来设计（低级别的独立测试）。

? 测试用例由开发小组中的其他成员来设计。

? 测试用例由组织内的其他小组成员来设计（独立的测试小组）。

? 测试用例由来自其他组织或其他公司的成员来设计（测试外包）。

测试的目标驱使着小组成员和项目的活动。小组成员将根据管理层或其他利益相关者设定的目标对他们的计划进行调整，比如需要发现更多的缺陷，或确认软件是否可以正常工作。因此，对测试的目标进行清晰的设定是非常重要的。

测试过程中发现的失效，可能会被看成是测试员对产品的责难或对产品开发者的不恭。因此，测试通常被认为是破坏性的活动，即使它对于管理产品风险是非常有建设性作用的。在系统中发现失效需要测试员具有一颗好奇的心、专业的怀疑态度、一双挑剔的眼睛、探究根底的精神、与开发人员良好的沟通能力以及对常见的错误进行判断的经验。

假如可以用建设性的态度对发现的缺陷或失效进行沟通，就可以避免测试员、分析人员和开发设计者之间的不愉快。这个道理同样适用于文档的评审过程。

在以建设性的方式讨论缺陷、进度和风险时，测试员和测试的负责人都需要具有良好的人与人之间沟通的能力。通过良好的沟通，要让软件代码或文档的作者明白，发现缺陷的信息可以帮助他们来提高他们的技术水平。在测试阶段发现和修复缺陷可以在项目后期节省时间和金钱，而且可以减少项目的风险。

沟通方面的问题经常会发生，特别是当测试员只是作为不受欢迎的缺陷消息的传递者的时候。然而可以使用下面的一些建议和方法来改善测试员和其他小组成员之间的沟通和相互关系：以合作而不是争斗的方式开始项目，时时提醒项目的每位成员：共同目标是追求高质量的产品。

?对产品中发现的问题以中性的和以事实为依据的方式来沟通，而不要嘲笑引入这个问题的小组成员或个儿。比如，客观而实际的描写缺陷报告和评审(review)发现的问题。

?尽量理解其他成员的感受，以及他们为什么会有这种反应。

确信其他成员已经理解你的描述，反之亦然。

摘要：随着软件测试受关注程度越来越高，如何采用技术手段有效提高软件测试质量就成了软件测试领域的一个重要课题。本文从软件测试的基本概念开始，对如何以软件测试性设计为中心、合理运用软件测试技术来提升软件测试质量提出了自己的看法。 关键词：软件测试；测试设计；测试质量 软件产品的质量取决于软件开发过程，软件测试作为软件生存期中的一个重要阶段，受重视程度越来越高。软件测试是保证软件质量和可靠性的关键步骤，也是用来验证软件是否能够完成所期望功能的唯一有效的方法。测试已不仅仅局限于软件开发中的一个阶段，它已开始贯穿整个软件开发过程，进行测试的时间越早，整个软件开发成本下降就越多。大量统计表明，软件测试的工作量往往占到软件开发总量的40%以上，在极端的情况下，甚至可能高达软件工程其它步骤成本总和的三至五倍，其目的是尽可能的提高软件产品的质量和可靠性。 1、软件测试相关概念 （1）软件测试：软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计出一批测试用例，并利用这些测试用例的运行结果来发现程序错误的过程。 （2）软件测试用例：测试用例实际上是对软件运行过程中所有可能存在的目标、运动、行动、环境和结果的描述。测试用例是测试组织的最小单位，指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并最终形成文档。 软件测试的核心是设计和执行测试用例。而测试用例的选择问题可以看作是从庞大的输入状态组合中，搜寻哪些可以发现错误的状态组合。因此需要用抽象的手段来尽量使测试更加有效。 （3）测试用例库：完整的单元测试很少只执行一个测试用例，开发人员通常都需要编写多个测试用例才能对某一软件功能进行比较完整的测试，这些相关的测试用例称为一个测试用例集。将大量的测试用例收集到测试用例库中，合理的分类后供测试人员选择使用，能够极大地提高软件问题的发现率。 2、提高测试质量的方法 2.1 采用测试性设计技术 软件测试是目前用来验证软件是否能够完成所期望的功能的唯一有效的方法。但是在测试的实施过程中，由于种种原因导致测试的难度相当大，甚至出现了无法测试的情形。为了提高软件的可测试性，我们在软件设计时应当遵循测试性设计原则，通过改变设计或代码、为软件增加专门测试结构等方法来提高软件的可测试性。 （1）测试驱动设计。这种设计就是直接把软件需求变成测试代码。在确定软件测试性能要求的基础上优先编写测试代码。先写验收测试，再写单元测试，并在开发过程中不断修正。 （2）每个操作对应一个方法，使方法小型化。使用小型化方法说明和重载带缺省方法参数的方法，使得测试中调用这些方法变的很容易。 （3）显示与控制分离。把代码移到GUI视图的外面，各种GUI动作就能成了模型上的简单方法调用。这样，在修改程序功能不会影响视图，同时通过方法调用测试功能也比间接地测试功能更容易。 （4）对于可能要作为参数的类，做一个接口。用接口说明外部程序组件或在需要时改变接口形成一个空类作为参数传入。 2.2 选择合适的测试管理模型 模型是系统功能的形式化或半形式化的表示，支持输入状态组合的系统枚举。基于模型的测试主要考虑系统的功能，可以认为是功能测试的一种。测试模型体现了被测试系统的最本质的功能关系。而且要比系统本身更易于开发和分析。一个可测试的模型要能提供足够的信息用来产生测试用例。所以可测试的模型必须满足以下要求： （1）必须是某种测试实现的完全准确的反映，模型必须表示要检查的所有特征； （2）是对细节的抽象； （3）可以表示所有事件和所有的动作；⑷可以表示系统的各种状态，以便由可知的方法来确定已达到或没有达到什么状态。

　　【IT168 资讯】作为一名测试人员，51真的是我们的精神家园，所以在收到OFFRE后决定给同样在寻找工作的朋友们一点自己的经历，今天主要说下面试的N家单位，都是杭州的。

　　一、恒生电子：由于我之前做过通信类产品测试，面的是他们的WIMAX岗位，是给NOKIA外包的。过去先做一套题，英文题目，有软件测试相关知识，wimax原理图，java编程，C语言编程等等，C语言题目是写strcpy/strcmp/strlen中的一个，由于没准备，所以我只做了测试相关题目。面试上来要我做个英文自我介绍，当时闷了，没准备，答得很郁闷。后面主要问以前的测试流程、测试相关知识等，最后看我简单的C题目没写出来，被狠狠BS了，当场告诉我不适合此岗位。第一次面试结束，彻底失败告终，要好好准备C和英文介绍。

　　二、H3C：过去首先做一套题，主要是C的，和HW差不多的题目。由于做了相应的准备，选择和填空基本完成，编程题没做。一面是测试的项目leader，主要以前的测试流程、测试相关知识，感觉不错，二面好像是HR主管，主要非技术问题，答的一般，三四面有技术和项目相关的问题，同样关注离职原因等。总体说来面后自我感觉良好，可惜还是挂了。

　　三、阿里&淘宝：两个都是电话面试，对这种面试形式不太习惯，都在下班后来的电话，主要问测试技术相关知识，两个电话面的都没结果。

　　四、三维通信：上市公司，新大楼不错。先是HR的面试，问的很多，聊的蛮久的，后面是技术面试，感觉他们不是做纯粹软件测试，因为他们的产品大体是基站的扩放器之类，测试侧重点主要是看仪器。所以聊的不投机，也没消息。

　　五、三汇数字：先HR，后技术。主要是嵌入式产品，问我有没有白盒测试经验，我想做白盒还会来你这么，国内做这个也不多。不知道他们到底要招怎么样的人，成年挂在51上。

　　六、淘宝：阿里的扩招是千真万确的。这次直接面试，好像是搜索部门。先做题，linux基本命令，C的strcmp原函数，一个用例设计题，对输入年月日做最多用例考虑。面的可能是是测试项目leadre，由于测试部分答的不错，C的那题还是没搞定，不过一周后还是给了2面。二面也做的相应准备，可惜的是还让写上次的C题目，超级郁闷，而且二面官问了些非常尖锐的问题，让我无从下手回答，很正常的挂了。后来在网上好好搜索了相关面试题目，发现还是自己准备不足。

　　继续在51上投，投了不下200份简历........囊括本市所以测试岗位。

　　七、公众信息产业：主要给电信做项目，过去先做了一套测试题，轻松。后面的技术面试谈的主要是以前的测试流程和技术，也轻松。后来某天下午3点让我5点过去二面，由于预约了另一家公司，让他们改天，至今无音讯。估计找工作的人实在太多了。

　　八、支付宝：还是阿里旗下，阿里的人招不完啊，几乎占据论坛3分之一版面了，呵呵。没做题，直接聊，主要测试相关，以前项目，问题比较细，问题也叼装，感觉阿里对招人要求还是很高的，虽然招的人多。聊了大概40分钟，两天后邮件通知挂。

　　九、3个个给阿里做外包的，由于自己已经面过阿里那边，所以都最后都无果。还有几个小公司，时间上冲突，没有再给机会。

　　十、给OFFER的公司：做一套题，涉及面非常广，C语言、数据库高级查询、用例发散设计、软件工程、项目管理知识、测试技术考的很细。面试是三对一，也是第一有这样的经历，刚开始蛮紧张的，问的问题之前的面试基本上问过。我只能说上帝给予了我这个职位。

　　离上班还有段时间，接下来重要深入学习LR和性能测试技术，数据库，linux，C编程，测试技术，希望有很好的准备和状态投入新公司。

　　下篇具体写面试题目介绍和准备，希望对大家有帮助。请多多支持，共同进步！

　　先说笔试：一般的公司会通过笔试淘汰一部分不符合他们公司职位要求的人员，毕竟每个公司具体岗位不一样，总希望招到能尽快上手的人，就像你做了2年多的纯功能方面的测试，而人家希望有点编程能力的做性能方面的测试，估计你会在笔试中被淘汰。所以笔试也是很重要的部分，当然你够牛就直接面吧。

　　1. 编程基础，我不知道有多少做测试的朋友讨厌编程或者做软件开发，我个人是比较讨厌的，虽然学校里学的是计算机，但是到毕业也没正儿八经地写过超过百行的代码，但没写过不代表读不懂。所以选择填空还是可以应付的。对于可能的编程题，我是准备了一些如冒泡，折半算法、strcpy/strcmp/strlen 原函数等。编程的能力是需要积累的过程，所以贵在平时。对于编程能力是否有助与测试这个论坛上讨论过的问题，我的观点是第一至少你找工作时用的着，第二如果做性能测试应该也需要，第三如果有2年以上的测试经历应该也会觉得非常有必要。本人也正硬着头皮再学c，虽然学了忘忘了学。

　　2.数据库知识，建议准备好sql语言，装个mysql自己通过敲命令，能掌握高级查询使用基本可以应对了。

　　3.软件测试理论，这个大家都不陌生，也是必考的了，应该可以轻松应付。要注意准备下web测试和性能测试这块，现在做web的公司好多。

　　4.根据公司具体的职位要求可以准备的有linux的命令，CMMI的基础知识，TCP/IP的基础知识，通信的如3G网络类知识等。

　　下面说面试：通过面试真的能看出很多，技术、经验、性格人品等，当然都是通过你的答题来让人家了解的。

　　1.请自我介绍一下。这个必答题。对于不善于表达的朋友要准备一把，我就是这种类型，好处是起码说起话来可以比较流利。说性格时可以提对做测试有优势点。

　　2.说说你以前公司的测试流程。必答题。主要结合自己的项目经验相信讲一个自己做过的项目，从立项到测试结束，当然侧重测试和自己所做的内容。这里面试官一般都会根据你说的再提问。

　　3.你是怎样做出自己的职业选择或者自己的职业规划。这题也经常问。可以从自己的优点说如何适合做软件测试，对与职业规划，我一般说在技术上往资深测试工程师发展。

　　4. 你觉得自己作为测试工程的优势在哪里？/你认为自己比你的同事优秀在哪里？也经常问，可以从性格出发，讲自己优点，以及在项目中表现，领导的良好评价等，总之“恰当”地往好处说，不要言过其实，让人怀疑你的人品哦。说说自己的缺点？这个也不好回答，最好能恰当地引申回答到优点上。

　　5.一个测试中不堪回首，或者让你很郁闷的事情。我被问到了，当时想不起来，后来想想可以讲一个项目中的失误及后果，然后讲自己如何去成功弥补及教训经验。我如果提前想一下就不会该说什么了。

　　6.你的好友是如何评价你的？你的项目组长是如何评价你的？ 这类题也经常问。回答总要往好处说，但是你要自信地回答。

　　7.在成年后，哪些成绩给你带来最大程度的满足？蛮不错的题。记得我但是答的是第一次自己带一个小项目，顺利完成测试任务。

　　8.列举几个可能碰到的题，大家可以想想。

　　测试时你提交的bug被研发拒绝或者他认为不是问题，你如何处理？

　　测试与开发沟通如何提高效率和改善沟通效果？测试工程师的素质和技能？

　　你在压力下能工作的很好嘛？测试计划包括哪些？

　　9.你期望的薪水？问的很多啦，根据自己能力和公司的大小，可以搜索下了解下情况。在工作难找的情况下OFFER到手实在些，骑驴找马总容易很多。

　　关于这些面试题，自己想不好的可以网上搜搜，51上也有很多关于答题的技巧和答案。最后要说下心态，面试的时候自信最重要，自信也来自良好的准备，所以面多了总结下，下次就更自信了。想想没被录用只能说明公司不适合你，或者人家要不起你。说的废话蛮多的，最后希望Tester在自己的职业道路上走地顺利......