引言

测试人员的业务流程理解程度直接影响测试用例的准确性和全面性。为了提高测试用例编写水平和测试效率，有两个关键方面需要注意。首先，通过仔细阅读需求文档并与产品经理进行充分沟通的方式可以达到这一目标。其次，通过进行代码审查来提高代码质量、减少错误，并对团队合作产生积极影响。在这篇文章中，笔者将分享一些关于使用 Go 语言编写项目和进行日常代码审查的方法和实践经验。

CodeReview 方法和工具

1、使用工具
goland：将代码 clone 到本地，可跟进代码逻辑和实现方式；同时还可设置断点、启动调试会话模式。
版本控制 git 插件：通过 git 插件，可全局查看开发针对需求的实现逻辑，以及后期每次修改代码的变动点。
postman：可通过工具模拟接口，向本地开启的服务发送请求，进行 debug，从而定位 bug。

2、切入点
通过 diff 代码方式，查看改动点，缩小测试范围。
通过接口方式，依据开发提供的接口文档，去跟进代码，来评估代码是否正确实现了所需的功能。
通过日志记录方式，可辅助故障排查，定位代码位置。

全局 CodeReview 实践

项目提测前，测试人员如有充分熟悉项目的时间，那我们就可以大致走读一下代码。一般情况下，笔者会优先对数据层进行比对分析。如

1.数据源的准确性：代码最终获取结果的数据表是否满足项目需求，以及数据的筛选条件甚至是排序都可重点关注。
那么如何去找到这些数据库表的位置？
做法：
①以笔者所测项目为例，找到接口定义如/list/account，定位到 account.go 类，分别跟进每个方法的调用，找到 dao 相关文件，即可发现调用的数据库表。一般表操作语句会有 where、limit、order by 语句等获取数据的条件。
②当分析完开发的代码，要与自己推断出的表及查询条件，进行对比和补充，并完善到测试用例，在用例评审时三方同时敲定、确认，避免重大错误的产生。
③如调用方法过多，可将调用关系罗列出来，避免造成跟进混乱。

2.数据存储的原子性和一致性：对于数据库的访问，是否开启事务，如成功则提交事务；如失败则回滚事务。保证操作的一致性。所以我们就需要了解事务相关，关键词：Rollback()、Commit()，代码参考如下：

案例：如订单审核功能，点击通过按钮，调用两张表的写入，一个是订单信息的表，一个是财务的表。
异常：如没有事务的引入，则订单表可能插入失败了，但是没有被回滚，仍然去进行插入财务表，财务插入成功，这就造成了订单表和财务表数据的不统一，而引发功能性 bug。

3.分支逻辑覆盖：我们可通过关键字如 if else、 case，for 等代码块，来分析判断逻辑是否合理、是否存在遗漏、是否冗余。功能逻辑的覆盖本来就要求测试人员对需求有全面、准确的了解，那么为了补足自身思想的局限性，我们就可以进行 codereview，分析并补全测试用例。

4.容易遗漏功能：尤其功能发生异常时需要发送报警邮件、打印日志功能，注意 err 的位置，是否有 sendMail、log 相关关键词。关注发送邮件方法，亦可快速查看出邮件包含的主题、内容等，也能判断出发送内容是否完整。

以上是新功能提测前，全局 codereview 的入手经验。

测试过程中，我们还可关注一些细节的处理。

1.如特殊字符、默认值、最值、空值等入库的处理，是否符合预期。关注对于参数是否调用 strings 内置包或者 unicode 内置包中的方法，进行了处理。
•对于'\t', '\n', '\v', '\f', '\r'的特殊字符
•对于收尾空格的处理
•对于连续空格的处理

2.如健壮性中异常处理问题，检查代码是否正确地处理了可能发生的错误和异常情况。确保代码不会因为错误而产生意外行为，此时多关注 error 和 defer 关键字，error 代码块中根据实际需求 return、doSomething() 等，defer 关键字确保资源有没有被正确释放。

3.如健壮性中变量踩踏问题，一般可以大致看一眼方法内是否存在相同变量名称的赋值语句，是 “:="还是"="。如有用":="赋值代码，可着重分析，其是否合理，笔者曾经遇到过一个不合理的赋值导致的 bug。

在上述示例中，需求本意是通过查询条件，取与全量数据的交集赋值给变量 validIDs。
但是由于红线部分②误使用 “:=” 赋值，那么一旦出了 if 的作用域，当前 validIDs 获取到的交集数据就失效了，造成在最下边③return 时，返回的实际上是①的值。
由此可见，当我们进行筛选后，返回的量并不是筛选后的，而是全量，从而引起功能逻辑错误。

善用代码 diff

何时可进行 diff 呢？

当需求为微小变更时，可优先使用 diff 策略，缩小测试范围。
•如修改列表的升降序排序，查看 db.order,DESC,ASC 等关键字；
•如新增一个枚举值类型，通过 diff 判断是否仅可测试新增内容；
•如针对某个产品线特殊操作，通过代码比对，是否仅仅取出了某个类型处理，仅回归个别类型即可。
当开发修改 bug 后，可优先使用 diff 策略。
如定位所改函数 getAccount()；使用全局搜索功能,ctrl+alt+F 输入方法；结果列表就是调用到本次修改的地方；那么再针对每个调用一一定位，反推代码是在哪个功能调用。以此来圈定回归范围，提升测试信心。

CodeReview 收益

•对于历史久远的已上线需求，没有明确的文档和负责人，此时 codereview 就起到作用了，当梳理完代码后，对于功能的认知更能加深一步。
•测试范围更加明确，以前对于修改代码后，需要回归的地方完全依赖于开发，那么现在可以自己根据调用关系来圈定范围，和开发互相补位。
•有效提升项目完成效率，测试过程中发现 bug，可走读代码大致定位原因，将详细的复现步骤与错误代码位置相结合，提高开发修复 bug 的效率，也减少了给开发复现 bug 的时间，从而正向推送项目的进行。

总结

以上就是笔者在实际项目中使用 CodeReview 的一些经验和体会，CodeReview 不仅能帮助我们更高质、高效完成项目测试任务，而且对自身的技术能力提升非常有帮助，强烈推荐在实际项目中多多使用。