1、什么是测试计划？ 回答：测试计划包含项目范围内的测试目的和测试目标的有关信息。此外，测试计划确定了实施和执行测试时使用的策略，同时还确定了所需资源。定义一个测试项目的过程，以便能够正确的度量和控制测试。
2、测试计划在什么时候创建为最佳？
回答：在项目的一开始就应该创建最初的测试计划，该计划成为“主测试计划”。随着每次迭代的筹划，将创建一个或多个更精确的“迭代测试计划”，其中包含与指定迭代有关的更精确的数据。所有测试计划内容都建立在测试计划模版的基础上。
对于确认及系统测试，在需求阶段就可以进行《测试计划》的编写，在执行测试计划之前的几个阶段都是在对测试计划进行完善设计的过程。
3、测试计划的作用是什么？
回答：1）提高测试工作的效率以及准确性，让测试工作有条理，有计划的进行，避免测试的“事件驱动”
2）使测试工作与整个开发活动更好的融合
3）规避风险，使资源和变更事先作为一个可控制的风险。
4、测试计划由哪些部分组成，各有什么作用？
回答：《测试计划》作为一个测试阶段的重要文档，各个公司根据实际情况的不同会定制符合自己情况的模版。
5、制定测试计划有哪些步骤？
回答：（省去---按部就班是写不出测试计划的）
6、什么是测试需求？
回答：测试需求的概念比较简单。例如，比方说一个计算平方根的程序，如果输入一个大于或等于零的数，程序可以给出一个结果；如果输入一个小于零的数，程序将指出输入错误。读过《软件测试的艺术》一书的工程师都会立即联想到边界值。对数值零进行测试；对零非常接近的负数进行测试，这就是两个具体的测试需求。
在一个更加复杂的程序中，你可以将打算测试的项目做成一个列表。但是，这些测试需求都不会确定具体的测试数据。例如，一个银行交易程序，一个测试需求是
试图支付客户的金额为负数，另一个测试需求是交易中的客户并不存在，等等。你有一系列这样的测试需求，它们并没有指出具体的数值或数据，如客户的姓名。
测试的下一步是选择满足这些测试需求的输入值/测试数据。一个简单的测试用例可能会同时满足好几个测试需求。一个用例能同时满足好几个测试需求，当然是最理想的情况，但是这样做的代价较高。另外一种方法是为每一个测试需求设计一个单独的测试用例，就可以不必考虑那些复杂的测试用例，但是这些相对简单的测试用例发现缺陷的能力就会有所下降。
这里有一个测试需求的实例：对一个哈希表的插入操作进行测试，有以下这些测试需求：
1）插入一个新的条目
2）插入失败－条目已经存在
3）插入失败－表已满
4）哈希表在插入前为空
这些就是测试需求，而非测试用例，因为它们没有对被插入元素进行描述。另外你也不能马上就着手书写用例，就好象软件需求完成后不能立即进行编码一样。还需要对测试需求进行评审，确保正确和没有需求遗漏。
7、确定测试需求的作用是什么？
回答：1）确定测试对象以及测试工作的范围和作用
2）确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础
8、确定测试需求的信息来源是什么？
回答：现有的需求列表，、用例、用例模型、用例实现、补充规约、设计需求、商业理由、最终用户访谈以及对现有系统的复审（PS：上面几种来源中最重要的是设计需求，其他文档在很多公司都是缺少的）
9、测试需求有哪几种类型，它们的具体内容分别是什么？
回答：分为 功能性测试需求，性能测试需求，可靠性测试需求。
功能性测试需求来自于测试对象的功能性行为说明。
性能测试需求来自于测试对象的指定性能行为。
可靠性测试需求有若干个来源，它们通常在补充规约、用户界面指南、设计指南和编程指南中进行说明。
10、评估风险的目的是什么？
回答：最大限度的提高测试效率并确定测试工作的优先级，制定一个可接受的测试顺序。（PS：简单的说就是把测试需求进行优先等级的划分，并描述这样划分的理由）
11、确定测试优先级的目的是什么？
回答：
1）确保将测试工作的重点放在最恰当的测试需求上
2）确保尽早地处理最关键，最有意义或风险最高的测试需求
3）确保在测试中考虑到了任意依赖关系（序列，数据等等）
12、如何评估风险并确定测试优先级？（PS：该问题篇幅很大，但在实际应用中大部分公司都没有应用该技术，所以只需了解即可，不必认真研究）
回答：具体的步骤如下：
1）评估风险
第一步：在评估风险之前，首先要确定并说明将要使用的风险程度指标（即优先级别的具体划分），一般的划分方法如下：
H - 高风险，无法忍受。 极易遭受外部的风险，公司公司将遭受巨大的经济损失、债务或不可恢复的名誉损失。
M - 中等风险，可以忍受，但是不希望其出现。遭受外部风险的可能性最小，公司可能会遭受经济损失，但只存在有限的债务或名誉损失
L - 低风险，可以忍受。根本不会或不太可能遭受外部的风险，公司只有少许经济损失或债务或根本没有损失。公司的名誉也不会受到影响
第二步：列出测试需求并为每个测试需求确定风险程度指标，并简要说明选择相应指标的理由。
可以从三个方面来评估风险：
（PS： 一般确定一个测试需求只需从一个方面来确定风险指标，但是对于确定为低风险的测试需求，最好在从另一方面进一步来确定风险指标）
影响 - 指定用例（需求等）失效后将造成的影响或后果
简单的来讲，就是如果测试需求没有得到满足，会产生什么不利影响，而这个影响处在什么风险等级上。
询问下面的问题来确定影响，“如果。。。。。。。。。，将出现什么情况”
原因 - 用例失效所导致的非预期结果
根据原因评估风险。在开始时可以声明某个非预期的事件或条件，并确定一组能够允许该条件存在的事件。询问如下问题：
___________为什么会发生？
可能性 - 用例失效的可能性
根据可能性来评估风险也就是确定用例（或实施用例的构件）失效的概率。这种概率通常基于某个外部因素，例如：
故障率和/或密度
变更率
复杂性
来源/始创人
应该注意的是：当根据这一方面来评估风险时，风险程度指标与发生故障的概率相关，而不是与故障对组织的影响（它用于根据结果和原因来评估风险）相关。
2）确定实施概要
第一步，确定实施概要程度指标，一般的划分方法如下：
H - 使用得相当频繁，在每个时期会使用很多次，或者由多个主角或用例使用。
M - 使用得比较频繁，在每个时期会使用若干次，或者由若干个主角或用例使用。
L - 很少使用，或者由很少的几个主角或用例使用
通常，用例或构件的使用次数越多，实施概要指标也就越高
第二步，列出测试对象中的每个用例或构件。为列出的每一项确定一个实施概要指标并且说明每个指标值的理由。工作量分析文档中的信息（请参阅工件：工作量分析文档，该工件我会在另一个问题中进行讲解）可用于此评估。
3）确定测试优先级
第一步，确定和说明将要使用的测试优先程度指标，一般的划分方法为：
H - 必须测试
M - 应该测试，只有在测试完所有 H 项后才进行测试
L - 可能会测试，但只有在测试完所有 H 和 M 项后才进行测试
第二步，列出测试对象中的每个用例或构件。然后，为列出的每一项确定一个测试优先级指标并且说明您的理由。
引用 删除 wangmin403522 / 2011-12-23 09:33:57
