Bug生命周期对Bug的处理开发组长/经理每天对Bug进展分配，标注处理意见，给定优先级〔发版前必须三方：需求、开发、产品共同确定〕问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员有可能是需求的问题，分配给需求人员定期对Bug库分析，找出常出错的模块，进展代码审查开发人员分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度B-Major类或紧急程度3-High类以上〔包含〕bug5个或5个以上，停顿新功能的开发需求人员解释需求，给出处理意见，将Bug库中的建议整理成需求文档评审确定后列入开发方案测试人员不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度验证Bug是否已被解决测试组长/经理审核测试人员提交的Bug定期对Bug库进展分析，描绘出曲线图等，报告现状、预测趋势在测试总结报告中给出意见产品人员可以对优先级和处理意见等进展审核，如果有意见，和工程组商量定夺 Bug状态(Status)：指缺陷通过一个跟踪修复过程的进展情况包括New、Open、Reopen、Fi*ed、Closed及Rejected等New为测试人员新问题提交所标志的状态。
Open为任务分配人〔开发组长/经理〕对该问题准备进展修改并对该问题分配修改人员所标志的状态Bug解决中的状态，由任务分配人改变对没有进入此状态的Bug，程序员不用管Reopen为测试人员对修改问题进展验证后没有通过所标志的状态；或者已经修改正确的问题，又重新出现错误由测试人员改变Fi*ed为开发人员修改问题后所标志的状态，修改后还未测试Closed为测试人员对修改问题进展验证后通过所标志的状态由测试人员改变Rejected开发人员认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错，从而拒绝的问题由Bug分配人或者开发人员来设置Bug严重级别(Severity，Bug级别)：是指因缺陷引起的故障对软件产品的影响程度由测试人员指定A-Crash错误导致了死机、产品失败〔“崩溃〞〕、系统悬挂无法操作；B-Major功能未实现或导致一个特性不能运行并且不可能有替代方案；C-Minor错误导致了一个特性不能运行但可有一个替代方案；D-Trivial错误是外表化或微小的〔提示信息不太准确友好、错别字、UI布局或罕见故障等〕，对功能几乎没有影响，产品及属性仍可使用；E-Nice to Have〔建议〕建立性的意见或建议。
Bug优先级(Priority)：指缺陷必须被修复的紧急程度由Bug分配者〔开发组长/经理〕指定5-Urgent阻止相关开发人员的进一步开发活动，立即进展修复工作；阻止与此密切相关功能的进一步测试4-Very High必须修改，发版前必须修正3-High必须修改，不一定马上修改，但需确定在*个特定里程碑完毕前须修正2-Medium如果时间允许应该修改1-Low允许不修改功能模块(Subject)：TD中需在Test Plan页中定义好Subject，才能在Defects页中使用问题描述、附图 请参见后面第四局部‘Bug描述要求’的有关内容处理意见:开发组长/经理(或具体Bug分配人员) 在审核新Bug时、将Bug分配给开发人员解决前，需要给出该Bug的处理意见Fi*able可修改表示Bug可以被修复或更正Duplicated重复表示该Bug已经被其它测试人员找出来了〔‘纯粹’重复〕，或者开发认为原因是一样的〔但从测试来看，认为出现的地方有所不同、表现有所不同等〕Postponed延后由于时间、进度、重要程度或者技术/需求等方面的原因，认为不能解决、须延期解决、或者本版不做留待到后续版本解决的Bug。
〔注：因‘Bug状态’字段中也有该值，根据各组各自使用情况，可以只保存一个，或者开发/测试各有侧重地使用这两个Postponed〕By Design因设计构造问题无法修改测试人员认为是Bug，不符合逻辑，也不符合用户的要求，但开发人员则认为是按照设计做的、只能如此处理，否则修改代价太大Can’t Reproduce 不可复现不能重现〔如因Bug出现的环境重现不了了〕，或以前出现的*个Bug自动消失了〔可能是在处理其他Bug的时候把这个Bug 一并修复掉了〕〔注：因TD本身亦带有‘是否复现(Reproducible)’字段，根据各组各自使用情况，可以用它来标识，或者不用它而在‘处理意见’字段中用该值标识出〕Disagree With Suggestion不同意所提意见或建议，不采纳Not Error不是问题测试人员提错了Won’t Fi*这个Bug是一个错误，但还没有重要到非要更正不可的地步，可以忽略不计说明：1. 定为Duplicated的Bug，必须注明和***bug重复2. 测试人员对标明为Duplicated的Bug复测，需要***Bug修改前方可进展3. 定期回忆Can't Reproduce,Postponed4. 定期整理By Design其它一些字段〔及所定义的枚举值〕的定义解释，供有需要用到的组参考：测试状态〔TestState〕：新提交的Bug定位标准。
由测试人员指定一般有8个〔提交Bug时给出〕1－New Defects〔或写成Defect〕新Bug2－Second Defects〔或写成SB〕复测时新出现的Bug3－Faculative偶发性4－Reappear原来修改正的问题又重新出现5－By Requirement需求要求但没有做的功能6－Suggestion需求需要完善7－Differ With Requirement与需求不一致8－By Design设计要求但没有做的功能复测状态(ReTestState)：复测时给出的状态，测试人员对于经过验证的Bug应按以下几种标准进展定位由测试人员指定一般有1－OK、2－PD、3－DV、4－NB、5－NR、6－AROK正确PD此问题悬而不决DV有错误可以暂时不考虑NB不是错误NR不能复现的错误AR需求不明确问题定位：Calculate_error计算错误，指计算过程中、计算结果错误Data_error数据错误，指非计算结果类的数据错误Graphics_error图形错误，指绘图、图形显示、图形编辑时发生的错误Interface_error界面错误Requirement_error需求错误Function_error功能错误Unknown_error未知错误缺陷来源(Source)：指引起缺陷的起因。
Requirement由于需求的问题引起的缺陷Architecture由于构架的问题引起的缺陷Design由于设计的问题引起的缺陷Code由于编码的问题引起的缺陷Test由于测试的问题引起的缺陷Integration由于集成的问题引起的缺陷类型(Type)：是根据缺陷的自然属性划分的缺陷种类F- Function影响了重要的特性、用户界面、产品接口、硬件构造接口和全局数据构造并且设计文档需要正式的变更如逻辑，指针，循环，递归，功能等缺陷A- Assignment 需要修改少量代码，如初始化或控制块如声明、重复命名，*围、限定等缺陷I- Interface 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷C- Checking提示的错误信息，不适当的数据验证等缺陷B- Build/package/merge由于配置库、变更管理或版本控制引起的错误D- Documentation 影响发布和维护，包括注释G- Algorithm 算法错误U- User Interface人机交互特性：屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷P- Performance不满足系统可测量的属性值，如：执行时间，事务处理速率等。
N- Norms不符合各种标准的要求，如编码标准、设计符号等〔以上依各组实际情况可以作适当调整〕工程组各角色在Bug库中的权限管理员：全部权限测试组长/经理：全部权限测试人员：可添加Bug、不能删除Bug、可添加注释评论(R&D ments)、不可修改他人所提Bug、可调整：Bug概要(题目，Summary)、问题描述、附图(Attachments)、Bug状态、Bug级别、测试版本、测试产品、功能模块、测试状态、问题定位、复测状态、注释评论(R&D ments)、复测人、复测日期、修改人开发人员/需求人员：不能删除Bug、可添加注释评论(R&D ments)、可调整：注释评论(R&D ments)、是否复现、Bug状态〔不过无法直接标为closed〕、问题描述、处理意见、待测版本、修改人、修改日期可添加Bug开发组长/经理/需求经理：除了开发人员的权限，还可调整：优先级别、责任人、Bug概要(题目，Summary) 、附图(Attachments)工程经理：可添加Bug、可添加注释评论(R&D ments)、可修改字段：Bug概要(题目，Summary) 、问题描述、附图(Attachments) 、Bug状态〔不过无法直接标为closed〕、修改人、优先级别、问题定位、处理意见、注释评论(R&D ments) 、是否复现、责任人、待测版本。
也可删除Bug，但要与测试组长/经理协商不属于工程组成员的其他人如研发中心经理组成员等，有必要查看TD库的话，可分配给其**及查看的权限Bug描述要求Bug描述的要求为分类准确、表达简洁、步骤清楚、有实例、易再现、复杂问题有据可查〔截图或其它形式的〕测试组长/经理把关，以开发人员的角度来审查Bug描述，看其是否描述清楚了Bug，不好描述的把工程文件或截图作为提交具体要求为：· 问题描述一般格式：问题描述时，建议分几步描述：模块或功能点=>测试步骤=>期望结果=>实际结果=>其它信息，可依实际情况调整； · 单一：尽量一个报告只针对一个软件缺陷，报告形式应方便阅读在主报告之后应注明不同的条件； · 简洁：每个步骤的描述应尽可能简洁明了只解释事实、演示和描述软件缺陷必要的细节，不要写无关信息； · 再现：问题必须在自己机器上能复现方可入库〔个别严重问题复现不了也可入库，但需标明〕； · 复杂的问题应附截图补充说明或直接通知指定的修改人；考虑到网络数据传输效率，截图的文件格式建议用JPG或GIF，不建议用BMP；抓图可用TestDirector自带的功能，亦可用HyperSnap之类的专用抓图工具。
· 报告中不允许使用抽象词句：比方“有错误〞之类； · 有关操作系统特征问题：应在不同操作系统上进展操作，看是否能重现，并在Bug报告中标识； · Bug描述例如： 例一**98土建标准换算操作：1.输入9-242.F83.在F8输入10期望结果：进展换算实际结果：提示“输入的厚度应大于20”例二〔模块或功能点也可在‘功能模块’字段中规定，则Bug描述中就不必写了〕操作：1.翻开新建向导；2.在“新建〞中的“工程名称〞中输入>。