摘要：什么出错了网站。出错了这样一句模糊的报告简直可以是任何情况网站可能宕机，注册页面可能出错了，某个应用可能在你不知不觉时把用户的裸体拍下来并用电子邮件发给他们的朋友们就是没有办法搞清楚是何种情况。
“出错了。”
没有那句话能像“出错了”一样让程序员/开发者如此沮丧，心里翻江倒海，怒火一点即燃，还要死掉一大片脑细胞。
这句生硬的开场白通常标志着让开发者恐惧的长时间排错工作要开始了。
在我的职业生涯中，我就进行过好几次这样的对话：
“出错了。”
“什么出错了？”
“网站。”
“网站什么地方出错了?”
“我不确定。你把它弄好就是了。“
对于很多的非技术人员来说，这句话在逻辑推理方面简直滴水不漏。毕竟，他的工作不是测试网站，所以指出哪里出错也不是他的职责。
但是，他发出了一个非常模糊的错误报告，意味着他决定承担起责任，报告一个需要修复的错误，同时，他也让修复过程变得耗时而混乱。
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报告者总是觉得任何事都是最最重要。但是为了公平，先深呼吸一下，再考虑问题究竟有多重要。下列条目对你有所帮助。
极度重要：“停下其他事，马上修复此问题！！！！”
重要：“需要尽快解决。”
一般：“快点修复，但如果不能马上解决也可以。”
不重要：“如果有必要，这个问题可以推后处理。”
极不重要：“这个想法或建议应该暂缓执行，以后再说。”
让工程师们爱上你如果你发现了错误——不管它看起来多么吓人，停下你手里的事，后退一步，写一份合适的bug报告吧。
如果你的开发者建有问题追踪系统，你应该登录上去，但如果你没有登上去（或是找不到），你可以发出电邮或是开始写一个文档。如果你经历了很多的bug，尝试着建立一个电子表格将它们全部列出来并分发出去。不要只是给工程师们打电话或是发给他们一行字的短信。对你发现的bug建档之后再发出警报，工程师们会利用你的报告来确定问题的优先级，并在修复过程中将其作为参考。
所以，现在你在检查开发者推出的全新软件或是让你气都喘不上来的东西时，你知道怎样可以修复得更快、更高效，还不会打击到你的工程师们。你成为了团队里有用的一份子，而不是半点线索都不能提供的局外人，而且也许在这一过程中你学到的东西可以让你成为一位软件内行呢。
PS：这个早读君可以分享下平时在项目中所看到的现象：
A：QA或编辑、运营直接贴两张图，让开发人员自己去发现臭虫，有点bug“找茬”。
B：前端的bug涉及到的浏览器版本，电脑类型等这些宿主因素，如果没说描述清楚的，修复bug的人还要二次去跟踪确认。
所以能否清楚、正确描述bug也是一门学问。
转自 toolate
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/8696.html
摘要：阅读本文约分钟序章月至月中旬一直在忙公司新项目，这也是我第一次做技术领队的项目，从面试开始就一直在阅读有关技术团队管理有关的书籍，本文将简述此项目的总结，从设计到编码实现到上线测试用户反馈等方面，篇幅略长，建议收藏。 阅读本文约5.8分钟 序章 7月至8月中旬一直在忙公司新项目，这也是我第一次做技术领队的项目，从面试开始就一直在阅读有关技术团队管理有关的书籍，本文将简述此项目的总结，...
摘要：现状分析之前，墨白身边一位测试老人提了一个打印文字溢出的缺陷，但该缺陷的负责人，一个年轻的程序员以项目临近上线没时间修改，且该缺陷影响很小而驳回，态度强硬强硬的诉苦，那位测试专家从开始的坚持到最后无奈妥协，让墨白感触良多。 前言 今天的话题，是所有测试员都会经历的，也多为此苦恼过。墨白借此谈...
摘要：一为什么需要一个测试脚本昨天讲解了命令的使用方式，今天趁着还热乎就手把手用写一个压力测试的脚本。对一些在测试情况下，各项状态的监控并不好。一个简单的测试脚本，包括这些基本上就足够了。六多说两句其实这个的压力测试脚本，已经满足测试的基本要求。 版权声明： 本账号发布文章均来自公众号，承香墨影（cxmyDev），版权归承香墨影所有。 允许有条件转载，转载请附带底部二维码。 一、为什么需...
目录 一、禅道 一、测试工具背景 二、测试管理工具 三、测试工具介绍 四、禅道介绍 五、禅道操作 7. 创建发布 8. 测试团队 二、缺陷报告 三、测试报告 一、概要 二、测试过程 三、缺陷分析 四、测试总结 四、接口测试以及用例编写 五、Fiddler 好文推荐 一、禅道 一、测试工具背景 当测试环境搭建完成后，测试人员将在自己搭建的环境上执行测试用例，开展测试工作。测试人员在执行测试用例的过...
阅读 2795·2023-04-26 02:23
阅读 1469·2021-11-11 16:55
阅读 3097·2021-10-19 11:47
阅读 3225·2021-09-22 15:15
阅读 1920·2019-08-30 15:55
阅读 982·2019-08-29 15:43
阅读 1238·2019-08-29 13:16
阅读 2084·2019-08-29 12:38
