在提交缺陷时，需要遵循以下5个原则：

　　准确性：缺陷每个组成部分描述准确，不会产生误解，减少“异常”“正常”等模糊词的使用

　　完整性：复现该缺陷完整的步骤、截图、日志

　　一致性：按照一致的格式书写全部缺陷信息

　　简洁性：只包含必不可少的信息，不包括任何多余的内容

　　清晰性：每个组成部分的描述清晰，易于理解

规范的目的：

　　方便开发人员更好的理解BUG问题与期望

　　方便相关人员重现BUG

　　测试人员更加清晰的描述问题

　　统一BUG单的编写习惯，提升工作效率

提单的规则：

标题
　　问题描述
　　特殊情况：
　　　　当问题为单机型导致时：【兼容机型】问题描述
　　　　当问题非必现时：【概率】问题描述
　　　　版本发布到预发布环境后，要判断问题是否版本增量导致：【增量/非增量】问题描述

内容（*表示必填）
　　*账号/密码：发现问题的账号密码；
　　测试机型：非必填，单机型问题时要填写；
　　预置条件：非必填，操作前必须的必备条件；
　　例：收藏夹的资讯翻页失败；其前置条件为用户收藏夹资讯>一页
　　*操作步骤：问题的操作步骤
　　*实际结果：问题的当前结果
　　*预期结果：问题修改后的期望结果
　　接口：非必填,问题接口的URL
　　SQL：非必填，相关数据的SQL语句
　　问题截图、视频：非必填，对问题进行截图描述（要在图片中给出相关标注）
　　　　上传视频后，要注明：详情见附件视频
　　　　上传接口文件后，要注明：接口数据见附件文件

属性（*表示必填）
　　关联需求：问题单所属需求
　　*迭代：问题单所属的迭代
　　*软件平台：问题单影响的软件平台（如：H5、IOS）
　　*优先级：问题单的优先解决等级
　　*模块：问题单所属的模块（如：动态、圈子）
　　*严重程度：问题单对当前的程序的影响程度
　　*缺陷类型：问题单所属的类型（如：文案、业务逻辑）
　　*处理人：当前问题单的处理人（开发、UI、产品、测试）
　　*测试人员：问题单的测试人员
　　*测试环境：问题单的所属环境

缺陷列表的显示：

　　总结：我们用的bug管理工具是TAPD，但是基本上bug管理工具都相似度高，设置后的列表更加直观性，可见的重要信息一眼可见

 1.作者：Syw

2.本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

3.如果文中有什么错误，欢迎指出。以免更多的人被误导。