一 : BUG的范围
想要尽可能的避免BUG，首先需要知道BUG大概的分类，可以简单概括成3类
1 : 阻断性BUG
该类型BUG为不应该出现的问题，即会影响正常的流程，进而测试无法进一步测试。
如：系统报错异常，服务器崩溃，数据库死锁，死循环等等。
2 : 缺陷性BUG
该类型BUG，主要体现在非正常流程出现的问题。即正常流程可以使用，但是有点误操作就会崩溃。
该类型的问题，为最常见也是最多的BUG。
如：页面参数未校验，系统提示语错误，查询失效等等。
3 : 建议性BUG
该类型BUG，前提是需要以用户角度实操系统，才能提出更符合用户操作系统的BUG。需要对系统的业务更加熟悉，深耕业务实际场景，并有一些创新性的思维等。
如：页面的操作是否需要模糊查询，页面样式是否居中，业务操作流程是否可以缩短等等。
二 : BUG产生的原因
1、没有进行自测（Web/App自测）
自测指的是用测试人员使用的页面测试，而非postman这种接口测试工具。阻断性的BUG、一般缺陷性的BUG，基本都是可以通过自测提前发现的。
2、没有修改联动的功能
目前很多的系统，其功能点都不是单一功能，而是有联动关联关系的。其逻辑类似于 省市区三级联动，如果修改了“市”那前后的联动自然也要同步修改。所以在开发过程中，并不能只着眼于当前开发的功能。更要分析当前功能是否有关联（功能的数据来源点、及数据使用点），站在全局的角度看开发的功能，才不会顾此失彼。
3、必要的参数，前后端都要加校验
对于系统的参数，增加校验的目的，是需要业务操作人员按照系统设定的方向走。如果没有校验，走偏了，很容易引起系统阻断性BUG。参数校验大致可分三种：非空校验、长度校验、合规校验非空校验：对于业务必要的参数，一定要增加校验长度校验：较为常见的类似于输入框、文本框等等。表的字段设置50，假设没有校验，数据库就会报错而引起阻断性BUG。合规校验：对于特殊规范的参数，如身份证，手机号，和一些特殊工号等等，可采取正则校验。
4、SVN/GIT提交代码，需要检查提交的内容是否有误
这一点也是很多人容易忽视的一点，最后临门一脚，太过自信，不去检查自己提交的内容，而导致不应该提交的也提交了。自己测试时候，为了方便而注释某些代码，提交的时候不做检查，就会导致测试有问题。需要渐渐的养成习惯，以减少不必要的BUG。
5、过需求的时候，要分析需求是否合理、还要看是否有遗漏
在开发需求的时候，有时候做完之后，才会发现可能不太合理，或者漏了某个功能。这就需要在开发之前，即需求评审时，对需求的细节进行分析。是否满足业务要求，是否符合业务操作习惯，功能流程是否合理，需求点是否遗漏等等。同第二点相似，站在全局的角度、用户的角度看需求，才能在源头避免需求本身的问题，进而减少BUG。
6、要注意页面显示的内容是否合理，*号，标点符号等
在前端开发时，并非功能不报错即可。同时也需要注意的是页面是否合理。如：页面显示某个字段没对齐，页面中文冒号英文冒号，页面样式与系统整体不同。必填字段是否有*号，审核退回/不通过时备注加*号等等。把自己当做用户使用系统，来发现使用过程中，页面的不合理之处。
7、提测之前，后端需要告知测试老师正常流程，同时要告知特殊情况及提示信息等
经常会碰到一些不是BUG的问题，而被测试老师提成了BUG。在开发完成之后进行提测之后，一般都是告知测试老师具体的测试流程，而特殊情况，恰恰是容易忽略的。这就需要开发人员在告知时，进行特殊说明，进而减少这种不是BUG的BUG。
8、提测之前需要清理脏数据
在提测之前，需要清理一下无用的脏数据，以防止对正常流程产生影响。其实，如果第3点做的比较充足，那也可以满足脏数据的存在。
9、存在关联必填项
也可同第2点内容，某一个内容必填，当内容变动，会关联其他内容必填。比如：审核退回，星号要根据 审核状态 进行判断是否显示。审核原因，仅在退回的时候是必填项等。
10、测试需要按照生产业务操作新建测试账号。以便复现生产问题
有时会方便测试，RBAC相关信息会随意创建，这种方式虽然可行，但是并不适用于生产问题的复现。当然测试的目的就是要看非正常情况，系统的处理。随意创建的RBAC信息需要有，但生产相同或相似的RBAC信息同时也需要存在。
11、所有的导出，除特殊情况外，页面数据内容和数据量应和导出一致
这是经常会被忽视的一个细节问题。向上归纳，其实也是属于第2点，不过这种情况算是一种典型。比如业务要求页面增加一个查询条件，大部分人都认为只是查询修改。其实如果第2点想的多，联动的 重置、导出等功能也是需要修改的。也存在一些特殊情况，这就需要开发、需求人员做到第7点。比如业务要求导出按照某种政策文件格式，这种情况如果不及时告知，测试人员一定会认为是BUG的。
12、后端数据存储和前端数据回显应保持一致
这种情况，理应不该出现的。向上归纳，其实也是属于第1点，不过这种情况算是一种典型。自测不应局限于程序是否报错，而应体现是数据是否正常落地。
13、后端开发除数据修改外，不要手动修改数据库
有的时候我们会手动修改数据库的内容。这种情况一定要谨慎，错误的程序会导致脏数据，手动修改数据，如果修改的不恰当，同样是会产生脏数据的。对于数据库的修改，一定要谨慎！！！
如有不正确之处，还望指正！书写不易，觉得有帮助就点个赞吧！☺☺☺
