var _gaq = _gaq || []; _gaq.push(['_setAccount', 'UA-333696-1']); _gaq.push(['_trackPageview']); _gaq.push(['_trackPageLoadTime']); (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })();
  • 2007年10月25日

    【翻译】自动化测试对测试自动化

    分类:

    原作者:Markus Clermont

    原文链接

     

    在过去的二三年测试实践已经历了深度的变化。我们已经把我们的艺术转为工程学,引进过程模型,提出最佳实践,并开发了工具以支持我们的日常工作和使每位测试工程师更富成效。一些工具瞄准测试执行。它们的目的是自动化重复的步骤,测试员将采用它们通过系统用户界面行使职责以验证其功能。我相信你已经看到了诸如SeleniumWebDriverEggplant工具或其它专有解决方案,并且你学会了热爱它们。

     

    在负面,当我们使用这些工具时我们观察到问题:

    l  脚本化你的手工测试,这种方式比仅手工执行它们耗费更长的时间。

    l  用户界面是任一个系统中最不稳定的接口之一,因此我们开始自动化在开发阶段晚期。

    l  测试的维护需要耗费大量时间。

    l  测试变得单薄。

    l  测试中断由于不当理由。

     

    当然,我们能争辩说这些问题中没一个是特别糟,并且自动化的好处仍大于成本。这可能是真的。我们学会了接受其中的一些问题作为“自动化的代价”,但另一些由一些常识性解决方法满足:

    l  它耗费太长时间来自动化一个测试那么,让只自动化这些重要的还将在回归测试中一次又一次被执行的测试。

    l  执行也许是缓慢的,但它仍然快于手工测试。

    l  测试不能中断因不当理由当它们中断我们发现了一个bug

     

    在余下的文章中我想要总结一些当我尝试过攻克这些问题时我已有的经验,不是拐弯抹角地解决而是消除它们的起因。

     

    这些问题的大部分根源于事实即我们只是自动化手工测试。这样我们没考虑加入的计算能力、访问不同界面和更快速地执行,是否应该使我们改变我们测试系统的方式。

    考虑这样一个事实即系统对环境暴露不同的接口比如,用户界面,前后端之间的某个接口,某个数据存储接口,和跟其它系统的接口显然我们需要看每个接口并测试它。不仅如此,我们不仅要考虑每个接口还要避免在太多不同的地方测试该功能。

     

    请允许我介绍仓库管理系统的例子,它允许你增加项目到仓库,看当前的库存,并且移出项目。为了增加一个项目,一个直接的手工测试用例将是去“增加”对话框,输入一新项目数量1,然后去“显示”对话框验证它。要自动化该测试用例,你将通过用户界面准确实施所有步骤。

    大概我上面所列的大部分问题将适用。一种避免它们的方法首先将是找出这系统内部看起来怎样。

    l  有数据库吗?如有,验证不应针对用户界面而应对数据库。

    l  我们需要供应商接口吗?如要,又如何去看这个交互?

    l  通过一个API有同样的功能吗?如有,它将通过API来测试,而且用户界面只需被验证跟API的交互正确。

     

    这将可能产生较高数量的测试,它们中的一些正是“很小”在它们的资源需求而且执行远快于端到端的测试。应用这些简单的问题将让我们:

    l  写更多通过API的测试,比如,去覆盖更多的边界条件,

    l  在同一机器上执行多线程测试,给我们一个机会去觉察竞争条件,

    l  较早地启动测试系统,像我们测试每个接口当它变成“准稳态”时,

    l  让测试维护和调试更容易些,像测试中断更接近问题的本源,

    l  要求少量的机器资源,并仍执行在合理的时间。

     

    这里我不主张完全没有用户界面测试。用户界面仅是另一个接口,因此它也值得重视。但是我确实认为,当前我们大部分的测试工作正集中在界面上。普遍的看法,即用户界面最值得关注,因为它是用户看到的,是有缺陷的。即使一个完善的用户界面也不会令用户满足如果基本功能是坏的。

    我们也不应该放弃我们的端到端测试。它们有价值并且没有它们系统不能被考虑测试。再次,这个我们必须扪心自问的问题是充分的端到端测试和规模较小的集成测试之间的比例。

     

    不幸的是,没有免费的午餐。为了改变测试自动化的设计,我们也将需要改变我们的测试方法。成功的测试自动化需要:

    l  在开发周期早开始,

    l  考虑内部的系统结构,

    l  对开发员有一个反馈回路,来影响系统设计。

    这些点中的一些要求一个相当的变化在我们处理测试的方法上。它们能完成只要我们作为一个单独的团队与我们的开发员工作。非常重要的是这个团队里这是一个信息绝对自由的流动在不同角色之间。

     

    在以往的项目中我们能做到这点靠:

    l  在测试工程师和开发工程师间移除空间间隔。座在下张桌子上也许是最佳促进信息交换的方式,

    l  像开发员那样适用同样的工具和方法,

    l  参与到每日的发言和设计讨论中。


    这不仅有助于真正地早介入(有项目是测试开发跟开发同时开始),而且还是一个很好的方法给连续的反馈。其中一些在名单上的项目要求恰是开发方向的测试工程师,因为这样他们更容易被开发团队认可为同侪。

     

    总的来说,我指出了一个成功的自动化项目需要:

    l  考虑测试中的系统内部细节和暴露接口,

    l  对每个接口要有许多快速测试(包括用户界面)

    l  要有一套端对端的测试,

    l  同开发一同开始,

    l  克服传统开发和测试间的界限(空间的,组织的和过程界限),和

    l  使用跟开发团队同样的工具。

    分享到: