TDBug管理规范V2.0.docVIP

此文档阐述了关于bug的提交，验证，修改等规范，供测试人员和开发人员使用。 Bug管理工具为TestDirector8.0（简称TD），TD中bug的来源为：测试人员，论坛帖子，客服反馈，公司内部 TD的使用人员为：开发人员，测试人员，项目经理和player账号。 Bug管理的一般流程 测试人员提交新的Bug入库，问题状态为New。 高级测试人员验证问题，如果确认是问题，分配给相应的开发人员，设置状态为Open。开发人员查询状态为Open的Bug，如果不是问题，则置状态为；如果是Bug则修复并置状态为Fixed不能解决的Bug，要留下文字说明及Bug为状态。测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，Bug的状态为置状态为Reopen。Bug状态： 新问题(New)：打开 (Open)： Fixed Verified 经测试验证后，确认被修改好了的bug Reopen?? 经测试验证后，发现依旧存在的bug。 Could Not Reproduce? 无法重现的bug Pending 由于时间问题将来在做处理的bug 开发人员须知： 定期查看TD（根据部门主管工作安排），优先级为5和4的bug回复日期不得超过２个工作日，优先级为3的bug的回复日期不得超过３个工作日。优先级低的（2，1）回复日期不得超过5个工作日。备注：回复并不一定是fixed，可以注明即将修改的版本号，但保持bug是Ｏpen或者Pending的状态。 对于测试人员提出的bug进行重新并修正。 不做修改的bug，请不要fixed，而要rejected，并注明不做修改及原因。 对于比较难以修改的或者需要一定时间修改的bug，请Pending，并注明原因。 加强沟通，不清楚或者不能重现的问题，可请测试人员给予充足的测试信息及操作步骤。 部门主管或通过某种会议研发人员解决BUG写的注释一定要有以下几点：说清楚BUG产生的原因写出BUG产生的文件修改后该文件的版本号注释上只写“已解决”为了保证问题的正确性，需要有丰富测试经验的测试人员验证发现的问题是否是真正的问题，书写的测试步骤是否准确，可以重复。。问题修复后必须由报告问题的测试人员验证后，确认已经修复，才能问题加强与程序员的交流，对于某些不能重复的问题，测试人员补充详细的测试步骤和方法，以及必要的测试用例。BUG提交规范： 创建的问题的时候，“概要”--用简单明了的语句说明白你这个BUG，就相当与BUG的中心语句然后选择你提交的BUG所以那个模块,并选择提交问题时版本上传截图或附件，可以进行简单明了的说明BUG存在，也可做为BUG证据最重要的在填写描述: 最好是把BUG产生的步骤一步一步写清楚，可以用以下方法写（如果一句话就可以说明的BUG，就不必要分步骤了）。。。。。。。。。写清楚，然后写出测试出的结果和你期望的结果，如：??? 测试结果：。。。。。期望结果：。。。。。BUG验证/关闭当BUG由pen变为Fed，回归测试后该问题被解决，则你就该BUG，并在注释中填写如下信息：验证通过：是验证日期：。。。验证版本：。。。如果回归测试验证不通过，则Reopen该BUG，并在注释中填写如下信息：? 验证通过：验证日期：。。。验证版本：。。。bug提交问题: 解决方案： 客服人员先确认问题存在，然后把问题描述清楚，提交TD。 TD中使用player账号，TD中bug的状态为New。 测试人员对player的问题给予内部重现后，状态改为Open。 开发人员可以查看到Open的问题。 关于玩家意见和反馈都可以提交，可以一个问题，记录多条几个玩家反映的问题或意见。 关于严重性与优先级知识： Severity（严重性）与Priority（优先级）之间的 一般来说，严重性高的bug修改的优先级也会高。但不是所有情况都如此： 例如：一个严重的Bug可能是那种对1%的用户来说也是不太会发生的使崩溃的bug那它的优先级优先级要低。 (Priority) 是从项目管理和时间管理的观点来厘定高低。 严重性 (Severity) 是从游戏质量管理的观点来思考的。 处理问题的严重性，以质量作为出发点，应针对所产生的问题是否会对产品造成严重的缺憾来决定等级的；其决定权，通常掌握在 QA 人员手中。 处理问题的优先级，以整体项目的进度、质量、市场，以及需求所造成的影响作为出发点，决定应对的措施；其决定权，可以由QA leader确定，最终决定权通常掌握在项目经理手中。 缺陷严重级别(Severity)定义:最高级--导致崩溃预期的功能没有得到实现,测试工作无法继续进行等紧急---事件非常重要,并且需要马上给予关注.高级---事件是重要的,并且应该在紧急的事件处理之后尽快得到解决.中级---事件是重要的,但是