作为测试新人，很多学员在工作中不知道从哪里进行下手进行测试，即使发现了问题也不确定是不是bug，从而导致非问题、重复bug等现象，现根据测试过程中比较常的问题进行分类，并针对这些问题怎样进行验证提出了相关的参考办法，相信能帮到刚入职不久的你打开思路：
一、功能性问题
当需求进行分析与评审后，系统都具备什么样的功能，测试人员都一清二楚，不管有没有进行冒烟测试，功能问题都是我们最容易发现且最没有疑问的问题。具体的问题体现要依具体的需求文档而定。
参考办法：《需求设计文档》
二、兼容性问题
不管是B/S构架还是C/S架构，在测试过程中都会做大量的兼容性测试，虽然进行兼容性测试的时间不一样（有专门留时间段进行兼容性测试，也有在功能测试的过程中同步进行），但兼容性测试始终是测试内容中的一大块，比如：按钮位置不对、文字显示不全、提示弹框出错等都是比较常见的兼容性问题。
参考办法：用多种不同的浏览器版本进行验证
三、易用性问题
所有的测试问题中，最有争议的莫过于易用性问题，易用性本身就是从方便与合理两个角度测试的，因此会因个人习惯与项目整体风格而产生的不同的意见，加上不涉及功能，往往这类问题也是走评审最多的。比如，导航按钮位置不合理、进行某步操作后没有给出明确的提示信息等。
参考办法：走评审、做竞品分析
四、数据库问题
数据库问题最直观的体现就是界面给出的类似”数据库异常”的提示，或是写数据写不过去，这种问题，要考虑数据库所在的机器是否正常，配置是否正确，连接进程是否正常运行等。
参考办法 ：日志
五、存储过程问题
都说在测试行业做手工测试太久的话，很容易被人取代，也找不到测试的乐趣，这是事实，因为不光技术的层面上不去，就连发现的问题也不太让人信服了，比如存储过程的问题，跟以往通过bug的出现再去查看日志协助定位不同，一般都是建议通过日志查看调用是否正常再去验证前台数据，当然，不是说不能通过前台现象确认存储过程的问题，只是反过来更简单一些。从日志可以看到调用的存储过程，传递的参数个数、位置、范围，因此，对业务与说明文档足够熟悉的话，可以脱离界面从而测试调用下发这个环节。比如：通过动态日志监控某个界面调用的存储过程中，下发的参数跟界面选择不符。
参考办法：数据库字段说明
六、性能问题
性能测试比功能测试介入的晚，一方面是由于功能不稳定不适合进行性能测试，一方面也是因为性能问题往往改动比较大。由于性能测出现的问题大多都是比较大的问题，且涉及的面比较广，因此对于专项做性能的测试人员与开发人员都有比较广的技术面的要求，往浅了说，简单的稳定性测试（保持长时间向服务器发送请求）也是每个项目都必须进行的。比如，往服务器加压的过程中，某核心组件异常断掉，或是因为请求未合理排队而导致服务器挂死等。
参考办法：查看日志、减压定位
七、设计错误问题
虽然需求分析时针对很多特定的场景有评审过，但还是避免不了在周期中，很多因为设计错误而产生的bug，这些问题要看具体的业务的设计与应用场景。往往认为最没有疑问的，但是由于应用场景不一样视为缺陷的场景并不少见。比如，项目中只要涉及权限就会有角色，但是有些项目中的管理权限是通过角色来限制，而有些则还是通过用户来管理。
参考办法：参考项目背景与适用场景、评审
八、外部条件问题
为什么需要进行测试，通俗来讲只是让产品能适应不同的人在不同的环境做不同的操作。作为测试人员，只是在上线前充当这过程中需要的人而已。
测试过程中，为了看部件或系统的容错能力，除了正常的功能测试外，也会做相关的“暴力测试”，比如，断网，断电。
参考办法：测试前后的数据对比、测试后的数据验证
九、数据同步问题
这类测试往往在做手工测试时不易察觉，需要接触接口测试或是性能测试后才能想到更深的同步问题。随着现在对服务器的释压，分布式是我们比较常见的一个词，不管是对服务器还是部件，甚至是业务层面，都会涉及到同步的问题。比如，在已知数据的基础上验证相关业务，发现数据对不上，排查了功能问题及误操作外，就要通过其它方式，比如时间，去验证是否是同步的问题
参考办法：查看日志、通过接口测试验证
十、需求理解问题
虽然这种问题不常见，但现实告诉我们，尽管有对需求进行评审，但是在测试过程中还是避免不了会存在需求理解错误的问题，当然这种问题不占大多数。
参考办法：需求文档、评审
不管是哪类bug，需求熟悉、业务熟练是根本，再就是流程与配置，只有熟悉了这些，遇到问题时，才能有办法去进行验证与定位，从而累积经验，在测试的道路上越好越顺！
标签：分类,参考,常见,办法,问题,测试,日志,bug From： https://www.cnblogs.com/xmxit/p/17175877.html