对于测试BUG的处理，代码缺陷的管理和改进，提高研发代码质量

概述

为提高研发代码质量，我们在处理研发 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