在提交缺陷时，需要遵循以下5个原则：
准确性：缺陷每个组成部分描述准确，不会产生误解，减少“异常”“正常”等模糊词的使用
完整性：复现该缺陷完整的步骤、截图、日志
一致性：按照一致的格式书写全部缺陷信息
简洁性：只包含必不可少的信息，不包括任何多余的内容
清晰性：每个组成部分的描述清晰，易于理解
规范的目的：
方便开发人员更好的理解BUG问题与期望
方便相关人员重现BUG
测试人员更加清晰的描述问题
统一BUG单的编写习惯，提升工作效率
提单的规则：
标题
问题描述
特殊情况：
当问题为单机型导致时：【兼容机型】问题描述
当问题非必现时：【概率】问题描述
版本发布到预发布环境后，要判断问题是否版本增量导致：【增量/非增量】问题描述
内容（*表示必填）
*账号/密码：发现问题的账号密码；
测试机型：非必填，单机型问题时要填写；
预置条件：非必填，操作前必须的必备条件；
例：收藏夹的资讯翻页失败；其前置条件为用户收藏夹资讯>一页
*操作步骤：问题的操作步骤
*实际结果：问题的当前结果
*预期结果：问题修改后的期望结果
接口：非必填,问题接口的URL
SQL：非必填，相关数据的SQL语句
问题截图、视频：非必填，对问题进行截图描述（要在图片中给出相关标注）
上传视频后，要注明：详情见附件视频
上传接口文件后，要注明：接口数据见附件文件
属性（*表示必填）
关联需求：问题单所属需求
*迭代：问题单所属的迭代
*软件平台：问题单影响的软件平台（如：H5、IOS）
*优先级：问题单的优先解决等级
*模块：问题单所属的模块（如：动态、圈子）
*严重程度：问题单对当前的程序的影响程度
*缺陷类型：问题单所属的类型（如：文案、业务逻辑）
*处理人：当前问题单的处理人（开发、UI、产品、测试）
*测试人员：问题单的测试人员
*测试环境：问题单的所属环境
缺陷列表的显示：
总结：我们用的bug管理工具是TAPD，但是基本上bug管理工具都相似度高，设置后的列表更加直观性，可见的重要信息一眼可见
