Bug管理规范
为了团队协条一致工作，写了些BUG管理的规范。Bug管理规范
作者：测试组
编写时间：2010年01月07日 11:30
1. 概述
本文详细描述() Bug管理规范。
本文针对TFS中Bug的填写。
本文根据MSF for Agile Software Development结合()团队实际情况编写。
2. 初始化
由()管理人员初始化Bug工作项模板。
描述省略。
3. 上报Bug的规范
3.1. 填写基本信息
图1. 填写基本信息
3.1.1. 标题
规则：填写一句可以描述Bug的短语或短句，句中及句末没有标点。
3.1.2. 分类-区域
规则：选择“测试的产品”\“测试所在的区域”。
如：()2008-v1\任务 表示测试的产品为()2008-v1，测试所在的区域为任务。
3.1.3. 分类-迭代
规则：选择“测试的产品”\“迭代的名称”。
如：()2008-v1\2010年1月10日公司内测版 表示测试的产品为()2008-v1，测试所在的迭代为2010年1月10日公司内测版。
3.1.4. 状态-指派给
规则：按小组或团队分工约定，应该处理当前状态Bug的人。
如：我所在的小组为目前测试()的任务部分，处理人为chenbf，则指派给chenbf。
3.1.5. 状态-状态
规则：选择Bug当前的状态。
“活动的”表明该Bug目前存在于系统中，并选择原因，参见3.1.8。
“解决的”表明该Bug目前已经被处理，并选择原因，参见3.1.8。
“关闭的”表明该Bug目前已经被处理并核实达到相关要求，并选择原因，参见3.1.8。
注意：状态必须与原因配合使用，在选择状态的时候，必须选择正确的原因参见3.1.8。
3.1.6. 状态-会审
规则：若Bug参与会审，负责会审的人员选择Bug的会审状态。
“调查”表明该Bug正在会审期间。
“已批准”表明该Bug的所有信息及状态已被会审正式通过。
注意：会审是对比较复杂，存在争议的Bug进行的活动，一般情况下，不做要求。
3.1.7. 状态-级别
规则：按如下规则填写Bug的重要度
0 – 表示导致系统崩溃，内存溢出，应用程序关闭等致命问题，必须处理。如：程序运行60分钟后，内存占用超过200M。
1 – 表示导致程序逻辑错误，底层错误抛出，对用户操作影响极大，验证需求错误的问题，必须处理。如：某对象没有实例化；任务开始时间必须大于任务结束时间。
2 – 表示程序界面元素显示，与正常操作习惯背离等问题，该问题不至于影响程序的正确运行，初期可选处理，发布前必须处理。如：窗口在默认大小时，label1的位置被后面的空间遮挡；按钮的颜色是黑色，文字也是黑色。
3 – 表示任何非上述问题的严重性更小的问题，该问题不至于影响程序的正确运行，可选处理。如：label1的右边缘与label2的右边缘没有对齐；某控件背景颜色偏暗。
注意：0，1级别的Bug必须处理，且在发布产品前一段时间必须保证没有该级别的Bug存在。2级别的Bug在初期可以允许，但在发布产品时必须保证没有该级别的Bug存在。3级别的Bug是潜在影响最小的严重性问题。
按上述规范区分不同级别的Bug的小技巧：
若程序崩溃或关闭等，则为0级。
若携带Bug使用程序，程序本身是错误的，则为1级。
若认为团队有时间处理的非逻辑错误Bug，则为2级。
若认为处理该Bug没必要，但严格的说确实是一个问题，则为3级。
2，3级别的Bug完全由测试人员对整个项目及团队开发的把握来定，没有客观依据。2，3级别的Bug是可以相互转化的。
3.1.8. 状态-原因
规则：按如下规则填写原因
1）状态为“活动的”
原因“新的”表明是新建的Bug。
原因“生成错误”表明应用程序生成失败。
原因“回归测试”表明在复测中再次发现该Bug。
原因“已重新激活”表明该Bug按照【重现步骤】仍然重现。
原因“错误修复”表明该修复Bug的方法是禁止的或修复了错误的地方。
原因“解决方法被拒绝”表明不允许使用这样的解决方法。
原因“未通过测试”表明修复后仍然无法通过测试。
最常用的原因为“新的”，“已重新激活”，“未通过测试”。
2）状态为“已解决”
原因“保留原样”表明指派给处理该Bug的人不认为这是个Bug，或者程序本来就是这样设计的。
原因“无法重现”表明按照【重新步骤】操作，Bug没有出现。
原因“已过时”表明该Bug的确存在，但过时了。如：原有的程序组件出现问题，被测试出Bug来，在新的版本中会整体替换该程序组件，这样的Bug就是过时的。
原因“已推迟”表明该Bug的确存在，但将被推迟处理。如：在某个迭代周期中时间来不及处理的优先级为2的Bug，被推迟。下一个迭代周期可能会被处理。
原因“已修复”表明该Bug被修复了。
原因“重复”表明该Bug和另外的Bug存在重复。
最常用的原因为“已修复”，“重复”，“无法重现”。
注意：“重复”的Bug需要在链接中给出另一个Bug。
3）状态为“已关闭”
原因“保留原样”表明指派给处理该Bug的人不认为这是个Bug，或者程序本来就是这样设计的。
原因“无法重现”表明按照【重新步骤】操作，Bug没有出现。
原因“已过时”表明该Bug的确存在，但过时了。如：原有的程序组件出现问题，被测试出Bug来，在新的版本中会整体替换该程序组件，这样的Bug就是过时的。
原因“已推迟”表明该Bug的确存在，但将被推迟处理。如：在某个迭代周期中时间来不及处理的优先级为2的Bug，被推迟。下一个迭代周期可能会被处理。
原因“已修复”表明该Bug被修复了。
原因“重复”表明该Bug和另外的Bug存在重复。
最常用的原因为“已修复”，“重复”，“无法重现”。
注意：“重复”的Bug需要在链接中给出另一个Bug。
注意：状态为“已解决”和“已关闭”的Bug可选的原因是相同的。
下图按人员角色及流程汇总了上述描述：
图2. Bug的状态转换
3.1.9. 状态-优先级别
优先级别表明要处理的Bug的紧急程度。
规则：按如下规则填写优先级别：
优先级1：直接影响软件正常运行的任何问题以及当前测试阶段规定的测试范围内的所有核心问题。
优先级2：不直接影响软件正常运行的问题且该问题的重要度为2或3且该问题是当前测试阶段中发现的问题。
优先级3：不直接影响软件正常运行的问题且该问题的重要度为2或3。
如：在第一次迭代中，逻辑问题的优先级是很高的，是1，而界面问题的优先级比较低是2或3；而在第三次迭代中，测试的范围包括对UI的测试，则虽然某个界面问题的重要度是2，由于属于当前的测试范围其优先级是2；对于其他不需要紧急处理的问题，优先级都为3。
注意，对优先级的填写，测试人员主观因素比较大，请仔细考虑优先级与重要度的区别。
3.2. 说明
规则：Bug的说明是对Bug的具体描述，具有一定的效力，编写时需要额外注意，一旦编写完成将作为Bug最原始的材料保存；除非有合理原因，当Bug的说明编写完成时，不得做任何修改。
其编写格式如下：
图3. Bug说明的编写格式
格式详细说明如下：
图4. Bug说明的编写格式规范
请严格按照上述格式填写Bug的说明。
“重现步骤”应该可以指导开发人员或其他测试人员再次重现Bug。
对“实际”和“期望”的描写应该具有对比性。
与该Bug重现有关的信息用其他来注明。
注意：对Bug的详细讨论禁止写在此处，统一写在历史记录中，如下所述。
3.3. 历史记录
规则：对Bug的所有批注或与相关人员的讨论在此处填写。
此历史记录是有关 Bug 报告的连续讨论，其中积累了随着所做的更改而额外写入的项每当对 Bug 进行更改时，“历史记录”字段中写入一项，描述所进行的更改和更改的原因，以及关于此次更改的任何额外相关信息。
图5. Bug历史记录
在历史记录中可以自由书写任何评论。
3.4. 链接
规则：目前只考虑Bug与Bug的链接，即链接相关联的Bug。
如：重复的Bug。
图6. 链接Bug
注释注明链接的原因为：“重复”或“参考”。
注意：目前()团队只需使用链接Bug，注释仅限为“重复”或“参考”。
3.5. 附件
规则：上传与该Bug有关的文件，目前仅限于截图，视频或普通文件，用来进一步说明Bug的重新过程。
对附件的起名没有限制。
注意：注释限于“截图”，“视频”，“文本”。
3.6. 详细信息
规则：目前()团队不适用该条目。
4. 团队成员的基本分工
开发人员和测试人员都可以新建Bug；
开发人员修复Bug；
项目经理会审不确定的Bug；
测试人员验证修复并关闭Bug。
5. 可参考的模板
请参见Bug（ID：1405）。
注意：该Bug仅是格式上的示例，内容没有实际意义。
6. 参考资料
Microsoft MSF for Agile Software Development, http://www.microsoft.com/downloads/details.aspx?FamilyId=9F3EA426-C2B2-4264-BA0F-35A021D85234&displaylang=en, 2009.01.07
[ 本帖最后由 chenjinxia 于 2010-1-11 19:08 编辑 ] 分享才是王道……谢谢啦 好全面呀！ 学习ing…… :handshake 那个bug状态转换图不够清晰明了，其他都还不错。
还有这个是不是应该发到“软件缺陷管理区”啊，这个不算用例吧，又不是测TFS 介绍很详细 顶一下 :handshake 谢谢分享 谢谢分享 O(∩_∩)O谢谢分享 很好 谢谢分享 very good :) 学习学习啊 LZ辛苦，顶下一楼 分享、学习呀。。 认真学习下。
页:
[1]
2
