要上线了，面对一大堆要上线的新代码，质量控制方面应该做什么

对于代码质量控制，在开发过程中，充分的理解业务逻辑和自我测试，是必不可少的，但是本次主要谈的是，一轮的开发已经结束，即将上线了，这个时候在质量控制方面应该做什么。

首先，明确所有的在这轮开发中所作出的修改（这个要基于分支的管理，每次发起feature/release分支向stable/master分支的pr来merge，详见下图），可以以文件为单位，列出一个表格，本次修改了那些文件，修改的比例为多少，引起上线事故的风险有多少。

做这些的目的涉及本次质量控制的第一步：风险评估。

风险评估的目的在于了解下一步的测试应该做什么。

可以列出一个表格，让做出对应修改的开发人员评估每一个修改引起线上事故的风险，风险的评估依据修改的程度，修改完后自测的程度，是否有兼容性问题，以及修改造成的bug的严重程度，几个维度，逐一进行评估，最后可以将这几个维度的评估值按照一定的运算规则得出综合评估风险。然后最终的测试流程可以依据评估结果，从高到低针对进行。

修改文件	修改程度	测试覆盖程度	造成bug的严重程度	……(潜在错误可能、兼容性问题)	综合评估风险
FinanceService.java	80%	20%	高		非常高
TranspotationService.java	10%	100%	一般		低
...					...

这个过程除了可以辅助定制上线前测试流程之外，还有以下几点作用：

1.可以让开发人员重新审视自己负责修改的代码，从业务角度或风险角度认识其中的重要性。

2.可以让开发人员重新评估代码中可能造成的问题对线上产品的影响。

3.如果按如此流程后上线仍然出现问题，可以对此优化评估流程，出现的问题是否在评估结果预料范围内？如果在，说明评估后处理工作做得不够，如果不在，说明评估出现问题。

下一步就是根据风险评估，进行上线前测试，对于高风险的问题，测试不完宁可不上线。因为以上评估是以文件为单位，所以对应的针对性测试应该以功能模块为单位，所以需要将文件映射到相关功能和业务，来安排测试。

修改文件	修改程度	测试覆盖程度(Code Coverage)	造成bug的严重程度	…...	综合评估风险
FinanceService.java	80%	20%	高		非常高
TranspotationService.java	10%	100%	一般		低
...					...

修改文件	对应业务范围	对应功能点	对应测试流程	兼容性测试...
FinanceService.java	个人财务中心	提现、流水查看、修改银行卡信息...	...
TranspotationService.java	行程管理	…..	…..
...