BUG提交规范
1、标题
2、步骤描述
①、步骤使用序号编排 ②、在特定情况下发生的问题，还需提供准确的前提条件 ③、精准的描述bug产生的路径后，再描述现象 如： >打开客户端进行首页->点击“我的”页面->点击用户头像进入个人资料页 >个人资料页点击头像选择拍照->拍照后点击保存头像 >从个人资料页返回 “我的”页面，查看头像是否更新
④、若步骤并不能必现错误，需要说明出现错误的概率（需要多次测试的基础上，若必现则填写100%，若偶现，则执行多次后统计概率填写）
3、期望结果
按照测试步骤应该得到的正确结果，应严格按照产品需求描述，并且结果必须是肯定的
期望结果不应包含该测试步骤，要是简单的一个结果
4、实际结果
按照测试步骤出现的错误结果，对错误的结果进行描述，必要时附上截图，或录屏（录屏工具：录屏大师[android] 、AirPlayer[ios]，iTools[ios]。）
①、UI类型：必须要附截图
②、功能类型：必要的截图和录屏
③、奔溃类型：log日志
5、所属产品-->所属版本---->所属模块--->功能
6、严重程度
①、Blocker：非常严重--系统（功能）无法执行、内存溢出或其他异常导致的奔溃、无法启动，应用模块无法继续往下测试（即直接阻塞）
当然，如果完成模块与需求严重不符，也属于阻塞，严重类型也是Blocker
②、Critical ：严重--功能存在较严重的缺陷，但不会影响继续执行测试的功能bug
③、Major ：重要---界面的一些问题，比如边界、兼容（系统、机型）、安全、性能上的（实际上就是功能都可以正常运行，没有严重的阻塞和缺陷以外的其他问题）
④、Minor ：一般--一般是站在用户的角度上提出的易用性，比如操作给出的提示不友好、或重点位置未给出
7、优先级
①、Immediate ：马上解决--其实对应Blocker，必须马上解决，否则无法继续往下测试
②、Urgent：继续解决--其实对应的是Critical ，意思是紧急要解决的，否则功能模块无法正常通过测试
③、High：高度重视---大致对应的是Major，意思是解决完前两种，紧接着就要解决的
④、Normal：正常处理--在不影响版本进度、个人进度、其他优先级高的
⑤、Low：低优先级--这个正常在发布前进行必须确认解决或确认可以不予解决。
备注：优先级和严重程度不一定是一一对应，举个例子
例如，界面单词拼写错误，但是如果是软件名称或公司名称的拼写错误，则必须尽快修正，因为这关系到软件和公司的市场形象。
再如：如果修正一个严重性很高的bug，需要重新修改软件的整体架构，可能会产生更多潜在的缺陷，而且软件由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，是否需要修正，需要全盘考虑。
总而言之，修复缺陷，不仅仅是考虑技术方面，还要考虑市场和产品质量等的综合因素
8、指派对象
Bug管理工具
1、Bugfree
①、听说是禅道的前身，目前已经不开放使用了
②、开源
③、非常简单上手
2、禅道（建议使用）
①、开源
②、可进行二次开发
③、管理的东西面向对象：产品（需求管理、项目管理、质量管理、文档管理）、测试（bug管理、用例管理[用例库]、测试报告、测试统计）
④、当然还有完整的用户管理、组织系统、统计功能
⑤、完善的个人事务管理：我的产品、我的需求、我的任务
3、TeamBuilder
①、web在线使用
②、页面简洁（只适合小小型的项目管理）
③、事务管理、质量管理上较弱，功能局限