codediff

什么是codediff?

所谓的codediff就是代码差异比较。在日常测试过程中，上线之前除了测试本次版本上线的内容，还需要对其他历史已上线内容进行全部回归测试，随着项目的发展，需要回归的case越来越多，花费的时间也越来越多，为了明确回归case执行范围提高效率，也为了避免开发修改代码后未同步测试导致漏侧现象，新添加了一种补充测试的手段codediff。

为什么要做？

1、降低漏测率。开发提交代码未通知测试，导致未测试的内容直接上线，出现线上问题。

2、确定测试范围。开发开发新功能后，明确新功能的改动点，以及确定对历史功能的影响范围，降低无效测试发生率。

3、加深系统实现的理解。测试了解代码改动，代码逻辑，可以加深对系统实现的理解，提高发现bug的几率。

4、提出系统改进建议。代码改动可能引起其他问题，了解改动后，测试可以对改动提出改进意见，从而降低bug发生率，前提要求测试对于整个项目实现逻辑理解的深入。

什么时候做？

三个时间段

1、提测时。了解开发开发新功能代码改动（新增、删除、修改）范围，主要包含具体文件、包、类、方法的改动。

2、测试阶段。开发修改bug后，测试可根据提交记录，通过git 的diff功能，查看代码改动点。

3、合release后，上线前。明确此次release版本与线上版本的改动点，是否有加非此次release版本的其他功能和漏掉的功能，以及测试未覆盖的内容。

注意：因时间、人员等额外因素，1，2非必须，而3是每次发版前都需要进行的。

前期准备

1、采取会议形式，提前预定会议室，并通知参会人员。包含：版本各功能对应的测试人员、开发人员、版本测试负责人、版本开发负责人。

2、会议开始前，测试熟悉gitlab中的要上线版本的提交记录（commit list）。

3、记录疑问点，会议中一一解答。

diff步骤

1、选择对应的tag/release（代表线上代码）与本次要上线的分支.

2、查看本次要上线版本的提交记录（commit list）

3、主工程diff：根据包管理文件

iOS：podfile文件(pod命令，用于安装第三方框架，生成podfile.lock文件)、podfile.lock(最后一次更新Pods时,所有第三方框架的版本号)

安卓：build.gradle文件

获取所有依赖库、代码仓库列表、前端资源包。

4、功能代码diff：根据commit列表依次进行diff（线上包代码分支与本次上线分支；上次tag与本次tag号

5、逐行对改动内容进行对比，重点关注修改部分（如url, 方法修改），删除代码块，其他功能在复用的代码，版本号修改等。

技巧: 先看文件名称、类名、方法名，大概能知道功能点。
开发者模式，变量声明bean、model，图片资源文件、布局文件，xml，png等可以不考虑
6、鼓励：对任何有疑问的点进行提问讨论。避免不做任何思考的diff，这样不会有效果。

需要得出什么结论？

1、开发需要修改的代码列表。

2、确定测试回测范围。

3、对于业务的理解更深入。

总结（经验积累）

1、新功能代码可以不看

2、主要在修改bug的代码

3、提测单里开发写上提测注意点

4、会议完成后，对回归case进行精简。