在一个团队中, 如果没有code review, 直接允许开发提交代码到版本库并部署环境, 那么在正式开始测试之前的代码走查就非常有必要了。
这里说的走查不是使用工具在持续化集成之前进行代码规范的检查, 而是根据PRD文档, 验证代码的实现是否符合需求描述。
在开始测试之前我都会先同步开发的代码, 然后询问开发人员具体有哪些接口涉及到本次功能提测, 之后从每个接口入手, 查看业务逻辑层与数据库访问层代码, 看其实现是否与需求相符, 并找出一些明显的错误。这样做的目的只有一个, 那就是节省时间。其实这些问题应该在开发提交代码前由code review发现的， 但是由于团队刚刚组建，没有形成一套合理的流程，而且时间非常有限。其实这些恶性bug都是可以在测试阶段发现的，而且是在冒烟测试阶段就能轻易发现，但是问题还是时间紧，不如先走查一遍代码，将错误处与开发沟通，之后提bug，将具体哪行哪个位置的问题标出，这样可以大大加快测试进展，起码可以快速使得测试通过冒烟阶段，节约一些时间。
下面就举几个栗子说明我在走查阶段发现的几个明显的问题：
首先看这段代码：
在数据库读取的时候查询的是UNSETTLED类型的账单，但查询结果直接赋值给了名为settledBills的引用，好吧，之后的代码就都是错的了。
再举个栗子：
这里调用了dubbo服务接口，对接另一个系统，传入的枚举UNSETTLE_BILL_REPAY，代表偿还未出账单的意思，但是这个代码是用来偿还已出账单的service层代码。。。
其实这种问题在我们项目的代码里发现的很多很多，在两个系统对接的时候，两方开发人员几乎不沟通，看哪个接口像就直接调用了，之后就都推给测试去测了，发现了问题再改，发现不了就呵呵了，不说了，都是泪。。。
总结一下，面对不靠谱、不沟通的开发，几乎没有管理的项目，一切靠测试手动发现问题实在是鸭梨山大啊。