测试基础 测试 BUG 究竟要怎么提？
在测试行业也已经干了七八年了，直到上一份工作中，让我在测试工作中产生困惑的事竟然是 bug 不知道咋提了，之前 bug 标题一直是这样写的：什么端什么模块在什么情况下出现了什么样的问题（详情会提供账号、截图等），但是这样提的 bug 被领导说了好几次让我改，她说 bug 标题应该写成预期要什么结果；有一次我想跟她掰扯，直接被怼了 “别跟我说这些，赶紧改”，当然后面的结果肯定是我离职了
，期间也质疑了自己写的是不是有问题，但是开发能看明白就行吧，我也翻看了大家的提的 bug，都差不多啊，有时候我怀疑这领导故意针对我，所以离职了以后感觉很放松，哈哈，现在特意来请教下各位同行大佬，提 bug 这个简单又不简单的事，大家是怎么提的。
添加购物车不成功
删除商品不成功
职场上都是对人不对事的（如果有人说不是，不要相信这种场面话）
建议社区的朋友们都要看看这部电影，我经常会拿出来警惕下
里面的飞全到死都不知道自己错在那里
感觉就是被针对了
标题写出现啥问题，或者期望结果 都可以吧，在详情里面写清楚 前置条件，操作步骤，实际结果，期望结果就好了
典型被针对了
什么端什么模块在什么情况下出现了什么样的问题 - 这个是实际结果，一般简单的我就直接是用前面这部分了，稍微复杂的就要加上预期结果。这个是因为有些开发对需求不是百分百熟悉，如果团队内部的人都很熟悉需求，不加也可以吧
我都是标题写现象，详情写步骤和预期，有的时候连步骤都没有直接贴个图
做测试 7 年了，前 6 年 bug 标题一直都是写的预期结果，今年开始写成了 什么端什么模块在什么情况下出现了什么样的问题。
这个变化主要在于对用例标题的思考，认为标题就是应该告诉开发人员出现了什么问题。然后 bug 详情里面，再说复现步骤、预期结果，以及其他 bug 附件证明。 这种 Bug 标题与详情的搭配表述，能够完整的说清楚是什么问题。
有时候 bug 光靠一个标题是无法描述完整的，全部塞进去，又要说出现了什么事情，又要说预期结果，整得又臭又长，有些不合理。
但单独针对这件事情来说，其实是一件小事情，主要是根据团队得习惯来针对性调整，无可厚非，大家都能看懂就行。所以还是觉得你被针对了。
无需在意，被针对而已
那标题不能超过 25 个字要保证开发能通过标题看懂什么问题，BUG 详情：前置条件、操作步骤、实际结果、预期结果必填，后端问题必须附接口请求、响应信息和日志文件，前端问题必须附 url 和截图这种怎么说