软件测试第八章-测试计划与测试文档_第1页
软件测试第八章-测试计划与测试文档_第2页
软件测试第八章-测试计划与测试文档_第3页
软件测试第八章-测试计划与测试文档_第4页
软件测试第八章-测试计划与测试文档_第5页
已阅读5页,还剩44页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

第8章测试计划与测试文档

高效率的测试是经过计划的。成功的测试需要有一定的方法。利用组织良好的测试计划、测试用例和测试报告,正确交流和制订测试工作是测试人员达到目标的保障。本章主要讨论与每一测试活动有关的具体任务和可交付文档。本章重点:

测试计划

验证测试计划

确认测试计划

软件测试文档高效率的测试是经过计划的。成功的测试需要有一定的方法,包括条例、结构、分析和度量。

8.1测试计划好的测试计划应该包括以下几方面的内容:●

目的●测试策略

●资源配置●

任务明确●进度安排●风险分析●停止测试的标准●测试用例库●组装方式●记录手段●工具●回归测试8.2软件测试文档软件测试文档用来描述要执行的软件测试及测试的结果。测试文档的编制是测试工作规范化的一个重要组成部分。包括以下几个内容:●

测试计划:该计划描述测试活动的范围、方法、资源和进度,其中规定了被测试的对象,被测试的特性、应完成的测试任务、人员职责及风险等。●

测试设计规格说明:该说明详细描述测试方法,测试用例以及测试停止的准则等。●

测试用例规格说明:该说明描述测试用例涉及的输入、输出,对环境的要求,对测试规程的要求等。

测试步骤规格说明:该说明规定了实施测试的具体步骤。●

测试日志:该日志是测试小组对测试过程所作的记录。●

测试事件报告:该报告说明测试中发生的一些重要事件。●

测试总结报告:对测试活动所作的总结和结论。

8.2软件测试文档测试文档的类型8.2

测试文档验证需求的正确性检验测试资源明确任务的风险开发测试用例评价测试结果回归测试确定测试的有效性测试文档的重要性表现在以下几个方面:8.3

主测试计划制定主测试计划的目标是:规定测试活动的范围、方法、资源和进度;明确正在测试的项目、要执行的主要测试任务、每个任务的负责人,以及与计划相关的风险。制定主测试计划是要在上层文档中弄清全貌,要进行什么类型的测试,有多少验证测试工作,进行什么样的确认测试,需要什么样的整体策略等。(1)目标8.3

主测试计划

风险是指任何威胁到项目目标成功实现的因素。测试的一个基本的原则是对项目中最具风险的部分进行详细的测试,以确保最具破坏性的故障能够被发现。在测试的每个层次上确定基于风险的优先级问题非常重要。主测试计划风险管理要考虑的问题包括:

●软件的大小和复杂性;●软件的关键性;●软件开发过程成熟度;●测试形式,进行全面测试还是部分测试;●人员、经验和组织等。(2)风险分析8.3

主测试计划主测试计划可交付的文档之一是软件验证测试计划和确认测试计划。按照IEEE/ANSI标准,软件验证和确认测试计划大纲包括以下几方面的内容:

目的●参考文件●定义●验证和确认测试概要●生存周期的验证和确认测试任务●软件验证和确认测试报告●验证和确认测试管理(3)验证和确认测试计划大纲8.4

验证测试计划验证测试活动包括:需求验证功能设计验证详细设计验证代码验证验证任务包括对各个验证活动制定测试计划并执行测试。8.4.1

制定验证测试计划(1)制定验证测试考虑的问题:

要进行的验证活动(需求验证、功能设计验证、详细设计验证、代码验证);●采用的方法(审查、走查等);●软件需要或不需要进行验证测试的区域;●不对软件某些区域进行验证测试的风险;●所需的资源、进度、设备、工具、责任等。8.4.1

制定验证测试计划(2)验证测试计划大纲

验证测试计划大纲包括以下几方面的内容:

测试计划标识●验证活动●要验证和不要验证的区域●任务●责任●人员配备和培训●进度安排●风险和意外事故●审批8.4.2验证执行验证执行可采用审查、走查、伙伴检查等方式进行。(1)审查报告

每次验证执行后应提交一份相应的审查报告。审查报告(大纲)可包括如下几方面的内容:

