根据其实现是否以来于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分离，是否易于进行接口测试等。一旦错过这个阶段，到了产品的中后期，就很难为了测试再修改产品代码。