“出错了。”
没有那句话能像“出错了”一样让程序员/开发者如此沮丧，心里翻江倒海，怒火一点即燃，还要死掉一大片脑细胞。
这句生硬的开场白通常标志着让开发者恐惧的长时间排错工作要开始了。
在我的职业生涯中，我就进行过好几次这样的对话：
- “出错了。”
- “什么出错了？”
- “网站。”
- “网站什么地方出错了?”
- “我不确定。你把它弄好就是了。“
对于很多的非技术人员来说，这句话在逻辑推理方面简直滴水不漏。毕竟，他的工作不是测试网站，所以指出哪里出错也不是他的职责。
但是，他发出了一个非常模糊的错误报告，意味着他决定承担起责任，报告一个需要修复的错误，同时，他也让修复过程变得耗时而混乱。
Bug：程序员的肉中刺
爱也好，恨也罢，bug是所有软件中不可避免的一部分。很多bug可以在程序员好几小时的试错中找到并修复。对于一名工程师，如果没有花大量时间去和问题提交者交谈，进行枯燥乏味的反复尝试以复现问题，他就不可能推断出问题到底是什么。修复bug的工作量很大。
“出错了”这样一句模糊的报告简直可以是任何情况——网站可能宕机，注册页面可能出错了，某个应用可能在你不知不觉时把用户的裸体拍下来并用电子邮件发给他们的朋友们——就是没有办法搞清楚是何种情况。
惊喜！你是质量管理员
即使进行了最严格的质量保证（QA）测试，还是会不时有漏网的bug。对于小型团队以及个人开发者，通常根本没有任何正规的质量保证测试——这使得客户、经理或是员工都要承担一部分质量保证工作职责。
作为一名和软件开发者一起工作的非技术人员，你总要在一定程度上扮演质量保证测试员的角色——无论这是否包括在你的岗位描述中。接受你的新职责对你有百利而无一害。当严重的bug影响了工作，让整个团队面色凝重，你若能帮助寻找bug，会让bug更快地得到解决。
报告Bug的正确方式
现在说说如何撰写一份bug报告，它可以帮助缩小问题的范围，可以让你的开发者高兴，还可以让你的软件尽快正常运行。
一份优秀的bug报告应该包括以下部分：
1）概述
出了什么问题？总结一下，不超过10个字。
2）定位
哪里出了问题？如果是一个网站，把网址复制粘贴下来。如果不是，给出发生问题的窗口名称。
3）软件的运行环境是什么？
你是用的PC还是MAC？Firefox还是Chrome？iPad还是iPhone？iOS还是安卓？软件的版本是什么？你安装了什么浏览器插件？后台有哪些奇怪的软件在运行？
4）描述问题。
详细描述发生的问题。
5）列出问题复现的步骤。
描述问题发生前你做的每一个步骤。例如：“1）打开浏览器；2）访问www.mysite.com；3）点击“登录”按钮”
6）期待情况以及实际情况
要写出当你执行了上述步骤后你期待发生什么，以及实际发生了什么。例如：“期待情况：显示登录表单。实际情况：一幅图片显示出来，上面有一只泰迪熊和一句话『网站故障，请耐心等待。』”
7）提出修复建议
你认为你知道如何搞定这个问题？太好了！为工程师节省点时间，让他们少些困扰，把你关于应该如何解决问题的想法写下来吧。
8）截屏！
如果你能看见问题的场景，将它截屏并附在报告中。有时，这是你在bug报告中提交的最重要的一件事。如果你能在截图上标示以指明问题，那就更好了。截屏取决于你使用的何种电脑或设备。如果无法截屏，用你的手机对屏幕拍照并发送出去。
9）优先级
优先级具有主观性，对于bug报告者总是觉得任何事都是最最重要。但是为了公平，先深呼吸一下，再考虑问题究竟有多重要。下列条目对你有所帮助。
1.极度重要：“停下其他事，马上修复此问题！！！！”
2.重要：“需要尽快解决。”
3.一般：“快点修复，但如果不能马上解决也可以。”
4.不重要：“如果有必要，这个问题可以推后处理。”
5.极不重要：“这个想法或建议应该暂缓执行，以后再说。”
让工程师们爱上你
如果你发现了错误——不管它看起来多么吓人，停下你手里的事，后退一步，写一份合适的bug报告吧。
如果你的开发者建有问题追踪系统，你应该登录上去，但如果你没有登上去（或是找不到），你可以发出电邮或是开始写一个文档。如果你经历了很多的bug，尝试着建立一个电子表格将它们全部列出来并分发出去。不要只是给工程师们打电话或是发给他们一行字的短信。对你发现的bug建档之后再发出警报，工程师们会利用你的报告来确定问题的优先级，并在修复过程中将其作为参考。
所以，现在你在检查开发者推出的全新软件或是让你气都喘不上来的东西时，你知道怎样可以修复得更快、更高效，还不会打击到你的工程师们。你成为了团队里有用的一份子，而不是半点线索都不能提供的局外人，而且也许在这一过程中你学到的东西可以让你成为一位软件内行呢。
原文链接： Ron Whitman 翻译： 伯乐在线 - toolate
