整理的测试问题提问单(测试计划篇)
上一篇 / 下一篇 2008-05-19 12:05:18 / 个人分类：Software Testing
什么是测试计划？
回答：
| 测试计划包含项目范围内的测试目的和测试目标的有关信息。此外，测试计划确定了实施和执行测试时使用的策略，同时还确定了所需资源。定义一个测试项目的过程，以便能够正确的度量和控制测试 |
2.测试计划在什么时候创建为最佳？
回答：在项目的一开始就应该创建最初的测试计划，该计划成为“主测试计划”。随着每次迭代的筹划，将创建一个或多个更精确的“迭代测试计划”，其中包含与指定迭代有关的更精确的数据。所有测试计划内容都建立在测试计划模版的基础上。上面一段话可能难于理解，下面以“瀑布式”开发模式为例来讲解一下具体情况：
如上图所示，对于确认及系统测试，在需求阶段就可以进行《测试计划》的编写，在执行测试计划之前的几个阶段都是在对测试计划进行完善设计的过程。
3.测试计划的作用是什么？
回答：1）提高测试工作的效率以及准确性，让测试工作有条理，有计划的进行，避免测试的“事件驱动”
2）使测试工作与整个开发活动更好的融合
3）规避风险，使资源和变更事先作为一个可控制的风险。
4.测试计划由哪些部分组成，各有什么作用？
回答：《测试计划》作为一个测试阶段的重要文档，各个公司根据实际情况的不同会定制符合自己情况的模版，下面我给出了一份在RUP中定义的《测试计划》模版，此模版可以自己根据情况定制。
《测试计划》模版见附件
5.制定测试计划有哪些步骤？
回答：
6.什么是测试需求？
回答：
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项后才进行测试
第二步，列出测试对象中的每个用例或构件。然后，为列出的每一项确定一个测试优先级指标并且说明您的理由。以下为确定测试优先级指标提供了一些指南。
当确定每一项的测试优先级指标时，应考虑下列各项：
先前确定的风险程度指标值
先前确定的实施概要程度指标值
主角说明（主角是否有经验？他们是否能够接受变通方法？等等）
合同责任（如果不交付用例或构件，测试对象能否被接受？）
确定测试优先级的策略包括：
对于每一项，将最高的评估因素（风险、实施概要等）值用作总体优先级。
确定一个最有意义的评估因素（风险、实施概要及其他），然后将该因素的值用作优先级。
使用评估因素的组合来确定优先级。
采用权重方案。在该方案中，将确定每个因素的权重，然后根据权重来计算各因素的值和优先级。
示例：
当使用最高的评估值来确定优先级时，得到的优先级为：
测试项 | 风险 | 实施概要 | 主角 | 合同 | 优先级 | ||||||||||||||||||||||||||||||||||||||||||||||||
安装新软件 |
相关阅读:
TAG: 测试理论
我的栏目标题搜索日历
我的存档数据统计
RSS订阅 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
