不知道大家有没有这样的习惯，每天在下班之后，坐在电脑面前，小憩一会儿，回想下今天的目标，是否还有遗漏，没去完成的，统一进行mark一下，看看企业微信是否还有未回复的短消息。
今天呢主要还是想给大家想分享一下软件测试人员密切接触的一个关键词 ”BUG“；主题是：测试人员如何正确的提交BUG。
分享前给大家分享一个工作中小案例，该场景应该部分测试人员在实际工作中有碰到过。
某天，某办公楼，在项目版本迫切上线的紧张周期下，石某某按照预期测试进度疯狂测试输出成果的一天，发现系统的各类潜在BUG，终于熬到下班时刻，将测试进度按照预期mark一下，同时将缺陷面板BUG清单链接周知在项目群，周知开发同学，收工。
打完下班卡，回家倒床，舒服的睡了一觉，第二天一大早来到公司，沏了壶醒脑茶，刚转身准备回到工位开干时。
却听到开发同学说：你们测试怎么提的BUG，给个截图能说明什么问题，具体的操作步骤，如何必现逻辑都没描述清楚，接口请求、日志什么都没有，Fuck！
此时是不是觉得自己的996，一切辛苦付诸东流
所以当我们做一件事情，已经付出了99%的汗水时，千万不要让1%的惰性将成果打水漂，这是一件很不划算的买卖。
做测试心态要好、韧性要强，坐得了冷板凳，耐得住寂寞
根据上面的案例，我们仔细分析一波，BUG信息不全，背后的黑手其实是"缺陷管理系统"，测试leader或项目管理人员在设计提交缺陷页面字段不完善的锅，如果源头的模板字段设计齐全了，哪还会出现重要的一些核心字段没有呢！
在这里小编给大家分享一份适用于任何缺陷管理工具BUG字段大全，适用于公司各类项目，可按照文档字段去更正当前企业缺陷管理系统流程提交BUG页面字段不全的地方，再也不用担心提交BUG被开发吐槽不够全面不够仔细。
带*号的为必填项，除了"问题判定责任方"、"原因分析"、"解决方案"是开发解决BUG时需要录入的字段，基本必填项都是测试人员必须要关注的。
最后在强调一遍，提交BUG核心点就在于缺陷页面模板，重要的信息字段是否有缺失，是否强制必填；有了模板，按照模板去提交，不会出现BUG信息不全的问题！
总之提交BUG遵循一点，根据缺陷已知的[ 现象+信息+风险+备注 ]>>[ 为什么出现+谁引起的 ]>>[ 如何去解决+什么时间点去解决 ]; 根据这个逻辑，按部就班的在缺陷面板去一项一项录入，戒骄戒躁。
记住,每一个BUG都是你测试水平的象征!
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
