软件系统缺陷管理规程模版Word文件下载.docx
《软件系统缺陷管理规程模版Word文件下载.docx》由会员分享，可在线阅读，更多相关《软件系统缺陷管理规程模版Word文件下载.docx（16页珍藏版）》请在冰豆网上搜索。
职责
项目经理
分配处理Rejected和Abandon的缺陷。
（虚拟职位，视项目而定）
开发组长
负责提交系统测试（版本war包和配置说明）,分配处理测试提交的缺陷。
测试工程师
执行测试，录入缺陷，验证、关闭修改后的测试缺陷。
开发工程师
修改测试缺陷。
记录人
记录评审发现的缺陷，录入QC。
（暂不启用）
跟踪人
跟踪、验证、关闭修改的评审缺陷。
3.进入准则
评审或测试发现缺陷
4.缺陷分类
4.1.缺陷引入阶段
1）缺陷引入阶段：
指在项目哪个阶段（过程）引入的缺陷。
2）选项：
需求阶段、设计阶段、实现阶段、QC测试阶段、升级上线阶段、运行维护阶段
3）填写角色：
项目经理、开发工程师。
4）说明：
不是项目当前所处阶段，该阶段可理解为过程。
4.2.缺陷严重等级
1）缺陷严重等级指该缺陷造成影响的严重等级。
2）填写角色：
缺陷严重等级
描述
致命
1、严重不合理，核心功能完全违反软件规范或业务规范，可能导致用户强烈的反感。
2、由于需求、设计错误导致流程和流程控制存在重大错误，与现有政策法规或实务惯例的规定（约定）有明显冲突；
3、由于程序错误引起的运行中死机、非法退出
4、由于程序错误引起的系统崩溃或资源严重不足；
5、在不依赖后台数据库和解密程序的情况下能够非法登录系统；
6、权限体系存在重大缺陷足够导致安全隐患；
7、对一些可能对信息安全或数据完整造成威胁的操作缺少强制备份、强制更换操作员、强制重新启动程序等控制
8、数据错误引起的用户重大损失。
高级
1、程序错误引起的功能无法实现
2、软件功能的实现过程中弹出未控制的系统错误提示，导致流程中断。
3、程序错误引起的功能实现错误，该错误导致流程中断。
4、需求中的既定功能未实现，该未实现的功能会导致流程中断。
5、程序错误引起的用户权限无法实现。
6、超时操作无处理，导致系统死循环。
7、程序错误引起的数据统计错误，该错误严重影响用户使用
较高
1、错误操作没有任何提示
2、需求中的既定功能未实现，该未实现功能会引起小部分系统错误。
3、程序错误引起的功能实现错误，该错误导致小部分系统错误。
4、破坏性操作没有提示确认
5、数据库发生死锁
6、未达到性能需求预期目标
7、性能测试中途出现错误，导致无法继续性能测试
8、程序兼容性未满足
9、界面混乱，严重影响用户使用。
中级
1、操作界面不规范、出现错别字和链接错误。
2、交互性操作风格不统一。
3、界面混乱，但不太影响用户使用
4、功能实现错误，该错误不太影响用户使用
5、需求中的既定功能未实现，但该未实现的功能不太影响用户使用
6、与需求规定配置兼容性不符合
7、数据库表、缺省值未加完整性约束条件
8、数据库中的表有过多空字段
优化
1、操作者感到不方便或者麻烦，但不影响执行工作功能或者重要功能
2、提示窗口文字未采用行业术语
3、处理过程中出现的对实现功能没有影响的缺陷；
4、局部页面不够美观；
5、虽有不尽人意之处，但不影响用户操作；
6、用户使用频率较低，并且不会造成错误；
4.3.缺陷类型
选项：
BugType分类
01_开发程序（默认）
1.1-编码规范
1.2-功能实现
1.3-兼容性
1.4-数据问题
1.5-其它
02_需求
2.1-逻辑缺失
2.2-细节缺失
2.3-异常处理缺失
2.4-需求变更
2.5-UI制作
2.6-其它
03_系统设计
3.1-架构缺陷
3.2-接口规范
3.3-安全设计
3.4-编程设计
3.5-其它
04_部署环境
4.1-目标环境
4.2-版本差异
4.3-数据库
4.4-其它
4.4.缺陷来源（发现手段）
1）选项：
评审（暂不启用）、自测、系统测试、转测试。
4.5.缺陷发现阶段
测试工程师。
4.6.缺陷主题
系统模块根据项目需求规格说明书来分类，同时增加文档和通用特征项与之并列。
文档的下级目录列出需评审的文档，通用特征项下级目录列出通用的各特征项。
5.缺陷处理过程
5.1.缺陷状态
缺陷状态
New
新增BUG，由测试人员提交
Open
开发组长对BUG进行分配时，状态置为Open，由开发组长执行
Reopen
对FIXED、Rejected和Abandon状态BUG重新打开，由测试人员执行
Fixed
修改完成的BUG状态置为FIXED，由开发工程师执行
Closed
对验证通过的BUG状态置为CLOSED，测试人员执行
Closed（Rejected）
对被拒绝的BUG状态置为Closed（Rejected），测试人员执行
Rejected
拒绝的BUG，需在备注中说明拒绝的详细理由，项目经理执行
Abandon
延后解决的bug,需在备注里面说明延后原因和延后时间点，项目经理执行
图表4：
5.2.评审缺陷处理流程（暂不启用）
评审发现的缺陷都必须录入QC库进行管理和跟踪，并要求在一周内关闭。
5.2.1.流程图
图表1：
评审缺陷处理流程
5.2.2.活动描述
1）记录人将评审发现的缺陷录入QC，缺陷状态修改为“Open”，分配给修改人，分析缺陷并填写Subject、缺陷严重等级、缺陷来源、发现阶段等。
2）修改人修改缺陷，将缺陷状态改为“Fixed”，并填写缺陷引入阶段。
3）跟踪人跟踪缺陷修改情况，逐一验证已修复的缺陷。
如验证通过，将缺陷状态修改为“Closed”；
验证未通过的改为“Reopen”，修改人重新修改缺陷。
5.3.测试缺陷处理流程
转测试和正式测试发现的缺陷都必须录入QC库进行管理和跟踪。
5.3.1.流程图
图表2：
测试缺陷处理流程
5.3.2.活动描述
1）测试工程师在测试过程中发现缺陷，将缺陷录入QC，新增的缺陷为New状态，分析缺陷选填写缺陷类型、发现手段、缺陷严重等级、缺陷发现阶段、Subject（缺陷主题）。
在QC库中新增缺陷前，应先检查是否有类似的缺陷已经存在，类似缺陷已关闭则重新录入，未关闭则在原缺陷中进行注明，避免重复。
缺陷填写要求参见：
附件一缺陷填写规范
2）开发组长对新建状态的缺陷进行分析，填写缺陷引入阶段。
将需要修改的缺陷状态改为“Open”，指定给相关软件工程师。
并选择缺陷引入阶段。
3）项目经理对暂缓修改、重新打开和拒绝三种类型的BUG进行分析处理。
Ø
将暂缓修改的缺陷状态改为“Abandon”，并填写暂缓原因。
项目经理每个版本对QC库中暂缓的缺陷进行处理，需修改的打开给相关责任人进行修改；
已修复的缺陷，将状态修改为“Fixed”，下一次提交测试时测试工程师进行验证。
将拒绝的缺陷状态改为“Rejected”，并填写拒绝的原因。
只有项目经理有暂缓和拒绝缺陷的权限。
对于暂缓和拒绝的缺陷，项目经理需与测试工程师沟通，不能达成一致时，上报给技术总监，对有争议的缺陷进行最终的确认。
修改测试人员填写的”优先级”，若觉得测试人员填写合理则不用修改。
对测试工程师指派的状态为Reopen的BUG进行分析并做下一步处理。
4）软件工程师修复分配的缺陷，
Ⅰ修改完毕后，将缺陷状态改为“Fixed”，将处理人改为发现该BUG的测试人员，并更新缺陷引入阶段和预计修复版本（填写规则：
预计下一版本修复时选择下一版本,不是下一版本修复时选择未知）。
Ⅱ将拒绝和延期的BUG指派给项目经理，但状态保持”open”，在备注中说明拒绝理由和延期理由，延期的BUG还需说明延期的时间点。
5）测试工程师在回归测试时，验证QC库中“Fixed”状态的缺陷。
验证通过的，将状态修改为“Closed”；
未通过的，状态改为“Reopen”，指派给软件工程师
6）测试工程师对Rejected的BUG分析后，若认为可关闭，则将BUG状态置为Closed（Rejected）；
若认为必须修改，则将BUG状态置为Reopen，指派给项目经理，由项目经理进行下一步操作。
6.缺陷分析
6.1.缺陷统计
缺陷统计是为了帮助未来项目设定量化的质量目标，理解和控制未来项目的实际结果，为缺陷预防奠定基础。
项目组进行阶段总结时，测试工程师针对消缺率、一次性通过率、Reopen率、缺陷引入阶段等指标对缺陷情况进行统计，生成缺陷统计报告，提交项目经理。
项目经理根据统计结果进行分析。
以下定义所指的缺陷除了特定项（采纳率和Reopen率）外均不包括建议性缺陷。
●消缺率：
展现对缺陷或建议的修复或采纳情况，公式：
消缺率=已关闭缺陷总数/缺陷总数（其中缺陷总数不包括“Rejected”状态及建议性的缺陷）
●一次性通过率：
展现提交测试的系统一次性转测试通过的情况。
●Reopen率：
展现缺陷的修复质量，公式：
Reopen缺陷数/验证的缺陷数（同一个缺陷重新打开多次按实际打开次数计算；
缺陷总数包括建议性缺陷）。
●缺陷引入阶段：
按照缺陷引入阶段进行统计，便于项目组进行缺陷分析。
缺陷统计报告模板参见：
xxx系统缺陷统计报告.dot。
7.缺陷预防
缺陷预防的着眼点在于缺陷的共性原因，通过找寻、分析和处理缺陷的共性原因，实现缺陷预防。
项目阶段总结时，项目组完成缺陷分析后，项目经理组织项目组对分析结果进行讨论，总结出缺陷预防改进措施列表。
比如：
增加对开发人员进行业务培训。
加强单元测试，单元测试安排措施等
增加代码走查工作
8.退出准则
缺陷关闭并完成缺陷分析和预防。
9.附件
9.1.附件一缺陷填写规范
缺陷摘要需以简洁的语言表述准确的信息，用准确表达意义的缩略语进行描述，一些关键词如“程序崩溃”、“系统无反应”和“文字错误”等，在把缺陷摘要作为检索条件时非常方便。
缺陷描述需要遵循以下7个要点：
精练、正确、中立、准确、普遍性、可再现和有证据。
9.1.1.精练
缺陷记录的描述需简单明了。
不加入与问题无关的叙述，去除不必要的信息，但涵盖所有必要的信息。
9.1.2.正确
一定要清楚所记录的缺陷的确存在，在提交前，先考虑如下几点：
对系统需求理解正确；
已经安装和系统相关的软件，机器设置没有问题；
被测软件本身的设置正确；
不是以前测试时遗留的错误数据导致的错误；
不是网络状况变化引起的问题，或者其它外在环境因素（如防火墙）引起的错误。
以上这些都对测试的结果有很大的影响，确认这些问题是否存在。
9.1.3.中立
客观地描述每一个缺陷，不带任何情绪化的语言。
9.1.4.准确
缺陷记录需要准确的描述缺陷发生的位置，产生条件和结果。
最好做到让阅读缺陷记录者不需要亲自上机操作就知道问题所在。
例子
缺陷描述
不准确的描述
查询中按状态查询发生错误。
准确的描述
信息查询>
天气预报信息查询：
在列表页面的查询条件中，按“状态”字段的“已审”查询条件进行查询时，查询结果无记录，没有查询出状态为“已审”的天气预报信息。
9.1.5.普遍性
记录缺陷时需明确的描述出该问题在整个系统中普遍存在的地方，便于一次修复同类缺陷。
9.1.6.可再现
为了快速、准确的重现缺陷，需列出缺陷产生的步骤。
每一个步骤尽量只记录一个操作。
步骤完整，准确，简短。
尽量使用短语和短句，避免复杂句型句式。
如果无法重现，需在缺陷记录中明确说明。
9.1.7.证据
为了直观的观察缺陷现象，通常需要附加缺陷出现的界面，以附件形式上传到缺陷记录中。
为了节省空间，又能真实反映缺陷或错误本质，可以捕捉缺陷产生时的全屏幕，活动窗口和局部区域；
如果打开某个特殊的文档而产生的缺陷，则必须附加该文档，从而可以迅速再现缺陷。
有时，为了使缺陷修正者进一步明确缺陷的表现，可以附加个人的修改建议或注解。
9.2.附件二 缺陷类型描述
9.2.1.功能
1）与系统需求不一致
软件未实现产品说明书要求的功能、软件实现了产品说明书未提到的功能。
2）功能实现错误
例：
查询结果不正确。
页面白屏或报404、500。
业务逻辑错误。
3）权限错误
“已审”状态的招工信息应不能修改，但是系统中可以修改并成功保存。
4）数据错误
数据计算错误、统计错误等。
5）链接错误
一般链接、页面跳转等不正确。
6）数据校验
边界值、字符校验等。
9.2.2.界面
1）界面不友好，控件布局不美观
界面布局不合理，按钮换行、字体大小不一致等。
2）错别字、备注文字或提示信息不合理
9.2.3.易用性
使用回车键确定。
在查询页面，输入查询条件后可以使用回车键执行查询。
9.2.4.兼容性
1）浏览器的兼容性
IE，遨游、FireFox，Maxthon，Opera,苹果及其各版本的浏览器等。
2）操作系统的兼容性
Windows2000、WindowsXP、Windows2007等各版本的操作系统。
3）硬件兼容性
最低硬件配置兼容性、旧硬件配置兼容性、硬件冲突。
4）软件兼容性
与其他公司软件不兼容、与本公司其他软件不兼容、与旧版本软件不兼容。
9.2.5.接口
1）接口通信错误及数据交互错误
数据同步到另一系统时丢失。
2）输入的要素信息配置不符合的接口文档，系统处理不正确。
根据接口文档中的参数说明传入接口参数，接口功能异常。
3）在处理过程中中断事务后，系统不能正确处理（中断用户到服务器的网络链接、中断web服务器到数据库验证服务器的链接）
提交数据后，中断网络链接，系统不能正确处理中断。
9.2.6.性能
1）页面响应慢
页面响应时间过慢。
打开查询列表页面慢，需要2分钟。
单用户进行统计或查询，几分钟才能显示出结果。
2）超时报错
批量导入200条数据，页面白屏，导入不成功（导入几条记录时正常）。
9.2.7.环境
测试环境初始化数据问题。
9.2.8.一致性
在同一系统中各模块、各页面相同功能页面展现不一致。
在招工信息录入页面有【返回】按钮，而在天气预报信息录入页面无【返回】按钮。
在招工信息录入页面用红色字体提示必填字段，而在天气预报信息录入页面用蓝色字体提示必填字段。
9.2.9.其他
9.3.附件三 缺陷等级描述
升级会员 