什么是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进行精简。