软件测试需求分析

《软件测试需求分析》由会员分享，可在线阅读，更多相关《软件测试需求分析（12页珍藏版）》请在金锄头文库上搜索。

1、软件系统测试需求分析模版产品名称：项目承担部门： 本文档使用部门：撰写人：完成日期：评审负责人:评审日期：目录目录 2修订历史记录3日期 3版本 3说明 3作者 31 概述 41.1测试需求分析的目的 41.2测试需求分析的依据 41.3测试需求分析的方法 41.4 定义 42 软件产品说明 42.1项目背景 52.2项目需求说明 52.3项目整体设计说明 53 测试需求分析 53.1原始需求 53.2产品测试需求列表 53.3测试类型确定93.4测试环境要求 94 测试规格评估 104.1 测试类型评估 104.2测试用例密度 104.3 需求覆盖率 10修订历史记录1 概述1.1测试需求分

2、析的目的测试需求分析的目的是明确应测什么，了解测试规模、复杂程度与可能存在 的风险，其核心是产品质量符合用户明确的或者隐含的需求程度。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) 列出软件开发

3、需求中具有可测试性的开发需求；2) 对 1)中的每一条开发需求，形成可测试的分层描述的测试需求；3) 对2)形成的测试需求，从GB/T16260.1-2006软件工程产品质量第1部 分：质量模型由定义的软件内部/外部质量模型来确定软件产品的质量 需求；4) 对 3)所确定的质量要求，分析测试执行时需要实施的测试类型；5) 建立测试需求跟踪矩阵，对需求进行管理。1.4 定义列出测试需求说明书中用到的专业术语的定义和外文首字母词组的原 词组、缩写词和符号。2 软件产品说明2.1 项目背景简要介绍产品的项目背景，行业、主要承担业务等。2.2 项目需求说明填写相关信息或相关文档，如详见XXX系统需求说

4、明文档2.3 项目整体设计说明填写相关信息或相关文档，如详见XXX系统总体设计3测试需求分析3.1 原始需求原始需求是从用户需求、产品包需求、系统需求、测试经验库、协议规 范等需求来源中提取的经过整理的输入集合。本文的原始需求亦即经过整理成文 的业务需求，将每一条需求对应的系统、业务需求编号、业务需求说明及相关文 档注明。其中系统名称为被测系统名称；需求版本号为业务需求版本号；业务需 求的编号和业务需求名称引用需求分析文档编号及名称，描述引用需求分析文档 描述。表1 业务需求表系统名称需求版本业务需求编号业务需求名业务需求描述3.2 产品测试需求列表测试需求列表是在原始需求列表的基础上，对每一

5、条原始业务需求进行分析，形成可测试的分层描述的测试要点，再根据标准和需求文档对每一个测试要点进行分析，得出需要执行的测试类型和更详细的测试描述，最终与原始需求列 第5页表综合形成测试需求列表。测试需求的类型，可分为功能性、安全性测试、接口测试、容量测试、完整 性测试、结构测试、用户界面测试、负载测试、压力测试、疲劳强度测试、恢复 时间测试、配置测试、兼容性测试、可维护性测试等；前置条件即测试需求需执 行的前提条件；优先级一般定义为核心级，重要级,一般级和建议级，其中核心 是指针对于必不可少的功能需求、非功能需求及核心的业务流程的测试需求；重 要是指针对于关键的功能需求、重要的非功能需求及重要的

6、业务流程的测试需求 一般是指对于一些为特定用户或业务需求而设的系统功能，由于这些系统功能使 用频率相对较低，或者这些系统功能可以由其它的方法实现其替代功能，因而即 使发布版中并未包括这些功能，也不会对收入或客户满意度造成太大的影响；建 议是指针对于一般的测试需求，如果受资源或时间的约束，在预定的产品发布时 间，有可能不能完成对这些系统功能的验证，则这些系统功能的测试需求被定义 为建议的。测试需求评审状态包括：未评审、已评审、不评审。评审的内容包括：1) 完整性评审：应保证测试需求能充分覆盖软件需求的各种特征，重点 关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠 性要求、系统约束等

7、方面，同时还应关注是否覆盖开发人员遗漏的、 系统隐含的需求；2) 准确性评审：应保证所描述的内容能够得到相关各方的一致理解，各 项测试需求之间没有矛盾和冲突，各项测试需求在详尽程度上保持一 致，每一项测试需求都可以作为测试用例设计的依据； 评审的形式有相互评审、交叉评审；轮查；走查；小组评审；审查。 评审人员：必须存在多种角色，保证不同类型的人员都参与，包括开发经理 、项目经理、测试经理、系统分析人员、相关测试人员和开发人员。根据系统需求，产品有不同类型的测试需求，如功能测试需求、性能测试等， 以续表形式分别列出。3.2.1 功能测试需求功能测试需求要求描述产品如何响应正确的、可预知的出错条件

8、、非法输入或动作，必须唯一地标示每一个需求。表2 功能测试需求列表3.2.2 性能测试需求性能需求测试要求包括测试精度、时间特性、适应性等要求表3 性能测试需求列表对系统不断施加压力，通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别。例如测试一个 Web 站点在大量的负荷下，何时系统的响应会退化或失败。表4 压力测试需求列表业务 需求 编号测试需 求编号测试需 求名称测试需 求描述前置条 件预期结 果类型优先级作 者评审状 态3.2.3 用户界面测试需求用户界面测试包括可视性（如界面整体布局协调性、色彩搭配合理性、界面 要素美观性）、可用性（显控协调性、操作方便性与灵

9、活性、提示、信息反馈、 系统响应时间、易学习型、帮助功能完备性和准确性）、健壮性（输入类型及边 界控制性能、危险操作拦截提示性能、操作可恢复性）容错等方面。表5 用户界面测试需求列表3.2.4 接口测试 硬件接口：描述系统中软件和硬件每一接口的特征。这种描述可能包括支持 的硬件类型和软硬件之间交流的数据、控制信息的性质一级所使用的通信协议。软件接口：描述该产品与其他外部组件的连接，包括数据库、操作系统、工 具、库和集成的商业组件，并描述在软件组件之间交换数据或消息的目的、所需 要的服务以及内部组件通信的性质，确定将在组件之间共享的数据。通信接口：描述与产品所使用的通信功能相关的需求，包括电子邮

10、件、web浏览器、网络通信标准或协议及电子表格，定义了相关的消息格式，规定通信安 全或加密问题，数据传输速率和同步通信机制，例如描述计算机与机器硬件接口， 波特率等的测试；通信过程中断电的测试，人为中断通信的测试，连续多次通信 的测试，通信过程中随意操作按钮的测试。表6 接口测试需求列表3.3 测试类型确定 根据原始需求及后续分析得到的测试需求列表，确定系统需要的测试类型在需要测试的项目使用丁标注。表7 待测系统的测试大项可靠性&?3.4 测试环境要求根据测试类型和内容列出测试环境的最低要求，包括软硬件及相关工具3.4.1 硬件要求3.4.2 软件要求4测试规格评估4.1 测试类型评估不同测试类型能否发现不同类型的缺陷，依据测试类型来评估测试分析设计 工作是非常必要的，必须在产品初期就要规划测试类型，以期尽可能的发现所有 相关类型的缺陷。表 8 测试类型评估4.2 测试用例密度 计算每千行代码的用例数。4.3 需求覆盖率对一个项目，所有的需求都应该覆盖，但是由于部分设计规格在一定的时间 内不适合做系统测试或者没有相关测试手段，对于这部分需求需要明确提出。无法测试需求说明。表 9 未测需求说明本文完）