自动化测试简介

1. 基础概念

1.1. 百度百科的概念

首先我们来了解一下“自动化”的概念，来源于百度百科：

• 自动化（Automation）是指机器设备、系统或过程（生产、管理过程）在没有人或较少人的直接参与下，按照人的要求，经过自动检测、信息处理、分析判断、操纵控制，实现预期的目标的过程。自动化技术广泛用于工业、农业、军事、科学研究、交通运输、商业、医疗、服务和家庭等方面。采用自动化技术不仅可以把人从繁重的体力劳动、部分脑力劳动以及恶劣、危险的工作环境中解放出来，而且能扩展人的器官功能，极大地提高劳动生产率，增强人类认识世界和改造世界的能力。因此，自动化是工业、农业、国防和科学技术现代化的重要条件和显著标志。

再来了解一下“自动化测试”的概念，来源于百度百科：

• 自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。

1.2. 个人的理解

从百度百科得来的关于“自动化”和“自动化测试”的概念，以及结合我日常工作的性质，个人认为自动化测试应该从广义和狭义两方面去区分一下。

• 自动化测试（Automated Testing）：这个层面属于广义的理解，就是说测试工作或者流程整体是都是自动化完成，机器不仅代替测试人员的体力劳动，也负责整体测试工作的协调、管理、控制和优化，自动化涉及测试工作的生命周期全过程。（如目前流行的devops，整个过程定义好就可以完成测试代码更新、编译、打包、发布、执行测试、生成测试报告并发送邮件等，这个过程完全不需要人为介入，可以算作是自动化测试）。
• 测试自动化（Test Automation ）:这个层面属于狭义的理解，范围相对要狭小一些，指使用特定的软件工具（测试工具）来控制测试的执行以及将实际结果与预测结果进行比较，能够自动执行一些重复但必要的任务，其实就是用机器代替测试人员的手工操作步骤的过程。通常大家说的自动化测试应该都是指“测试自动化”。关于“Test automation”可以参考一下维基百科的词条连接：https://en.wikipedia.org/wiki/Test_automation

当然上面都是对文字意义上的理解，实际上为了完成测试自动化，还需要完成其他协同的相关工作内容，包括自动化团队的建设、工具的选择与使用等等。

2. 分层的自动化测试

测试金字塔（Test Pyramid）：其实分层的自动化测试就是指测试金字塔。

迈克科恩在2009年《 Succeeding with Agile 》中对此进行了描述，并称为“测试自动化金字塔”。最早是一个包含UI/Service/Unit三层的金字塔，后来Lisa Cripin在《agile testing》中给塔加了一个手工测试的帽子，后来随着敏捷测试的推进，帽子部分转变为探索式测试。马丁福乐在2012年也在他的博客中对测试金字塔进行了描述，主要是增加了对成本和速度箭头的想法。还有 Alister Scott提出的测试金字塔。

迈克科恩的测试金字塔:

Lisa Cripin的测试自金字塔：

马丁福乐的测试金字塔：

Alister Scott的测试金字塔：

这些形形色色的测试金字塔，都是传统的自动化测试金字塔模型，都是很棒的视觉隐喻，可以让人思考不同层次的测试，还会告诉我们在每个测试层要做多少测试。大体上这些测试层分为UI Tests(e2e Tests)、Serveice Tests（API/Integration/Component Tests）、Unit Tests、Exploratory Testing。

注：下面部分内容借鉴齐涛道长
分层自动化测试倡导的是从黑盒（UI）单层到黑白盒多层的自动化测试体系，从全面黑盒自动化测试到对系统的不同层次进行自动化测试，也揭示了我们对于自动化测试在每个层面的应该投入的情况，如下图：

Unit层（单元自动化测试），测试金字塔最底层，投入与产出都是最大的层级，主要有单元测试、代码审查等可以实现自动化。这个层级的东西应该是开发人员做的事情。

• 单元测试是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数、Java中单元指一个类、图形化的软件中单元可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块单元。规范的进行单元测试就需要借助单元测试框架，如Java语言的Junit、TestNG，C#语言的Nunit。
• Code Review 中文翻译为代码评审或代码审查，是指在软件开发过程中，通过对源代码进行系统性检查的过程。通常的目的是查找系统缺陷，保证软件总体质量和提高开发者自身水平。与Code Review相关的插件与工具有很多，例如Java语言中基于Eclipse的Review Clipse和Jupiter、findbugs等。

