软件测试26-深入浅出之静态测试方法

在分享《不破不立:掌握代码级测试的基本理念与方法》这个主题时,系统地介绍了代码级测试常见的五种错误类型(包括语法特征错误、边界行为特征错误、经验特征错误、算法错误,以及部分算法错误),以及对应的四大类测试方法(包括人工静态方法、自动静态方法、人工动态方法,以及自动动态方法)。

今天,我将和你详细讨论人工静态测试方法和自动静态测试方法,来帮你理解研发流程上是如何保证代码质量的,以及如何搭建自己的自动静态代码扫描方案,并且应用到项目的日常开发工作中去。

人工静态方法本质上属于流程上的实践,实际能够发现问题的数量很大程度依赖于个人的能力,所以从技术上来讲这部分内容可以讨论的点并不多。但是,这种方法已经在目前的企业级测试项目中被广泛地应用了,所以我们还是需要理解这其中的流程,才能更好地参与到人工静态测试中。

而自动静态方法,可以通过自动化的手段,以很低的成本发现并报告各种潜在的代码质量问题,目前已经被很多企业和项目广泛采用,并且已经集成到 CI/CD 流水线了。作为测试工程师,我们需要完成代码静态扫描环境的搭建。接下来我会重点和你分享这一部分内容。

人工静态方法

通过我上一次的分析,我们知道了人工静态方法检查代码错误,主要有代码走查、结对编程,以及同行评审这三种手段。那么我们接下来就看一下这三种方法是如何执行的。

  • 代码走查(Code Review),是由开发人员检查自己的代码,尽可能多地发现各类潜在错误。但是,由于个人能力的差异,以及开发人员的“思维惯性”,很多错误并不能在这个阶段被及时发现。
  • 结对编程(Pair Programming),是一种敏捷软件开发的方法,一般是由两个开发人员结成对子在一台计算机上共同完成开发任务。其中,一个开发人员实现代码,通过被称为“驾驶员”;另一个开发人员审查输入的每一行代码,通常被称为“观察员”。
    当“观察员”对代码有任何疑问时,会立即要求“驾驶员”给出解释。解释过程中,“驾驶员”会意识到问题所在,进而修正代码设计和实现。
    实际执行过程中,这两个开发人员的角色会定期更换。
  • 同行评审(Peer Review),是指把代码递交到代码仓库,或者合并代码分支(Branch)到主干(Master)前,需要和你同技术级别或者更高技术级别的一个或多个同事对你的代码进行评审,只有通过所有评审后,你的代码才会被真正递交。
    如果你所在的项目使用 GitHub 管理代码,并采用 GitFlow 的分支管理策略,那么在递交代码或者分支合并时,需要先递交 Pull Request(PR),只有这个 PR 经过了所有评审者的审核,才能被合并。这也是同行评审的具体实践。目前,只要你采用 GitFlow 的分支管理策略,基本都会采用这个方式。

对于以上三种方式,<

  • 21
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

程序员zhi路

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值