有一些初始的小测试团队，对BUG单可能会进行重要程度的划分，但并不会进行类型划分。
其实，如果不对BUG进行错误类型定义，项目经理或测试经理并不好确认后续质量提升在哪方面进行改进，具体研发的哪个环节更需要进行改进。
故此合理的对BUG单进行分类也是提交BUG的前提。以下是我整理的BUG类型分类情况：
版本提交问题
与版本提交相关的问题：
-
程序文件或数据库脚本提交错误
-
程序文件缺少或数据库脚本缺少
-
未提交相关文档或文档提交错误
-
相关文档不详细
-
版本号错误
需求问题
涉及到在需求阶段引入的问题：
-
需求文档中有需求点遗漏造成的问题
-
需求文档中不合常理而造成的问题
-
需求文档自相矛盾等产生的问题
功能问题
所有影响功能无法正常使用的问题：
-
没有实现需求所要求的功能
-
实现的功能超出需求范围
-
功能实现与需求不符
-
功能不能正常实现或不能正常操作
-
数据库不能正常存储或存储值不正确
-
界面不能正确回显已输入的值
-
数据不能及时刷新
-
链接或下载错误
异常处理问题
对于异常数据、异常操作的相关处理：
-
无信息合法性检查
-
无对关键字段判重
-
无数据长度检查
-
异常操作无进行相关处理
-
程序异常未进行处理或处理不正确
UE问题
所有影响用户视觉/操作上的体验问题：
-
界面文字错误或缺少
-
提示信息不清、错误或缺少
-
界面风格、布局不统一
-
操作不方便
-
操作方式不统一
性能问题
有关操作响应、稳定性等方面有相关问题：
-
操作反应速度慢
-
长时间使用后不稳定
-
数据量过多时进行相关操作无反应或造成出错
安全性问题
涉及到加密、session过期、口令验证、权限等相关性问题：
-
数据的存储、传输加密问题
-
Session过期时间判断
-
页面访问权限控制
-
帐号登录唯一性检查
-
用户登录密码验证、密码修改验证等
兼容性问题
涉及在不同的软件版本或硬件下使用出现的问题：
-
与操作系统版本不兼容
-
与浏览器版本不兼容
-
与其它相关的软件版本不兼容
-
与硬件不兼容
建议性问题
包括功能性或操作性建议：
-
功能性建议
-
界面/操作性建议
进行BUG类型分类仅是第一步，作为WEB类的项目，一般情况下，明面上的二、三类问题，自测时容易发现且会完成修改，留到测试去提出的机率相对会少一点。
而其它类问题常常因为开发时间不够或不重视等原因，大量的留给了测试阶段去提出。对于这类现象，负责的项目经理有时候是心有余而力不足，而不太负责的项目经理，有可能就睁一只眼闭一只眼。
作为测试团队，想要提高提交版本质量，可以用以下几种方式去做尝试：
-
与项目组，确认清楚接收版本的准则，即让项目组成员都清楚存在哪些问题，版本会被打回；
-
提供P0用例给到开发，提高开发的自测质量；
-
整理不同开发重复出现的问题，与项目经理商议每个问题的具体代码上的处理方案，整理为项目组内的知识点，在开发团队中进行宣导或组织专题会议进行讲解；
-
对于严重影响测试工作效率或反复出现的问题单，可以适当的提高问题单的严重程度，以引起项目组的重视。
以上，是个人愚见，欢迎大家一起留言交流！
最后也给软件测试的朋友们分享一份测试资料：
以上内容，对于软件测试的朋友来说应该是最全面最完整的备战仓库了，为了更好地整理每个模块，我也参考了很多网上的优质博文和项目，力求不漏掉每一个知识点，很多朋友靠着这些内容进行复习，拿到了BATJ等大厂的offer，这个仓库也已经帮助了很多的软件测试的学习者，希望也能帮助到你。关注我公众号：程序员二黑，免费获取！
机会只垂青有准备的人，这是一个靠本事的社会。有时候，你之所以发展得不好，不是因为没有机遇，而是因为你没有准备好，导致机遇与你擦肩而过。如果你想要学习，什么时候开始都不晚，而不是瞻前顾后，你只要用尽全力，剩下的交给时间！
加油吧，测试人！路就在脚下，成功就在明天！