桩程序都是需要开发的。
8．负载测试是验证要检验的系统的能力最高能达到什么程度。（） 关于负载测试和压力测试在论坛中的帖子中有详细的解释，大家可以去看一下就能得出正确的答案
9．测试人员要坚持原则，缺陷未修复完坚决不予通过。（） 同样，这一题没有正确的答案。缺陷是否修复是需要听取测试人员的意见，但测试人员的意见非决定性。所以还是要看一个企业赋予测试人员有多大的权力。
10．代码评审员一般由测试员担任。（） 如果测试员有这个水平，那么当然是可以参加的。不过大多数的企业不会让普通的测试人员参与代码的评审。
11．我们可以人为的使得软件不存在配置问题。（） 首先大家先搞清楚什么是配置管理什么是软件配置，从这道题目中看不出出题人想问的是关键工程中的配置管理还是单纯的软件配置。但是可以肯定的是不论是何种情况，答案均是否定的。
12．集成测试计划在需求分析阶段末提交。（） 集成测试计划在开发人员完成软件集成计划之后就可以开始进行了。所以在需求分析阶段之后提交是不现实的事情，应该在软件的设计阶段后，编码前。
二、不定项选择题（每题2 分，10分） 1．软件验收测试的合格通过准则是：（）
A． 软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。 B． 所有测试项没有残余一级、二级和一
C． 立项审批表、需求分析文档、设计文档和编码实现一致。
D． 验收测试工件齐全。 回答这道题，你必须是这家企业的员工。前面说到了验收测试的目的和目标，一个是需求必须实现，二是证明软件是适合使用的。这样能满足这两个通用标准就可以了。当然有些软件企业会对验收测试标准做一些调整。
2．软件测试计划评审会需要哪些人员参加？（） A．项目经理 B．SQA 负责人 C．配置负责人
D．测试组 上面的4种角色都需要参与
3．下列关于alpha 测试的描述中正确的是：（） A．alpha 测试需要用户代表参加 B．alpha 测试不需要用户代表参加 C．alpha 测试是系统测试的一种
D．alpha 测试是验收测试的一种 首先大家需要知道alpha测试是系统级别的测试，该测试是在一个受控的环境中进行的。用户需要直接参与进来。所以答案应该是AD 转贴请注明 : http://www.pghome.net 志远工作室 4．测试设计员的职责有：（） A．制定测试计划
B．设计测试用例
C．设计测试过程、脚本
D．评估测试活动 合理的答案的是BC，同时要看软件企业对该类人员的职责是如何定义。
5．软件实施活动的进入准则是：（） A．需求工件已经被基线化 B．详细设计工件已经被基线化 C．构架工件已经被基线化
D．项目阶段成果已经被基线化 先要了解一下什么是基线。这个是软件配置管理中一个重要的概念。工作产品必须纳入到一定的基线里面。所以选择ABC是必定的，至于是否选择D要看这家企业自身的标准了
填空题（每空1分，24 分）
1．软件验收测试包括___、___、____三种类型。 软件验收测试包括正式验收测试、alpha测试、beta测试三种测试。 2．系统测试的策略有功能测试、、、、易用性测试、、、、、、、、 、、等15 种方法。 系统测试的策略有很多种的，我知道的有性能测试、负载测试、强度测试、易用性测试、安全测试、配置测试、安装测试、文档测试、故障恢复测试、用户界面测试、恢复测试、分布测试、可用性测试。。。
3．设计系统测试计划需要参考的项目文档有、和迭代计划。 设计系统测试计划需要参考的项目文档有软件测试计划、软件需求工件、和迭代计划。
4．对面向过程的系统采用的集成策略有___、___两种。 5．通过画因果图来写测试用例的步骤为___、___、___、___及把因果图转换为状态图共五个步骤。 利用因果图生成测试用例的基本步骤是： § 分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。 § 分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的是什么关系? 根据这些关系，画出因果图。 § 由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。 § 把因果图转换成判定表。 § 把判定表的每一列拿出来作为依据，设计测试用例。
常见的软件测试面试题
常见的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
1. 等价类划分
常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类
中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
2. 边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3. 错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例.
4. 因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
5. 正交表分析法
有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。
6. 场景分析方法
指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。
您认为做好测试用例设计工作的关键是什么？
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题
详细的描述一个测试活动完整的过程。
1. 项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后SQA进入项目，开始进行统计和跟踪
2. 开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。
3. 测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
4. 测试用例完成后，测试和开发需要进行评审。
5. 测试人员搭建环境
6. 开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现BUG后提交给BugZilla。
7. 开发提交第二个版本，包括Bug Fix以及增加了部分功能，测试人员进行测试。
8. 重复上面的工作，一般是3-4个版本后BUG数量减少，达到出货的要求。
9. 如果有客户反馈的问题，需要测试人员协助重现以及回归测试。
以往是否曾经从事过性能测试工作？请尽可能的详细描述您以往的性能测试工作的完整过程。
曾经做过一套网管系统的性能测试，主要测试该软件在同时管理大量终端的情况下，在响应时间，CPU/磁盘/内存等参数是否满足要求。
也曾经做过软交换系统的呼叫性能测试，主要是测试软交换系统在有大量呼叫的情况下，响应时间，呼叫成功率，CPU/磁盘/内存等参数是否满足设计要求。
您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
测试网管系统中，使用的Mimic来模拟终端，能够大量的节省成本。
测试软交换系统的时候，使用的Prolab来模拟终端并发送呼叫软交换，他完成了同时数百人才能完成的摘机拨号工作，主要工作原理是产生一些符合要求的IP包并发送给软交换系统，同时对软交换系统的回应进行处理，决定下一步动作。
您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？
主要是保障在大量用户的情况下，服务能正常使用。
在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
1. 在传统的BugZilla中，BUG描述应该包括以下的信息
2. 和BUG产生对应的软件版本
3. 开发的接口人员
4. BUG的优先级
5. BUG的严重程度
6. BUG可能属于的模块，如果不能确认，可以用开发人员来判断
7. BUG标题，需要清晰的描述现象
8. BUG描述，需要尽量给出重新Bug的步骤
9. BUG附件中能给出相关的日志和截图。
高质量的BUG记录就是指很容易理解的BUG记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。
对软件测试工程师面试题目的回答
01.为什么要在一个团队中开展软件测试工作？