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