1.描述一下测试过程
类似题目:测试的生命周期
思路:这是一个"范围"很大的题目，而且回答时间一般在3分钟之内，不可能非常详细的描述整个过程，因此答题的思路要从整体结构入手，不要过细。为了保证答案的准确性，可以引入双V测试模型对测试的过程划分。
答:
1)、每个公司的测试过程都不尽相同，但基本都依据或参考行业所认可的一些测试模型，如 V模型、双 V模型等，不同的模型对测试的过程划分也不尽相同。例如V模型多了一个"验收测试过程"。
2)、对测试过程划分比较细致的是双V模型，依据和开发的参照关系分为3个大的阶段:单元测试阶段、集成测试阶段、系统测试阶段:每个阶段的工作内容又分为4个小阶段:计划阶段、设计阶段、实现阶段、执行阶段。其中计划、设计、实现被统称为"测试准备阶段"，可以前置实现(即
在开发编码的同时测试在进行用例的编写等工作)。
3)、在测试的实际过程中要有相关的工具进行支持和管理，如 Junit(单元测试)、SVN(配置管理)、QC(系统测试管理)。其中 QC对测试的支持大致可以划分为版本周期管理、测试需求管理、测试用例管理、测试执行管理、缺陷跟踪。
2.描述一下缺陷跟踪过程
思路:缺陷跟踪实际是描述公司对缺陷的管理过程，因为过程较复杂，纯文字描述很难表达逻辑的准确性，因此建议配合图形的方式回答(面试时需要自备纸笔)。
答:
1)、缺陷跟踪的目的:管理缺陷，随时跟踪缺陷所处的位置，并进行缺陷分析。
2)、跟踪使用的缺陷字段是"状态"，一般至少包括:new、open、fixed、reopen、closed。根据公司实际情况可以自行添加状态，如:Reject。
3)、实现跟踪需要支撑的工具，如 QC(在定制管理的用户组权限中进行设置)。
3.黑、白、灰盒测试的区别
答:
1)、黑盒测试:不考虑组件或系统内部结构的功能或非功能测试(简单来说就是:代码不可见
的测试)，主要应用于系统测试阶段，常见的测试方法包括:功能测试、易用测试、兼容测试等。2)、白盒测试:基于对组件或系统的内部结构的分析而进行的测试。(简单来说就是:代码可见的测试)，主要应用于单元测试阶段，常使用逻辑覆盖率(路经覆盖、分支覆盖等)进行测试设计。
3)、灰盒测试:介于黑盒和白盒之间的测试，一般理论上存在，实际招聘岗位的很少。主要应用于集成测试阶段，常用于接口测试。
4.静态、动态测试的区别
答:
1)、这两种测试方法主要以代码是否被"执行"作为区分的标准。
2)、静态测试:代码没有被执行。如:代码走读，Java 编译工具(代码写完要先编译，检查语法是否有错误，属于静态+自动化测试，如果编译没有错误才可能被运行)。
3)、动态测试:代码被执行起来了。如功能测试(分别输入有效、无效值测试输入，程序必须要先运行起来)。兼容测试(被测程序在不同的环境(Win7、win8 等)下运行是否正常)
5.验收测试和α测试、β测试的区别
思路:对这几个测试方法的分类，业界没有形成统一的标准，为了防止考官和你学习的标准不统一，回答问题前最好加上些说明。
答:
1)、业内对以上方法的划分没有形成统一的标准，有人认为是并列关系，即验收测试针对的是项目而言，α和β测试针对的是产品而言。有人认为是从属关系，即α测试属于内部验收测试，是可控的，β测试属于外部验收测试，一般难以控制。
2)、关于这三个测试的定义可以参考前面的"名词解释"部分。
6.负载、压力、容量测试的区别
思路:一般这些测试均属于性能测试的范畴，业界的解释也是不统一的，类似的还包括"基准测试"
等。
答:
1)、以上词汇属于性能测试的常见术语。
2)、定义见文档名词解释部分(压力测试、负载测试、容量测试)。
7. 测试计划和策略都包括哪些内容
答:
1)、测试计划:主要内容包括:测试的对象、工作任务安排(谁什么时间做什么事儿)、风险评估、结束或成功的标准等。
2)、测试策略(设计):主要内容包括:依据《测试计划》进行用例的设计和分析、如何设计测试数据、如何搭建测试环境等。
3)、定义见文档名词解释部分。
8.简述常见的测试方法和类型
思路:对于"测试方法"、"测试类型"业界也没有统一的标准划分，因此答题的时候干脆把所有可能的分类方法都说出来。
答:
1)、当前业界类似种类划分很多，没有形成统一的标准，我的理解是:
2)、测试方法分为:白盒、黑盒、静态、动态、人工、自动等。
3)、测试类型分为:(参考 IS09126):功能、安全、兼容等 27 项。
4)、用例设计方法:等价类、边界值、判定表、正交实验、流程分析、状态迁移。
9.单元测试和白盒测试的区别答:
1)、单元测试一般指的是:测试的某个阶段
2)、白盒测试一般指的是:一种测试方法
3)、他们的关系:在单元测试阶段，使用白盒测试的方法
10.测试用例的组成字段
思路:每个公司用例的组成字段都不相同，因此回答分为两个部分，主要字段(所有公司都有的字段，属于重要的内容)和其他字段(相对来说不是很重要，每个公司都不尽相同)，这样防止考官总说你回答的字段不全。
答:
1)、一般用例的主要字段包括:用例标题、步骤名称、步骤描述、预期结果、实际结果
2)、其它辅助字段各个公司都不尽相同，如:用例编号、编写人、预置条件、优先级、对应版本、执行状态，覆盖需求等。
3)、额外补充:如 QC 工具可以将共性的用例步骤设计为模板，并进行参数化出来，以减少大量重复用例写作，提高工作效率。公司额外的字段也可以在不同的项目中自行添加。
4)、把用例的设计工作和编写工作最好分开，以便于评审和复用。
5)、注意用例对需求的覆盖(跟踪)关系维护，以及确定执行的优先级和次序。
11.缺陷报告的组成字段
思路:同上
答:
1)、主要字段:标题、描述、状态、严重程度、优先级
2)、其它字段:时间(提交、修改、回归、关闭)、版本(提交、修改、关闭)、人(提交人、分配人)、缺陷产生原因等。如果字段的数量多，也意味着缺陷分析的角度就多。
3)、为了防止表达不清楚和二义性，最好附加一些截图、操作视频、测试数据等附件。
4)、额外补充:如 QC类工具，可以添加用户指定的字段，并进行缺陷分析(柱形图、饼状图)。
12.如果出现需求变更怎么办
思路:需求是一个很大的范畴，统称需求工程，涵盖内容很多，主要从学习过的内容回答即可。
答:
1)、从 IS09000 的定义中，需求包括:显示、隐式和规范性需求。除了客户提出的显示需求,要尽量挖掘和发现隐式需求，同时要满足行业、国家等相关的规范。
2)、需求要经过评审才能使用，保证需求的准确性和全面性。因为几乎所有的生命周期模型中都以需求作为开始的起点，因此如果需求出现问题，会导致缺陷的发散。
3)、可以对需求进行"建模"，绘制"流程终"或者"状态图"，用图形的方式保证需求尽量不产生二义性(因为图形元素的定义是标准的)，而且可以为后续的测试用例编写提供依据。4)、维护需求跟踪关系，如需求和用例的跟踪覆盖关系(Qc 中可以实现)，一旦有需求发生变更，可以确定需求变更对用例的影响范围。
5)、每次需求变更并评审通过后，要进行基线化控制，保证相关人员使用的同一个版本的需求。
13.开发不认可你的缺陷怎么办
思路:这道题就没有标准答案了，可以说是"人各有志"，不同的人有不同的方法，因此主要考察点不是对测试知识和技能的掌握，而是你处理人际关系，团队关系，同事关系的能力。
季
1)、要尽可能避免这种情况发生，此类情况多发生在新员工身上，由于技术和业务掌握不是很扎实，导致提交一些无效的缺陷，这时可以增加测试内部的评审的环节来解决，即测试提交新缺陷(New)后，由测试经理或资深人员进行审核，确认无误可以打开缺陷(0pen)，提交给开发修改，否则置为无效(Abandon)，不提交给开发进行修复。参考《缺陷跟踪流程图》。
2)、尽量沟通协调，听听对方的理由，如果开发理由充分，放弃此缺陷
3)、如果认为开发理由不充分，确实需要修复，你要举出反例(参考其它同类软件的功能)来证明该缺陷是有道理的。
4)、咨询其他资深的测试同事，看是否有过类似问题，可以求教一下。
5)、实在无法协调的，可以直接提交缺陷报告，改或不改完全由开发决定，起码保证客户反馈类似问题的时候，责任不在测试这里。
6)、总之，凭借我的技术和沟通能力，相信一定能很完美的处理类似的问题。
14.发现不可重现的缺陷怎么办
答:
1)、检查是否严格按照用例去执行的，还是无意中发现的，尽量去重现或者找到规律2)、检查测试环境，包括操作系统、测试数据等一切可能引起缺陷的原因。
3)、在缺陷报告中注明:不可重现或无法发现规律，最好缺陷报告中就设定类似字段(QC中默认有该字段，叫"是否可重现")。
4)、在提交缺陷报告的时候尽可能添加附件，如当时抛出的异常，日志信息等，也许开发能从中发现一些蛛丝马迹，进而修复缺陷。
15.验证和确认的区别
答:
1)、确认:做没做。如软件的功能是否被开发实现了。
2)、验证:做的对不对。如开发出来的功能需要验证(测试)是否正确，
3)、这个词出现的频率很高，如 CMMI(3 级中有验证、确认两个过程域)、双 V模型。
16.给你个纸杯怎么测
思路:这类题属于常见问题，一般是可以按照套路出牌的，类似问题有"给你张白纸怎么测","一部电梯怎么测"等等，主要回答进行测试的角度即可。
答:
1)、可以从多个角度进行测试，如:
功能测试:盛水、倒水是否流畅，是否漏水。
易用测试:是否口大底小，易于手握住。
可靠测试:盛水一段时间后是否出现渗漏的情况，
依从性测试:材质、规格是否符合国家相关环境、安全标准
2)、对于软件测试而言，角度会更多，为了保证充分性可以参考 S09126 质量模型进行分析。
17.简述评审过程
18.测试结束的标准有哪些
答:
1)、测试的结束或者成功与否的标准，一般在《测试计划》中进行定义。
2)、每个公司制定的该标准也是各不相同，如:
A、没有新的 Bug 产生或者反弹
B、覆盖率和通过率达标:如高级需求 100%覆盖并通过，低级 30%盖并通过。
C、缺陷修复率，如致命 100%修复，轻微 70%修复
D、自动化测试用例的比例(IBM 软件研究院)