首先声明，bug的测试规范应该在公司的正式文档建立。
本建议非正式文档，有些内容可能不正确，有些内容可能需要继续商榷，甚至有些内容同公司规范有冲突。如果发现问题，直接忽略本文相应内容。
本帖本意仅就工作中的一些现象记录，可以通过简单规范让大家工作轻松，高效。
后续继续补充修改，也请大家补充修改。

其次，本帖也仅就填写bug报告的行为进行了一些梳理和建议，不能取代正式的bug测试流程或质量管理过程。

内容：

填写bug报告，可能是专门的测试人员或者开发人员，甚至其他临时帮忙或者最终用户。
发现bug和解决bug是一件非常重要的工作。大家的目的都是为了软件能够安全、稳定运行起来，提交bug的人同解决bug的人目标是一致的，而不是对立的，不是找麻烦。

测试工作其实非常复杂和繁重，发现问题仅仅是第一步，更重要的是确定是bug，是不是可以重现，跟正确结果的差别在哪里。
最终提交的bug不要让修复者重复太多工作才能重现，也不要让修复者猜测或者试验力。最快让修复者找到问题是关键。
如果修复者花费太长时间琢磨一个bug报告的重现，最好还是直接演示给他看，这是最有效的方式。

基于这些共识，我们希望达成一致的规范。

提交者规范建议：

1.
提交bug是针对真实存在的缺陷。那些偶尔出现的bug，提交者尽量找到重现的真正原因。如果可能，尽量在2个不同终端上可以确定重现。如果没有2台终端，至少用2种浏览器或者2个虚拟机等方式模拟重现出来。
2.
如果是浏览器兼容问题，确定重现步骤后，bug报告中尽量写清哪个类型浏览器，版本号，语言，以及设置方式。
3.
描述清楚。有些bug是需求没有满足，但是没有其他崩溃结果哦出现，尽量将“期待”的内容和“实际”的情形区别开，
如，一个bug，一个按钮点击后的“需求”是打开窗口，实际运行结果是转到另外一个地址。转移地址是错误的，就要告诉修复者。
而不是报告：这个点击按钮后转到了一个新地址。
修复者有时理解成需求是要转移到一个新地址，结果他看到的就是这个结果。修复这可能要仔细对照需求说明书，才能知道这是一个错误。他记忆中的需求可能就是转移到一个新地址。
建议写成：“需求”是打开窗口，“当前”的bug是转到另外一个地址。

4.
缩小范围。如果能将bug出现定位在一个确定的范围，则减少了重现和定位的重复工作，也更加清晰bug的关键内容。
如，bug报告中如果是这样一条报告，修复者会是一脑门子汗。
论坛网站上不去！
这个bug的范围太广泛。有如下几种具体bug都可以说成是网站上不去。


内网能上，外网不能上。
用IE浏览器可以上，用chrome不能上
网站的页面打不开，一直等待
网站的页面打开了报错，全部英文，不能显示有用文字。
网站的网页可以打开，但是没有登录的部分。
网站登录框正确填写用户名口令后，还是提示“用户名密码不能验证通过”
网站登录框正确填写用户名口令后，无反应。
网站登录框正确填写用户名口令后，页面变成错误信息。


所以，bug报告也是有质量的，要有质，而不是量。这也正式测试人员不能以bug数量计算工作量的原因。

5.
如果界面的一些细小问题，请将你发现的问题截图。截图后，一定要用明显标记的方式，指出错误所在。
如果有可能，将正确的截图也提供出来，而且也明显标记出对应的位置。

6.
多个关联的bug，尽量将每一个bug单独提交，并且通过bugfree进行明确的关联。缺陷的分解也体现测试者的工作到位。

修复者规范建议：
1.
尊重bug提交者的劳动，认真对待每一个bug。
2. 如果有不清楚的bug报告，尽快联系提交者，以便重现bug，意见达成一致。
3.
如果属于其他人的问题，尽快转发。
4.
多练“找不同”、“找茬儿”、“连连看”之类的游戏，提高眼力。尤其是几面中一个像素或者1px线的瑕疵。
建议人力资源部在入职考试中加入连连看测试和成绩入档案。

Bug报告提交规范