单元测试计划.doc_第1页
单元测试计划.doc_第2页
单元测试计划.doc_第3页
单元测试计划.doc_第4页
单元测试计划.doc_第5页
免费预览已结束,剩余3页可下载查看

下载本文档

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

文档简介

单元测试计划Unit_Test.Doc单元测试计划2002.1.1Version: 1.0.0Written by iokingAll Rights Reserved更改记录更改日期说明更改标志2002-1-10审核/批准项目名称:版本号:签名HG审核人:签名:日期:客户批准人:签名:日期:其他意见:目录封面1前言411编写目的412背景413变更历史414定义、缩略词415参考资料42产品描述521功能描述522当前版本53测试概述531测试目标532测试方法5321白箱测试5323测试覆盖533进入准则634结束准则635考虑事项64控制和协调641测试案例检查和质量控制642测试流程643开发组和测试组之间程序版本控制65资源需求和依赖条件751软/硬件依赖条件752测试数据需求753测试人员需求76进度表7附录1.单元测试报告81前言11编写目的 编写指南:说明编写这份概要设计说明书的目的,指出预期的读者。 目的: 适用读者: 12背景 编写指南:说明待开发软件系统的名称;列出此项目的任务提出者、开发者、用户以及将运行该软件的计算站(中心)。 本概要设计说明书所针对的软件系统是:“”,以下用英文简称。该项目由委托北京华光数码公司开发,将运行在内部的计算机网络中。13变更历史 编写指南:本节主要说明在涉及本说明书的设计、开发阶段的变更历史。时间说明参与人员14定义、缩略词 编写指南:列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 本说明书所用文字定义:l 黑色字:一般文本,系统中的主要说明文本。l 蓝色字:表格、图形、重要流程图的标题。l 青色字:本章节的注意事项、编写指南。l 粉红色字:说明书中的重要用词、说明。l :表示保密或者待填写的文本。 缩写词表:缩略词、定义说明UT单元测试计划15参考资料 编写指南:列出有关的参考文件:本项目的经核准的计划任务书或合同,上级机关的批文;属于本项目的其他已发表文件;本文件中各处引用的文件、资料,包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。 以下是本说明书有关的参考文件:l GB/T l1457 软件工程术语2产品描述21功能描述编写指南:对本系统的功能描述可以列表形式做简要陈述,也可指明去参考那些已发表文档,如:需求说明书、功能说明书。22当前版本编写指南:指明本单元测试计划针对系统名称及版本,如:系统 版本:1.0。3测试概述31测试目标编写指南:列出单元测试的目标,必要时也说明单元测试需要完成的任务。l 测试程序或代码单元(例如程序或模块)的功能l 测试内部逻辑l 检查内部设计l 测试路径与条件覆盖面l 测试以外条件和错误处理32测试方法编写指南:说明本单元测试所采用的测试方法及如何实施这些方法,如:白箱测试。321白箱测试l 在白箱法中,测试者了解系统的内部。他们关心“怎么干”而不是“干什么”。l 白箱测试是逻辑导向的,测试者关心程序中控制流所有可能的途径的执行。l 白箱法本质上是单元测试方法(有时用于集成测试和操作性测试)并且几乎总是由技术人员进行。白箱测试的例子有:l 测试代码中的分支和判断l 跟踪程序中的逻辑路径323测试覆盖测试覆盖:一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度,测试覆盖包括函数、分支、扩展分支和条件覆盖等。覆盖种类:l 函数覆盖是最基本的测试要求,一般应该达到100%,即测试过所有的函数。l 条件覆盖指出真值条件和假值条件被测试的次数,在单元级测试时应该力求达到100%,不然的话就会留下未测试的代码,引发潜在的风险。但在集成测试时,要达到100%的条件覆盖是非常困难的。选择合适的测试覆盖指标依赖于你的测试目标。33进入准则编写指南:列出满足那些条件,才能进入单元测试。l 编码阶段已经审核完成l 项目经理已经批准了单元测试计划l 测试组已经设计好测试案例,经过测试组组长的检查,并通过项目经理批准l 测试数据已经准备好并经过检查l 测试资源已经到位(软件、硬件、人力)34结束准则编写指南:列出满足那些条件,才能结束单元测试,进入开发的下一个阶段。l 测试遇到的所有问题已经记录下来l 所有测试案例都已运行l 95的测试案例已经成功通过l 所有测试案例至少运行了三次,所有错误已经修改l 测试结果已经记录,测试分析报告已经提交项目经理检查35考虑事项l 单元划分l 局部数据结构l 重要的实行路径l 错误处理l 极端条件l 基于程序说明的测试案例4控制和协调41测试案例检查和质量控制编写指南:确定为了保证单元测试质量,应该做那些工作,如:所有测试案例应该经过测试负责人的检查。42测试流程测试人员发现一个错误/问题 | +-在单元测试记录库中增加一条错误记录 | +-通知开发人员(一般是测试员本人) | | | +-开发人员更正此错误/问题,并在该错误记录中注明 | +- | | | 循环 | +-通知测试人员 | | 直到 | | | | 测试 | +-测试人员验证此修改,并将结果记入该错误记录 | | 案例 | | | | 结束 | | | 结束此案例 +-若不成功43开发组和测试组之间程序版本控制编写指南:组内程序版本控制是进行高效率测试的基础之一。在本节要定义完善的版本控制规则。为测试组人员保存测试代码提供一个固定的、完整的测试程序目录。开发组负责对其内容的修改。所有编程人员必须在自己的工作站保存最新版本的代码,不得变更测试程序目录下的内容。在修改之前,由开发组负责人通知测试组负责人将做哪些修改和修改将影响的功能。5资源需求和依赖条件51软/硬件依赖条件编写指南:单元测试应在与开发环境一致的情况下进行,所有测试的软硬件环境应当配置完善。软/硬件名称数量开始日期截至日期说明52测试数据需求在测试案例运行前,应准备所有需要的测试数据。53测试人员需求编写指南:此节列明单元测试各阶段的人员需求,最好说明需要的时间。l 测试组组长:l 测试人员:l 测试案例设计人员:l 测试数据准备人员:l 测试运行人员:6进度表编写指南:用表格或MSProject中图表方式列出单元测试进度表,以便控制测试过程进度。附录1.单元测试

温馨提示

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

评论

0/150

提交评论