VS 2010 测试功能学习(19) - 什么情况下应该引入UI自动化测试？（转）

 在本系列关于Visual Studio 2010测试功能介绍中，花了很多的篇幅介绍了其新功能Coded UI Test（以下简称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的自动化测试用例的，根据我的经验列出下面几种情况，供大家参考：

1. 基本用户场景测试和验收确认(acceptance）测试用例。这类测试用例要求从真实用户的使用角度去测试产品的实现，只有包括了UI层才完整和验证了产品的真实用户体验。从实现的角度来看，这类用例应该是只覆盖最基本和核心的端到端的用户场景（End-to-End user scenario），对于敏捷开发，会在用户故事中描述用户使用的基本场景。一般不使用基于UI测试实现那些步骤复杂，或者边边角角(corner case)的测试用例。
2. 逻辑与用户界面绑定在的一起，无法绕过UI直接测试核心逻辑模块。这种情况也是不得已而为之，在实际工程中也最经常出现的，它反映了软件构架设计方面存在的问题，即没有很好的模块化、模块之间过度耦合。如果是一个全新的软件和功能，在项目初期，测试人员应该与开发人员/构架师仔细探讨一下可测试性(Testability)问题，特别是针对自动化测试的可测是性， 比如：逻辑与UI分离，是否易于进行接口测试等。一旦错过这个阶段，到了产品的中后期，就很难为了测试再修改产品代码。 

      总结一下，UI自动化测试也好，非UI测试也好，我认为，作为一项技术本身，它们本身没有好与差之分，功/过完全取决于使用者是否因时、因项目合理地使用它们。作为一名热爱测试，热爱技术的工程师，时刻保持对各种技术客观和冷静的判断和评价，是体现你是否够Profressional的重要评判标准之一。对技术再好一点儿，再耐心一点儿，你才会更有收获，呵呵。