开发如何尽可能的避免BUG

一 : 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、后端开发除数据修改外，不要手动修改数据库

有的时候我们会手动修改数据库的内容。
这种情况一定要谨慎，错误的程序会导致脏数据，手动修改数据，如果修改的不恰当，同样是会产生脏数据的。
对于数据库的修改，一定要谨慎！！！

如有不正确之处，还望指正！书写不易，觉得有帮助就点个赞吧！☺☺☺