Chinaunix首页 | 论坛 | 博客
  • 博客访问: 488071
  • 博文数量: 279
  • 博客积分: 4467
  • 博客等级: 上校
  • 技术积分: 2830
  • 用 户 组: 普通用户
  • 注册时间: 2007-04-03 14:43
文章分类

全部博文(279)

文章存档

2013年(1)

2012年(39)

2011年(35)

2009年(29)

2008年(131)

2007年(44)

分类:

2008-09-01 10:01:01

测试计划模板


        测试计划应有一个封面。包括名称、版本号、编写人、审批人、审批日期。

1 、引言 

1.1   编写目的

       例如:“本计划定义软件测试活动的范围、方法、资源和进度,被测试的对象、被测试的特性、应完成的测试任务、人员职责等。”
 
1.2   编写依据

       本软件测试计划编写依据,包括项目计划,项目质量计划,有关的规定、相关的标准等。

1.3   测试目标

       规定本次测试的目标,或软件通过本次测试,将要达到的某种用途的目标。例如:“通过确认测试后,该软件将在用户现场投入试运行。”

2   测试范围(内容/需求)

    描述被测试的对象,包括其版本、修改级别。对于集成测试,可以按所要集成的子系统或完整的业务功能系统描述。系统测试则对完整的系统进行表述。如各子系统版本不同应分别描述。例如:

2.1    征管信息子系统(V1.0.3)

    包括:税务登记、税基管理、发票管理、申报征收。

2.2    计会统票管理信息子系统(V1.0.1)
 
    包括:会计核算、票证管理、税收计划。

3   测试阶段

    测试阶段大致分为三个阶段:单元测试、集成测试、系统测试。应规定本测试计划包括哪一个或几个测试阶段。例如:“本测试计划包括单元测试和集成测试两个阶段。”。

4   测试依据

    分阶段规定本次测试所依据的需求规格说明书,设计文档,操作手册及其版本。
例如:“确认测试依据《某某需求规格说明书》(V1.5.3)”。

5   测试要求

5.1   被测试特性

   分不同的测试阶段(如单元测试、集成测试、确认测试)分别规定需要测试特性,主要从功能性、性能、可靠性、使用性、可维护性、安全性等方面进行维护。

5.2   不被测试特性

   分不同的测试阶段(如单元测试、集成测试、确认测试)分别规定不需要测试特性,例如:不考虑可移植性和高效性。

6   测试方法 

     应分测试阶段规定所要采用的测试方法。测试方法主要有程序走查,白盒测试,黑盒测试等。
如是集成测试,还应规定软件的集成方式。如哪些部分采用自顶向下集成,哪些部分测试自底向上集成。
对于白盒测试,应具体规定是采用语句覆盖、判定覆盖、条件覆盖、路径覆盖等测试方法中的一种或者几种的组合。例如:采用语句覆盖。
对于黑盒测试,应具体规定采用GUI测试,等价类划分、边界值分析、错误推测、比较测试等测试方法中的一种或者几种的组合。
例如:

1. 单元测试把每个模块作为一个单独的实体来测试,所发现的往往是编码和详细设计的错误。采用黑盒测试法。
重要模块:要求至少采用等价类划分、边界值分析、错误推测。
一般模块:要求至少采用等价类划分、边界值分析。

2. 集成测试是把经过单元测试的模块放在一起形成一个功能模块或子系统来测试。着重测试模块的接口。

3. 确认测试是证实软件功能与用户要求是否一致。还应该验证系统确实能提供需求说明书中指定的功能,而且系统的动态特性也符合预定要求。着重从用户角度发现问题。
由于测试阶段的根本目标是尽可能多发现并排除软件中潜藏的错误,最终把一个高质量的软件系统交给用户使用,因此用户在测试阶段的直接参与、指正和确认起着十分重要的作用。在后两个测试阶段,集成测试和确认测试将需要局方精悍有素的业务人员的大力支持与配合,并且为我方提供大量的测试数据。

7   测试工作流程 

     测试工作流程所依据的公司的质量体系中的程序文件或质量体系作业指导书,或部门自行编制的规程或作业指导书。例如:“依据公司质量系统的作业指导书《软件测试规程》”。

8   测试通过准则

     分测试阶段描述测试项通过准则。例如:“确认测试阶段重要模块100%通过,一般模块99%测试通过则测试通过”。

9   环境要求

     应按照以下各节描述每一个使用到的测试站点。

9.1  测试站点名称1

       根据不同的软硬件测试环境分别列出。如果所有的测试只在一个测试站点执行,则本节和以下的节只需列出一个。如有多个站点使用相同的测试环境,则可以只在第一次出现时描述,其它地方则引用该描述。
 
9.1.1  硬件

       规定测试环境所必备的硬件设备及其型号要求。例如:
服务器:仿真开发环境,包括数据库管理服务器一套。
客户工作站:系统应用工作站PC 4套
网络硬件:测试环境建立HUB(16口)一部,UTP网络线等若干;
外围设备:系统应用工作站打印机2 —— 3台

9.1.2  软件

         规定支撑测试所需的软件,测试工具及其版本。例如:
系统运行软件:Windows NT Server 4.0 & Delphi4.0 & Oracle 8.0 & Windows 98
测试软件:PL/SQL Developer 2.0.0
其他应用软件:字处理器、电子邮件、电子表格等。

9.1.3   测试数据环境

         指作为本次测试的基础数据。描述该数据的来源,是否真实数据,数据覆盖的时间范围。
应对该数据进行标识和备份。以保证测试的具有可重复性。但在用户正式运行的现场进行测试,应避免将备份数据重新装入。

9.1.4   测试环境的安装、测试和控制 

         测试环境的安装、测试和控制包括:
 
        1. 获取或开发测试环境中的每一个成分。
        2. 在使用前安装和测试测试环境的每一个项。
        3. 控制和维护测试环境的每一项。

9.1.5   人员 

         描述各测试站点在测试期间所需要人员的数量,类型和技能水平。

10    职责分工

10.1  测试组组长 

        规定测试组组长的职责。例如:“负责本项目测试任务的派发、管理和测试进度的控制。定期编写工作进度报告等管理文件。”

10.2  测试员 

        规定测试员的工作职责。例如:“编写测试用例,进行实际的测试,并编写测试报告,进行错误登记和统计。”

11   进度安排 

       规定测试工作的时间安排和测试任务分工。 
       由于测试工作的时间安排会比较依赖于开发的进度,可以不规定具体的起始时间,而是规定单元测试、集成测试、确认测试的相对起始时间,需要多长时间完成测试工作。例如:“对于单元测试应规定提交一个单元后平均需要1天时间完成测试。集成测试在模块可以集成时即开始测试。”,应规定测试组对开发工作的要求以便于测试工作的顺利开展。为了提高测试效率,可以考虑在开发组向测试组提交文档时,测试组开始设计测试用例。

12   需求可追溯性

      建议考虑需求的可追溯性。在需求文档已规范时应包括这一部分内容。
      需求可追溯性包括:
 
       1.从本计划中标识的测试的到软件配置项的可追溯性。如可能,应指出所引用的软件需求说明书及版本。
 
       2.从软件配置项到本计划中标识的测试的可追溯性。
                                                                       

阅读(1594) | 评论(0) | 转发(0) |
0

上一篇:系统优化

下一篇:black-box testing

给主人留下些什么吧!~~