软件测试需求分析报告文档格式.docx

软件测试需求分析报告文档格式.docx

《软件测试需求分析报告文档格式.docx》由会员分享，可在线阅读，更多相关《软件测试需求分析报告文档格式.docx（8页珍藏版）》请在冰豆网上搜索。

说明

作者

1概述

测试需求分析的目的

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

测试需求分析的依据

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

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

3）GB/《软件工程产品质量第1部分：

质量模型》；

4）GB/T《软件工程软件产品质量要求与评价（SQuaRE）商业现货（COTS）软件产品的质量要求和测试细则》；

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

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

测试需求分析的方法

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

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

3）对2）形成的测试需求，从GB/《软件工程产品质量第1部分：

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

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

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

1.4定义

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

]

2软件产品说明

项目背景

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

项目需求说明

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

项目整体设计说明

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

3测试需求分析

原始需求

原始需求是从用户需求、产品包需求、系统需求、测试经验库、协议规范等需求来源中提取的经过整理的输入集合。

本文的原始需求亦即经过整理成文的业务需求，XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX将每一条需求对应的系统、业务需求编号、业务需求说明及相关文档注明。

其中系统名称为被测系统名称；

需求版本号为业务需求版本号；

业务需求的编号和业务需求名称引用需求分析文档编号及名称，描述引用需求分析文档描述。

表1业务需求表

系统名称

需求版本

业务需求编号

业务需求名

业务需求描述

产品测试需求列表

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

测试需求的类型，可分为功能性、安全性测试、接口测试、容量测试、完整性测试、结构测试、用户界面测试、负载测试、压力测试、疲劳强度测试、恢复时间测试、配置测试、兼容性测试、可维护性测试等；

前置条件即测试需求需执行的前提条件；

优先级一般定义为核心级，重要级,一般级和建议级，其中核心是指针对于必不可少的功能需求、非功能需求及核心的业务流程的测试需求；

重要是指针对于关键的功能需求、重要的非功能需求及重要的业务流程的测试需求；

一般是指对于一些为特定用户或业务需求而设的系统功能，由于这些系统功能使用频率相对较低，或者这些系统功能可以由其它的方法实现其替代功能，因而即使发布版中并未包括这些功能，也不会对收入或客户满意度造成太大的影响；

建议是指针对于一般的测试需求，如果受资源或时间的约束，在预定的产品发布时间，有可能不能完成对这些系统功能的验证，则这些系统功能的测试需求被定义为建议的。

测试需求评审状态包括：

未评审、已评审、不评审。

评审的内容包括：

1）完整性评审：

应保证测试需求能充分覆盖软件需求的各种特征，重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面，同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求；

2）准确性评审：

应保证所描述的内容能够得到相关各方的一致理解，各项测试需求之间没有矛盾和冲突，各项测试需求在详尽程度上保持一致，每一项测试需求都可以作为测试用例设计的依据；

评审的形式有相互评审、交叉评审；

轮查；

走查；

小组评审；

审查。

评审人员：

必须存在多种角色，保证不同类型的人员都参与，包括开发经理

、项目经理、测试经理、系统分析人员、相关测试人员和开发人员。

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

功能测试需求

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

表2功能测试需求列表

测试需求编号

测试需求名称

测试需求描述

前置条件

预期结果

类型

优先级

评审状态

性能测试需求

[性能需求测试要求包括测试精度、时间特性、适应性等要求]

表3性能测试需求列表

压力测试需求

对系统不断施加压力，通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别。

例如测试一个Web站点在大量的负荷下，何时系统的响应会退化或失败。

表4压力测试需求列表

用户界面测试需求

用户界面测试包括可视性（如界面整体布局协调性、色彩搭配合理性、界面要素美观性）、可用性（显控协调性、操作方便性与灵活性、提示、信息反馈、系统响应时间、易学习型、帮助功能完备性和准确性）、健壮性（输入类型及边界控制性能、危险操作拦截提示性能、操作可恢复性）容错等方面。

表5用户界面测试需求列表

1

接口测试

硬件接口：

描述系统中软件和硬件每一接口的特征。

这种描述可能包括支持的硬件类型和软硬件之间交流的数据、控制信息的性质一级所使用的通信协议。

软件接口：

描述该产品与其他外部组件的连接，包括数据库、操作系统、工具、库和集成的商业组件，并描述在软件组件之间交换数据或消息的目的、所需要的服务以及内部组件通信的性质，确定将在组件之间共享的数据。

通信接口：

描述与产品所使用的通信功能相关的需求，包括电子邮件、web浏览器、网络通信标准或协议及电子表格，定义了相关的消息格式，规定通信安全或加密问题，数据传输速率和同步通信机制，例如描述计算机与机器硬件接口，波特率等的测试；

通信过程中断电的测试，人为中断通信的测试，连续多次通信的测试，通信过程中随意操作按钮的测试。

表6接口测试需求列表

测试类型确定

根据原始需求及后续分析得到的测试需求列表，确定系统需要的测试类型，在需要测试的项目使用√标注。

。

表7待测系统的测试大项

功能测试

性能测试

可靠性

易用性

安全性

可移植性

备注

测试环境要求

根据测试类型和内容列出测试环境的最低要求，包括软硬件及相关工具。

硬件要求

软件要求

4测试规格评估

测试类型评估

不同测试类型能否发现不同类型的缺陷，依据测试类型来评估测试分析设计工作是非常必要的，必须在产品初期就要规划测试类型，以期尽可能的发现所有相关类型的缺陷。

表8测试类型评估

序号

测试类型

比率

测试用例密度

计算每千行代码的用例数。

需求覆盖率

对一个项目，所有的需求都应该覆盖，但是由于部分设计规格在一定的时间内不适合做系统测试或者没有相关测试手段，对于这部分需求需要明确提出。

无法测试需求说明。

表9未测需求说明

需求编号

原因

（本文完）