一、背景

现在很流行谈测试左移,按我个人浅显的理解,测试同学的工作越往开发同学靠,越能体现 “左” 的概念,这里强调的理念是测试与开发工作保持高度统一,他们不分你我,互相有足够的信任和共同的目标,并发挥他们各自的价值。
Code Review,是测试左移的手段之一,通过 Review 代码,提前发现软件的潜在风险。

二、Review 代码前的准备

Review 代码前做充分的准备,如何开展?(供参考)

1、角色定位

设置自己是开发团队的新人,找一个开发哥当自己的导师,新人就会看很多开发文档,包括新人指南、业务介绍、技术文章等。这个过程要求我们熟悉业务、熟悉开发工作模式和流程

2、搭建开发环境

不管是客户端,服务端还是其他,都有开发对应的语言和代码编辑环境,如 AndroidStudio、IntelliJ IDEA、GoLand

3、熟悉代码编辑工具

查看 Git Log、切换分支、模糊查找、查找方法,高阶一些是编译和调试

4、熟悉语言的基础语法

这里说的熟悉,倒不是说熟悉到会写,我个人认为语法是帮助我们理清代码逻辑,关注代码整体是要做什么,有哪些可能的输入和输出、方法内部有哪些判断条件。这些了解基础的语法就能胜任

5、熟悉编码/语言规范

通用的编码/语言规范,提高代码可读性、可理解性,同时,也能约束开发遵循规范

三、Review 代码,Review 什么?

前期的所有准备都是值得的,也许过了一周、二周,甚至一个月,就算过了几个月也没关系,测试同学在为业务赋能的道路上一天天在进步,下面我结合自身经验,通过一些实际碰到过的案例,跟大家一起 Review 代码,如下:

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)(不包含 k)内的任意正整数,上面代码的 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、技术架构

给我们提出更高的要求,了解一些技术原理是必要的,透过现象看本质,才能明白数据走向、代码流程、框架流程等

四、结束语

以上是我结合自身经历的总结,实际工作环境可能比我们想象的更加复杂,每一个公司都有一套工作体系,我们其实在过程中不断摸索和成长,任重而道远,探讨各种技术经验,摸索适合自己或公司的工作方式。
我发现在这个过程中学到了很多知识,增强了开发的信任,当你在业务上的经验越来越丰富,在需求评审或技术评审阶段,能提出一些产品建议或技术建议,我想这也是测试在业务赋能上做出一定的贡献吧。
欢迎大家一起分享和交流。


↙↙↙阅读原文可查看相关链接,并与作者交流