下班前提了5个bug，程序猿说要打我？

作为测试鹅，你是否有过以下日常：

正准备下班的时候又又又发现了5个bug，兴冲冲地告诉开发，你猜他们会怎么样？

开发A：你刚刚说什么？我没听清！（不听不听，王八念经~）
开发B：你提任你提，修改不着急。
开发C：你礼貌吗？

提的时间很尴尬也没办法，但再试想下，临下班给开发提了N个bug，但bug提交不规范，bug说明要啥没啥。

例如↓↓↓

那开发是不是会很无语？会不会质疑你的能力？

开发跟你复沟通确认后定位到了问题，埋头继续修改，改好回归测试无误后，再完成了版本的发布，加班到很晚，那开发是不是很崩溃？会不会想和你干架？再进一步，如果因此项目发版不得不延迟，Boss会不会想杀“鹅”祭天？要是真到了这一步，请答应我，提前想好你的墓志铭。所以说，一个合格的测试鹅，一个想升职加薪的测试鹅，一个不想被开发、产品、Boss混合双打、拔毛下锅fire的测试鹅真的有必要练好基本功，学会提交BUG的正确姿势！这不，小檬给你总结了几点：

01

bug标题

bug标题要简明扼要，直接命中问题本身，让解决者一眼就能看到问题影响的范围、可能出现的问题的原因，不要泛泛而谈。

例如：

反例

打开官网页面报错

正例

首次以游客身份浏览官网首页，页面console报错提示"undefined"

点
评

正例指出了出现问题的用户角色、问题发生的位置、操作方式和简要的错误信息

反例

打开聊天窗口App Crash了

正例

[安卓必现] 打开我的"页面查看消息，App Crash

点
评

正例指出了问题出现的端，问题出现的频率、路径，而反例则很模糊

02

bug描述信息

bug描述信息要条理清晰，步骤具体，信息完备。

理想的情况下，bug的解决者也就是开发要能通过描述能快速定位到出错的代码、配置、数据等，减少反复确认和沟通的时间，提高bug的处理效率。

因此，一般来说，bug的描述应该包含以下几个部分：

☆缺陷描述：描述Bug造成的影响和频率，和标题内容呼应可相同

☆前置条件：Bug产生的前置条件，如账号、环境、数据要求等

☆复现步骤：细粒度且可操作的步骤说明，最好配上视频和截图则

☆期望结果：预期得到的结果，与用例TC上的需描述-致，最好附上用例链接、需求/设计稿链接

☆实际结果：本次操作实际不符合预期的结果，最后配上图文说明

☆附件：Bug场景的视频、截图、异常数据集、异常配置等

☆原因定位：尝试定位后，得出Bug可能产 生的原因

☆修复建议：根据定位的原因，得出可能修复方式

建议各位测试鹅最好是要填写完标☆的项目！

如果大家对代码和系统运用原理有一定的了解的话，“原因定位”和“修复建议”的准确填写会让开发对我们测试鹅刮目相看！

这里举一个比较清晰的bug描述例子：

缺陷描述：10KB以内图片，头像上传失败

重现步骤

[步骤]1.登录网站，点击我的账户，点击头像2.选择图片3.点击确定

[结果]上传目录根本不存在，请尝试手动创建

[期望]1.显示默认头像，正常弹出更换头像界面2.选择成功，支持预览3.提示上传成功，头像显示更新

相关责任人2021-7-24 10:33:07, 由 速成班**期*** 创建。

03

bug概要信息

bug概要信息一般要标明等级并指定相关责任人。

具体来说，要写的包括bug修复者、bug类型（功能、性能、稳定性、兼容性等）、bug的优先级（紧急、高、中、低）、bug关注者（前后端对应的开发同学、知会相关的业务或产品同学）、bug严重程度（阻塞、主要、普通）、bug标签、bug项目、bug模块等等。

而这三招总结成一份具有普适性的缺陷管理工具BUG字段大全就是：

根据缺陷已知的[ 现象+信息+风险+备注 ]>>>[ 为什么出现+谁引起的 ]>>>[ 如何去解决+什么时间点去解决 ] 。

按这个字段逻辑填写数据，测试鹅可以很方便地提出bug，并按照不同的维度产出不同的质量数据。

PS：多花几分钟去提出bug单子，不仅能让自己和开发进行有质量的沟通，对研发效率的提升的贡献也是显而易见的！

戒骄戒躁，按部就班地在缺陷面板去一项一项录入，尽量避免出现BUG信息不全的问题！

每一个BUG都是我们测试鹅测试水平的象征!做“靠谱”的测试，提专业的bug，迈出每一个测试鹅快乐工作的第一步！