测试设计
-
一、
制
定测试计划
目的
收集和组织测试计划信息。
创建测试计划。
步骤
确定测试需求
确定测试需求是测试计划活动的开始。
测试需求确定测试对象以及测试工作
的范围和作用。
测试需求还用来确定整个测试工作
（如安排时间表、
测试设计等）
并作为测试覆盖的基础。
被确定的测试需求项必须是可核实的。
即
，
它们必须有一个可观察、
可评测
的结
果。无法核实的需求不是测试需求。
执行如下步骤确定测试需求：
复审所有材料。
由于测试需求可从多
种来源确定，因此作为第一步，对将要开发的应用程序
/
系
统的所有可用材料进行复审是十分重要的。
最常用的测试需求来源包
括现有的需
求列表、用例、用例模型、用例实现、补充规约、设计需求、商业理由、最终
用
户访谈以及对现有系统的复审。
指明测试需求。
< br>除确定测试需求的来源之外，
还必须有某种形式的确定方法来确定将成为测试目<
/p>
标的需求。
这将导致测试需求层次的产生。
该层次可能基于现有的层次结构，
也
可能是新近生成的。
层次结构是测试需求的逻辑分组。
常用分组方法包括按照用
例、
商业理由、
测试类型
（功能、
性能等）
或者以上各项的组合对项目进行分组。
本步骤产生的结果是一份确定将成为测试目标的需求的报告（层次
结构）。
评估风险
要获得对风险的认识，请执行如下操作：
确定并验证测试风险因子
测试工作需
要平衡资源约束和风险。最重要的测试需求能够反映最高的风险。
可从以下几个方面观察风险：
效果
-
用例（需求等）失效造成的影响或后果
原因
-
确定不合需要的结果，并确定哪些用例或需求一旦失效将产生该结果
可能性
-
用例或需求失效的概率
复审每一项测试需求并确定风险因子（比如高、中或低）。有
时从两个或更多方
面对风险进行评估可能会得到不同的风险因子。
在这种情况下，
请使用最高的风
险因子值。同时还应给出关于
对某一给定测试需求为何选择特定风险因子的说
明。
确定并验证测试的实施概要因子
大多
数应用程序都有某些功能是经常使用的，
而另外一些则是较少使用的。
< br>因此
要对应用程序进行合理的测试，
必须确保不仅测试具
有最高风险的测试需求，
而
且还应测试经常使用的功能（因为这
些功能通常是最终用户最频繁使用的）。
确定每一个测试需求
的实施概要因子，
并说明为什么确定特定因子值的原因。
这
可通过复审商业理由或者同最终用户及其经理访谈来完成。
另一种方
法是观察最
终用户与系统的交互行为或者使用监视
/
记录软件来记录最终用户与系统的交互
行为（供分析用）。
确定并验证测试优先级因子
在确定和验证每一个测试需求的测试风险和实施概要之后，
就应该确定和验证测
试优先级因子。
测试优先级因子确定测试需求的相对重要性以及测试其
的顺序或
时序。
测试优先级因子通过
利用风险因子、
实施概要、
合同义务、
其他约束或者它们的
组合来确定。
在确定测试优先级时，
考虑所有的因素十分重要，
这样可以确保测
试
适当而有重点。
制定测试策略
测试策略的目的是向每一个人传达如何进行测试以及采用何种评测标准来确定
测试的
完成和成功程度。
策略不必十分详尽，
但它应该向读者指明如何
进行测试。
制定测试策略包括：
确定和描述测试方法
测试方法是对如
何实施测试的说明（陈述）。它应该说明或指出测试对象、测试
时采取的主要操作以及如
何核实结果等。
说明应该为读者提供足够的信息以便他
们能够理
解测试的对象（尽管尚不了解测试深度），如以下说明陈述：
对于每一个用例，确定并执行测试用例，包括有效和无效的输入数据。
对于每一个用例都将设计和开发测试流程。
利用三个月的时间来实施测试过程以模拟客户账号管理。测试
过程包括添加、修改
和删除账号以及客户。
实施测试过程并通过
1500
个虚拟用户来执行测试脚本，每个用户都执行功能
A
、
B
和
C
，并且使用不同的输入数据。
确定测试标准
测试标准是关于测试的客观说明，它指明那些用于确定
/
识
别测试完成时间的值
和被测试应用程序质量。
测试标准可能包括
一系列说明或对其他文档
（比如方法
指南或测试标准等）的引用
。测试标准应确定：
测试对象（具体测试目标）
评测方法
评估评测方法所采用的标准
测试标准示例：
对于每一高优先级用例：
所有计划好的测试用例和测试过程已被执行。
所有确定的缺陷已被解决。
所有计划好的测试用例和测试过程已被重新执行并且没有发现
新的缺陷。
在上例中，
“对于每一高优先级用例”说明测试对象。
“所有计划好的测试用例
和测试过程已被执行”说明评测的方法。
评估标准包含在最后两个陈述
“所有确
定的缺陷已被解决”和“所有计划好的测试用例和测试过程已被重新执行并且<
/p>
没有发现新的缺陷”之中。
确定测试的特殊事项
应列出所有关于测试或者依赖关系的特殊事项，如下所示：
测试数据库将由操作资源恢复。
<
/p>
测试（性能）必须在办公结束后开始（不受日常的正常操作影响）并且在凌晨
5:00
以前结束。
必须与遗留系统同步（或模拟同步）
。
确定资源
一旦确定测试对象和测试方法，就需要确定执行测试人员及测
试活动所需支持。
确定资源需求包括确定所需的资源，资源包括如下：
< br>
人力资源（人员数量和技能）
测试环境（包括硬件和软件）
工具
数据
确定人力资源需求
对于大多数测试工作而言，您需要符合下列条件的人力资源：
管理和制定测试计划
设计测试及数据
实施测试和数据
执行测试并评估结果
管理和维护测试系统
确定非人力资源需求
测试环境（包括硬件和软件）
推荐使用两个不同的物理环境（尽管这不是必需的）：
执行测试管理、设计和实施活动的实施环境，以及
执行所有测试的执行环境，它是一个独立的执行系统（通常是
生产系统的克隆）
。
软件也有必要进行测试。
需要测试的软件最少应包括所测试的应用程序、
客户机
操作系统、网络以及服务器端操作系统。此外，可能还需要精
确地模拟
/
复制生
产环境的软件，这类
软件包括：
与其他系统（如遗留系统）的接口。
其他桌面应用程序，如
Microsoft
Office
、
Lotus Notes
等。
其他
驻留于文件服务器和网络或在其中执行的应用程序。当所测试的应用程序不需
要这些应用
程序时，它们就驻留在其执行环境中。
工具
应该声明何种软件工具（供测试
用）将被使用、被谁使用，以及使用各种工具所
能够获得哪些信息或好处。
数据
软件测试在很大程
度上取决于输入数据
（创建或支持某一测试条件）
和输出数据<
/p>
（同预期结果作比较）的使用。应确定解决以下与测试数据有关的问题的策略：
收集或生成用于测试的数据（输入
和输出）
。
数据库构架（隔离外界影响的手段以及在测试完成后将数据返回初始状态的方法）
。<
/p>
创建时间表
创建时间表包括：
估计测试工作
估计测试工作时，应考虑如下假设：
投入到项目中的人力资源的生产率
和技能
/
知识水平
（比如他们使用测试
工具或程序
的能力）
。
要构建的应用程序的有关参数（比如窗口数目、构件、数据实
体和相互关系以及重
复使用的百分比等）
。
测试覆盖
（实施并执行测试的
可接受深度）
。
如果只实施和执行一个测试用例
（对每
一个用例
/
需求）
，则表述每一个用例
/
需求是不同的。经常
需要多个测试用例来对某一个
用例
/
需
求进行可以接受的测试。
测试估计还应考虑到在测试生命周期
的各个阶段使用不同方式对工作进行划分，
这是因为某些类型的（工作）量在生命周期内
是变化的。例如，性能测试工作，
由于其包含在复杂环境中建立测试系统并执行测试的工
作，
因此该测试执行活动
就占了工作估计的很大比重。
此划分对于安排时间是很重要的。
测试设计和
测试实施工作需要一个单独的调度
时期，
并增加一些小的改进。
相比之下，
每一个应用程序工作版本都需要重复执
行测试，因此必须对测试执行工作做相应的调整。
测试工作需要包含回归测试的时间。
下表显示了经过不同测试阶段的几次迭代之
后回归测试用例是如何进行积累的。
迭代与阶段
系统
集成
单元
第一次迭代
本
次
迭
代
中
以
本次迭代中以工作版
本次迭代中以单元为目
系
统
为
目
标
的
本为目标的测试用例
标的测试用例
的测试
测
试
用
例
的
测
的测
试
试
下一次迭代
本
次
迭
代
测
试
用
例
以
及
用
于
回
归
测
试
的
先
前
迭
代
< br>的
测
试
用例的测试。
对本次迭代测试用例
本次迭代测试用例以及
以及用于回归测试的
用于回归测试的先前迭
先前迭代的测试用例
代的测试用例的测试。
的测试。
制定测试进度
测试项目时间表可以通
过工作估计和资源分配来建立。
在迭代开发环境中，
每一
迭代都需要一个独立的测试项目时间表。在每一迭代中都将重复所有的测试活
< br>动。
在某一特定迭代中，
测试计划和测试设计活动处理软
件中的新功能。
测试实
施活动包括为新功能创建新的测试用例，
并为已变更的功能修改测试用例。
测试
执行和评估步骤验证新功能并为现有功能执行回归测试。
早期迭代引入许多新功
能和新测试。
随着集成流程继续进行，
新测试的
数目将减少，
而需要执行以检验
累计功能的回归测试的数目将增
加。
因此，
早期迭代更多地要求在测试计划和设
计上进行工作，
而后期迭代则偏重于测试执行和评估。
为每一迭代提供详尽的时
间表是不可能的。
通常并不知道将会有
多少迭代，
或者在哪一次迭代中将达到某
一测试标准。
使用估计好的工作和已分配的资源创建测试工作的时间表。
以下示
例表概述了所有测试活动。
显示的工作估计是各项任务的相对工作数量
。
在制定
时间表时，
必须确保它符合实
际。
有些时间表很有野心，
但人们没有足够的时间
或精力来按时间安排行动，
从而导致无法成功执行测试。
这样的时间表是再令人
沮丧不过的了。