文章作者：罗汉
文章来源：TesterHome论坛
作者简介：从事广告 SDK、广告服务端测试
现在很流行谈测试左移，按我个人浅显的理解，测试同学的工作越往开发同学靠，越能体现 “左” 的概念，这里强调的理念是测试与开发工作保持高度统一，他们不分你我，互相有足够的信任和共同的目标，并发挥他们各自的价值。
Code Review，是测试左移的手段之一，通过 Review 代码，提前发现软件的潜在风险。
1、角色定位
设置自己是开发团队的新人，找一个开发哥当自己的导师，新人就会看很多开发文档，包括新人指南、业务介绍、技术文章等。这个过程要求我们熟悉业务、熟悉开发工作模式和流程。
2、搭建开发环境
不管是客户端，服务端还是其他，都有开发对应的语言和代码编辑环境，如 AndroidStudio、IntelliJ IDEA、GoLand。
3、熟悉代码编辑工具
查看 Git Log、切换分支、模糊查找、查找方法，高阶一些是编译和调试。
4、熟悉语言的基础语法
这里说的熟悉，倒不是说熟悉到会写，我个人认为语法是帮助我们理清代码逻辑，关注代码整体是要做什么，有哪些可能的输入和输出、方法内部有哪些判断条件。这些了解基础的语法就能胜任。
5、熟悉编码/语言规范
通用的编码/语言规范，提高代码可读性、可理解性，同时，也能约束开发遵循规范。
1、Go 语言结构体定义错误
type AppPublisher struct {Name string `json:"name"`Pkgname string `json:"pkgname"`Version string `json:"pkgname"`}Go 语言定义的结构体，可能我们并不熟悉这里的语法，但即使这样，也不影响我们发现它的错误，即第四行应定义为 Version string
json:"version"，这么基础的定义为什么会犯错呢？这里可能跟开发编码的习惯有关，经常编码的人都知道，Command+D 复制当前行到下一行，所以这里猜测是复制了第三行代码到的第四行，导致忘记修改，其实这是开发经常出错的地方之一。
2、Java 随机函数取值范围
public void Solution(){int number = random.nextInt(0, 1)if(number == 1){...处理业务逻辑...}}单看代码没看出什么问题，可能我们之前也不熟悉随机函数的用法，为此我们去度娘一把，nextInt(int k) 生成范围在 [0, k)（不包含 X）内的任意正整数，上面代码的 number 永远取不到 1，意味着下面的判断永远进不去，所以可以改为 random.nextInt(0, 2)。
3、初始化问题
public static String getOAID() {if(TextUtils.empty(Core.OAID)){String oaid = OaidManager.getOaid();if(!TextUtils.empty(oaid)){UniBundle.putOAID(oaid)} else {Core.OAID = UniBundle.getOAID();}}return Core.OAID;}
看方法我们知道是要获取 oaid，但只要 OaidManager.getOaid() 有值，Core.OAID 永远都不会被赋值，正确的改法：
public static String getOAID() {if(TextUtils.empty(Core.OAID)){String oaid = OaidManager.getOaid();if(!TextUtils.empty(oaid)){UniBundle.putOAID(oaid)}Core.OAID = UniBundle.getOAID();}return Core.OAID;}
去掉 else，我们发现 Bug 往往在于多一行或少一行代码。
当然这样的案例有很多，以上是想告诉大家，Code Review 没有想象中这么困难，回到今日主题：我在 Review 代码，我在 Review 什么？
1、明确涉及的接口及内容
我们很多需求逻辑需依赖各种配置平台，客户端通过网络请求获取配置，我们在 Review 代码过程中明确涉及的接口和内容，便于自己在测试时可以 Mock 配置测试，这里的价值在于降低一定沟通成本。同时，也能指导产品做相应的配置。
2、明确涉及的数据/埋点上报
任何形式的数据/埋点上报，最为关键的是上报时机，其次才是上报内容。明确时机，明确内容。
3、明确代码影响范围
这是老生常谈的内容，不管是开发或测试都最为关注的，也是难点、重点。我们测试常常询问开发，做新功能测试或回归测试时希望开发能给出明确的影响范围。有时候复杂的业务逻辑模糊了我们的方向，导致评估不准，但这里强调的是，多一个从测试评估的视角，而不是任凭开发圈定，测试能从代码去关注影响的范围，指导我们测试设计或回归相应的用例去覆盖影响，又或者这是不该被影响的业务逻辑。
4、编码规范
编码规范也有一些内容，可以看看相关的技术文章。如命名规范、日志、代码格式等。
5、业务逻辑
业务逻辑是我们关注的重中之重，我们的业务都建立在产品需求上，理清业务逻辑，并考虑是否合理。理清业务逻辑目的是指导我们设计相应的测试用例，考虑是否合理目的是否符合需求设计、交互设计、用户体验等。
6、技术架构
给我们提出更高的要求，了解一些技术原理是必要的，透过现象看本质，才能明白数据走向、代码流程、框架流程等。
04 — 结束语 以上是我结合自身经历的总结，实际工作环境可能比我们想象的更加复杂，每一个公司都有一套工作体系，我们其实在过程中不断摸索和成长，任重而道远，探讨各种技术经验，摸索适合自己或公司的工作方式。
我发现在这个过程中学到了很多知识，增强了开发的信任，当你在业务上的经验越来越丰富，在需求评审或技术评审阶段，能提出一些产品建议或技术建议，我想这也是测试在业务赋能上做出一定的贡献吧。欢迎大家一起分享和交流~
TesterHome x MTSC
TesterHome社区（测试之家）是国内最大的测试开发技术社区之一。从2012年创立到现在，一直秉承务实、分享、高质量的理念，携手众多测试工程师致力于帮助新人成长，提高测试地位，推进质量发展。
▮TesterHome社区网址：https://testerhome.com/
中国互联网测试开发大会（Testing Summit China），由国内最大的测试开发技术社区之一TesterHome发起，始于 2015 年，已成功举办了九届。从最初的 300 多人到 2019 年的近 2000 人，MTSC 测试大会已经成功塑造了落地、务实、有深度的内容风格和良好口碑。
▮第十届MTSC大会官网：http://www.qacon.net/ 2022年9月4日-5日 | 深圳喜登路国际大酒店
-第十届MTSC大会已确定议题 - 另有70+议题复审中 公司名称
议题 | 演讲嘉宾
转转
全链路数据构造在转转的落地应用
许微卫
小米
Android自动化测试新利器-Testool
杨立凯
龙测科技
基于AI增强及模型驱动的UI功能自动化测试
师江帆
京东
智能测试实践之路 - UI异常检测与自动化
邹军
字节跳动
抖音精准客户端性能防劣化建设实践
毛乾康
知乎
Mobile PaaS 工程架构实践
陈康
知乎
研效提升的最佳实践
纪云凤、高志超
知乎
持续集成流水线的产品化思维
徐实
知乎
千万级日活产品的用户反馈系统建设
许剑东
知乎
知乎质量分度量体系建设
卢秋英
百度
AI技术在用例筛选与推荐领域的应用与实践
黄磊
字节跳动
EvoDroid移动端单元测试自动生成原理与实践
甘陈卿
美团
美团到店平台单元测试解决方案
陈永达、沈佳龙
↙↙ 阅读原文可查看作者的更多文章，并与ta在线交流
文章评论