审查报告标识●测试项目和版本●参审人员●被审查材料的规模●审查小组的准备时间●返工的工作量及返工结束的预期日期●故障清单●故障概要(分类整理的故障数量)8.4.2验证执行(2)验证测试报告验证测试报告是对验证活动的概要说明。验证的目标是对所有与软件有关的文档进行验证测试,但最终验证了多少?出现了哪些需要解决的内部问题?哪些已经完成?哪些还没有完成?可以把验证测试报告当作一种执行概要,用于提高管理层对测试过程的认识,引起他们对有关问题的注意。每一验证活动都应有一个验证测试报告,目的是对这一验证活动的所有验证进行概括总结。8.5确认测试计划确认测试活动包括:

单元测试和集成测试●可用性测试●功能测试●系统测试●验收测试确认测试任务

●将所有确认测试活动看作一个整体,制定主确认测试计划●以确认测试活动为单位制定详细测试计划,开发测试用例,执行测试,评估测试,维护测试。8.5.1制定确认测试计划(1)制定确认测试计划时应考虑的几个问题:

确认测试采用的方法●测试执行所需的设备●测试工具和支撑软件●测试配置管理●风险分析、预算、资源要求、进度安排、人员配备等。8.5.1制定确认测试计划(2)主确认测试计划大纲主确认测试计划是为整个确认测试工作制定的,是对整个确认测试工作的概括,即确定具体的确认测试活动、每一确认测试活动大致需要的资源、粗略的进度安排、总的培训要求和风险等,但不涉及具体的细节。主确认测试计划包括目的和大纲两方面的内容。8.5.1制定确认测试计划(2)主确认测试计划大纲目的:规定测试活动的范围、方法、资源要求和进度安排等。大纲包含以下一些内容:

●测试计划标识●测试概述●测试项目●要测试的特征●不要测试的特征●测试方法●测试任务●测试环境要求●进度安排●项目通过/不通过的标准●测试停止标准●测试可交付文档●风险和偶然事件●人员配备和培训要求●审批8.5.2测试结构设计每个重要的软件产品都有并且只有一个测试结构规格说明,用来说明测试是如何组织的,它们是基于需求还是基于功能还是基于内部结构的测试?如何将它们进行分类?如何构建测试用例库等?测试结构设计需要考虑几方面的内容:●测试基础(基于需求、功能、还是内部结构);●测试的分类和分类规则;●测试用例库的结构和命名则等。8.5.3详细测试设计

详细测试设计是指定测试方法并确定测试用例的过程,包括确定测试的目标,哪些方面要优先考虑,对于相关的测试项目组,任何集中高层测设计,但详细测试设计不给出具体的测试用例或者执行测试的步骤。(1)详细测试设计考虑的问题:

测试目标;●测试结构;●设计测试用例等。8.5.3详细测试设计(2)详细测试设计的基本步骤确定要测试的目标;以风险为基础确定哪些项目要优先测试;针对相关测试项目组,开发高层测试设计;根据高层测试设计,设计测试用例。8.5.3详细测试设计(3)测试目标确定测试目标确定是指确定所有要测试项目的目标,即对需求和功能设计规格说明进行仔细研究、分解和分析,为基于功能的测试开发出测试目标清单。对测试目标清单进行提炼时可采取以下几步:如果基于需求和基于功能的测试目标清单是独立开发出来的,则对两份清单进行比较,删除多余的测试目标。以进度安排、资源要求和不测试各项的风险为基础,对各测试目标进行低、中、高优先级筛选。对于每一目标清单,生成一个覆盖矩阵,用以说明测试目标和测试用例之间的关系,即哪些测试用例覆盖了哪些测试目标。对于关键软件,生成一个需求跟踪矩阵。

一个需求跟踪矩阵示范。

8.5.3详细测试设计8.5.3详细测试设计(4)测试设计规格说明测试设计规格说明是一种概括性文档,其目的是组织和描述针对具体特征需要进行的测试,以帮助确定测试用例。按照IEEE/ANSI标准829/1983,测试设计规格说明包括:目的:指出测试方法的改进之处,确定设计和相关测试所覆盖的特征,确定测试用例和测试步骤,并指定特征通过/不通过标准。大纲:

