软件测试需求分析报告

软件系统测试需求分析模版

产品名称：_____

项目承担部门：_______________________________

本文档使用部门：撰写人：_______________________________ _______________________________

完成日期：_____

评审负责人: 评审日期：_______________________________ _______________________________

目录

目录 (2)

修订历史记录 (3)

日期 (3)

版本 (3)

说明 (3)

作者 (3)

1概述 (4)

1.1测试需求分析的目的 (4)

1.2测试需求分析的依据 (4)

1.3测试需求分析的方法 (4)

1.4 定义 (5)

2 软件产品说明 (5)

2.1项目背景 (5)

2.2项目需求说明 (5)

2.3项目整体设计说明 (5)

3测试需求分析 (5)

3.1原始需求 (5)

3.2产品测试需求列表 (6)

3.3测试类型确定 (11)

3.4测试环境要求 (12)

4测试规格评估 (12)

4.1 测试类型评估 (12)

4.2测试用例密度 (13)

4.3 需求覆盖率 (13)

修订历史记录

1概述

1.1测试需求分析的目的

测试需求分析的目的是明确应测什么，了解测试规模、复杂程度与可能存在的风险，其核心是产品质量符合用户明确的或者隐含的需求程度。

1.2测试需求分析的依据

1)待测软件系统相关的需求文档，如《xxx系统软件需求规格说明》；

2)待测软件系统相关的设计文档，如《XXX系统设计文档》；

3)GB/T16260.1-2006《软件工程产品质量第1部分：质量模型》；

4)GB/T 25000.51-2010《软件工程软件产品质量要求与评价(SQuaRE) 商

业现货(COTS) 软件产品的质量要求和测试细则》；

5)软件系统相关的协议、规；

6)待测软件系统业务行标。

1.3测试需求分析的方法

1)列出软件开发需求中具有可测试性的开发需求；

2)对1）中的每一条开发需求，形成可测试的分层描述的测试需求；

3)对2）形成的测试需求，从GB/T16260.1-2006《软件工程产品质量第1

部分：质量模型》由定义的软件部/外部质量模型来确定软件产品的质量需求；

4)对3）所确定的质量要求，分析测试执行时需要实施的测试类型；

5)建立测试需求跟踪矩阵，对需求进行管理。

1.4定义

[列出测试需求说明书中用到的专业术语的定义和外文首字母词组的原词组、缩写词和符号。]

2软件产品说明

2.1项目背景

[简要介绍产品的项目背景，行业、主要承担业务等。]

2.2项目需求说明

填写相关信息或相关文档，如详见《XXX系统需求说明文档》。

2.3项目整体设计说明

填写相关信息或相关文档，如详见《XXX系统总体设计》。

3测试需求分析

3.1原始需求

原始需从用户需求、产品包需求、系统需求、测试经验库、协议规等需求来源中提取的经过整理的输入集合。本文的原始需求亦即经过整理成文的业务需求，将每一条需求对应的系统、业务需求编号、业务需求说明及相关文档注明。其中系统名称为被测系统名称；需求版本号为业务需求版本号；业务需求的编号和业务需求名称引用需求分析文档编号及名称，描述引用需求分析文档描述。

3.2产品测试需求列表

测试需求列表是在原始需求列表的基础上，对每一条原始业务需求进行分析，形成可测试的分层描述的测试要点，再根据标准和需求文档对每一个测试要点进行分析，得出需要执行的测试类型和更详细的测试描述，最终与原始需求列表综合形成测试需求列表。

测试需求的类型，可分为功能性、安全性测试、接口测试、容量测试、完整性测试、结构测试、用户界面测试、负载测试、压力测试、疲劳强度测试、恢复时间测试、配置测试、兼容性测试、可维护性测试等；前置条件即测试需求需执行的前提条件；优先级一般定义为核心级，重要级,一般级和建议级，其中核心是指针对于必不可少的功能需求、非功能需求及核心的业务流程的测试需求；重要是指针对于关键的功能需求、重要的非功能需求及重要的业务流程的测试需求；一般是指对于一些为特定用户或业务需求而设的系统功能，由于这些系统功能使用频率相对较低，或者这些系统功能可以由其它的方法实现其替代功能，因

而即使发布版中并未包括这些功能，也不会对收入或客户满意度造成太大的影响；建议是指针对于一般的测试需求，如果受资源或时间的约束，在预定的产品发布时间，有可能不能完成对这些系统功能的验证，则这些系统功能的测试需求被定义为建议的。

测试需求评审状态包括：未评审、已评审、不评审。

评审的容包括：

1)完整性评审：应保证测试需求能充分覆盖软件需求的各种特征，重点关

注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性

要求、系统约束等方面，同时还应关注是否覆盖开发人员遗漏的、系

统隐含的需求；

2)准确性评审：应保证所描述的容能够得到相关各方的一致理解，各项测

试需求之间没有矛盾和冲突，各项测试需求在详尽程度上保持一致，

每一项测试需求都可以作为测试用例设计的依据；

评审的形式有相互评审、交叉评审；轮查；走查；小组评审；审查。

评审人员：必须存在多种角色，保证不同类型的人员都参与，包括开发经理、项目经理、测试经理、系统分析人员、相关测试人员和开发人员。

根据系统需求，产品有不同类型的测试需求，如功能测试需求、性能测试等，以续表形式分别列出。

3.2.1功能测试需求

功能测试需求要求描述产品如何响应正确的、可预知的出错条件、非法输入或动作，必须唯一地标示每一个需求。