《Bug生命周期(理论).ppt》由会员分享，可在线阅读，更多相关《Bug生命周期(理论).ppt（15页珍藏版）》请在三一办公上搜索。
1、Bug生命周期,王心悦,Bug生命周期图,Mantis上状态,对Bug管理人员职责,开发组长/经理每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产品共同确定）。问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找出常出错的模块，进行代码审查开发人员分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度High类或紧急程度很严重类以上（包含）bug5个或5个以上，停止新功能的开发。需求人员解释需求，给出处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发计划测试人员
2、不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。验证Bug是否已被解决测试组长/经理审核测试人员提交的Bug。定期对Bug库进行分析，描绘出曲线图等，报告现状、预测趋势。在测试总结报告中给出意见产品人员可以对优先级和处理意见等进行审核，如果有意见，和项目组商量定夺,Bug状态,新建：对新发现的问题进行提交。已分派：分派给相应的工作人员反馈：提交的问题还有没有解决完的问题，需要进一步处理已解决：问题已经解决，可以进行关闭已关闭：目前由测试人员来关闭,Bug严重级别,A-宕机：错误导致了死机、产品失败（“崩溃”）、系统悬挂无法操作；B-崩溃：功能未实现或导致一个特性不能运行并且不可能
3、有替代方案；C-很严重：错误导致了一个特性不能运行但可有一个替代方案；D-小错误、小调整、细节：错误是表面化或微小的（提示信息不太准确友好、错别字、UI布局或罕见故障等），对功能几乎没有影响，产品及属性仍可使用；E-新功能：建设性的意见或建议。,Bug优先级(Priority),5-特急：阻止相关开发人员的进一步开发活动，立即进行修复工作；阻止与此密切相关功能的进一步测试4-加急：必须修改，发版前必须修正3-高：必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修正2-中：如果时间允许应该修改1-低/无：bug不严重，建议性修改,处理意见,Fixable可修改。表示Bug可以被修复或更
4、正Duplicated重复。表示该Bug已经被其它测试人员找出来了（纯粹重复），或者开发认为原因是相同的（但从测试来看，认为出现的地方有所不同、表现有所不同等）Postponed延后。由于时间、进度、重要程度或者技术/需求等方面的原因，认为不能解决、须延期解决、或者本版不做留待到后续版本解决的Bug。（注：因Bug状态字段中也有该值，根据各组各自使用情况，可以只保留一个，或者开发/测试各有侧重地使用这两个Postponed）By Design因设计结构问题无法修改。测试人员认为是Bug，不符合逻辑，也不符合用户的要求，但开发人员则认为是按照设计做的、只能如此处理，否则修改代价太大Cant Re
5、produce不可复现。不能重现（如因Bug出现的环境重现不了了），或以前出现的某个Bug自动消失了（可能是在处理其他Bug的时候把这个Bug 一并修复掉了）。（注：因TD本身亦带有是否复现(Reproducible)字段，根据各组各自使用情况，可以用它来标识，或者不用它而在处理意见字段中用该值标识出）Disagree With Suggestion不同意所提意见或建议，不采纳Not Error不是问题。测试人员提错了Wont Fix这个Bug是一个错误，但还没有重要到非要更正不可的地步，可以忽略不计,测试状态,1New Defects（或写成Defect）新Bug2Second Defect
6、s（或写成SB）复测时新出现的Bug3Faculative偶发性4Reappear原来修改过的问题又重新出现5By Requirement需求要求但没有做的功能6Suggestion需求需要完善7Differ With Requirement与需求不一致8By Design设计要求但没有做的功能,复测状态,OK正确PD此问题悬而不决DV有错误可以暂时不考虑NB不是错误NR不能复现的错误AR需求不明确,问题定位,Calculate_error计算错误，指计算过程中、计算结果错误。Data_error数据错误，指非计算结果类的数据错误。Graphics_error图形错误，指绘图、图形显示、图形编
7、辑时发生的错误。Interface_error界面错误Requirement_error需求错误Function_error功能错误Unknown_error未知错误,缺陷来源,Requirement由于需求的问题引起的缺陷Architecture由于构架的问题引起的缺陷Design由于设计的问题引起的缺陷Code由于编码的问题引起的缺陷Test由于测试的问题引起的缺陷Integration由于集成的问题引起的缺陷,类型,F-Function影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑，指针，循环，递归，功能等缺陷A-Assignment
8、需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷I-Interface与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。C-Checking提示的错误信息，不适当的数据验证等缺陷。B-Build/package/merge由于配置库、变更管理或版本控制引起的错误D-Documentation影响发布和维护，包括注释。G-Algorithm算法错误。U-User Interface人机交互特性：屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷P-Performance不满足系统可测量的属性值，如：执行时间，事务处理速率等。N-Norms不符合
9、各种标准的要求，如编码标准、设计符号等。,项目各角色在bug管理中的权限,管理员：全部权限测试组长/经理：全部权限测试人员：不能删除Bug、不可修改他人所提Bug、其他权限正常开发人员/需求人员：不能删除Bug、可添加注释评论(R&D Comments)、可调整：注释评论(R&D Comments)、是否复现、Bug状态（不过无法直接标为closed）、问题描述、处理意见、待测版本、修改人、修改日期。可添加Bug。开发组长/经理/需求经理：除了开发人员的权限，还可调整：优先级别、责任人、Bug概要(题目，Summary)、附件附图(Attachments)项目经理：可添加Bug、可添加注释评论
10、(R&D Comments)、可修改字段：Bug概要(题目，Summary)、问题描述、附件附图(Attachments)、Bug状态（不过无法直接标为closed）、修改人、优先级别、问题定位、处理意见、注释评论(R&D Comments)、是否复现、责任人、待测版本。也可删除Bug，但要与测试组长/经理协商。不属于项目组成员的其他人如研发中心经理组成员等，有必要查看TD库的话，可分配给其帐号及查看的权限。,Bug描述要求,问题描述一般格式：问题描述时，建议分几步描述：模块或功能点=测试步骤=期望结果=实际结果=其它信息，可依实际情况调整；单一：尽量一个报告只针对一个软件缺陷，报告形式应方便
11、阅读。在主报告之后应注明不同的条件；简洁：每个步骤的描述应尽可能简洁明了。只解释事实、演示和描述软件缺陷必要的细节，不要写无关信息；再现：问题必须在自己机器上能复现方可入库（个别严重问题复现不了也可入库，但需标明）；复杂的问题：应附截图补充说明或直接通知指定的修改人；考虑到网络数据传输效率，截图的文件格式建议用JPG或GIF，不建议用BMP；抓图可用TestDirector自带的功能，亦可用HyperSnap之类的专用抓图工具。报告中不允许使用抽象词句：比如“有错误”之类；有关操作系统特征问题：应在不同操作系统上进行操作，看是否能重现，并在Bug报告中标识；,Bug报告条件,结构清晰 复现故障再写报告 隔离Bug：更改条件复测 归纳：是否其他模块也有相同的Bug 比较：其他测试用例是否使用到此Bug 总结：报告的开头有Bug的总结 精简：不要有多余的步骤和语言 无歧义：语言明确 中立：无批评性语言 讨论：将要发出的报告送其他测试人员讨论,
