从用户关心的角度对软件BUG进行分类《转载》

软件BUG的分类方式很多，如通过对系统的影响程度可分为严重级别，致命错误，严重错误、一般错误、建议项等；通过重现频率可分为可重现错误、偶然错误等，通过错误内容可以分功能错误、用户界面错误、边界值相关错误、初始化错误、计算错误、内存相关错误、硬件相关错误、文档错误等。这些分类对于跟踪BUG的修改很有帮助。但是这类划分标准都是从测试人员、开发人员的角度进行分类，并没有很好的反映出最终用户对产品的不同关注程度。由于最终用户关心的角度并不是开发的过程，而是业务功能的准确性、性能以及操作方便性，因此看问题的角度会有不同。这里本人尝试通过用户的视角进行BUG分类，在有最终用户参与的测试过程中，可以酌情参考使用。51Testing软件测试网NpW6f0J9q9uPS

 51Testing软件测试网f.a"i:k/O'L8vL;c)F

第一类：理解性错误。包含在分析和概要设计过程中工作不到位造成的失误。例如使用了不合理的代码体系；系统内部编码规则不统一；业务术语错误；主要前后逻辑错误等。这类问题说白了就是没有很好的理解基础需求，给用户以外行的印象，对整个系统就有理由持怀疑态度。这类错误是最严重的。一般要一到几个月才能解决。51Testing软件测试网 ?k U p"v

第二类：功能性错误。如保存数据不成功；系统抛出未经封装的底层错误；应用程序意外中断；正确性无法验证等，这类错误造成对最终用户对系统的失望，遇到这类问题，其它功能就测不下去。这是比较严重的错误，影响系统其它功能的测试，一般需要一到几周才能解决。

第三类：功能衔接错误。如保存的数据无法查询；各个查询之间的查询口径无法统一，查询结果有偏差；上环节的数据传递到下环节不能使用，通过后台处理，勉强能够进行下环节的测试。这类问题让用户感觉还不能进行试运行，还得经过系统测试、修改后才能系统上线。

第四类：内部逻辑错误；如缺乏必要的输入输出校验；提示信息缺少或者不够友好、不易操作等；这类问题除了明确具体的要求外，需要开发人员细心完善解决。

第五类：扩展性问题或建议，如没有提供打印输出功能，显示操作员登陆信息、自动计算合计数等，这类问题是对基础功能的补充，用户提了但不影响最终的上线使用。

对于行业应用软件的测试，在早期应以发现前三类错误为目标，测试人员应当具备一定的业务知识，才能发现问题的主要矛盾，而不能只停留在满足测试出的BUG数量上。