测试计划的目的是传达测试任务的意图。尽早创建此文档是至关重要的。即使是早在精化阶段的前几个迭代之一就生成此工件,也并不嫌太早。可能需要迭代地制定测试计划,当有信息可用时添加章节。
应谨慎而明确地表述测试范围、测试需求、测试策略以及所需资源。此信息确定测试工作的目的和范围、测试的内容、测试的方式以及测试所需的资源。明确地表述这些信息将加快对测试工作的复审、反馈和批准。
在项目开始时,应创建一个确定项目的整体预期测试的测试计划,称为“主测试计划”。计划每个迭代后,就会创建一个更精确的“迭代测试计划”(或多个按测试类型组织的测试计划),该计划中仅包含与该迭代相关的数据(测试需求、测试策略、资源等)。或者,此信息可以包含在迭代计划中(如果它不会使该迭代计划太难于管理或使用)。
下面是更好地确定和传达测试需求、测试风险和优先级以及测试策略的一些指南。
测试需求确定将测试什么。它们是测试的特定目标。当得出测试需求时,有一些可以应用的一般规则:
-
测试需求必须是可以观察、可以度量的行为。如果测试需求不能观察或度量,则无法评估它以确定是否已满足需求。
-
每个用例或系统的补充需求与测试需求之间没有一对一的关系。用例通常有多个测试需求,而一些补充需求将得出一个或多个测试需求,另一些却得不出需求(例如营销或包装需求)。
可以从许多源得出测试需求,包括用例、用例模型、补充规范、设计需求、业务案例、与用户的面谈和软件体系结构文档。应复审所有这些内容以收集用于确定测试需求的信息。
功能测试需求,恰如其名,源自测试目标的功能行为的描述。最低,每个用例应得出至少一个测试需求。一个更详细的测试需求列表将为每个用例事件流程包含至少一个测试需求。
性能测试需求源自测试目标的指定性能行为。 通常,性能被陈述为在各种条件下对响应时间和/或资源使用的度量,这些条件包括:
-
不同的工作负载和/或系统条件
-
不同的用例
-
不同的配置
性能的需求在“补充规范”中描述。复审这些资料,特别注意包含以下内容的陈述:
-
对时间的陈述,例如响应时间或计时概要信息
-
指示必须在规定的时间段中发生的事件或用例的数目的陈述
-
比较一个项与另一个项的行为的陈述
-
比较一个配置与另一个配置上的应用程序行为的陈述
-
一个时间段内的操作可靠性(失败或 MTTF 的平均时间)
-
配置或约束
您应对规范中反映诸如上述信息的每个陈述得出至少一个测试需求。
可靠性测试需求源自若干来源,通常在“补充规范”、“用户界面指南”、“设计指南”和“编程指南”中描述。
查看这些工作产品,对包括以下内容的语句要特别注意:
-
对可靠性或抵抗失败和运行时错误(例如内存泄漏)的陈述
-
指示代码完整性和结构(符合语言和语法)的陈述
-
关于资源使用的陈述
应从这些工作产品中反映上述信息的每个陈述中得出至少一个测试需求。
成功的测试要求测试活动成功地平衡诸如资源约束和风险之类的因子。为了做到这点,应排列测试活动的优先级,使最重要的、意义重大的或最有风险的用例或组件先进行测试。为了排列测试工作的级,会执行一项风险评估和操作概要信息,并将其用作制定测试优先级的基础。
以下章节描述如何确定测试优先级。
确定测试需求只是确定将测试什么的一部分。还应该对将测试什么和以什么顺序测试确定优先级。进行此步骤是出于若干原因,包括以下内容:
-
确保测试工作注重于最适用的测试需求
-
确保尽早处理最关键、最重要或风险最大的测试需求
-
确保测试任何诸如顺序或数据这样的依赖关系
评估风险和制定测试优先级分成三步:
下面提供了这三个步骤中每一个的指南:
制定测试的优先级从评估风险开始。由于失败而引起最大风险或者具有最大失败概率的用例或组件应在测试的第一批用例中。
以确定和描述将使用的风险量级指示符开始,例如:
-
H - 高风险,不可容忍。严重的外露。公司将承受巨大的财务损失、债务或不可恢复的声誉损失。
-
M - 中风险,可以容忍,但希望不要出现。最低外露,公司可能承受财务损失,但债务或声誉损失有限。
-
L - 低风险,可以容忍。很少或没有外露,公司有很少或没有财务损失或债务。公司的声誉不受影响。
确定风险量级指示符之后,列出测试目标中的每个用例或组件。对于列表中的每个用例或组件,确定一个风险量级指示符,并解释(以简短的陈述)您选择该值的理由。
有三个角度可以用于评估风险:
-
影响 - 指定的用例(需求等)失败导致的影响或后果
-
原因 - 以用例失败导致的不良后果开始,检验可能的原因
-
可能性 - 用例失败的概率。
选择一个角度,确定一个风险量级指示符,并解释您选择的理由。没有必要为每个风险角度均确定一个指示符。但是,建议如果确定了一个较低的指示符,请尝试另一个风险角度来评估该项,以确保该项确实是一个低风险。
下面是从这三个角度评估风险的更详细的信息。
要按后果评估风险,请确定一个条件、事件或操作,并尝试确定其影响。询问以下问题:
“如果 ___________,会发生什么情况?”
例如:
-
“如果在安装新软件时,系统磁盘空间不足,会发生什么情况?”
-
“如果在进行查询事务期间丢失因特网连接会发生什么情况?”
-
“如果在进行购买事务期间丢失因特网连接会发生什么情况?”
-
“如果用户输入了意外的值会发生什么情况?”
下面是这些项的一个样本解释矩阵:
描述
|
风险缓解因子
|
解释
|
安装期间磁盘空间不足
|
H
|
安装该软件向用户提供了产品的第一印象。任何不希望出现的结果(例如下面列出的那些)将会降低用户系统和所安装软件的性能,并向用户传达一个负面的印象:
-
安装了部分软件(一些文件、一些注册表项),这将使所安装的软件处于不稳定的状态
-
安装停止,使系统处于不稳定的状态
|
查询期间因特网连接丢失
|
L
|
丢失连接对数据或数据库不会造成任何损坏。大家认识到丢失连接会向用户传达一个负面印象。
|
购买期间因特网连接丢失
|
H
|
导致下列后果的任何连接或事务丢失都是不可接受的,因为它们增加了开销成本并降低了利润:
-
数据库损坏
-
不完整的订单
-
丢失数据或订单
-
多个订单(重复)
|
输入了意外的值
|
H
|
导致下列后果的任何事务都是不可接受的:
|
按原因评估风险与按后果评估相反。以陈述不希望出现的事件或条件开始,确定可能允许该条件存在的事件的集合。询问如下问题:
“怎么会发生 ___________?”
例如:
-
“系统上怎么仅有一部分文件,而且没有设置所有注册表项?”
-
“中央数据库中怎么没有正确反映事务?”
-
“开票周期陈述怎么仅在数据库中反映了一部分满足所需条件的记录?”
下面是这些项的一个样本解释矩阵:
描述
|
风险缓解因子
|
解释
|
遗漏应用程序文件和注册表项
|
H
|
使该应用程序(并可能整个系统)无法使用。安装是用户看到的对应用程序的第一印象。如果安装因任何原因失败,则用户会对该软件产生不良印象。
此条件的可能原因包括:
-
安装过程未安装所有文件,未正确更新注册表
-
由于用户干涉(取消或退出),安装过程停止
-
由于软件/硬件干涉(磁盘空间不足、不受支持的配置等),安装过程停止
-
由于未知条件,安装过程停止
-
用户删除了文件/注册表项
在这些原因中,仅最后一个无法由安装过程检测并处理。
|
不完整的订单
|
H
|
不完整的订单无法履行,导致损失收入和客户。
可能的原因包括:
-
由于用户操作(断开调制解调器、关闭 PC 等)而丢失因特网连接
-
由于 IP 而丢失因特网连接
-
由于雇员操作(断开调制解调器、关闭服务器电源等)而丢失因特网连接
|
数据/数据库损坏
|
H
|
不管出于何种原因,均不能容忍损坏的数据。
可能的原因包括:
-
由于用户干涉,写入数据库的事务未完成/未提交
-
由于因特网连接丢失,写入数据库的事务未完成/未提交
-
用户在事务中输入了无效数据
-
数据库访问方法/实用程序
-
(当初始实例化时)数据库未正确填充
|
重复的订单
|
H
|
通过与装运、处理和重新储存相关联的成本,重复的订单会增加公司开销并降低利润。
可能的原因包括:
-
由于用户干涉,将订单写入数据库的事务重复,用户输入订单两次 — 未确认输入
-
由于非用户干涉(从丢失的因特网连接恢复的过程、数据库恢复),将订单写入数据库的事务重复
|
订单中不精确的数据
|
H
|
任何不能完成的订单或招致额外开销成本的订单都是不可接受的。
可能的原因包括:
-
由于用户干涉,订单事务未完成/未提交
-
由于丢失因特网连接,订单事务未完成/未提交
-
用户输入了无效数据
|
语句中反映的记录数目错误
|
H
|
业务决策和应收科目依赖于这些报告的精确性。
可能的原因包括:
-
不正确的搜索/选择条件
-
不正确的 SQL 语句
-
数据库中数据损坏
-
数据库中数据不正确
|
按可能性评估风险是确定一个用例(或实施用例的组件)将失败的概率。该概率通常基于一个外部因子,例如:
应该注意,当使用这种风险角度时,风险量级指示符与失败的概率相关,而不是与像在按后果和原因评估风险中使用的失败对组织的后果或影响相关。
这些因子和失败概率之间存在相关性,如下所示:
外部因子
|
概率
|
失败发现率
|
当失败发现率或密度增加时,失败概率增加。
缺陷倾向于集中出现,因此,当在一个用例或组件中发现率或缺陷数目(或密度)增加时,发现另一个缺陷的概率也会增加。当使用此因子评估风险时,先前发布的发现率和密度也应考虑,因为先前的高发现率或密度表明其他失败的高概率。
|
变更率
|
当用例或组件的变更率增加时,失败概率增加。因此,当变更数目增加时,引入缺陷的概率也会增加。每次对代码做出变更,就有“注入”另一个缺陷的风险。
|
复杂性
|
当用例或组件的复杂性度量增加时,失败概率增加。
|
发起/发起方
|
关于代码发起之处和发起方的知识和经验可以增加或减小失败的概率。
使用第三方组件通常会减小失败的概率。但是,只有在该第三方组件已经认证的情况(通过正式测试或经验,满足您的需求)下才是这样。
失败概率通常随着实施者的知识和技能的增加而减小。但是,诸如使用新工具、技术或扮演多个角色的因素可能会增加失败的概率,即使是由最好的团队成员实施。
|
例如:
-
安装新软件
-
“过去,我们在用来实施用例 1、10 和 12 的组件中发现许多缺陷,客户请求在用例 14 和 19 中做出许多变更。”
下面是这些项的一个样本解释矩阵:
描述
|
风险缓解因子
|
解释
|
安装新软件
|
H
|
我们在编写自己的安装实用程序。
使该应用程序无法使用。安装是用户看到的对应用程序的第一印象。如果安装因任何原因失败,则用户会对该软件产生不良印象。
|
安装新软件
|
L
|
我们在使用商业上成功的安装实用程序。
尽管安装失败使应用程序无法使用,但选择的安装实用程序来自一个产品占据最大市场份额并营业超过四年以上的供应商。我们对他们的产品的评估表明产品满足我们的需要,客户满意他们的产品、供应商及其服务和支持水平。
|
在用例 1、10、12 中的高失败发现率/缺陷密度。
|
H
|
由于先前的高失败发现率和缺陷密度,用例 1、10 和 12 被视为高风险。
|
用例 14 和 19 中的变更请求。
|
H
|
对这些用例的大量变更增加了将缺陷注入代码的概率。
|
评估风险和建立测试优先级中的下一步是确定测试目标的操作概要信息。
以确定和描述将使用的操作概要信息量级指示符开始,例如:
-
H - 非常频繁地使用,每个阶段许多次,或由许多参与者或用例使用。
-
M - 频繁使用,每个阶段若干次,或由若干参与者或用例使用。
-
L - 不频繁使用,或由非常少的参与者或用例使用。
您选择的操作概要信息指示符应基于执行用例或组件的频率,包括:
-
一个参与者(或用例)在给定时间段内执行该用例(或组件)的次数
-
执行该用例(或组件)的参与者(或用例)的数目
通常,使用一个用例或组件的次数越多,操作概要信息指示符越高。
确定要使用的操作概要信息指示符之后,列出测试目标中的每个用例或组件。为您的列表中的每项都确定一个操作概要信息指示符,并陈述选择该指示符值的理由。工作负载分析文档(请参阅工作产品:工作负载分析文档)中的信息可以用于此评估。
示例:
-
安装新软件
-
从在线目录订购商品
-
下订单之后客户在线查询他们的订单
-
商品选择对话框
描述
|
操作概要信息因子
|
解释
|
安装新软件
|
H
|
执行一次(通常),但由许多用户执行。但是,如果不安装,应用程序就无法使用。
|
从目录订购商品
|
H
|
这是用户执行的最常见用例。
|
客户查询订单
|
L
|
很少有客户在下订单之后会查询它们
|
商品选择对话框
|
H
|
此对话框用于客户下订单和仓储员工补充库存。
|
评估风险和制定测试优先级中的最后一步是制定测试优先级。
以确定和描述将使用的测试优先级量级指示符开始,例如:
-
H - 必须测试
-
M - 应该测试,仅在所有 H 项测试之后才测试
-
L - 可以测试,但在测试完所有 H 和 M 项之前不测试
确定要使用的测试优先级量级指示符之后,列出测试目标中的每个用例或组件。为您的列表中的每项都确定一个测试优先级指示符,并陈述选择该指示符的理由。下面是确定测试优先级指示符的一些指南。
当为每项确定测试优先级指示符时,请考虑以下各项:
-
您先前确定的风险量级指示符值
-
您先前确定的操作概要信息量级值
-
参与者描述(参与者是否经历过?是否容忍变通方法?等)
-
合同义务(如果用例或组件未交付,测试目标是否将可以接受?)
制定测试优先级的策略包括:
-
将每项的最高评估因子(风险、操作概要信息等)值用作总体优先级。
-
将一个已评估因子(风险、操作概要信息、其他)确定为最重要,并使用该因子的值作为优先级。
-
使用已评估因子的组合确定优先级。
-
使用加权模式,其中各个因子被加权,因子的值和优先级基于权重计算。
示例:
-
安装新软件
-
从在线目录订购商品
-
下订单之后客户在线查询他们的订单
-
商品选择对话框
当使用最高的评估值确定优先级时的优先级:
项
|
风险
|
操作概要信息
|
参与者
|
合同
|
优先级
|
安装新软件
|
H
|
H
|
L
|
H
|
H
|
从目录订购商品
|
H
|
H
|
H
|
H
|
H
|
客户查询
|
L
|
L
|
L
|
L
|
L
|
商品选择对话框
|
L
|
H
|
L
|
L
|
H
|
当使用一个因子(风险)的最高评估值确定优先级时的优先级:
项
|
风险
|
操作概要信息
|
参与者
|
合同
|
优先级
|
安装新软件
|
H
|
H
|
L
|
H
|
H
|
从目录订购商品
|
H
|
H
|
H
|
H
|
H
|
客户查询
|
L
|
L
|
L
|
L
|
L
|
商品选择对话框
|
L
|
H
|
L
|
L
|
L
|
当使用加权值计算优先级时的优先级:
(请注意:在下面的矩阵中,H = 5,M = 3,L = 1。大于 30 的总加权值是高优先级测试项,大于等于 20 小于等于 30 的值是中优先级,小于 20 的值是低优先级)。
项
|
风险(x 3)
|
操作概要信息(x 2)
|
参与者(x 1)
|
合同(x 3)
|
加权值
|
优先级
|
安装新软件
|
5(15)
|
5(10)
|
1(1)
|
5(15)
|
41
|
H(2)
|
从目录订购商品
|
5(15)
|
5(10)
|
5(5)
|
5(15)
|
45
|
H(1)
|
客户查询
|
1(3)
|
1(2)
|
1(1)
|
1(3)
|
9
|
L(4)
|
商品选择对话框
|
1(3)
|
5(10)
|
1(1)
|
1(3)
|
17
|
L(3)
|
测试策略描述了特定测试活动的一般方法和目标。
一个好的测试策略应包含以下内容:
清楚地陈述正在实施的测试类型和测试的目标。明确地陈述该信息可以减少疑惑并将误解(尤其因为一些测试看起来非常相似)降到最低。目标应清楚地陈述为什么执行该测试。
示例:
“功能测试。功能测试注重于从用户界面执行在测试目标中实施的以下用例。”
“性能测试。系统的性能测试将专注于度量用例 2、4 和 8 - 20 的响应时间。对于这些测试,将使用一个参与者的工作负载来执行这些用例,而且不在测试系统上施加任何其他的工作负载。
“配置测试。通过执行配置测试来确定和评估测试对象在三种不同配置下的行为,并根据我们的基准配置来比较性能特征。”
清楚地陈述将执行测试的阶段。下面确定的是执行常见测试的阶段:
|
测试阶段
|
测试类型
|
单元
|
集成
|
系统
|
验收
|
功能测试
(配置、功能、安装、安全、容量)
|
X
|
X
|
X
|
X
|
性能测试
(个别组件的性能概要信息)
|
X
|
X
|
(X)
可选或当系统性能测试揭示缺陷时
|
|
性能测试
(负载、压力、争用)
|
|
|
X
|
X
|
可靠性
(完整性、结构)
|
X
|
X
|
(X)
可选或当其他测试揭示缺陷时
|
|
技术应描述将如何实施和执行测试。包括将测试什么、在测试执行期间要采取的主要操作以及用于评估结果的方法。
示例:
功能测试:
-
对于每个用例事件流,将确定一组代表性的事务,每个都代表当执行该用例时参与者采取的操作。
-
将为每个事务至少开发两个测试用例;一个测试用例反映正面条件,一个反映负面(不可接受的)条件。
-
在第一个迭代中,将以下面的方式测试用例 1 - 4 和 12:
-
用例 1:
-
用例 1 开始时参与者已登录应用程序并处于主窗口,而当用户指定了“保存”时终止。
-
将使用 Rational Robot 实施和执行每个测试用例。
-
验证和评估每个测试用例的执行将使用以下方法进行:
-
测试脚本执行(每个测试脚本是否成功地并如预想的那样执行?)
-
“窗口存在”或“对象数据”验证方法(在测试脚本中实施)将用于验证关键窗口显示,并验证在测试执行期间指定的数据被测试目标捕获/显示。
-
测试目标的数据库(使用 Microsoft Access)将在测试前检查,并在测试后再次检查,以验证测试期间执行的更改精确反映在数据中。
性能测试:
-
对于每个用例,如工作负载分析文档中所确定,一组代表性的事务将使用 Rational Suite PerformanceStudio(vu 脚本)和 Rational Robot(GUI 脚本)实施和执行。
-
至少三个工作负载将反映在测试脚本和测试执行时间表中,包括以下工作负载:
-
压力工作负载:750 个用户(15 % 经理、50 % 销售、35 % 营销)
-
峰值工作负载:350 个用户(10 % 经理、60 % 销售、30 % 营销)
-
额定工作负载:150 个用户(2 % 经理、75% 销售、23 % 营销)
-
用来执行每个事务的测试脚本将包含相应的计时器以捕获响应时间,例如总事务时间(在工作负载分析文档中定义)以及关键事务任务或进程时间。
-
这些测试脚本将执行工作负载一小时(除非工作负载分析文档另有说明)。
-
验证和评估每个测试(或工作负载)的执行将包括:
-
测试执行将使用状态直方图进行监视(以验证测试和工作负载如预期和希望的那样执行)
-
测试脚本执行(每个测试脚本是否成功地并如预想的那样执行?)
-
使用以下报告捕获和评估所确定的响应时间:
陈述完成标准是为了两个目的:
清楚的完成标准陈述应包含以下各项:
-
度量的功能、行为或条件
-
度量方法
-
度量的标准或符合程度
示例 1
-
所有计划的测试用例都已执行
-
所有确定的缺陷都已处理,形成协商一致的解决方法
-
所有计划的测试用例都已重新执行,所有已知缺陷都已按协商的那样处理,而且没有发现任何新的缺陷
示例 2
-
所有高优先级测试用例都已执行。
-
所有确定的缺陷都已处理,形成协商一致的解决方法。
-
所有严重性 1 或 2 的缺陷都已解决(状态为“已修复”或“已推迟”)。
-
所有高优先级的测试用例都已重新执行,所有已知的缺陷都已按协商的那样处理,并且没有发现任何新的缺陷。
示例 3
-
所有计划的测试用例都已执行。
-
所有确定的缺陷都已处理,形成协商一致的解决方法。
-
所有严重性 1 或 2 的缺陷都已解决(状态为“已验证”或“已推迟”)。
-
所有高优先级的测试用例都已重新执行,所有已知的缺陷都已按协商的那样处理,并且没有发现任何新的缺陷。
本节应确定可能影响测试策略中描述的测试工作的任何影响或依赖关系。这些影响可能包括:
-
人力资源(例如要支持/参与测试的非测试资源的可供性或需要)
-
约束(例如设备限制或可用性,或需要/缺乏特殊设备)
-
特殊需求,例如测试时间安排或系统访问权
示例:
-
测试数据库将需要一个数据库设计人员/管理员的支持,以创建、更新和刷新测试数据。
-
系统性能测试将在现有网络(支持非测试流量)上使用服务器。测试将需要安排到数小时之后,以确保网络上没有非测试流量。
-
测试目标必须使旧系统同步(或模拟同步)以实施和执行完全功能测试
|