code diff在项目哪个环节合适

在讨论code diff（这里code diff是指开发与QA两方一起执行的）在项目哪个环节合适之前，先说明项目流程包括几个环节，大部分公司的项目流程包括以下环节：

• 需求评审（有的公司在需求评审前有需求 idea FR，需求评审完会有需求FR）
• 技术设计评审
• 开发阶段（在开发阶段QA会提供测试用例，指定开发自测的测试用例-冒烟用例）
• 提测
• 测试阶段
• 产品 验收阶段
• 发布
• 线上验证

code diff哪个环节更合适呢？提测后开始测试前？测试阶段主流程case执行都通过时？测试完成50%？一轮case执行完成后？测试完成100%产品验收阶段？接下来分析每个阶段的优缺点：

一提测后开始测试前 code diff

优点：一句话概况梳理出系统结构数据流转提前发现问题

• 能够提前梳理出系统的依赖关系，验证开发提供的发布步骤是否正确；
• 如有搭车修改的代码（分本次需求相关的功能）可以提前发现，及时调整测试计划；
• 梳理出本次功能的数据流，数据来自哪里，有增删改的操作能够清楚对应数据存储到哪里；
• 如果开发的leader参与code diff，这环节会提前发现代码设计问题，代码上有可能会做大优化，避免在测试后期QA回归测试的工作量大；
• 提前发现实现功能与产品需求不一致的问题
• 明确对应代码模块对应的功能，测试过程中发现问题能够快速排出是代码问题还是环境问题还是测试方法错误

缺点：

• 比较早的code diff，由于对应功能未测试，在diff时功能细节有可能注意不到；
• 假设一次diff后代码改动大，二次 diff的工作量会比较大，测试阶段在code diff环节占用时间会比较长；
• 一次code diff后出现主流程case不通，阻断测试，此时QA的工作有可能处于暂停状态，项目测试周期有可能拉长

二测试阶段主流程case执行都通过时（推荐）

优点：

• 已确保主功能正常，避免出现阻断，QA暂停测试的情况；
• 能够提前梳理出系统的依赖关系，验证开发提供的发布步骤是否正确；
• 如有搭车修改的代码（分本次需求相关的功能）可以提前发现，及时调整测试计划；
• 如果开发的leader参与code diff，这环节会提前发现代码设计问题，代码上有可能会做大优化，避免在测试后期QA回归测试的工作量大；
• 提前发现功能细节与产品需求不一致的问题
• 明确对应代码模块对应的功能，测试过程中发现问题能够快速排出是代码问题还是环境问题还是测试方法错误

缺点：

• 假设一次diff后代码出现设计上重构情况，二次diff 要花费的时间相对多

三测试完成50%

优点：

• 对需求的一些细节了解清楚，能够清楚功能对应的代码，diff相对会快些

缺点：

• 如果本次设计上有问题需要重构的话，如果对应代码模块正好是已执行的50%case，对应case需要回归，执行测试用例时间比预期长

四一轮case执行完成（依情况推荐）

如果测试确定需要二轮测试，还是比较推荐一轮case执行完成后code diff

优点：

• 一轮测试完成后，对所有功能已经很熟悉，在diff中能够依据功能匹配对应代码模块，思路清晰，容易发现遗漏的测试点
• 由于功能上很熟悉了，大部分问题已修复，有些代码容易出问题的场景已通过case验证通过，code diff可以较少关注实现逻辑是否正确，多关注是否有漏测点，code diff会更快一些

缺点：

• 如果本次设计上有问题需要重构的话，对应case需要回归，有重复工作，执行测试用例时间比预期长

五测试完成100%产品验收阶段

个人不太推荐，项目delay风险相对大些

缺点：

• 项目最后时间比较紧张的话，code diff的效果不太理想
• code diff发现大的问题，修复代码及测试回归需要时间
• 将风险放到了最后，由于时间紧张，应该要做优化的点，推迟优化

以上是个人的工作经验积累，请多多留言互相交流