●测试设计规格说明标识●要测试的特征●方法●确定测试用例●特征通过/不通过规则8.5.3详细测试设计(5)测试用例规格说明一个测试用例可以通过多个测试设计规格说明确定,每一个测试设计规格说明又有一个或多个测试用例规格说明。按照IEEE/ANSI标准829/1983,测试用例规格说明包括:目的:定义测试设计规格说明确定的测试用例。大纲:

●测试用例规格说明标识●测试项●输入要求●输出要求●环境要求●特殊要求●测试用例之间的依赖关系有条不紊地仔细计划测试用例,是达到测试目标的必由之路,因为:●

组织性。正确地计划和组织测试用例,有助于测试人员和其他项目小组成员有效地审查和使用它们。●

重复性。项目期间会多次执行同样的测试,以寻找新的软件故障,保证老的软件故障得以修复。●

跟踪。计划执行了多少个测试用例,在软件最终版本上执行了多少个测试用例,多少个测试失败?是否有忽略的测试用例,如果测试用例没有计划,就不能回答这些问题。●

测试证实。在少数高风险行业中,软件测试小组必须证明确实执行了计划执行的测试。发布忽略某些测试用例的软件实际上是不合法和危险的。8.5.3详细测试设计8.5.3详细测试设计(6)测试实施

实施是将每一测试用例规格说明翻译成可执行测试用例的过程。测试实施可交付的文档包括:

●测试用例●测试步骤规格说明●己完成的功能覆盖矩阵●己完成的需求覆盖矩阵●对于关键软件,己完成的需求跟踪矩阵8.5.3详细测试设计(7)测试步骤规格说明测试步骤规格说明一步一步解释如何进行测试设置,如何开始测试,如何监视测试运行,以及测试停止后如何重新开始测试。测试步骤规格说明包括:目的:确定进行测试需要的所有步骤。大纲:

测试步骤规格说明标识●特殊要求●启动测试的步骤●判断测试结果的标准●偶然事件处理步骤

●测试执行步骤8.5.3详细测试设计上面介绍的几种测试计划规格说明关系如图8-1所示。

8.5.4测试执行和事故报告1.测试执行测试执行是执行所有或挑选的测试用例并对结果进行观察的过程。包括:

测试用例选择●执行前设置、执行后分析●记录活动、结果和事件●判断故障是由软件错误还是由测试本身的错误引起的●测量内部逻辑覆盖测试执行的主要可交付文档包括测试记录、测试事故报告和逻辑覆盖报告。8.5.4测试执行和事故报告2.测试记录

测试记录保留了测试执行的有关细节。按照IEEE/ANSI标准829-1983,测试记录包括:目的:按时间顺序记录测试执行的有关细节。大纲:

●测试记录标识●测试描述●事件记录8.5.4测试执行和事故报告3.事故报告

事故报告是软件故障(即问题、缺陷、错误)报告的别名,其中最重要的部分是事故描述,这一部分不仅要描述出现的情况,还应该将预期结果与实际结果进行比较。报告软件故障的基本原则是:

●尽快报告软件故障。●有效描述软件故障。●报告软件故障时不做评价,只针对产品,陈述事实。●完善软件故障报告,保证软件故障被正确报告。小软件故障严重软件故障项目开始

时间

项目结束可能修复的软件故障图8-2时间和故障修复之间的关系8.5.4测试执行和事故报告时间和故障修复之间的关系软件故障的严重性和优先级

任何软件故障报告都必须由提供者注明故障的严重性和优先级别。严重性表示软件故障的恶劣程度,反映其对产品和用户的影响。优先级表示修复故障的重要程度和应该何时进行修复。严重性:系统崩溃、数据毁坏、数据丢失。遗漏功能、操作性错误、错误的结果。小问题、用户边面布局问题、罕见故障、错别字。建议。优先级:停止进一步测试,立即修复。在产品发布之前必须修复。如果时间允许,应该修复。可能会修复,但也可能发布。8.5.4测试执行和事故报告按照IEEE/ANSI标准829/1983,软件故障报告包括:目的:记录需要进一步调查的测试执行事件。大纲:

●软件故障报告标识●概述●软件故障描述●软件故障影响软件故障报告8.6测试评估(1)测试评估的内容