Service层（可以叫做集成测试也有叫接口自动化测试的），测试金字塔居中的位置，投入与产出居中的价值位置。由于所有的应用程序都存在于其他部件（与其他应用程序的网络调用、数据库、文件系统）集成在一起，集成测试就是测试应用程序与应用程序内外的所有部分的集成内容。也可以理解为接口测试，对于接口测试分为：
模块接口测试，主要测试模块之间的调用与返回。也可以将其看作是单元测试的基础。它主要强调对一个类方法或函数的调用，并对返回结果的验证，所用到的测试工具与单元测试相同。
Web接口测试又可分为两类：服务器接口测试和外部接口测试。

• 服务器接口测试：指测试浏览器与服务器的接口。Web开发一般分前端和后端，前端开发人员用HTML/CSS/JavaScript等技术,后端开发人员用PHP/Java/C#/Python/Ruby等各种语言。用户的操作是在前端页面上，需要后端提供服务器接口，把前端通过调用这些接口来获得需要的数据，通过HTTP协议来实现前后端的数据传递。
• 外部接口测试：指调用的接口由第三方系统提供。典型的例子就是第三方登录，例如新上线的产品为了免于新用户注册账号的麻烦会提供第三方登录，那么用户在登录的时候调用的就是第三方登录的接口，用户登录信息的验证由第三方完成，并返回给当前系统是否验证通过。

UI层（E2E Tests）,处于测试金字塔的塔尖，相对来说投入产出比最小。
UI层是用户使用该产品的入口，所有功能都通过这一层提供并展示给用户，所以大多测试工作都集中在这一层进行。为了减轻这一层的测试人力和时间成本，早期的自动化测试工具主要针对该层设计。
除了UI层所展示的功能外，前端代码同样需要进行测试。在前端开发中最主要的莫过于JavaScript脚本语言。测试金字塔映射了不同测试阶段所投入的自动化测试的比例，UI层被放到了塔尖，这也说明UI层应该投入较少的自动化比例。如果系统只关注UI层的自动化测试并不是一种明智的做法，因为其很难从本质上保证产品的质量。如果妄图实现全面的UI层的自动化测试，那么需要投入大量的人力和时间，然而，最终获得的收益可能远低于所投入的成本。因为对于一个系统来讲，越接近用户其越容易变化，为了不断适应这种变化就必然需要投入更多的成本。既然UI层的自动化测试这么劳民伤财，那么我们是不是只做单元测试与接口测试就可以了呢？答案是否定的，因为不管什么样的产品，最终呈现给用户的是UI层的功能，所以产品才需要招聘大量的测试人员进行UI层的功能测试。

在《Google 测试之道》一书中提到，Google对产品测试类型划分为：小测试、中测试和大测试，采用70%（小）/20%（中）/10%（大）的比例，大体对应测试金子塔中的Unit、Service和UI层。在进行自动化测试中最担心的是变化，因为变化会直接导致测试用例的运行失败，所以需要对自动化脚本进行不断调整。如何控制失败，降低维护成本是对自动化测试工具及人员能力的挑战。反过来讲，一份永远都运行通过的自动化测试用例已经失去了它存在的价值。

对于测试金字塔，还有一个帽子是探索性测试。
探索性测试是一种手动测试方法，强调测试人员的自由和创造力，使用破坏性的思维方式，想出办法在被测对象中引发问题和错误，以便在测试对象中发现质量问题。
就算对于测试金字塔UI、service、unit所有层的自动化都做的极致，由于自动化用例设计或可用性等也不能保证所有某些边缘情景都考虑，发现所有问题也是不可能的事情。所以依然需要有经验的手工测试去补充。让机器做最擅长的重复性工作，让测试人员做一些有挑战的有意义的探索性测试。

分析测试金字塔，讲的都是理论上的内容，实际的自动化测试实践，大多数情况都变成了倒着的测试金字塔，UI层成了我们投入最多的地方，依次是service层和unit层。