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