一.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完成时，项目测试也执行完成了。