当前位置:文档之家› 单元测试计划

单元测试计划

Unit_T est.Doc

单元测试计划

2002.1.1

Version: 1.0.0

Written by ioking

All Rights Reserved

更改记录

审核/批准

签名

目录

封面

1.前言 (4)

1.1.编写目的 (4)

1.2.背景 (4)

1.3.变更历史 (4)

1.4.定义、缩略词 (4)

1.5.参考资料 (4)

2.产品描述 (5)

2.1.功能描述 (5)

2.2.当前版本 (5)

3.测试概述 (5)

3.1.测试目标 (5)

3.2.测试方法 (5)

3.2.1.白箱测试 (5)

3.2.3.测试覆盖 (5)

3.3.进入准则 (6)

3.4.结束准则 (6)

3.5.考虑事项 (6)

4.控制和协调 (6)

4.1.测试案例检查和质量控制 (6)

4.2.测试流程 (6)

4.3.开发组和测试组之间程序版本控制 (6)

5.资源需求和依赖条件 (7)

5.1.软/硬件依赖条件 (7)

5.2.测试数据需求 (7)

5.3.测试人员需求 (7)

6.进度表 (7)

附录1.单元测试报告 (8)

1.前言

1.1.编写目的

编写指南:说明编写这份概要设计说明书的目的,指出预期的读者。

目的:

适用读者:

1.2.背景

编写指南:说明待开发软件系统的名称;列出此项目的任务提出者、开发者、用户以及将运行该软件的计算站(中心)。

本概要设计说明书所针对的软件系统是:“×××××”,以下用英文简称×××。该项目由××××××××委托北京华光数码公司开发,将运行在××××××××内部的计算机网络中。

1.3.变更历史

编写指南:本节主要说明在涉及本说明书的设计、开发阶段的变更历史。

1.4.定义、缩略词

编写指南:列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

本说明书所用文字定义:

●黑色字:一般文本,系统中的主要说明文本。

●蓝色字:表格、图形、重要流程图的标题。

●青色字:本章节的注意事项、编写指南。

●粉红色字:说明书中的重要用词、说明。

●×××:表示保密或者待填写的文本。

缩写词表:

1.5.参考资料

编写指南:列出有关的参考文件:本项目的经核准的计划任务书或合同,上级机关的批文;属于本项目的其他已发表文件;本文件中各处引用的文件、资料,包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。

以下是本说明书有关的参考文件:

●GB/T l1457 软件工程术语

2.产品描述

2.1.功能描述

编写指南:对本系统的功能描述可以列表形式做简要陈述,也可指明去参考那些已发表文档,如:《×××需求说明书》、《×××功能说明书》。

2.2.当前版本

编写指南:指明本单元测试计划针对系统名称及版本,如:×××系统版本:1.0。3.测试概述

3.1.测试目标

编写指南:列出单元测试的目标,必要时也说明单元测试需要完成的任务。

●测试程序或代码单元(例如程序或模块)的功能

●测试内部逻辑

●检查内部设计

●测试路径与条件覆盖面

●测试以外条件和错误处理

3.2.测试方法

编写指南:说明本单元测试所采用的测试方法及如何实施这些方法,如:白箱测试。

3.2.1.白箱测试

●在白箱法中,测试者了解系统的内部。他们关心“怎么干”而不是“干什么”。

●白箱测试是逻辑导向的,测试者关心程序中控制流所有可能的途径的执行。

●白箱法本质上是单元测试方法(有时用于集成测试和操作性测试)并且几乎总是由

技术人员进行。

白箱测试的例子有:

●测试代码中的分支和判断

●跟踪程序中的逻辑路径

3.2.3.测试覆盖

测试覆盖:一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度,测试覆盖包括函数、分支、扩展分支和条件覆盖等。

覆盖种类:

●函数覆盖是最基本的测试要求,一般应该达到100%,即测试过所有的函数。

●条件覆盖指出真值条件和假值条件被测试的次数,在单元级测试时应该力求达到

100%,不然的话就会留下未测试的代码,引发潜在的风险。但在集成测试时,要

达到100%的条件覆盖是非常困难的。选择合适的测试覆盖指标依赖于你的测试目

标。

3.3.进入准则

编写指南:列出满足那些条件,才能进入单元测试。

●编码阶段已经审核完成

●项目经理已经批准了单元测试计划

●测试组已经设计好测试案例,经过测试组组长的检查,并通过项目经理批准

●测试数据已经准备好并经过检查

●测试资源已经到位(软件、硬件、人力)

3.4.结束准则

编写指南:列出满足那些条件,才能结束单元测试,进入开发的下一个阶段。

●测试遇到的所有问题已经记录下来

●所有测试案例都已运行

●95%的测试案例已经成功通过

●所有测试案例至少运行了三次,所有错误已经修改

●测试结果已经记录,测试分析报告已经提交项目经理检查

3.5.考虑事项

●单元划分

●局部数据结构

●重要的实行路径

●错误处理

●极端条件

●基于程序说明的测试案例

4.控制和协调

4.1.测试案例检查和质量控制

编写指南:确定为了保证单元测试质量,应该做那些工作,如:所有测试案例应该经过测试负责人的检查。

4.2.测试流程

测试人员

发现一个错误/问题

|

+----->在单元测试记录库中增加一条错误记录

|

+----->通知开发人员(一般是测试员本人)

| |

| +----->开发人员更正此错误/问题,并在该错误记录中注明

| +-----> |

| | 循环 | +----->通知测试人员

| | 直到 | |

| | 测试 | +----->测试人员验证此修改,并将结果记入该错误记录

| | 案例 | |

| | 结束 | |

| <-----+ 若成功 ---> 结束此案例

+<--------------------------若不成功

4.3.开发组和测试组之间程序版本控制

编写指南:组内程序版本控制是进行高效率测试的基础之一。在本节要定义完善的版本控制规则。

为测试组人员保存测试代码提供一个固定的、完整的测试程序目录。开发组负责对其内容的修改。所有编程人员必须在自己的工作站保存最新版本的代码,不得变更测试程序目录下的内容。在修改之前,由开发组负责人通知测试组负责人将做哪些修改和修改将影响的功能。

5.资源需求和依赖条件

5.1.软/硬件依赖条件

编写指南:单元测试应在与开发环境一致的情况下进行,所有测试的软硬件环境应当配置完善。

5.2.测试数据需求

在测试案例运行前,应准备所有需要的测试数据。

5.3.测试人员需求

编写指南:此节列明单元测试各阶段的人员需求,最好说明需要的时间。

●测试组组长:

●测试人员:

●测试案例设计人员:

●测试数据准备人员:

●测试运行人员:

6.进度表

编写指南:用表格或MSProject中图表方式列出单元测试进度表,以便控制测试过程进度。

附录1.单元测试报告

页___共___页

测试组组长签名:_______ 日期:___/___/____

相关主题
相关文档 最新文档