软件测试需求分析.docx

软件系统测试需求分析模版 产品名称： 项目承担部门： 本文档使用部门： 撰写人： 完成日期： 评审负责人 : 评审日期：  _____ _______________________________ _______________________________ _______________________________ _____ _______________________________ _______________________________ 目录 修订历 史记录 日期 版本 说明 作者 概述 1.1 测试需求分析的目的 测试需求分析的目的是明确应测什么，了解测试规模、复杂程度与可能存在的风险，其核心是产品质量符合用户明确的或者隐含的需求程度。 1.2 测试需求分析的依据 待测软件系统相关的需求文档，如《 xxx 系统软件需求规格说明》； 待测软件系统相关的设计文档，如《 XXX系统设计文档》； GB/T16260.1-2006 《软件工程产品质量第 1 部分：质量模型》； GB/T25000.51-2010《软件工程软件产品质量要求与评价 (SQuaRE)商业现货 (COTS)软件产品的质量要求和测试细则》； 软件系统相关的协议、规范； 待测软件系统业务行标。 1.3 测试需求分析的方法 列出软件开发需求中具有可测试性的开发需求； 对 1） 中的每一条开发需求，形成可测试的分层描述的测试需求； 对 2） 形成的测试需求，从 GB/T16260.1-2006《软件工程产品质量第 1 部分：质量模型》由定义的软件内部 / 外部质量模型来确定软件产品的质量需求； 对 3） 所确定的质量要求，分析测试执行时需要实施的测试类型； 建立测试需求跟踪矩阵，对需求进行管理。 1.4 定义 [ 列出测试需求说明书中用到的专业术语的定义和外文首字母词组的原词组、 缩写词和符 号。 ] 软件产品说明 2.1 项目背景 [ 简要介绍产品的项目背景，行业、主要承担业务等。 ] 2.2 项目需求说明 填写相关信息或相关文档，如详见《 XXX系统需求说明文档》 。 2.3 项目整体设计说明 填写相关信息或相关文档，如详见《 XXX系统总体设计》。 测试需求分析 3.1 原始需求 原始需 求是从用户需求、产品包需求、系统需求、测试经验库、协议规范等需求来源中提 取的经过整理的输入集合。 本文的原始需求亦即经过整理成文的业务需求， 将每一条需求对应的系统、业务需求编号、 业务需求说明及相关文档注明。 其中系统名称为被测系统名称；需求版本号为 业务需求版本号； 业务需求的编号和业务需求名称引用需求分析文档编号及名称， 描述引用需求分 析文档描述。 表 1 业务需求表 系统名称 需求版本 业务需求编号 业务需求名 业务需求描述 3.2 产品测试需求列表 测试需求列表是在原始需求列表的基础上，对每一条原始业务需求进行分析，形成可测试的分 层描述的测试要点， 再根据标准和需求文档对每一个测试要点进行分析， 得出需要执行的测试类型和更详细的测试描述，最终与原始需求列表综合形成测试需求列表。 测试需求的类型， 可分为功能性、 安全性测试、 接口测试、容量测试、完整性测试、 结构测试、用户界面测试、负载测试、压力测试、疲劳强度测试、恢复时间测试、配置测试、兼容性测试、可 维护性测试等；前置条件即测试需求需执行的前提条件；优先级一般定义为核心级，重要级 , 一般级和建议级，其中核心是指针对于必不可少的功能需求、 非功能需求及核心的业务流程的测试需求；重要是指针对于关键的功能需求、 重要的非功能需求及重要的业务流程的测试需求； 一般是指对于一些为特定用户或业务需求而设的系统功能， 由于这些系统功能使用频率相对较低， 或者这些系统功能可以由其它的方法实现其替代功能， 因而即使发布版中并未包括这些功能， 也不会对收入或客户满意度造成太大的影响； 建议是指针对于一般的测试需求， 如果受资源或时间的约束， 在预定的产品发布时间， 有可能不能完成对这些系统功能的验证， 则这些系统功能的测试需求被定义为建议的。 测试需求评审状态包括：未评审、已评审、不评审。 评审的内容包括： 完整性评审：应保证测试需求能充分覆盖软件需求的各种特征，重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面，同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求； 准确性评审：应保证所描述的内容能够得到相关各方的一致理解，各项测试需求之间没有矛盾和冲突，各项测试需求在详尽程度上保持一致， 每一项测试需求都可以作为测试用 例设计的依据； 评审的形式有相互评审、交叉评审；轮查；走查；小组评审；审查。 评审人员：必须存在多种角色，保证不同类型的人员都参