软件测试面试题

测试计划文档的内容应该包括什么？其中哪些是最重要的？一

软件测试计划是指导测试过程的纲领性文件。包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。 测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试策略和测试方法（最好是能先评审）。 答：测试计划工作是对测试工作内容的一个有效的组织和规划，能保证测试工作有效的展开。测试计划工作包括测试目标，测试范围的定义，测试方法的选择，测试进度里程碑，测试资源的有效配置和管理。

测试计划工作也称为测试策略，主要描述测试工程的总体方法和目标，描述目前在进行那一阶段的测试（单元测试，集成测试，系统测试）以及每一阶段内进行的测试种类（功能测试，性能测试等）确定测试范围，生成测试数据等。

其中软件计划中的测试目标最重要，他的软件测试的所需要达成的最终结果。 你认为做好测试计划工作的关键是什么？

1. 明确测试的目标，增强测试计划的实用性

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

2. 坚持“5W”规则，明确内容与过程 “5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。 3. 采用评审和更新机制，保证测试计划满足实际需求

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

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

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

白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果 黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测

试，以最少的用例在合理的时间内发现最多的问题

答：测试用例设计工作的关键是对可行的和不可行的都要考虑。 1，输入 2，详细的操作步骤 3，预期输出 4，实际输出。 详细的描述一个测试活动完整的过程。

1. 项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后SQA进入项目，开始进行统计和跟踪

2. 开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。

3. 测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。 4. 测试用例完成后，测试和开发需要进行评审。 5. 测试人员搭建环境

6. 开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现BUG后提交给BugZilla。

7. 开发提交第二个版本，包括Bug Fix以及增加了部分功能，测试人员进行测试。 8. 重复上面的工作，一般是3-4个版本后BUG数量减少，达到出货的要求。 9. 如果有客户反馈的问题，需要测试人员协助重现以及回归测试。 常见的测试用例设计方法都有哪些？ 1. 等价类划分

划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 2. 边界值分析法

边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据. 3. 错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例. 4. 因果图方法

前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之

间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况. 5. 正交表分析法

有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。 6. 场景分析方法

指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。

在一次输入多个条件的完整性查询中。利用等价类划分法则和边界分析法则，首先利用等价类划分法，可以一个或多个结果是OK的测试用例，然后确认多个NG的测试用例，然后利用边界值分析法，可以对结果分别是OK和NG的测试用例进行扩展和补充。

以往是否曾经从事过性能测试工作？请尽可能的详细描述您以往的性能测试工作的完整过程。

曾经做过一套网管系统的性能测试，主要测试该软件在同时管理大量终端的情况下，在响应时间，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记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。

答：检测时间，系统环境，硬体环境，严重程度，程式版本，确认人，功能模块，问题描述，详细操作步骤，是否会重现。

问题描述和详细操作步骤要尽可能的详细。Bug应该尽量用书面语，对与严重程度比较高的缺陷要在相同环境下在测试一遍。

在C/S模式下，如果条件满足可以使用替换法来确认是client端的问题还是server端的问题。 答：一条Bug记录最基本应包含：编号、Bug所属模块、Bug描述、Bug级别、发现日期、发现人、修改日期、修改人、修改方法、回归结果等等；要有效的发现Bug需参考需求以及详细设计等前期文档设计出高效的测试用例，然后严格执行测试用例，对发现的问题要充分确认肯定，然后再向外发布如此才能提高提交Bug的质量。

BUG管理工具的跟踪过程

用BugZilla为例子

测试人员发现了BUG，提交到Bugzilla中，状态为new，BUG的接受者为开发接口人员 开发接口将BUG分配给相关的模块的开发人员，状态修改为已分配

开发人员和测试确认BUG，如果是本人的BUG，则设置为接收；如果是别的开发人员的问题，则转发出去，由下一个开发人员来进行此行为；如果认为不是问题，则需要大家讨论并确认后，拒绝这个BUG，然后测试人员关闭此问题。

如果开发人员接受了BUG，并修改好以后，将BUG状态修改为已修复，并告知测试在哪个版本中可以测试。

测试人员在新版本中测试，如果发现问题依然存在，则拒绝修改；如果已经修复，则关闭BUG。

您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？

尽量能有面对面的沟通，如果做不到，那么尽量能直接通过电话沟通，如果只能通过Email等非及时沟通工具的话，强调必须对特性的理解深刻以及能表达清楚。

一是真诚，二是团队精神，三是在专业上有共同语言，当然也可以通过直接指出一些小问题，而不是进入BUG Tracking System来增加对方的好感。 了。

测试人员在软件开发过程中的任务是什么？ 1、寻找Bug；

2、避免软件开发过程中的缺陷； 3、衡量软件的品质； 4、关注用户的需求。

总的目标是：确保软件的质量。

设计测试用例应当从以下几方面考虑：边界值，等价类划分，有效/无效值等。 4． 请描述软件测试活动的生命周期。 5． 画出软件测试技术图。 .区别阶段评审的与同行评审

同行评审目的:发现小规模工作产品的错误,只要是找错误; 阶段评审目的:评审模块 阶段作品的正确性 可行性 及完整性

同行评审人数:3-7人 人员必须经过同行评审会议的培训,由SQA指导 阶段评审人数:5人左右 评审人必须是专家 具有系统评审资格 同行评审内容:内容小 一般文档 < 40页, 代码 < 500行 阶段评审内容: 内容多,主要看重点 同行评审时间:一小部分工作产品完成

阶段评审时间: 通常是设置在关键路径的时间点上!

设计系统测试计划需要参考的项目文挡有：软件测试计划，软件需求工件和迭代计 划。

对面向过程的系统采用的集成策略有：自顶向下，自底向上两种。 画因果图来写测试用例的步骤为：

（1）分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类）， 哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。

（2）分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应 的是什么关系? 根据这些关系，画出因果图。

（3）由于语法或环境，有些原因与原因之间，原因与结果之间的组合情况不可 能出现。为表明这些特殊情况，在因果图上用一些记号标明约束或条件。 （4）把因果图转换成判定表。

（5）把判定表的每一列拿出来作为依据，设计测试用例。

测试用例通常包括那些内容？着重阐述编制测试用例的具体做法

软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。

重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ”

解释冷备份和热备份的不同点以及各自的优点

解答：热备份针对归档模式的数据库，在数据库仍旧处于工作状态时进行备份。而冷备份指在数据库关闭后，进行备份，适用于所有模式的 数据库。热备份的优点在于当备份时，数据库仍旧可以被使用并且可以将数据库恢复到任意一个时间点。冷备份的优点在于它的备份和恢复

操作相当简单，并且由于冷备份的数据库可以工作在非归档模式下,数据库性能会比归档模式稍好。（因为不必将archive log写入硬盘）

Linux常用命令有哪些，

SQL语句：增、删、改、查、创建视图、创建存储过程等，