本文共 1789 字,大约阅读时间需要 5 分钟。
在本系列关于Visual Studio 2010测试功能介绍中,花了很多的篇幅介绍了其新功能(以下简称CUIT),也欣喜地看到很多朋友对CUIT非常感兴趣。但是前一段时间,在一个邮件讨论组,有个朋友提出了这样一个问题:他的应用程序有上百个表单,用来显示和操作从数据源读取的不同信息,他希望能够用CUIT来实现对这个应用程序的自动化测试。听起来似乎是合情理的,但仔细推敲一下有点儿问题 : 这上百个表单都要用CUIT这样的基于UI的测试用例覆盖吗? 没有单元测试等非UI的测试用例吗? 得到的回答是:是,没有!我......晕倒……
上面这个小插曲反映了实际工程中对UI自动化的过度执着和过度使用(over-use)的一种情况,自动化测试的实质是为了快速、高效地发现和预防回归缺陷,它不是为了发现新缺陷的(Test Monkey那样的自动化工具除外)。请记住:自动化测试(特别是基于UI的自动化测试)不是万能的,也不是测试的全部,更不是没有成本的。我们知道除了微软的CUIT,在业界还有像QTP等基于UI的自动化测试用例开发库和框架。但是需要澄清的一点的是,软件测试用例是多种类型测试用例的组合,各种类型测试用例的实现和分布应该是一个金字塔结构(pyramid),如下图所示。按照由塔基到塔顶顺序,依次为 :单元测试、集成测试、功能测试和用场景测试(确认测试)。
根据其实现是否依赖于UI界面,也可以把它们分为:非UI测试和UI测试。一般情况下,只有用户场景测试和一部分集成测试用例采用基于UI的实现,而大量的单元测试、集成测试以及大部分功能测试都是采用没有UI的测试实现。为什么要这样呢?原因是:成本。这个成本包括:用例实现成本、执行成本、分析和维护成本。下图给出了一个更为清晰的说明,详细的对比了彼此之间的优劣势。其中的Feature Testing对于有UI界面的应用程序来说,我们就可以理解为UI测试。自动化测试往往是看起来很美、很酷、很高深,但其背后所需要的人员和时间的投入也是相当可观的,它需要持续的投入。“成本 vs 回报”永远是考虑否采用自动化测试、采用哪个级别自动化所需要最、最、最优先考虑的问题,基于UI的自动化测试尤为如此。个人认为:只有在你的项目具有一定的规模(功能点比较多),并且具有一定的延续性(会有多个版本、开发周期比较长)才需要自动化测试。
从本质上讲,非UI测试和UI测试,是互为补充的,根据其成本和特性的不同,在实际工程应用中也应该领会运用。其基本原则:非UI自动化测试用例为主,UI自动测试为必要的补充,考虑成本因素,UI自动测试可以被手动测试所取代。那么到底哪些情况下需要基于UI的自动化测试用例的,根据我的经验列出下面几种情况,供大家参考:
总结一下,UI自动化测试也好,非UI测试也好,我认为,作为一项技术本身,它们本身没有好与差之分,功/过完全取决于使用者是否因时、因项目合理地使用它们。作为一名热爱测试,热爱技术的工程师,时刻保持对各种技术客观和冷静的判断和评价,是体现你是否够 Professional 的重要评判标准之一。对技术再好一点儿,再耐心一点儿,你才会更有收获,呵呵! 关于设计测试用例的一些原则,请参见我的另一篇博文 - 《》。
转载地址:http://ywgki.baihongyu.com/