浅谈codediff_Allione_新浪博客

Code diff最重要在于和Dev沟通交流的过程，有时你的一些问题、疑问，就能让开发意识到错误，而对开发所用技术实现的理解也加强了自身的代码能力；更重要的是，对代码改动的了解，使得每次测试和上线做到心中有数。 

1、什么是Code diff 

1）  比较代码差异

2）code diff 与code review

Ø      code diff：测试同学为保证自己checklist完整而做的工作

Ø      code review：开发检查代码是否规范，设计是否合理

2、为什么要Code diff

1.  评估影响面（包括对老功能的影响）

2.  补充测试点

3.  确认需求实现

4.  提前发现问题

5.  确认发布步骤

6.  加深对技术实现的理解

示例：

Ø    开发merge代码出错，例如丢掉、合并代码错误

Ø    代码仅修改了一行，最终出了故障（调用方，评估影响范围，确定回归测试的范围）

Ø    多个bug同时修改完成后，难以确定影响范围

Ø    最终上线代码与分支代码不一致

Ø    在QA不知情下默默搭车

  3、何时进行Code diff

1.  提测时的code diff

Ø     得到本次代码的改动范围，确认开发代码的提交量，测试的回归量

Ø     使用branch代码与master代码全量diff

Ø     参与人员 QA、RD

2.  提测后，每次开发修复bug而更改的code diff

Ø     可以视情况而合并多次提交的代码做diff

Ø     参与人员可以只有QA

Ø     对于修复bug改动代码影响、复杂度大的需要QA、RD一同diff

3.  测试结束，待上线状态的code diff

Ø     确认最终上线代码

Ø     参与人员可以只有QA

   Code diff 注意事项

Ø     提醒开发合并最新master/release后，在进行diff

Ø     Diff前，使用git fetch 拉取最新的branch到本地，然后与remote/master进行比较

Ø     实际操作过程中，可以直接通过查看分支的修改历史，确定代码变更

Code diff的产出

1.  测试范围/checklist

2.  违反规范、需求实现错误、逻辑错误的bug

3.  系统改进建议

4.  明确测试方法/测试手段

5.  确认发布步骤是否正确

如何进行Code diff

1.  Code diff工具——idea

Branch与release之间的diff（git->compare with branch）

同一branch改动的diff

   

  同一 branch 改动的 diff  

  

  1.  如何 进 行 Code diff —— 准 备

Ø    熟悉产品需求----需求文档，show case，讲设计

Ø    如果是你怎么实现----依赖于对系统的了解程度

Ø    了解产品的整体结构以及与关联模块的交互关系

Ø    了解系统的整体结构以及与关联模块的交互关系

 2.  code diff ——进行

Ø    要求实现的业务是否已经实现 ----功能

Ø    修改的基础方法或者工具类，找到所有的调用方，确认调用方的请求是否可以满足----接口变更

Ø    数据库设计是否合理，新旧数据是否兼容 ----db，数据

Ø    敏感数据是否加密，是否存在sql注入等问题----安全

Ø    接口间的调用是否存在性能问题，是否需要使用缓存----性能

Ø    是否依赖于第三方系统----第三方依赖

Ø    发布是否是兼容发布，是否是可以回滚的----兼容(枚举值的升级)

Ø    如果多线程并发，是否会产生死锁的问题----并发

Ø    监控，日志是否添加完整----监控日志

3.  补充

Ø    判断前期准备的case是否有遗漏----补充checklist

Ø    系统实现是否合理，业务逻辑是否完整闭合----系统设计

Ø    代码修改的影响面是否在评估范围内----工作量评估

4.  规范

Ø    前端代码规范

Ø    监控相关规范

ü  通常在关键业务节点上添加，业务被请求的次数，处理时长，任务成功/失败监控等

ü  调用外部接口，请求外部接口的次数，时长，成功/失败监控----快速定位问题

ü  确保监控名称和后台配置一致

Ø    日志相关规范

ü  业务日志:需要考虑性能相关问题

ü  异常日志: 需要在diff过程明确catch住可能存在异常的部分

ü  日志输出符合易读的原则，不使用system.out输出，尽量不使用中文

Ø    NULL异常:日志输出要判断变量是否可能为空，敏感信息

5.  代码层面

Ø    接口改了

ü  Dubbo接口还是Http接口

ü  返回值修改了需要回归哪些测试点

ü  接口参数修改了需要回归哪些测试点

Ø    调用新的接口

ü  同步还是异步

ü  是否添加了异常处理

ü  是否需要重试

Ø     for，while循环，递归算法，要检查好退出条件

ü  避免死循环

Ø     if条件，结合业务逻辑判断，注意if-else使用

Ø     多线程

ü  线程是否安全

ü  是否需要加锁

ü  加锁后是否及时释放

Ø     方法中参数为空时如何处理?是否会发生空指针异常

Ø     复制了一段代码

ü  逻辑是否满足本次需求

ü  参数是否需要重新处理

Ø     枚举新增字段

ü  是否将所有的调用方都考虑到了，是否可回滚(一般先升级枚举值，再发布业务实现)

 6.  数据库——sql

Ø     sql规范

 7.  发布前diff

Ø     配置文件是否按照生产环境的要求修改正常(黑白名单)

Ø     beta配置是否使用了线上地址?线上配置是否使用了beta地址

Ø     mq是否申请，config是否需要配置，sql是否需要执行，权限是否已经配置

Ø     是否存在开发默默搭车的代码

Ø     发布的依赖包是否包含snapshot

Ø     文件类型的发布是否与线上最新版本diff通过

Ø     web.xml中如果配置了过滤，需要保证静态文件，jsp，healthcheck.html能正常访问，不被拦截