做软件测试这一行，找bug是基本功，但真正决定你专业度的，是怎么把bug提好。很多测试新人经常遇到这种情况：辛辛苦苦测出来一个问题，提交上去，开发回一句“无法复现”就给关了，气得不行。其实大多数时候，问题不出在bug本身，而是bug单写得不够清楚。今天就来聊聊，怎么提一个让人挑不出毛病的bug。
一个合格的bug单必须包含哪些内容
先把最核心的东西列出来，一个能落地的bug单，下面这几项缺一不可。
第一是标题。标题要一眼能看出问题在哪，别写“功能有问题”“页面不对”这种废话。正确写法应该是“模块名加现象”，比如“订单管理页面，点击提交按钮后订单状态未更新”。这样开发扫一眼就知道去哪儿看。
第二是环境信息。包括测试环境、浏览器版本、操作系统、前后端版本号、测试账号等。同一个bug，在Chrome上是好的，在IE上就崩，不写环境，开发怎么查？很多“无法复现”的扯皮，就是环境信息没写全导致的。
第三是复现步骤。这是bug单的灵魂。步骤要按顺序一条一条列出来，精确到每一次点击。比如：1.用测试账号登录；2.进入商品列表页；3.搜索关键词“手机”；4.点击第二个商品的详情按钮。步骤越细，开发复现得越快，你被退回的概率就越低。
第四是预期结果和实际结果。预期结果写“按照需求文档，点击提交后订单状态应变为已支付”，实际结果写“状态仍显示待支付”。有对比才有伤害，开发一看就明白问题出在哪。
第五是证据。截图、录屏、日志、请求报文，能附的都附上。界面问题用截图，偶尔出现的闪退用录屏，后端报错直接贴日志和接口返回。证据在手，谁也没法说这是你操作不当。
提bug常见的几个坑
第一个坑是一单提多个问题。有人喜欢在一条bug里写“这个页面按钮不对、文字也错了、颜色还不对”，开发改起来容易漏，测试回归也容易漏。正确的做法是一个问题提一条，分开管理。
第二个坑是描述带情绪。“这代码写得什么玩意”“这么明显的bug都测不出来”，这种话千万别写。bug单是工作沟通工具，不是吵架的地方。事实讲清楚就够了，脾气留在心里。
第三个坑是定级随便拍脑袋。致命级别的bug写成一一般，或者把一个文案错别字标成严重级别，都会影响开发排期，也会让你的bug单信誉度下降。一般来说，导致系统崩溃、数据丢失、资金损失的算致命；核心流程走不通算严重；非核心功能异常算一般；界面错位、文案问题算轻微。
bug被开发拒绝复现怎么办
这是测试绕不开的问题。遇到“无法复现”的回复，先别急，按这个顺序处理：检查自己的复现步骤是不是漏了前提条件；确认环境版本是否一致，有些bug只在特定版本出现；看看是不是有缓存、并发、数据量的影响。如果这些都确认了开发还是复现不了，可以约个时间当面或远程一起操作一遍，很多时候当面走一遍流程问题就清楚了。
另外，对于偶现问题，要养成记录的习惯。出现时间、操作记录、当时的日志都留好，出现两三次以后规律就出来了，开发想不认都不行。
好的bug单是测试人员的名片
说白了，提bug这件事，考验的不是你找问题的能力，而是你沟通和表达的能力。一份描述清晰、证据充分、定级合理的bug单，能让开发少走弯路，让问题更快解决，整个团队的效率都会提升。时间长了，开发也会更信任你提的问题，配合度自然就高了。
所以下次提bug之前，花一分钟检查一下：标题清楚吗？环境写了吗？步骤完整吗？预期和实际对比了吗？证据附了吗？这五点都做到了，你就是一个靠谱的测试工程师。