Bug状态流程图.docx

1、Bug状态流程图Bug状态流程图对Bug的处理开发组长/经理每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产品共同确 定）。问题分配时，应尽可能将 咨询类、理解错误类等问题处理掉，而不是留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找岀 常出错的模块，进行代码审查开发人员分析Bug,写岀问题原因，修改Bug ;实行Bug优先原则，严重程度B-Major类或紧急程度3-High类以上（包含）bug5个或5 个以上，停止新功能的开发。需求人员解释需求，给岀处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发计划测试人员不参与问题的优先

2、级的定位，只用 Bug级别反映Bug的严重程度。验证Bug是否已被解决测试组长/经理审核测试人员提交的Bug。定期对Bug库逬行分析，描绘岀曲线图等，报告现状、预测趋势。在测试总结报告中给出意见产品人员可以对优先级和处理意见等进行审核，如果有意见，和项目组商量定夺New Open Reopen. Fixed、Bug状态（Status）：指缺陷通过一个跟踪修复过程的进展情况。包括Closed 及 Rejected 等New为测试人员新问题提交所标志的状态。Ope n为任务分配人（开发组长/经理）对该问题准备进行修改并对该问题 分配修改人 员所标志的状态。Bug解决中的状态，由任务分配人改变。对没

3、有进入此状态的 Bug，程序员不用管。Reopen为测试人员对修改问题进行验证后没有通过所标志的状态；或者已经修改正确的 问题，又重新岀现错误。由测试人员改变。Fixed为开发人员修改问题后所标志的状态，修改后还未测试。Closed为测试人员对修改问题进行验证后通过所标志的状态。由测试人员改 变。Rejected开发人员认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议、或 虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错，从而 拒绝的问题。由 Bug分配人或者开发人员来设Bug严重级别（Severity，Bug级别）：是指因缺陷引起的故障对软件产品的影响程度。由测试

4、人员指A-Crash错误导致了死机、产品失败（“崩溃”）、系统悬挂无法操作；B-Major功能未实现或导致一彳、特性不能运行并且不口J能有替代方案；C-Mi nor错误导致了一个特性不能运行但可有一个替代方案；D-Trivial错误是表面化或微小的（提示信息不太准确友好、错别字、 UI布局或罕见故障等），对功能几乎没有影响，产品及属性仍可使用；E-Nice to Have （建议）建设性的意见或建议。Bug分配者（开发组长/经理）指定Bug优先级（Priority）:指缺陷必须被修复的紧急程度。由5-Urge nt阻止相矢开发人员的进一步开发活动，立即进行修复工作；阻止与此 密切相矢功 能的进

5、一步测试4-Very High必须修改，发版前必须修正3-High必须修改，不一定马上修改，但需确定在某个特定里程碑结束刖须修 正2-Medium如果时间允许应该修改1-Low允许不修改功能模块（Subject） : TD中需在Test Plan页中定义好Subject，才能在Defects页中使用问题描述、附件附图请参见后面第四部分Bug描述要求的有矢内容。处理意见：开发组长/经理（或具体Bug分配人员）在审核新Bug时、将Bug分配给开发人员解决前，需要给岀该Bug的处理意见。Fixable可修改。表示Bug可以被修复或更正Duplicated重复。表不该Bug已经被其它测试人员找岀来J

6、（纯粹重复），或者开发 认为原因是相冋的（但从测试来看，认为岀现的地方有所不冋、表现有所不冋 等）Postp oned延后。由于时间、进度、重要程度或者技术 /需求等方面的原因，认为不能解决、须延期解决、或者本版不做留待到后续版本解决的Bug。（注：因Bug状态字段中也有该值，根据各组各自使用情况，可以只保留 一个，或者开发/测试各有侧重地使用这两个Postponed ）By Desig n因设计结构问题无法修改。测试人员认为是 Bug，不符合逻辑，也不符合用户的要求，但开发人员则认为是按照设计做的、只能如此处理，否则修改 代价太大Car? t Reproduce不口j复现。不能重现（如因Bu

7、g岀现的环境重现不了了），或以刖岀现的某个 Bug自动消失了（可能是在处理其他Bug的时候把这个Bug 一并修复掉了）。（注：因TD本身亦带有 是否复现（Reproducible），字段，根据各组各自 使用情况，可以用它来标识，或者不用它而在处理意见字段中用该值标识 出）Disagree With Suggesti on不同意所提意见或建议，不采纳Not Error不是问题。测试人员提错了Won t Fix这个Bug是一个错误，但还没有重要到非要更正不可的地步，可以忽略不计说明：1 定为Duplicated的Bug,必须注明和XXXbug重复2.测试人员对标明为Duplicated的Bug复测

8、，需要XXXBug修改后方可进行3.定期回顾 Cant Reproduce,Postponed4.定期整理By Design其它一些字段(及所定义的枚举值)的定义解释，供有需要用到的组参考:测试状态(TestState ):新提交的Bug定位标准。由测试人员指定。一般有8个(提交Bug时给出)1 New Defects （或写成 Defect ）新Bug2 Seco nd Defects （或写成 SB复测时新岀现的Bug3 Faculative偶发性4 Reappear原来修改过的问题又重新出现5 By Requireme nt需求要求但没有做的功能6 Suggesti on需求需要完善7

9、Differ With Requireme nt与需求不一致8 By Desig n设计要求但没有做的功能复测状态(ReTestState):复测时给岀的状态，测试人员对于经过验证的 Bug应按以下几种标准进行定位。由测试人员指定。一般有1- 0K2- PD 3-DV 4- NB 5- NR 6-AF。0K正确PD此问题悬而不决DV有错误可以暂时不考虑NB不是错误NR不能复现的错误AR需求不明确问题定位:Calculate error计算错误，指计算过程中、计算结果错误。Data error数据错误，指非计算结果类的数据错误。Graphics error图形错误，指绘图、图形显示、图形编辑时发

