测试是否有必要看开发代码(如何能看懂?)

说出来你可能不信,上一秒我还在赛道刷圈速,下一秒就想到了这个话题...
测试是否有必要看开发代码(如何能看懂?)
文章图片

其实这个话题在我待整理列表里躺了挺久的,今天恰好周六,那就静下来谈谈我个人的一些感受。
就以题目里的 2 个问题进行展开吧。
一、是否有必要看开发代码?
对于这个问题,我觉得回答“必要”或者“不必要”都会不太恰当,具体因人而异。
觉得“不必要”

  • 对于测试工程师的日常工作,我只要弄得清业务逻辑,通过各种方法论以及测试工具的辅助,一样可以完成需求的测试上。
  • 另外,很多时间点都点不过来了,哪有时间去看开发代码呀?
  • 再说了,我要是会看代码,那直接去做开发好了。
这是我曾经看到或听到过的一些观点,有主观、也有客观的,对此我个人表示非常理解。
阅读开发代码,这事情其实不在我们常规定义和理解的本职工作范围内。而且,当工期紧,压力大,点都点不过来的时候,面对这些事情,就会更加心有余而力不足。
一心只想快点把用例执行完,回归完毕顺利上线,我自己有时候也是这个样子。
【测试是否有必要看开发代码(如何能看懂?)】还有,对于有些代码基础薄弱的童鞋,对代码会有一定的“恐惧感”,这就更正常了。人对未知事物的恐惧是与生俱来的,但是我们要去接触学习它,否则就陷入死循环了。
觉得“必要” 我个人是比较偏向于这个答案的,但是前提条件肯定还是得时间允许,当然这个时间也可能是挤出来的。这些我自己都有过经历,先来回顾一下。
有时间
最近参与了一个比较大的项目,负责其中部分模块的测试工作。对接的人,都是来自别的事业部的同事,我一个都不认识。
所幸现在还留有一定的测试点梳理时间,我于是申请了项目代码权限,拉取代码到本地,重点浏览了我要测试的接口相关代码。
因为要测试的接口中,很多底层处理涉及到另一份外部文档里的接口调用,但是我发现,存在好几个接口是没接入的。立马整理出来确认,明确是不接入的,也就是说我是不用测的。
但是这个事情在产品和开发提供出的文档里是没有说明的,这里就不去说谁的责任问题,或许是太忙忘记了,也都可以理解。
如果我不读代码,我对着文档写用例,必然把这几个也写进去了,大概率是要到评审用例时候才会发现。
没时间
领导有布置大家整理各自业务的文档,从系统交互、业务逻辑、场景构造、监控报警等方面,这个事情是有积极意义的,但是需要我们“合理”安排时间来做。
合理就是,不忙的时候工作时间整,忙的时候下班抽空整,大家都懂得。
我拿到一块不熟悉的业务,所幸这个业务逻辑不是很复杂,重点是接口逻辑的梳理。
首先肯定还是先把能搜集到的文档先浏览一遍,再去找开发问一些疑问点之类的。但是开发很忙(或者假装忙),如果不当面问,大概率回复得晚,咱也不能怪人家。
那我就要了项目权限,找到相关接口的代码,看下里面的是否存在一些特殊处理需要校验,是否有涉及到缓存,MQ 等。所幸这个开发的代码注释写的还比较详细,所以看起来比较轻松。
如果我不读代码,可能整理的进度大概率变慢,而且老是问开发,说不定人家会很烦。
但并不是说烦我就不问了,最好的办法是你可以抓住重点,高效的提问。
所以,我个人感觉去看开发代码还是受益多多的:
  • 尽早的发现一些不必要的问题,更精确的确定测试范围。
  • 可以更加了解开发的实现逻辑,有利于有的放矢,高效提问。
  • 知道开发本次改动的范围,有助于判断是否有其他不必要的改动(或者带上线的别的内容)。
  • 更精准的定位开发问题,有助于分析问题根因。
  • 倒逼自己学习更多的开发知识。
二、如何能看懂开发代码?
相信有不少童鞋也想去阅读开发代码,但是不知道该学习到什么程度才可以看得懂。
不要怕 首先我觉得是不要怕。
其实,对于很多常规的项目,抛开一些架构模式设计的话,要看懂后端代码逻辑其实并不难。
比如我测试的项目中就有使用 C# 语言写的,我之前看都没看过,但是没办法,网上了解了一点语法之后就硬着头皮看,配合开发注释大概也可以了解7788。
代码学到何种程度? 当然,如果是一门你不了解的语言,还是要进行一些基础知识的学习的,但是肯定不需要全面学习完之后才可以。
比如你写自动化用例用 python,而开发使用的是 java ,就觉得学习 java 是一个从0开始的事情。其实不然,各种编程语言除一些设计理念外,核心点不外乎就是那几个。
更何况像 python 和 java 都是面向对象的,它们有很多地方都比较接近,所以说,能看懂 python 代码,学习一下后也能看得懂 java 代码。
除了语言基础知识之外,再了解下开发框架相关知识(比如 spring),了解下分层和常规用法,基本上也就可以了。
有条件的,也可以自己参考开发的项目,自己按照分层来写个接口来进一步理解。
看代码的心得 要看代码,首先最重要是你得能找到目标代码。
最省事的方法是:问开发。
然后就是自己动手了。以我的经历来看,通常我肯定是有个关注的接口,我知道接口的路径名称,也大概知道开发的代码项目分层,基本上就可以找到接口入口了。
以之前java的测试平台项目为例,当我找到了入口,就可以进一步找到这个接口的 service 层,里面有更多的实现细节。
再通过 idea 工具的辅助,不断的跳转里面各种调用的方法,查看逻辑实现情况。
另外,我推荐使用 idea 的代码定位功能,可以帮助你了解项目的层级结构。
测试是否有必要看开发代码(如何能看懂?)
文章图片

但是也不是所有项目都是像上面这样简单,有些项目就有很多的子模块,每个子模块下面也有很多的代码;还有项目是 dubbo 服务,结构又不一样了。
这种情况我会使用 idea 的全局搜索,去查接口名称,基本上都可以搜到,最次也可以搜小排查范围。
测试是否有必要看开发代码(如何能看懂?)
文章图片

总结
说了这么多,最后总结下吧。
个人觉得有条件的(没条件的可以创造条件),还是尽量去尝试阅读开发的代码,从目前来看,除了需要你挤出一些时间也没啥别的毛病了。
更何况,你挤出的这点时间是有收获的,不是浪费时间。
至于代码要看到多细,那还是取决于你个人的目的了。总之,多学学没坏处。

    推荐阅读