下午开完周例会，关于我们讨论的工作流程，我又细想了产生了以下想法：
1.开发提测
2.测试开始测试
3.开发代码review，修改代码，提交
4.测试不知道review范围模块，业务逻辑。虽然能看到git变更记录。这个变更记录依赖开发提交代码时的备注。测试需要分析备注，不理解时再找开发沟通，我个人觉得这个沟通成本比较高，反而降低了工作效率和质量。
5.我还是觉得代码review时把测试叫上，一方面review 会议能使开发与测试对业务实现达成共识。另一方面也能拓展知识面
6.对于测试人员来说，参与到code review中的好处又有哪些呢：
1. 可以更深入地理解开发实现，易于测试覆盖到一些非需求性的点；
2. 方便评估影响范围，有效提高测试效率，不会因为一个小改动而动全身，大范围的回归测试，实际上只是因为改了一行代码，只不过在多次被调用而已；或出现今天这种情况，已经测试通过的模块，review后又出现bug，导致测试通过的模块需要重新测试一遍。
7.关于review是否影响测试正常工作的问题：并不会，老大这边安排我优先保障支付项目的质量问题。其他项目优先级较低。如果支付项目出现严重bug这才是影响了测试的工作。
网友评论