开发如何尽可能的避免BUG

柔光的暖阳◎ 2023-09-28 18:08 41阅读 0赞

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

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

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