BUG流程分析

　关于BUG流程相信大家都已经很熟悉了，并且用起来也得心应手，在此不再赘述。以下对BUG有一些小小的建议，主要针对我们日常工作中没有注意到的地方说的，建议虽小，但要重视噢。

　　对于研发经理：

　　当一个BUG被你审核通过，在派给开发人员时，你应该将BUG的状态改为“打开”。

　　审核BUG时你有最高权限，可以审核BUG的所有信息是否正确，所以最好重新审核一下我们提交的BUG严重程度，你有权修改哦。还有类型也可以修改的。

　　对于软件工程师：

　　请开发人员修正后，注明修改后达到的功能效果以及可能影响到哪些其他的功能模块，还有拒绝或延期的理由。同时最好写上解决的方式或非正常解决问题的原因，对于我们来说这些积累是一笔很大的财富。

　　如果你正陷入让测试人员使用bug管理库的苦恼中，你只要不用其他方法接受bug报告。如果你的测试人员习惯将bug报告用邮件的形式发给你，你只需用一个简短的消息回复他们：“请将它们输入到bug库中，因为我无法追踪邮件。”

　　对于测试人员：

　　请测试人员提交新错误时，尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象、（建议），并尽量截图。

　　尽量减少重现的步骤以达到用最少的步骤来重现问题；这对编程人员来说是很有帮助发现问题根源的。

　　当你的bug报告以“not repro（不可重现）”打回给你时，先检查一个步骤是否有遗漏或清晰，再去找编程人员。编程人员通常是在无法用bug报告中的步骤重现bug时才选择这个选项。

　　不要使用完全的大写形式，那样会让人感觉象控诉。不要使用感叹号或其他表现个人感情色彩的词语或符号。

　　不要使用含糊的词语（例如，好像，似乎）来描述发现的现象。

　　在提交BUG的标题第一行写上错误的总结是非常关键的。这要求测试人员编写的报告要能够吸引读者，引起他们的注意，并使和管理层的沟通清晰。

　　再次强调，在bug report的初稿完成后，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是bug report的目标。

　　测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。

　　大家都要注意的地方：

　　当你发现一个BUG，或者正在修改BUG时，请考虑如下问题：

　　1. 同一软件中的相似功能是否有相同的问题？

　　2. 其他的浏览器是否有相同的问题？

　　3. 其他的软硬件配置是否有相同的问题？

　　4. 其他的区域（locales）是否有相同的问题？

　　5. 不同的安排设置是否有相同的问题？

　　6. 以前的版本否有相同的问题？