EEPW论坛

(一) BUG录入：每天下班前录入当天系统的遗留BUG，格式按照现有格式。 (二) BUG的处理和关闭 程序员每天花一定时间进行BUG的修改，修改后标记为“已解决”“已修复”；测试员再次测试“已解决”“已修复”的BUG，根据情况标记为“已关闭”或“活动的”。 (三) BUG处理方法：三方会审 A. 三方会审结果确定原则：少数服从多数。 B. 每天上午上班时或上一天测试人员写入BUG后设计/开发者查看“未批准（未经会审）”的BUG，测试人员查看“已解决”的BUG，如果有问题则标记为“问题”并发起项目管理&设计/开发/测试三方一起会审BUG。 C. 如果中午之前没有开会则表示所有人认可昨天新填BUG的正确性和优先级，以及昨天BUG解决的正确性。由项目管理人员将“未批准”的BUG状态修改为“已批准”，测试人员将“已解决”的BUG状态改为“已关闭”。 D. 如果任何人对BUG的处理结果不同意（比如测试人员认为没有修复而程序员认为已经修复），可以随时发起三方会审。结果以三方会审结果为准，所有人必须遵守。 E. 每次迭代结束清理BUG时，不能遗留优先级为1，2的BUG。 (四) BUG的优先级设定原则如下： 1. 优先级为1的（必须马上修改的）： A. 逻辑（包括业务逻辑）出现错误 B. 系统崩溃、死机、无法运行、无法部署、影响其它用户使用的错误页面 C. 数据损失、败坏或遗失，破坏文档 D. 主要功能无法正常使用、主要功能与设计不符 E. 阻碍测试工作的继续进行 F. 严重安全问题 2. 优先级为2的（应该一周内修改的）： A. 绝大多数的辅助功能问题（包括无法使用和与设计不符等） B. 会给用户造成迷惑的非功能性问题,如提示与事实不符。 C. 绝大多数的非控制的页面，如只影响本机使用的错误页面。 3. 优先级为3的（有时间就修改的）： A. 偶尔出现的、无法重现的功能性问题 B. 这阶段不用修改或没有也可以发行的功能性问题 C. 不会给用户造成困惑的界面小问题：错字、错误图标、字体大小、没有对齐、颜色等。 (五) 标记为“问题”的BUG来源： A. 测试人员填写时自己把有问题的（不能确定的）做标记。 B. 测试人员有空时相互检查不属于自己填写的BUG，认为有问题（写得不清楚、错误的BUG等）的做标记。 C. 程序员和其它开发相关者认为有问题的做标记