概述
为提高研发代码质量,我们在处理研发 BUG 的时候不能只满足于修复,还要主动分析 BUG 原因,以便在未来的开发中避免重复错误
规则
【强制】解决 QA 提的 bug 时,必须填写 BUG 原因,选项说明如下表所示
分类 | 选项 | 说明 | 改进意见 |
---|---|---|---|
需求相关 | 需求或需求文档不完善 | 需求本身存在逻辑错误,或缺少必要逻辑 | RD 在评估需求时,不能只满足于理解现有需求,应多从产品角度理解其业务意图。尤其对于主R而言,要更能关注需求的完整性,逻辑的合理性,及早发现问题,帮助 PM 完善需求。 |
需求变更或新增需求 | 因需求变更导致各方理解不一致,进而导致的 bug | 需求的变更应及时与 PMO、RD、QA 沟通 | |
对需求的理解存在偏差 | 因对需求的理解错误,或偏差,而导致的 bug | 产品与技术的思维结构往往并不相同,文档与 UI 体现的产品形态,与技术的设计也未必一致,因此在需求评审与技术设计阶段双方要保持良好的沟通,而沟通的基础应该是“通用语言”。 产研间应维护好一套通用语言,以降低相互之间的误解,同时要就业务模型达成一致,相关方法可参看“领域驱动设计”相关知识。 | |
代码相关 | 复制粘贴大法 | 因代码相似度高,使用复制粘贴大法后,没有做完善的修改 | 首先,当发生大段代码复制时,应首先考虑是否可以重构,避免代码汇总出现重复或相似度极高的代码,一个基本的判断依据是,当你修改一处时,是否也要同时修改另外复制的一处 其次,确实发生复制粘贴时,可以先把原先的代码注释掉,然后进行修改,再取消注释,这样修改不完善时,开发工具一般也会给出提示 |
未处理的异常 | 应针对方法抛出的异常做业务处理,却没有做 | 开发过程中,应对程序产生的异常要有基本的预判 对于空指针、数组越界、undefined之类的情况要提前判断,避免此类异常直接响应给调用方,或造成脚本报错 如果产生的异常具有业务上的含义,则要结合产品需求进行恰当地处理,需求无明确定义的,要与产品做好沟通,确定处理逻辑 服务端与客户端的交互中要对异常情况的处理达成一致,服务端的异常响应要符合开发规范,有特殊情况的要有文档说明 | |
非法输入校验 | 因非法输入导致的bug | 任何程序对输入都是有要求和限制的,对限制范围以外的输入应当直接拒绝,并给出理由,而无需进入程序,避免不可控的处理与输出 具体的校验规则除了参照需求文档,还应参照测试提供的 checklist 需求文档未必面面俱到,开发人员也许要根据经验与常识,来设计校验规则、 | |
多次修改操作错误覆盖数据 | 一次请求或一个事务中,对同一条数据进行了多次修改,后面的修改错误地覆盖了前面的值 | 面向过程式的开发更容易引起此类问题,在技术设计阶段应该理清业务模型,梳理好代码结构,给出以下两点建议 使用面向对象的编程方式,而非面向过程或面向数据,对一条数据的修改应对应到一个实例对象的修改 如果是命令式的编程方式,则明确变更的字段,避免引入无关数据。 | |
局部修改导致意外影响 | 全局或共享的代码,因某个功能的需求进行修改,却意外地影响了其他功能或展示 | 编写代码过程中应该尽量限制代码的作用域,一旦定义成了公有方法,或者作为组件向其他模块提供服务,就不能轻易修改 如有修改则必须考虑到所有的使用场景,如无法确定兼容性,应通过新增功能的方式进行变更,而将老方法置为不建议使用 | |
框架问题 | 框架组件bug,或框架组件的实现与常规认知不符 | 此类问题要做好记录,形成文档,避免未来再次踩坑。同是也要关注相关 bug 的修复进度,及时更新版本。 | |
沟通及方法 | 不合理的输入输出 | 输入输出值明显不符合需求,如每月销量返回负数 | 优秀的研发要有良好的产品意识,对于一些想而易见的不合常理不合逻辑的情况,不需要产品文档面面俱到,研发人员要有能力做出合理设计 |
与文档定义不符 | 代码实现与文档定义或事前约定不符,此处包括技术文档或需求文档 | 文档是项目长期持续保持高质量的基础,也是团队合作的基础 技术文档,在技术评审阶段应该仔细核对评估文档的健全性,开发过程中应遵守文档定义,如有不符应及时更新文档 需求文档,对于那些未在技术文档体现的应尤为重视,避免遗漏,如字段的校验规则等 | |
主观臆断 | 在相关方文档或说明不明确的前提下,仅依赖具体数据或猜测,而非明确沟通,来确定交互逻辑 | 这里包括产品和研发两个层面, 产品层面上,开发前首先要理解产品需求,要知道所做功能对业务上的意义,在此基础上,才能提前发现需求中未明确写明的地方。但不管何时发现,不管是否有显而易见的逻辑,都应该与产品进行确认。 研发层面上,一切交互逻辑都应该在技术评审之前确定,并落实到文档,再发现有不明确的地方,一定需要交互双方进行确认,并落实到文档 | |
其他 | 兼容性BUG | 程序在不同操作系统或浏览器等环境下,表现出的功能不一致 | 应注重此类问题的知识积累,将遇到的问题记录下来,形成文档,并定期组织内部分享,提高研发人员经验与技能,从团队的层面避免再犯相同问题 针对积累的经验,定制适合的自测方案,并尽量做到自动化,以便通过流程规范来避免此类问题发生 |
环境或数据问题 | 因环境或数据异常而导致的临时性问题,或因环境或数据无法满足自测条件,而未能避免的 bug | 此类问题常见于跨部门跨团队合作的项目,应在技术评审阶段就对此类问题有足够的预期,提前反馈风险 应合理使用联调测试环境,保持主业务流程相关环境随时可用,对不稳定的环节要心中有数,及时反馈给相应团队,督促解决 对于需要复杂操作才能进行的验证,应提前寻求 QA 的帮助,评估好排期 | |
原因待查 | 无法复现、无法确定原因,或是不具备排查条件的历史遗留问题 | 良好的日志输出有助于排查问题 | |
不满足需求 | 代码实现与需求不符 | 如无法归纳到以上分类的,可选择此分类。 所有的 bug 都是不满足需求,而满足需求应该是研发工作的最低标准。我们对于 bug 的分析目标在于找到问题的根本原因,并能有针对性地做出优化,避免未来犯类似错误。如果仅是单纯的没有满足需求,这将是最低级的错误。 | |
不是BUG | QA识别错误,不是BUG |