《Bug提交与管理规范ppt课件》由会员分享，可在线阅读，更多相关《Bug提交与管理规范ppt课件（15页珍藏版）》请在金锄头文库上搜索。
1、Bug提交与管理规范编写人：姚妮娜2021.8.20Bug提交与管理规范概述Bug的生命周期测试流程中的角色与职责判别Bug的规那么Bug的分类、形状、级别Bug的报告、跟踪、封锁测试人员验证/封锁问题描画开发人员处理问题描画Bug的生命周期角色与职责流程任务内容/管理方法职责输出建立bug库提交系统测试后，建立相应bug库测试经理Bug库称号提交版本开发经理提交软件版本号和详细信息开发经理Build号提交测试bug测试人员提交测试bug测试经理审阅后，提交开发人员待处置测试人员测试经理Bug记录Bug修正开发经理分配bug给相关开发人员修正，修正后提交待开发提交开发经理开发人员修正记录提交新
2、版本开发经理提交新的版本，将修正信息和修正的bug写明在记录中开发经理版本阐明Bug回归测试测试人员根据修正阐明，返测bug测试人员Bug形状记录Bug归档返测结果正确，可以提交归档。假设有问题，继续退还开发人员处置测试经理测试人员Bug形状其他渠道反映的bug客户、销售、邮件或者会议上反映的bug，确认后可以记录到bug库中开发经理测试经理产品经理Bug记录判别Bug的规那么软件未到达产品规格阐明书需求标明的功能。软件出现了规格阐明书指明不会出现的错误。软件功能超出规格阐明书指明的范围。软件未到达规格阐明书虽未指出但应到达的目的隐含需求。软件测试员以为软件难以了解、不易运用、运转速度缓慢，或
3、者最终用户以为不好。需求留意的是，测试人员报告Bug时，该当保证Bug是可以重现的。对于有时不可重现的Bug，该当反复测试，直到最终确定Bug的发生场景为止。Bug的分类1.1.功能功能A.A.反复的功能；反复的功能；B.B.多余的功能；多余的功能；C.C.功能没有到达功能没有到达设计的要求；的要求；D.D.功能功能实现与与设计要求不相符。要求不相符。2.2.易用性易用性A.A.界面不美界面不美观，控件，控件陈列、格式不一致，焦点控制不合理或不全面；列、格式不一致，焦点控制不合理或不全面；B.B.短少短少协助信息，或者助信息，或者协助信息不助信息不完全；完全；C.C.功能操作复功能操作复杂，提
4、示信息不合理，易，提示信息不合理，易产生歧生歧义。3.3.平安性平安性A.A.数据有效性数据有效性检测不合理；不合理；B.B.重要数据在重要数据在传输中没有加密；中没有加密；C.C.短少身份短少身份认证机制或机制或认证不合理；不合理；D.D.数据数据产生缺乏随机性；生缺乏随机性；E E网网络平安性：开放端口、效力；平安性：开放端口、效力；F F系系统日志、日志、审计。4.4.可靠性可靠性A.A.数据存数据存贮的可靠性；的可靠性；B.B.业务处置的可靠性；置的可靠性；C C硬件可靠性：如打印机；硬件可靠性：如打印机；D.D.应急急处置措施；置措施；E E数据数据备份、恢复。份、恢复。5.5.性能
5、性能A.A.并并发量；量；B.B.吞吐量；吞吐量；C.C.呼呼应时间。6.6.兼容性兼容性A.A.硬件兼容性；硬件兼容性；B.B.软件兼容性。件兼容性。7.7.可可维护性性A.A.可可扩展性；展性；B.B.方便晋方便晋级。Bug的形状新建形状新建形状 NEW NEW BugBug创建后的初始形状。建后的初始形状。已分配形状已分配形状ASSIGNEDASSIGNED 经过确以确以为合法合法软件件问题后分配后分配给开开发人人员的形状。的形状。待待验证形状形状RESOLVEDRESOLVED 开开发部部门对软件件问题进展展处置或修正后的形状。置或修正后的形状。重新翻开形状重新翻开形状REOPENED
6、REOPENED对开开发部部门修正后修正后软件件问题，经过验证，假，假设依然存在，那么将依然存在，那么将其形状改其形状改为“重新翻开形状。重新翻开形状。对于于“封封锁/ /延延迟修正形状的修正形状的软件件问题，假假设时机成熟，需求重新开机成熟，需求重新开发，那么将其形状改，那么将其形状改为“重新翻开形状。重新翻开形状。封封锁形状形状CLOSEDCLOSEDBugBug生命周期的生命周期的终了。了。处理形状理形状VERIFIEDVERIFIED经测试部部门对修正后的修正后的软件件问题进展展验证并确并确认修正正确后的形修正正确后的形状。状。未未经证明形状明形状UNCONFIRMEDUNCONFIR
7、MED由开由开发人人员本人提交的本人提交的BugBug，是一种初始形状，待，是一种初始形状，待测试人人员确定确定后后变为“New“New。Bug的级别在软件测试过程中发现的Bug，要根据其严重程度进展分类，然后，进展不同的处置。可以把Bug划分为七级：第一级blocker: 引起操作系统“挂起或“解体的错误；第二级critical: 引起软件本身“挂起或“解体的错误；第三级major: 不能完成软件阐明书定义的功能的错误；第四级normal: 程序所完成的功能与软件阐明书定义不符的错误；第五级minor : 显示方面的错误；第六级trivial : 其它“细微的错误如文本过失；第七级enhan
8、cement：加强或者改良。Bug的修正优先级修正优先级通常可分为五个级别：P1：尽快或立刻修正；P2：每个里程碑或测试周期终了前必需修正；P3：假设时间允许就修正；P4：低优先级。 P5：在未来的某个版本修正也可以处置的任务日Blocker、critical：呼应时间1天，处置1天Major、normal：呼应时间1天，处置3天Minor、trivial：呼应时间1天，处置7天Enhancement:时间未定Bug报告的内容缺陷IDBug的独一标志，由Bug管理系统自动生成缺陷标题简明扼要地对Bug进展概要描画产品称号每个要测试软件工程都有独一的称号测试版本报告错误时，一定要正确填写产生错误
9、的软件版本号。 测试环境软件环境：操作系统和其他必要的软件程序；硬件环境：测试计算机和其他设备的配置信息 前提条件问题来源，引起错误发生的前提条件根本信息Bug的类型 、严重程度 以及处置的优先级；Bug所属模块；测试者称号、测试时间操作步骤详细描画错误重现的步骤，便于重现错误，修复错误和验证错误。 实践结果描画实践测试后得到的结果。 期望结果描画满足设计要求的结果。 出现频率错误出现的概率文字注释与附图测试者的建议与必要的附图,便于确认错误的表现方式和错误位置。 有效描画Bug短小：只解释现实和演示、描画Bug必需的细节；单一：每一个报告中针对一个Bug；步骤明晰：要清楚地描画出Bug的发生
10、场景，包括前置条件和操作的详细步骤；再现：按照预定步骤可以重现一样情况；在报告Bug时只描画现实，不做评价，也不要有人身攻击；必要的时候可以添加注释remarks；可以上载屏幕抓图和其他附件。Bug的验证与封锁测试人员要不断跟踪Bug，直到Bug修正，问题处理为止。新提交的Bug为NEW形状，经开发人员修正后，Bug变为RESOLVED待验证形状。此时就需求测试人员对Bug进展回归测试，验证问题能否修正。假设问题依然存在，那么测试人员将该Bug的形状修正为REOPENED重新翻开；假设经过验证确认问题曾经修正好了，那么测试人员将该Bug的形状置为VERIFIED已验证，同时添加附加意见如“该B
11、ug在Release xx.xx版本中曾经修正。还有一种情况：开发人员以为Bug在当前版本可以暂不修正，而思索在后续版本中再做修正，Bug的对应形状为LATER。对于这种情况，工程担任人应召集开发人员、测试人员和其他工程相关人员进展讨论，假设讨论结果为赞同在后续版本修正，那么测试人员可以将该Bug的形状置为VERIFIED；假设讨论结果是需求在本版本中处理问题，那么测试人员应将该Bug的形状置为REOPENED，重新翻开Bug。对于形状为VERIFIED的Bug，应由Bug的开启者即测试人员封锁。开发人员无权封锁Bug。将Bug的形状标志为CLOSED，那么Bug生命周期的终了。测试人员验证/
12、封锁Bug测试人员验证/封锁Bug阐明：当Bug由open变为fixed，应进展回归测试，假设回归测试后该问题被处理，那么closed该Bug，并在注释中填写如下信息： 验证版本：xxx 验证次数：xxx 验证经过：是 验证日期：xxx 验证人员：xxx假设回归测实验证不经过，那么Reopened该Bug，并在注释中仍填写注释信息： 验证版本：xxx 验证次数：xxx 验证经过：否 验证日期：xxx 验证人员：xxx研发人员处理Bug研发人员应该及时对分配给本人的bug在Bugzilla中添加注释信息，以便以后的信息搜集和更好的保管作成果。针对不同情况，须按以下模块填写注释1.曾经矫正的Bug Bug产生缘由 Bug处理方案 Bug修正后的版本号 处理人员：*2.不能处理的Bug： Bug缘由分析 无法处理缘由技术问题，条件问题 处理人员：*3.Bug反复： 注明与之反复的Bug ID 如根本缘由一样，景象不同，给出简要分析阐明 处理人员：*开发人员做此修正，必需由工程经理或主管经理确认，同意。4.无效Bug： 给出无效缘由，例如设计方案就是如此。 处理人员：*开发人员做此修正，必需由工程经理或主管经理确认，同意。Bug形状报告工程进入系统测试阶段后，SQA人员要定期做Bug形状报告。Bug形状报告要以邮件方式发送给工程组长、工程组成员、测试人员和工程高层管理者。
