测试基础 测试 BUG 究竟要怎么提？
在测试行业也已经干了七八年了，直到上一份工作中，让我在测试工作中产生困惑的事竟然是 bug 不知道咋提了，之前 bug 标题一直是这样写的：什么端什么模块在什么情况下出现了什么样的问题（详情会提供账号、截图等），但是这样提的 bug 被领导说了好几次让我改，她说 bug 标题应该写成预期要什么结果；有一次我想跟她掰扯，直接被怼了 “别跟我说这些，赶紧改”，当然后面的结果肯定是我离职了
，期间也质疑了自己写的是不是有问题，但是开发能看明白就行吧，我也翻看了大家的提的 bug，都差不多啊，有时候我怀疑这领导故意针对我，所以离职了以后感觉很放松，哈哈，现在特意来请教下各位同行大佬，提 bug 这个简单又不简单的事，大家是怎么提的。
添加购物车不成功
删除商品不成功
职场上都是对人不对事的（如果有人说不是，不要相信这种场面话）
建议社区的朋友们都要看看这部电影，我经常会拿出来警惕下
里面的飞全到死都不知道自己错在那里
感觉就是被针对了
标题写出现啥问题，或者期望结果 都可以吧，在详情里面写清楚 前置条件，操作步骤，实际结果，期望结果就好了
典型被针对了
什么端什么模块在什么情况下出现了什么样的问题 - 这个是实际结果，一般简单的我就直接是用前面这部分了，稍微复杂的就要加上预期结果。这个是因为有些开发对需求不是百分百熟悉，如果团队内部的人都很熟悉需求，不加也可以吧
我都是标题写现象，详情写步骤和预期，有的时候连步骤都没有直接贴个图
做测试 7 年了，前 6 年 bug 标题一直都是写的预期结果，今年开始写成了 什么端什么模块在什么情况下出现了什么样的问题。
这个变化主要在于对用例标题的思考，认为标题就是应该告诉开发人员出现了什么问题。然后 bug 详情里面，再说复现步骤、预期结果，以及其他 bug 附件证明。 这种 Bug 标题与详情的搭配表述，能够完整的说清楚是什么问题。
有时候 bug 光靠一个标题是无法描述完整的，全部塞进去，又要说出现了什么事情，又要说预期结果，整得又臭又长，有些不合理。
但单独针对这件事情来说，其实是一件小事情，主要是根据团队得习惯来针对性调整，无可厚非，大家都能看懂就行。所以还是觉得你被针对了。
无需在意，被针对而已
那标题不能超过 25 个字要保证开发能通过标题看懂什么问题，BUG 详情：前置条件、操作步骤、实际结果、预期结果必填，后端问题必须附接口请求、响应信息和日志文件，前端问题必须附 url 和截图这种怎么说
我最近也遇到了，bug 被打回两次，说是不清楚，增加沟通成本，我发到测试群，其他小伙伴都说没问题
zgxlz
回复
主要是研发能看明白就行 合作久了大家自然知道啥意思 研发都没说看不明白 我 bug 没提一分钟呢 领导就跳出来指指点点了 那几天真是干的烦躁
这么近 那么美 周末到河北
回复
觉得有些女领导特别抠细节，以及喜欢补文档。遇到过测试阶段我们忙着测，研发阶段我们忙着补文档的团队，还要频繁给别的团队解释复盘形成文档（道歉，地位低的一批）。团队全女就你一个男的话，可能氛围会很奇怪
可能想让你写出 bug 本质吧，更深入层面，不过也得看具体是什么问题
有过类似经历，5 个正式岗测试，就我一个男的，不过还有几个外包测试是男的，但是我这个唯一男正式测试也疯狂坐牢，活最多，岗位级别最低
本来测试都是归开发（项目经理）管的，但是另一个女测试找项目经理强行把我要过去，帮她干活，还天天被恶心，真是无语
这么近 那么美 周末到河北
回复
既然你离职了，那当她的话是放屁就好了，不用在意什么，她在享受管理的感觉，在你啵嘴之后，她不爽找茬而已。事实上这种旁枝末节的东西，你怎么写都可以挑刺，或许就是想把你恶心走，然后让她的姐妹入职而已，不要老是用技术思维去看问题
指给后端我有时候也是不写步骤，但是我要贴上接口、入参、日志；但是指给前端要写步骤；标题是直接写结果
你直接把你提的和同组别人提的拿出来比较 如果没有本质上的区别就说明是故意为难你
没有能力的领导才会天天纠结这些规范格式的东西
之前单位用 vs 提 bug，本身就巨难用，那个领导还个各种扣 bug 描述和模块之类的细节，然后有一次我不小心选错了模块，那个测试领导就阴阳我说你简历上上家单位提了那么多 bug 是咋提的。我当场想问候他祖宗。当然后来不惯着他，当面跟他 battle 后提离职了走了。工作嘛，舒心最重要，遇到垃圾领导不必怀疑自己，不用惯着。记住，好的领导是站在你这边的。
