二、分层的自动化测试
二、分层的自动化测试
我们应该有更多的低级别的单元测试，而不仅仅是通过用户界面运行的高层的端到端的测试。
传统的自动化测试我们可以理解为基于产品UI层的自动化测试，它是将黑盒功能测试转化为由程序或工具执行的一种自动化测试。
但是在目前的大多数研发组织当中，都存在开发与测试团队割裂（部门墙）、质量职责错配（测试主要对质量负责）的问题，在这种状态下，测试团队的一个“正常”反应就是试图在测试团队能够掌握的黑盒测试环节进行尽可能全面的覆盖，甚至是尽可能全面的 UI 自动化测试。
这可能会导致两个恶果：一是测试团队规模的急剧膨胀；二是所谓的全面UI自动化测试运动。因为UI是非常易变得，所以UI自动化测试维护成本相对高昂。
分层自动化测试倡导的是从黑盒（UI）单层到黑白盒多层的自动化测试体系，从全面黑盒自动化测试到对系统的不同层次进行自动化测试。
2.1 单元自动化测试
单元自动化测试是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判断其具体含义，如C语言中单元是指一个函数，Java中单元是指一个类，图形化的软件中单元是指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。规范的进行单元测试需要借助单元测试框架，如Java语言的Junit、TextNG，C#语言的NUnit，以及Python语言的unittest、pytest等，目前几乎所有的主流语言都有其相应的单元测试框架。
Code Review中文翻译为代码评审或diamante审查，是指在软件开发过程中，通过对源代码进行系统性检查的过程。通常的目的是查找系统缺陷、保证软件总体质量以及提高开发者自身水平。与Code Review 相关的插件和工具有很多，例如Java语言中基于Eclipse的ReviewClipse和Jupiter、主要针对Python语言的Review Board等。
2.2 接口自动化测试
Web应用的接口自动化测试大体分为两类：模块接口测试和Web接口测试。
2.2.1 模块接口测试
主要测试模块之间的调用与返回。当然，我们也可以将其看做是单元测试的基础。它主要强调对一个类方法或函数的调用，并对返回结果的验证，所用到的测试工具与单元自动化测试相同。
2.2.2 Web接口测试
Web接口测试又可以分为两类：服务器接口测试和外部接口测试。
• 服务器接口测试：指测试浏览器与服务器的接口。我们知道Web开发一般分前端和后端，前端开发人员用HTML/CSS/JavaScript等技术，后端开发人员用PHP/Java/C#/Python/Ruby等各种语言。用户的操作是在前端页面上，需要后端提供服务器接口，前端通过调用这些接口来获取需要的数据，通过HTTP协议实现前后端的数据传递。
• 外部接口测试：指调用的接口由第三方系统提供。典型的例子就是第三方登录，例如新上线的产品为了免于新用户注册账号的麻烦会提供第三方登录，纳闷用户在登录的时候调用的就是第三方登录的接口，用户登录信息的验证由第三方完成，并返回给当前系统是否验证通过。
当然，接口测试也有相应的类库或工具，例如测试HTTP的有HttpUnit、Postman等
2.3 UI自动化测试
UI层是用户使用该产品的入口，所有功能都通过这一层提供并展示给用户，所以测试工作大多集中在这一层进行。为了减轻这一层的测试人力和时间成本，早期的自动化测试工具主要针对该层设计。目前主流的测试工具有UFT、Watie、Robot Framework、Selenium等。
除UI层所展示的功能外，前端代码同样需要进行测试。在前端开发中最主要的莫过于JavaScript脚本语言，而QUnit就是针对JavaScript的一个强大的单元测试框架。
测试金字塔映射了不同测试阶段所投入的自动化测试的比例，UI层被放到了塔尖，这也说明UI层应该投入较少的自动化测试。如果系统只关注UI层的自动化测试并不是一种明智的做法，因为其很难从本质上保证产品的质量。如果妄图实现全面的UI层的自动化测试，那么需要投入大量的人力和时间，然而， 最终获得的收益可能远低于所投入的成本，因为对于一个系统来讲，越接近用户其越容易变化，为了适应这种变化就必须要投入更多的成本。
既然UI层的自动化测试这么劳民伤财，那么我们是不是只做单元测试与接口测试就可以了呢？答案是否定的，因为不管什么样的产品，最终呈现给用户的都是UI层的功能，所以产品才需要招聘大量的测试人员进行UI层的功能测试。也正是因为测试人员在UI层投入了大量的时间与精力，所以我们才有必要通过自动化的方式帮助测试人员解放部分重复的工作。所以，应该更多的提倡“半自动化”的开展测试工作，把可以自动化测试的工作交给工具或脚本完成，这样测试人员就可以把更多的精力放在更重要的测试工作上，例如探索性测试等。
至于在金字塔中每一层测试的投入比例则要根据实际的产品特征来划分。在《Google测试之道》一书中提到，Google对产品测试类型划分为：小测试、中测试和大测试，采用70%（小），20%（中）、10%（大）的比例，大体对应测试金字塔中的Unit、Service和 UI 层。
在进行自动化测试中最担心的是变化，因为变化会直接导致测试用例的运行失败，所以需要对自动化脚本进行不断调整。如何控制失败、降低维护成本是对自动化测试工具及人员能力的挑战。反过来讲，一份永远都运行通过的自动化测试用例已经失去了它存在的价值。