qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

软件测试金字塔

软件测试金字塔

 在敏捷方法中,持续集成是其基石,持续集成的核心是自动化测试。下面这篇关于测试金字塔的文章,来自大师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)来测试,而不仅仅是底层的单元测试。

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

posted on 2012-12-19 12:31 顺其自然EVO 阅读(433) 评论(0)  编辑  收藏 所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。


网站导航:
 
<2012年12月>
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