测试评估包括以下几个方面:●测试覆盖评估测试覆盖评估是对软件测试用例集合进行的全面性评价,并决定是否需要补充测试用例。

●软件故障评估软件故障评估则根据测试的执行对软件质量进行评价,并决定是否需要开发补充测试用例。

●测试有效性评估测试有效性评估是对照测试停止标准,对当前测试工作的整体有效性进行评价,以及决定是停止测试还是增加测试用例并继续测试的过程。

测试有效性评估8.6测试评估主要考虑的问题有:●决定停止测试还是继续测试。●如果决定继续测试,则需要补充哪些测试测试。●如果决定停止测试,如何撰写测试概要报告。8.6测试评估(2)测试总结报告最终文档是测试总结报告,对确认测试活动的结果作出概述。按照IEEE/ANSI标准829/1983,测试总结报告包括以下几方面的内容:目的:总结与一个或多个测试设计规格说明相关的测试活动结果并提供基于这些结果的评估。大纲:●测试总结报告标识●测试概要●测试活动概述●测试综合评价●测试结果概述●测试评估●测试审批8.7用户手册用户手册是事关产品成败的主要因素之一,其重要性决不低于代码本身。在开发过程中必须检查文档草稿以确保文档的正确性、可理解性和完整性,必须将手册当作产品的重要部分来对待,必须采用验证测试(包括计划和报告)的概念和方法对手册进行综合测试,其主要目标是找出功能设计规格说明和用户手册之间的差异。手册中的范例都应该作为手册测试的一部分接受测试,以判断它们运行起来是否与描述的一样。8.8IEEE/ANSI测试文档概述(1)测试计划和规格说明的文档结构SQAP:软件质量保证计划,每个软件测试产品一个。SVVP:软件验证和确认测试计划,每SQAP一个。VTP:验证测试计划:每个验证活动一个。MTP:主确认测试计划,每个SVVP一个。DTP:详细确认测试计划,每个活动一个或多个。TDS:测试设计规格说明,每个DTP一个或多个。TPS:测试步骤规格说明,每个TDS一个或多个。TCS:测试用例规格说明,每个TDS/TPS一个或多个。TC:

测试用例。每个TCS有一个TC。8.8IEEE/ANSI测试文档概述SQAPVTPVTPVTPSVVPMTPDTPDTPDTPDTPDTPDTPTDSTDSTDSTDSTCSTCSTCSTPSTPSTCTCTC每确认活动一个或多个图8-3测试计划和规格说明的文档结构8.8IEEE/ANSI测试文档概述(2)测试报告的文档结构VTR:验证测试报告。每个验证活动一个。TPS:测试步骤规格说明。TL:测试记录。每个测试执行一份。TIR:测试事故报告。每个事故一个。TSR:测试总结报告。8.9软件生存周期各阶段

的测试任务与可交付的文档

软件生存周期按瀑布模型可分为:需求、功能设计、详细设计、编码、测试和运行维护六个阶段,不同阶段可能在一定程度上有重复,但阶段结束必须按一定顺序进行,比如提交可交付文档、审批、签字等。8.9.1需求阶段(1)测试输入:

软件质量保证计划(任选)●需求(来自开发)(2)测试任务:

●制定验证和确认测试计划●对需求进行分析●对需求进行审核●分析并设计基于需求的测试,构造相应的需求覆盖或跟踪矩阵.(3)可交付的文档:

软件验证测试计划●验证测试计划(针对需求)●验证测试报告(针对需求)8.9.2功能设计阶段(1)测试输入:功能设计规格说明(来自开发)(2)测试任务:

●功能设计验证和确认测试计划●分析功能设计规格说明●审核功能设计规格说明●设计可用性测试●分析并设计基于功能的测试,构造相应的功能覆盖矩阵●实施基于需求和基于功能的测试(3)可交付的文档:

●(主确认)测试计划●验证测试计划(针对功能设计)●验证测试报告(针对功能设计)8.9.3详细设计阶段(1)测试输入:详细设计规格说明(来自开发)(2)测试任务:

详细设计验证测试计划●分析详细设计规格说明●审核详细设计规格说明●分析并设计基于内部的测试(3)可交付的文档:

详细确认测试计划●验证测试计划(针对内部设计)●验证测试报告(针对内部设计)●测试设计规格说明

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论