文档介绍：该【Bug(缺陷管理)需求规格说明书(可编辑修改word版) 】是由【秋江孤影】上传分享，文档一共【5】页，该文档可以免费在线阅读，需要了解更多关于【Bug(缺陷管理)需求规格说明书(可编辑修改word版) 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。三、需求规格说明书
需求规格说明书
软件缺陷跟踪管理系统在现代软件开发中已经占据了很重要的位置。每一个
软件组织都知道必须妥善处理软件中的缺陷,这是关系到软件组织生存、发展
的质量根本。所以我们要熟悉了解软件跟踪管理系统的基本流程。
软件名称:软件缺陷跟踪管理系统软件。
软件测试的主要目的在于发现软件存在的错误(Bug),对于如何处理测试中
发现的错误,将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误,才
能消除软件错误,保证要发布的软件符合需求设计的目标。在实际软件测试过
程中,对于每个Bug都要经过测试、确认、修复、验证等的管理过程,这是软
件测试的重要环节。
为了正确跟踪每个软件错误的处理过程,通常将软件测试发现的每个错误作
为一条条记录输入制定的错误跟踪管理系统。
作为一个缺陷跟踪管理系统,需要正确设计每个错误的包含信息的字段内容和
记录错误的处理信息的全部内容。字段内容可能包括测试软件名称,测试版本
号,测试人名称,测试事件,测试软件和硬件配置环境,发现软件错误的类型,错误
的严重等级,详细步骤,必要的附图,测试注释。处理信息包括处理者姓名,处理时间,
处理步骤,处理意见,错误记录的当前状态。
缺陷就是:不满足用户确定的需求;软件使用当中出现的问题;不符合设计要
求。
(1)确保被发现的缺陷能够被解决;这里解决的意思不一定是被修正,也可
能是其他处理方式(例如,在下一个版本中修正或是不修正),总之,对每个
被发现的BUG的处理方式必须能够在开发组织中达到一致;
(2)收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段;决定测试过程是
否结束有很多种方式,通过缺陷趋势曲线来确定测试过程是否结束是常用并且
较为有效的一种方式;
(3)收集缺陷数据并在其上进行数据分析,作为组织的过程财富。
缺陷信息提交后,会进行分配,进入待修正状态。通常情况下,被分配的
开发人员会负责对它进行修复。然后由测试人员进行验证,验证通过后就会被
关闭。如果没有通过验证,就会交给开发人员进行修复。但开发人员基于某种
原因或理由,也可能会拒绝修改,这时会交给评审委员会进行评审,如果通过
评审,则这个缺陷会被关闭,否则开发人员还是要继续进行修复。
三、需求规格说明书
测试人员:进行测试的人员,缺陷的发起者;
项目经理(高级测试人员):对整个项目负责,对产品质量负责的人员;
开发人员:执行开发任务的人员,完成实际的设计及编码工作;
评审委员会:对缺陷进行最终地确认,在项目成员对缺陷达不成
一致意见时,行使仲裁权。
(1)新错误(New):测试中新报告的软件缺陷。
(2)打开(Open):被确认并分配给相关人员,正在处理。
(3)已修正(Fixed):开发人员已完成修正,等待测试人员验证。
(4)拒绝(Rejected):拒绝修改缺陷。例如:缺陷等级太低,
修正成本太大等。
(5)延期(Deferred):不在当前版本修复的错误,下一版修复。
(6)关闭(Closed):错误已被修复或过期。
(7)重新打开(Reopen):已经修正的错误再次发生。例如:
修正新的错误造成已经解决的错误再次发生等。
(8)挂起(Suspend):暂时不处理。例如:处理人员正忙于处理更紧迫
的任务时,而这个错误级别低,这时错误被挂起,处于一较种等待状态。
此流程的图示如下:
三、需求规格说明书
本系统的软件运行环境包括:操作系统使用Windows2003Server(或更
高级别)(以上),浏览器基于IE内核
或谷哥内核都可,数据库服务器使用SQLServer2008;程序运行服务器的配置
,,硬盘共800G(每个盘200G),只开通80
端口;,,硬盘共800G,只开
通1433端口;,,硬盘共800G。考
虑到目前OFFICE2003(及更高版本)的市场占有率已达到91%,所以我们的系
统日常的文档和数据处理应该能够支持OFFICE2003
(1)由于本系统的开发将是基于浏览器的B/S结构,所以浏览器端的语言使用
HTML/CSS/JavaScript,服务器端的语言使用ASP(.NET),开发人员将不能用
其他的开发语言(编写组件除外)。而数据库也将随之采用SQLServer2008。
(2)开发人员在编写代码的程过中需要严格按照软件工程的要求来进行,以利
于接下来的测试和维护及升级。
三、需求规格说明书
用例
1、注册:注册一个新的用户。
2、登录:用户登录到软件缺陷管理系统主页。
3、提交bug:测试人员提交新的Bug入库。
4、验证:高级测试人员验证提交的bug是否真的为错误。
5、验证bug:测试人员验证已经进行的修改是否已经修改。
6、查询状态:开发人员查询目前状态。
7、修改状态:开发人员根据具体的处理情况修改状态。
8、修改缺陷:对于已经发现的各种错误进行修改。
三、需求规格说明书