当我们谈论自动化测试

Cockburn在《敏捷软件开发》中提到“沟通的成功依赖于发送者和接收者有可以引用的共同体验”,因此当我们提到自动化测试时,就一定需要有共同的词汇表。首先,什么是自动化测试?

对一些人来说,一提到自动化测试,第一个闪过脑海的念头就是QTP、WebDriver等自动化测试工具,以及依据这些工具建立的针对功能或是UI的自动化测试测试脚本,但其实这些只是自动化测试中的一小部分而已,在我看来,所有“使用机器的能力”对测试进行部分或全部自动化的操作都应该被叫做“自动化测试”。无论是针对代码中的类或是方法建立的单元测试,还是针对产品建立的需要人工参与的diff的方式,都是自动化测试的具体方法。

对测试来说,自动化测试不是一个存在的目标,而仅仅是一种用以达成测试目标的手段。我们希望从自动化测试中得到什么?自动化测试覆盖率?自动化测试覆盖率是用来衡量自动化测试所占比例的一种手段,但这仍然不是我们在项目中开展自动化测试的目标。我们在项目中开展自动化测试,目标只能是“通过自动化测试提高测试或是产品的质量”。因此,在谈论自动化测试时,可以被称为目标的,只能是下面这几项:

(1)在保证相同的测试覆盖率的情况下,减少人力资源的投入;
(2)在相同人力资源投入的情况下,增加了测试覆盖率;
(3)让测试的执行向上游移动,帮助开发者更早的发现产品中的问题,从而降低修复成本。

有了目标,剩下来的就是怎么做的问题。“减少人力资源的投入”是一个最容易被直观理解的自动化测试目标,因此,不少团队的做法就是“用自动化测试替代手工测试”,将原先需要手工执行的测试用例变成UI自动化测试用例,改由自动化测试工具来执行脚本。不能说,这种方式没有效果,但由于自动化测试在识别缺陷方面的有效性远远低于手工测试(从UI测试的角度来说,一个非“预期”产生的缺陷很难被自动化测试发现,而手工测试则能轻松的发现这个缺陷),而且由于UI本身的变化性,要想达到和手工测试相同的覆盖率,单纯的UI自动化测试往往很难证明自己的投资回报。

“增加测试覆盖率”是自动化测试可以产生收益的另一个方面。容易想到的例子是性能测试和模糊测试(Fuzz testing)。依靠机器的能力,模拟大量用户的并发,以及依靠机器的能力,基于规则产生大量随机数据并发送给服务器,用于检测服务器可能的安全性问题,在这些领域,自动化测试能带来明显的收益。但,当我说到“增加测试覆盖率”时,我所想要谈论的不仅仅是性能测试或是模糊测试这一类的针对应用某个质量属性的验证。

2 weeks ago, this page was being read.

,

Subscribe to Comments