2016年马上就要过去了，作为一个没有测试培训经验就直接上岗的测试人员，感觉有必要对自己这近一年的测试工作做个总结。一是回顾下这一年做了什么，二是为以后的工作提供个借鉴，让自己能在测试道路上走的更加清晰。
但是发现自己居然无从说起......尴尬之余想起一种另类的总结，拿几套面试题来谈一谈，因为自己也没有培训经历，理论方面就看过一本Software Testing，就结合自己的实际工作来检验下能否通过面试吧。
软件测试面试题和答案
一、判断题
1．软件测试的目的是尽可能多的找出软件的缺陷。（Y）
2．Beta测试是验收测试的一种。（Y）
3．验收测试是由最终用户来实施的。（N）
4．项目立项前测试人员不需要提交任何工件。（Y）
5．单元测试能发现约80%的软件缺陷。（Y）
6．代码评审是检查源代码是否达到模块设计的要求。（N）
7．自底向上集成需要测试员编写驱动程序。（Y）
8．负载测试是验证要检验的系统的能力最高能达到什么程度。（N）
9．测试人员要坚持原则，缺陷未修复完坚决不予通过。（N）
10．代码评审员一般由测试员担任。（N）
11．我们可以人为的使得软件不存在配置问题。（N）
12．集成测试计划在需求分析阶段末提交。（N）
判断题解析总结：
1.软件测试的目的。曾在Software Testing这本书中看到，软件测试的目的不是发现所有缺陷提交一个完美的产品，软件测试的目的是在软件上线前尽可能早的发现更多的bug。那么这里我还想谈下为什么要尽早的发现bug。
以我们公司为例，一个bug的生命周期包括提交→确认→分配→设计→处理→申请发版→已发版→测试通过→关闭，一旦在回归测试过程中发现问题，那么会将这个BUG打回到确认状态再进行一次处理。这是时间的浪费，这是成本的增加。如果在设计及处理阶段就能把问题处理的干净利落，那么会省很多麻烦，而做到这一点可能就还需要在处理完成后添加单元测试，或者是Code Review，但是这样也会增加成本，并且对测试人员的要求能力更高，不然没法体现出这个位置的价值。没有单元测试或Code Review那就需要开发人员提高自测的质量了。
2.验收测试：验收测试包括alpha测试，beta测试，验收测试。我并没有这三种验收测试的理论概念，先来看下百度是怎么定义这三种测试的：
Alpha测试是由用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。开发者坐在用户旁边，这是在开发者受控的环境下 进行的测试。由开发者随时记录下错误情况和使用中的问题并进行修改。
Beta测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试，它是在系统根本完成时进行的测试。开发者通常不在测试现场，这是在开发者无法控制的环境下进行的测试。由用户记录下遇到的所有问题，定期向开发者报告。beta测试是一模拟真实的使用环境从而发现缺陷的一种测试
验收测试是以用户为主的测试，软件开发和QA人员也应该参加，测试一般在用户所在地进行，由用户验证软件产品是否满足了所有的需求的一系列的验收测试工 作。仅限于做项目的公司，部门内部测试稳定后，根据合同中需求由发包商进行验收测试。验收测试的目的是为了以发现”未实现的需求”为目的，以评估”适合使用”为目标， 该类测试的不是以发现缺陷为主要目的。
我认为不同公司对于验收测试的方法是不一样的。以我们公司的项目为例：我们的验收测试一般分为两种，普通专题类验收测试和大型项目更新验收测试。当客户需要上线一个新功能（专题），当我们测试人员测试完毕，会提供给客户一个相对稳定的服务器环境进行测试，客户将问题直接反馈给测试人员，再由我们测试人员与开发沟通；大型项目更新换代测试的话，这个就需要客户驻场测试，来到我们公司进行验收测试，会直接与开发及我们测试进行沟通。结合实际工作来说，我们的验收测试并没有说很好的吻合这三种测试的哪一种，我认为这个要根据项目的实际需要来。alpha测试有点像我们外派测试人员，beta测试有点像我们的专题验收测试，而验收测试则与客户来我们公司进行驻场验收有点相像。
3.测试流程规范：上面已经提到了我们bug管理生命周期，其实这也是一个测试流程规范。在bug处理完成阶段，开发会进行代码评审；在测试阶段，我们会有测试案例评审；在发版上线阶段，我们还会有开发和测试共同的bug评审。经过这一系列工作，一个bug的修改或者一个新功能才会提交到生产环境。那么同样也会遇到这样一个尴尬的问题，如果一个功能已经到了计划上线日期，还有缺陷存在，那到底是上还是不上。相信很多测试人员都会遇到这样的问题。那在我们这边是怎么处理的呢？在这里首先我们还要有这样一个概念：软件缺陷等级。在简答题中也有问到。
A类—严重错误，包括以下各种错误： 1． 由于程序所引起的死机,非法退出 2． 死循环 3． 数据库发生死锁 4． 因错误操作导致的程序中断 5． 功能错误 6． 与数据库连接错误 7． 数据通讯错误
B类—较严重错误，包括以下各种错误： 1． 程序错误 2． 程序接口错误 3． 数据库的表、业务规则、缺省值未加完整性等约束条件
C类—一般性错误，包括以下各种错误： 1． 操作界面错误（包括数据窗口内列名定义、含义是否一致） 2． 打印内容、格式错误 3． 简单的输入限制未放在前台进行控制 4． 删除操作未给出提示 5． 数据库表中有过多的空字段
D类—较小错误，包括以下各种错误： 1． 界面不规范 2． 辅助说明描述不清楚 3． 输入输出不规范 4． 长操作未给用户提示 5． 提示窗口文字未采用行业术语 6． 可输入区域和只读区域没有明显的区分标志
E类—测试建议
对于一个不完美的功能，我们会评审是否满足上线需求，在不影响正常的用户体验的情况下，是可以让软件带着缺陷上线的，但是如果有重大缺陷BUG级别，那是没办法上线的。如果非要上线，测试人员一定要记得写一份测试报告，将软件缺陷及影响程度详细记录发给上级领导，这个锅不能随便背!
二、选折
1．软件验收测试的合格通过准则是：（ABCD）
A．软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。
B．所有测试项没有残余一级、二级和三级错误。
C．立项审批表、需求分析文档、设计文档和编码实现一致。
D．验收测试工件齐全。
2．软件测试计划评审会需要哪些人员参加？（ABCD）
A．项目经理
B．SQA负责人
C．配置负责人
D．测试组
3．下列关于alpha测试的描述中正确的是：（AD）
A．alpha测试需要用户代表参加
B．alpha测试不需要用户代表参加
C．alpha测试是系统测试的一种
D．alpha测试是验收测试的一种
4．测试设计员的职责有：（BC）
A．制定测试计划
B．设计测试用例
C．设计测试过程、脚本
D．评估测试活动
5．软件实施活动的进入准则是：（ABC）
A．需求工件已经被基线化
B．详细设计工件已经被基线化
C．构架工件已经被基线化
D．项目阶段成果已经被基线化
三、添空
1.软件验收测试包括：正式验收测试，alpha测试，beta测试。
2.系统测试的策略有：功能测试，性能测试，可靠性测试，负载测试，易用性测试，强度测试，安全测试，配置测试，安装测试，卸载测试，文挡测试，故障恢复测试，界面测试，容量测试，兼容性测试，分布测试，可用性测试，（有的可以合在一起，分开写只要写出15就满分哦）
3.设计系统测试计划需要参考的项目文挡有：软件测试计划，软件需求工件和迭代计划。
4.对面向过程的系统采用的集成策略有：自顶向下，自底向上两种。
5.（这题出的有问题哦，详细的5步骤为~~）通过画因果图来写测试用例的步骤为：
（1）分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。
（2）分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的是什么关系?根据这些关系，画出因果图。
（3）由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。
（4）把因果图转换成判定表。
（5）把判定表的每一列拿出来作为依据，设计测试用例。
四、简答（资料是搜集整理的，感谢前辈的解题）无
1.区别阶段评审的与同行评审
同行评审目的:发现小规模工作产品的错误,只要是找错误;
阶段评审目的:评审模块阶段作品的正确性可行性及完整性
同行评审人数:3-7人人员必须经过同行评审会议的培训,由SQA指导
阶段评审人数:5人左右评审人必须是专家具有系统评审资格
同行评审内容:内容小一般文档< 40页,代码< 500行
阶段评审内容:内容多,主要看重点
同行评审时间:一小部分工作产品完成
阶段评审时间:通常是设置在关键路径的时间点上!
2.什么是软件测试
为了发现程序中的错误而执行程序的过程
3简述集成测试的过程
系统集成测试主要包括以下过程：
1.构建的确认过程。
2.补丁的确认过程。
3.系统集成测试测试组提交过程。
4.测试用例设计过程。
5.测试代码编写过程。
6. Bug的报告过程。
7.每周/每两周的构建过程。
8.点对点的测试过程。
9.组内培训过程。
4怎么做好文档测试
仔细阅读，跟随每个步骤，检查每个图形，尝试每个示例。P142
检查文档的编写是否满足文档编写的目的
内容是否齐全，正确
内容是否完善
标记是否正确
5白盒测试有几种方法
总体上分为静态方法和动态方法两大类。
静态：关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义
动态：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
6系统测试计划是否需要同行审批，为什么
需要，系统测试计划属于项目阶段性关键文档，因此需要评审。
7Alpha测试与beta的区别
Alpha测试在系统开发接近完成时对应用系统的测试；测试后仍然会有少量的设计变更。这种测试一般由最终用户或其它人员完成，不能由程序或测试员完成。
Beta测试当开发和测试根本完成时所做的测试，最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其它人员完成，不能由程序员或测试员完成。
8比较负载测试，容量测试和强度测试的区别
负载测试：在一定的工作负荷下，系统的负荷及响应时间。
强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。
容量测试：容量测试目的是通过测试预先分 析出反映软件 系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试 还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据 的，并且它的目的是显示系统可以处理目标内确定的数据容量。
9测试结束的标准是什么？
用例全部测试。
覆盖率达到标准。
缺陷率达到标准。
其他指标达到质量标准
实际工作总结：测试案例执行完毕；测试覆盖率达到标准；缺陷率达到标准；验收测试完毕，提交验收报告。
10描述软件测试活动的生命周期？
测试周期分为计划、设计、实现、执行、总结。其中：
计划：对整个测试周期中所有活动进行规划，估计工作量、风险，安排人力物力资源，安排进度等；
设计：完成测试方案，从技术层面上对测试进行规划；
实现：进行测试用例和测试规程设计；
执行：根据前期完成的计划、方案、用例、规程等文档，执行测试用例。
总结：记录测试结果，进行测试分析，完成测试报告。
实际工作总结：上面谈到了bug的生命周期，这里谈的是测试活动生命周期。在我的测试工作中，是这样的：
1.确定测试范围。（大体知道自己要测试哪些东西）
2.制定测试计划。（大体分析出需要多长时间可以测试完成并制定计划）
3.如果作为一个测试团队来说的话，多人共同测试的话还需要进行测试分工。
4.拿到具体的测试功能模块，就要进行测试案例设计编写了。
5.进行测试案例评审。
6.执行测试案例。
7.测试总结。
11软件的缺陷等级应如何划分？
见判断分析
------------------------------------------------------未完待续----------------------------------------------------------------