一.diff的前提
对该需求的设计实现了解
对业务需求的了解
对系统结构、数据流完整的了解
二.diff代码时候至少要做到以下几件事
查看需求的功能是否实现
查看变更对整个系统的影响点，补充checklist
根据变更，追述到入口点(Dubbo, http, 页面)，进行回归测试覆盖变更代码逻辑
发现业务漏洞
三.diff中关注的内容
业务是否如实在代码中实现（不管对错），改多了、改少了？是否符合设计；逻辑是否都是完整闭合的（即，能按照完整流程图实施，考虑所有异常分支）
diff时要进入业务，不要深入代码，要多想else是否缺了，如果没有else的时候要考虑是否漏了业务
某个时间点的task是否有冲突？需要考虑数据量等问题
线上是什么样子的架构？
发布被diff的代码时候是否会异常？
日志、业务监控的添加是否完整
监控：失败、成功是否都有监控，在这个业务上次数和时间我们更关注那个？
日志是否需要单独打印？是否需要打印，打印的级别。
四.代码层面
代码的基本规范是否满足（视个人能力及代码水平而定）比如：日志规范、db链接、前端调用的域名
代码对异常、超时相关的处理，是否输出相关日志
代码中长出现不好验证的测试点，如:线程是否回收了？链接是否因为数据量过大会释放？
新写代码是否重复造轮，是否有必要重写,比如：已有的qunar相关类库实现相同功能
对事务的处理
通过方法的调用关系找到最终的用户,其他的方法调用，要找到谁在使用？sql改了，有哪些查询受影响？
五.DB设计是否合理
字段、索引的设计（观察属性）
新旧数据的处理、兼容
大表的查询，是否走了索引，这样加索引是否正确
数据库的表结构能承受多大的数据库？
六.配置相关测试
对dubbo、qmq、qschedule、qconfig的配置,超时相关
qzz版本是否变更
线上环境是否修改？
beta的配置是否使用的线上地址？
七.对系统结构的测试
缓存有效性：将缓存服务器清楚掉的处理
容灾
外部系统调用常见处理：超时、异常、retry次数
被调用的外部接口是否可用？该接口wiki地址？
八.对于无法测试执行的中间数据，如何添加测试方法
九.关注beta和线上的区别
账户是否在线上可以使用
接口是否可以使用（包括图片和接口）
db地址是否为ip，禁止用机器名
前端接口外网应用禁止使用ip
十.diff要产出的东西
测试范围/checklist（更改的每一个方法都要追溯到最终的业务调用，去验证业务；每个数据都要追溯到源头和最终使用）
违反规范的bug(sonar静态代码检查的)
系统改进建议
明确测试方法/测试手段
diff过程中可以进行测试执行，也许diff完成时，项目测试也执行完成了。
