ImageVerifierCode 换一换
格式:DOCX , 页数:8 ,大小:19.11KB ,
资源ID:4918898      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/4918898.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(软件测试需求分析.docx)为本站会员(b****5)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

软件测试需求分析.docx

1、软件测试需求分析-CAL-FENGHAI.-(YICAI)-Company One1 -CAL-本页仅作为文档封面,使用请直接删除软件测试需求分析(总10页)软件系统测试需求分析模版产品名称: _项目承担部门:_本文档使用部门:撰写人:_完成日期: _评审负责人:评审日期:_修订历史记录日期版本说明作者1概述1.1测试需求分析的目的测试需求分析的目的是明确应测什么,了解测试规模、复杂程度与可能存在的风险,其核心是产品质量符合用户明确的或者隐含的需求程度。1.2测试需求分析的依据1)待测软件系统相关的需求文档,如xxx系统软件需求规格说明;2)待测软件系统相关的设计文档,如XXX系统设计文档;3

2、)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)所确定的质量要求,分析测试执行时需要实施

3、的测试类型;5)建立测试需求跟踪矩阵,对需求进行管理。1.4定义列出测试需求说明书中用到的专业术语的定义和外文首字母词组的原词组、缩写词和符号。2软件产品说明2.1项目背景简要介绍产品的项目背景,行业、主要承担业务等。2.2项目需求说明填写相关信息或相关文档,如详见XXX系统需求说明文档。2.3项目整体设计说明填写相关信息或相关文档,如详见XXX系统总体设计。3测试需求分析3.1原始需求表1业务需求表系统名称需求版本业务需求编号业务需求名业务需求描述3.2产品测试需求列表 测试需求列表是在原始需求列表的基础上,对每一条原始业务需求进行分析,形成可测试的分层描述的测试要点,再根据标准和需求文档对

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

5、相对较低,或者这些系统功能可以由其它的方法实现其替代功能,因而即使发布版中并未包括这些功能,也不会对收入或客户满意度造成太大的影响;建议是指针对于一般的测试需求,如果受资源或时间的约束,在预定的产品发布时间,有可能不能完成对这些系统功能的验证,则这些系统功能的测试需求被定义为建议的。测试需求评审状态包括:未评审、已评审、不评审。评审的内容包括:1)完整性评审:应保证测试需求能充分覆盖软件需求的各种特征,重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面,同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求;2)准确性评审:应保证所描述的内容能够得到相关各方的一

6、致理解,各项测试需求之间没有矛盾和冲突,各项测试需求在详尽程度上保持一致,每一项测试需求都可以作为测试用例设计的依据;评审的形式有相互评审、交叉评审;轮查;走查;小组评审;审查。评审人员:必须存在多种角色,保证不同类型的人员都参与,包括开发经理、项目经理、测试经理、系统分析人员、相关测试人员和开发人员。根据系统需求,产品有不同类型的测试需求,如功能测试需求、性能测试等,以续表形式分别列出。3.2.1功能测试需求功能测试需求要求描述产品如何响应正确的、可预知的出错条件、非法输入或动作,必须唯一地标示每一个需求。表2功能测试需求列表业务需求编号测试需求编号测试需求名称测试需求描述前置条件预期结果类

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

8、可用性(显控协调性、操作方便性与灵活性、提示、信息反馈、系统响应时间、易学习型、帮助功能完备性和准确性)、健壮性(输入类型及边界控制性能、危险操作拦截提示性能、操作可恢复性)容错等方面。表5用户界面测试需求列表业务需求编号测试需求编号测试需求名称测试需求描述前置条件预期结果类型优先级作者评审状态11硬件接口:描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型和软硬件之间交流的数据、控制信息的性质一级所使用的通信协议。软件接口:描述该产品与其他外部组件的连接,包括数据库、操作系统、工具、库和集成的商业组件,并描述在软件组件之间交换数据或消息的目的、所需要的服务以及内部组件通信的性

9、质,确定将在组件之间共享的数据。通信接口:描述与产品所使用的通信功能相关的需求,包括电子邮件、web浏览器、网络通信标准或协议及电子表格,定义了相关的消息格式,规定通信安全或加密问题,数据传输速率和同步通信机制,例如描述计算机与机器硬件接口,波特率等的测试;通信过程中断电的测试,人为中断通信的测试,连续多次通信的测试,通信过程中随意操作按钮的测试。表6接口测试需求列表业务需求编号测试需求编号测试需求名称测试需求描述前置条件预期结果类型优先级作者评审状态113.3测试类型确定根据原始需求及后续分析得到的测试需求列表,确定系统需要的测试类型,在需要测试的项目使用标注。表7待测系统的测试大项系统名称

10、功能测试性能测试可靠性易用性安全性可移植性备注3.4测试环境要求根据测试类型和内容列出测试环境的最低要求,包括软硬件及相关工具。3.4.1 硬件要求3.4.2 软件要求4测试规格评估4.1 测试类型评估不同测试类型能否发现不同类型的缺陷,依据测试类型来评估测试分析设计工作是非常必要的,必须在产品初期就要规划测试类型,以期尽可能的发现所有相关类型的缺陷。表8 测试类型评估序号测试类型比率4.2测试用例密度计算每千行代码的用例数。4.3 需求覆盖率对一个项目,所有的需求都应该覆盖,但是由于部分设计规格在一定的时间内不适合做系统测试或者没有相关测试手段,对于这部分需求需要明确提出。 无法测试需求说明。表9 未测需求说明序号需求编号原因 (本文完)

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1