Bug报告提交规范

首先声明，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线的瑕疵。
建议人力资源部在入职考试中加入连连看测试和成绩入档案。