10、生的错误。In terface error界面错误Requireme nt error需求错误Fun ctio n error功能错误Unknown error未知错误缺陷来源(Source):指弓I起缺陷的起因Requireme nt由于需求的问题引起的缺陷Architecture由于构架的问题引起的缺陷Desig n由于设计的问题引起的缺陷Code由于编码的问题引起的缺陷Test由于测试的问题引起的缺陷In teg rati on由于集成的问题引起的缺陷类型仃ype):是根据缺陷的自然属性划分的缺陷种类。F- Fun cti on影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据

11、 结构。并且 设计文档需要正式的变更。如逻辑，指针，循环，递归，功能等缺陷A Assig nment需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷1-1 n terface与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相 互影响的缺 陷。C- Check ing提示的错误信息，不适当的数据验证等缺陷。B u i 1 d/packag e/m e rge由于配置库、变更管理或版本控制引起的错误D Docume ntati on影响发布和维护，包括注释。G- Algorithm算法错误。U User In terface人机交互特性：屏幕格式，确认用户输入，功能

12、有效性，页面排版等方面的缺陷P Performs nee不满足系统可测量的属性值，如：执行时间，事务处理速率等。N- Norms不符合各种标准的要求，如编码标准、设计符号等。(以上依各组实际情况可以作适当调整)项目组各角色在Bug库中的权限管理员：全部权限测试组长/经理：全部权限测试人员：可添加Bug、不能删除Bug可添加注释评论(R&D Comments)不可修改他人所提Bug可调整：Bug概要(题目， Summary)问题描述、附件附图(Attachmen、Bug状态、Bug级别、测试版本、测试产品、功能模块、测试状态、问题定位、 复测状态、注释评论 (R&D Comments)复测人、复

13、测日期、修改人Bug概要(题目,开发人员/需求人员：不能刪除Bug、可添加注释评论(R&D Commen可调整：注释评论(R&D Comments)是否复现、Bug 状态(不过无法直接标为closed)、问题描述、处理意见、待测版本、修改人、修改日期。可添加Bug。开发组长/经理/需求经理：除了开发人员的权限，还可调整：优先级别、责任人、Summary) 附件附图(Attachments)项目经理：可添加Bug、可添加注释评论（R&D Comments）可修改字段：Bug概要（题目，Summary）、问题描述、附 件附图（Attachments） 、Bug状态（不过无法直接标为closed ）

14、、修改人、优先级别、问题定位、处理意见、注释评论（R&D Comme nts）、是否复现、责任人、待测版本。TD库的话，可分配给其帐号及查也可刪除Bug，但要与测试组长/经理协商。不属于项目组成员的其他人 如研发中心经理组成员等，有必要查看 看的权限Bug描述要求Bug描述的要求为分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂问题有据可查（截图或其它形式的附件）。测试组长/经理把矢，以开发人员的角度来审查 Bug描述，看其是否描述清楚了Bug，不好描述的把工程文件或截图作为附件提交。具体要求为：问题描述一般格式：问题描述时，建议分几步描述：模块或功能点 =测试步骤=期望结果=实际结果=其它

15、信息，可依实际情况调整；单一：尽量一个报告只针对一个软件缺陷，报告形式应方便阅读。在主报告之后应注明不同的条件；简洁：每个步骤的描述应尽可能简洁明了。只解释事实、演示和描述软件缺陷必要的细节，不要写无矢信息；*再现：问题必须在自己机器上能复现方可入库（个别严重问题复现不了也可入库，但需标 明）；复杂的问题应附截图补充说明或直接通知指定的修改人；考虑到网络数据传输效率，截图的文件格式建议用JPG或GIF,不建议用BMP抓图可用TestDirector自带的功能，亦可用HyperSnap之类的专用抓图工具。*报告中不允许使用抽象词句：比如“有错误”之类；*有矢操作系统特征问题：应在不同操作系统上进

16、行操作，看是否能重现，并在 Bug报告中标识；*Bug描述示例：例_河北98 土建标准换算操 作：1 .输入9-242.F83.在F8输入10期望结果：进行换算实际结 果：提示“输入的厚度应大于20” 例二（模块或功能点也可 在功能模块字段中规 定，则Bug描述中就不必 写了）操作：1 打开新建向导；2在“新建”中的“项目名 称”中输入80个字符；3.点击“下一步”例三（程序员知道期望结果的情况下）云南98 土建操作：1.输入131702.F53.在F5中修改3240008的名称，处于编辑状态4.到人材机，再回来实际 结果：F5中变白 例四（建议、需求类）功 能：预算页，子目排序后可 恢复原顺

17、序用途：用户误操作后可复原期望结果：“项目名称”应=80个字符，输入大于 80个字符，点击“下一步”应有错误提示 实际结果：进入“比重调 整”界面板注：若3不处于编辑态切换则正常5因此对于注：所有项目采用TestDirector逬行Bug管理，该工具能从测试步骤自动生成 Bug报告Bug描述要求在测试方案用例设计（在 Test Plan页中）阶段就可以进行控制。附：好的Bug报告应满足以下几方面的要求：结构清晰复现故障再写报告*隔离Bug：更改条件复测归纳：是否其他模块也有相同的 Bug4比较：其他测试用例是否使用到此 Bug*总结：报告的开头有Bug的总结精简：不要有多余的步骤和语言无歧义：语言明确*中立：无批评性语言讨论：将要发岀的报告送其他测试人员讨论小结通过专业的技术测试岀精确的Bug ;!通过准确的文档报告Bug； 通过良好的沟通使Bug尽快解决。