测试金字塔

社区广播:运维派(Yunweipai.com)是国内最早成立的IT运维社区,欢迎大家投稿,让运维人不再孤寂的成长!

在敏捷方法中,持续集成是其基石,持续集成的核心是自动化测试。下面这篇关于测试金字塔的文章,来自大师Martin Fowler。

测试金字塔的概念来自Mike Cohn,在他的书Succeeding With Agile中有详细描述:测试金字塔最底层是单元测试,然后是业务逻辑测试,最后是端到端的测试(GUI或CLI)。

在我的职业生涯中,很多次听到过自动化测试,自动化测试意味着端到端的通过界面完成的测试。完成这种自动化测试的工具一般是录制然后回放,初始使用很容易,不需要任何编码技能。

不过你使用一段时间后就会遇到很多麻烦,GUI的自动化测试运行速度都很慢导致版本发布速度下降,同时完成自动化测试的软件,一般都是商业软件需要license因此只能在特定的机器上部署,且不容易通过脚本集成。

GUI测试用例还很脆弱,如对系统的一些修正可能导致很多用例的失败,这时候你需要重新录制。你可以放弃录制的方法来解决这个问题,通过写GUI测试代码,但是这样效率非常低。就算你已经很精通了GUI测试代码的编写,端到端的GUI测试用例也很容易出现不可预期结果的问题-一些用例成功一些用例失败,因此,基于GUI的自动化测试是脆弱、耗时(包括用例维护和执行)的。所以测试金字塔要表达的是:底层应当有更多的单元测试和接口测试和逻辑测试,GUI测试用例能覆盖到主业务流程即可。

我们注意到测试金字塔中间这一层:服务。业务服务的测试,我称其为皮下测试,因为这一层就在用户界面GUI下面。服务测试可以完成很多端到端的功能测试而不需要像GUI自动化测试那样需要使用复杂的框架。如一个Web应用,你可能使用自己写的脚本测试端到端的逻辑,而GUI自动化你可能会使用Selenium这个工具。

测试金字塔发源与敏捷测试实践,使用测试金字塔原则很容易将你项目中的测试用例达到平衡的状态。在很多项目中都混淆了“端到端测试”,“UI测试”,“面向用户的测试”的概念,其实他们都是测试的不同角度。例如你有一个javascript开发的应用,那UI部分就需要用javascript的单元测试工具Jasmine完成大部分的UI功能测试;复杂的业务逻辑需要使用面向用户的表单(form)来测试,而不仅仅是底层的单元测试。

因此我通常将上层的测试称为“测试的第二防线”,如果你的一个上层测试用例执行失败,表现出来不仅仅是这个功能有问题,还说明你遗漏了这个地方的单元测试,因此你在修复功能之后,还需要补充相关的单元测试用例。

源文章来自Martin Flower的blog

网友评论comments

发表评论

电子邮件地址不会被公开。 必填项已用*标注

暂无评论

Copyright © 2012-2017 YUNWEIPAI.COM - 运维派 - 粤ICP备14090526号-3
扫二维码
扫二维码
返回顶部