bug的知识

Bug状态(Status)：指缺陷通过一个跟踪修复过程的进展情况。包括New、Open、Reopen、Fixed、Closed 及Rejected等 New 为测试人员新问题提交所标志的状态。 Open 为任务分配人（开发组长/经理）对该问题准备进行修改并对 该问题分配修改人员所标志的状态。Bug 解决中的状态，由 任务分配人改变。对没有进入此状态的 Bug，程序员不用管。 Reopen 为测试人员对修改问题进行验证后没有通过所标志的状态； 或者已经修改正确的问题，又重新出现错误。由测试人员改 变。 Fixed 为开发人员修改问题后所标志的状态，修改后还未测试。 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的处理意见。 Fixable 可修改。表示 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 Fix 这个Bug是一个错误，但还没有重要到非要更正不可的地步， 可以忽略不计 说明： 1. 定为Duplicated的Bug，必须注明和XXXbug重复 2. 测试人员对标明为Duplicated的Bug复测，需要XXXBug修改后方可进行 3. 定期回顾Can't Reproduce,Postponed 4. 定期整理By Design 其它一些字段（及所定义的枚举值）的定义解释，供有需要用到的组参考： 测试状态（TestState）：新提交的Bug定位。由测试人员指定。一般有8个（提交Bug时给出） 1－ New Defects（ 或写成 Defect） 新 Bug 2－ Second Defects（或写成 SB） 复测时新出现的 Bug 3－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－AR。 OK 正确 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描述，看其是否描述清楚了Bug， 不好 描述的把工程文件或截图作为附件提交。具体要求为： · 问题描述一般格式：问题描述时，建议分几步描述：模块或功能点=>测试步骤=>期望结果=> 实际结果=>其它信息，可依实际情况调整； · 单一：尽量一个报告只针对一个软件缺陷，报告形式应方便阅读。在主报告之后应注明不同 的条件； · 简洁：每个步骤的描述应尽可能简洁明了。只解释事实、演示和描述软件缺陷必要的细节， 不要写无关信息； · 再现：问题必须在自己机器上能复现方可入库（个别严重问题复现不了也可入库，但需标明）； · 复杂的问题应附截图补充说明或直接通知指定的修改人；考虑到网络数据传输效率，截图的 文件格式建议用 JPG或 GIF，不建议用 BMP；抓图可用 TestDirector自带的功能，亦可用 HyperSnap之类的 · 专用抓图工具。 · 报告中不允许使用抽象词句：比如“有错误”之类； · 有关操作系统特征问题：应在不同操作系统上进行操作，看是否能重现，并在 Bug报告中标 识； 注：所有项目采用TestDirector进行Bug管理，该工具能从测试步骤自动生成Bug报告，因此对于 Bug描述要求在测试方案用例设计（在Test Plan页中）阶段就可以进行控制。 附：好的Bug报告应满足以下几方面的要求： · 结构清晰 · 复现故障再写报告 · 隔离 Bug：更改条件复测 · 归纳：是否其他模块也有相同的 Bug · 比较：其他测试用例是否使用到此 Bug · 总结：报告的开头有 Bug的总结 · 精简：不要有多余的步骤和语言 · 无歧义：语言明确 · 中立：无批评性语言 · 讨论：将要发出的报告送其他测试人员讨论 ² 确保字体在不同浏览器中都相同 ² 检查以确保每一个链接都指向正确的文件或站点 ² 检查图形以确保其分辨率何大小正确 ² 对每一页进行拼写检查 ² 让原稿编辑检查语法和风格 ² 在页面载入时检查光标位置，以确保其在正确的文本框中 ² 检查以确保在页面载入时选中了默认的按钮 Bug的 5个等级: Ø Low ： 微小。不影响产品继续使用，如界面中的错别字等。开发人员可以根据实际情 况决定是否修正。 Ø Medium ： 一般。次要功能出现错误，不太严重，对产品使用影响不大，如提示信息 不太准确等。需要开发人员进行修正。 Ø High ： 高。主要功能出现错误，比较严重，影响产品的使用。需要开发人员积极进行 修正。 Ø Very high ： 较高。主要功能丧失，导致系统出现严重问题或致命错误，需要开发人员 尽快修正。 Ø Urgent ： 紧急，迫切。因软件原因导致系统死机，数据丢失等，需要开发人员马上修 正。 对于缺陷的严重性，如果分为 3级，则按下面的方法确定： 1—a类 ： 严重的缺陷 例如：软件的意外退出甚至操作系统崩溃，造成数据 丢失，内存溢出，reset，掉网，断电，死机，菜单功能失效，画面花屏，画面重影，通话断 点，音频语音资粮差。 2—b类 ： 比较严重的缺陷 例如：ui风格不统一，设计不合理（音量高低界 面指示相反，菜单与背景图不符），文字错误，标点错误，给予的提示模糊不详，相应速度 太慢。 3—c类 ： 一般缺陷 例如：缺少相应 icon提示，画面颜色偏淡，测试人员给 予的建设性的建议。 Bug的状态： UNCONFIRMED-----没有人确认这个 bug需要被解决。有正确权限的用户可 以确认这个 bug,把它的状态改成"NEW”。bug经常直接被解决并被标志成"RESOVLED”,但 是通常的情况是 bug需要先被指定这个 bug的属主开发人员确认 NEW----bug已经被加入到属主的 bug列表中,必须被处理。在这种状态下的 bug即将被接受且被标志成"ASSIGNED”,或者是传递给另外某一个人员,期间把 bug状态维 持在 NE,或者是直接被解决,并标志成"RESOLVED” ASSIGNED----这个状态下的 bug还没有被解决,但是已经指派给可以解决它 的人员。从这一步往下,bug可以被指派给另一个人员,并标志成 NEW,或者是直接解决 bug, 标志成"RESOLVED”。 REOPENED----bug曾经被解决,但是解决方案被认为是不正确的。从这一步 往下,bug可以被标志成 ASSIGNED和 RESOLVED。 RESOLVED----bug的解决方案已经形成,在等待 QA的验证。从这一步往下,bug可以被标 志成"REOPENED”,或者是"VERIFIED”,或者是被认为很好的解决了,标志成"CLOSED”。 VERIFIED----QA已经查看过 bug的解决方案,并且同意针对 bug已经做出的 修改。 CLOSED---- bug已经被解决,解决方案是被认为是正确的。 "解决” FIXED----对 bug的一个修改已经被登记,并且已经经过测试。 INVALID----被描述的问题不是一个 bug。 WONTFIX----被描述的问题是一个 bug,但是不准备进行修改。 LATER----被描述的问题是一个 bug,但是不在产品的目前版本中进行修改。 REMIND----被描述的问题是一个 bug,但是很可能不在产品的目前版本中进行 修改,但可能还是问题。 DUPLICATE----提出的问题和当前已经存在的某个 bug重复。 WORKSFORME----不能重现这个 bug,查看源代码也不知道为什么会出现这样 的 bug 现象,如果以后有更多的关于这个 bug的线索,重新接受这个 bug。