1、上图来一张，Code Review翻译为：代码审查/代码评审
在金字塔中每一层测试的投入比例则要根据实际的产品特征来划分。在《Google 测试之道》一书中有提到，Google对产品测试类型划分为：小测试、中测试和大测试，釆用 70% (小）20% (中）/10% (大）的比例，大体对应测试金字塔中的Unit、Service和UI层。
1.1 单元自动化测试
单元自动化测试是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元是指一个函数， Java中单元是指一个类，图形化的软件中单元是指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。规范的进行单元测试需要借助单元测试框架，如Java 语言的 Junit、TestNG, C#语言的 NUnit,以及 Python 语言的 unittest、pytest 等，目前几乎所有的主流语言都有其相应的单元测试框架。
1.2 接口自动化测试
Web应用的接口自动化测试大体分为两类：模块接口测试和Web接口测试。
1）模块接口测试，主要测试模块之间的调用与返回。当然,我们也可以将其看作是单元测试的基础。它主要强调对一个类方法或函数的调用，并对返回结果的验证，所用到的测试工具与单元自动化测试相同。
2）Web接口测试又可分为两类：服务器接口测试和外部接口测试。
● 服务器接口测试：指测试浏览器与服务器的接口。我们知道Web开发一般分前端和后端，前端开发人员用HTML/CSS/JavaScript等技术，后端开发人员用PHP/Java/C#/Python/Ruby等各种语言。用户的操作是在前端页面上，需要后端提供服务器接口，前端通过调用这些接口来获得需要的数据，通过HTTP协议实现前后端的数据传递。
● 外部接口测试：指调用的接口由第三方系统提供。典型的例子就是第三方登录。
当然，接口测试也有相应的类库或工具，例如测试HTTP的有HttpUnit、Postman、soapUI等。
1.3 UI自动化测试
UI层是用户使用该产品的入口，所有功能都通过这一层提供并展示给用户，所以测试工作大多集中在这一层进行。为了减轻这一层的测试人力和时间成本，早期的自动化测试工具主要针对该层设计。目前主流的测试工具有UFT、Watir、RobotFramework、Selenium等。
2、什么样的项目适合自动化测试
1）软件需求变动不频繁
2）项目周期较长
3）自动化测试脚本可重复使用
3、自动化测试及工具简述
1） UFT
UFT(Unified Functional Testing)由QTP(QuickTest Professional software)与ST(Service Test)合并而来，由HP公司开发。它是一个企业级的自动测试工具，提供了强大易用的录制回放功能，同时兼容对象识别模式与图像识别模式两种识别方式，支持B/S与C/S两种架构的软件测试，是目前主流的自动化测试工具。
2 ) Robot Framework
Robot Framework是一款基于Python语言编写的自动化测试框架，具备良好的可扩展性，支持关键字驱动，可以同时测试多种类型的客户端或者接口，可以进行分布式测试。
3) Watir
Watir (Web Application Testing in Ruby)是一个基于Web模式的自动化功能测试工具。Watir是一个Ruby语言库，使用Ruby语言进行脚本开发。
4）Selenium
Selenium也是一个用于Web应用程序测试的工具，支持多平台、多浏览器、多语言去实现自动化测试。貝前在Web自动化领域应用越来越广泛。
4、自动化测试模型
自动化測试库、框架和工具之间的区别。
库的英文单词叫Library，库是由代码集合成的一个产品，供程序员调用。面向对象的代码组织形成的库叫类库，面向过程的代码组织形成的库叫函数库。所以从这个角度来看， WebDriver就属于库的范畴，因为它提供了一组操作Web页面的类与方法，所以，我们可以称它为Web自动化测试库。
框架的英文单词叫Framework，框架是为解决一个或一类问题而开发的产品，用户一般只需要使用框架提供的类或函数，即可实现全部功能。所以从这个角度来理解unittest 框架，它主要用于实现测试用例的组织和执行，以及测试结果的生成。因为它的主要任务就是帮助我们完成测试工作，所以我们通常把它叫做单元测试框架。
工具的英文单词叫Tools，在笔者看来工具与框架所做的事情类似，只是工具会有更高的抽象，屏蔽了底层的代码，一般会提供单独的操作界面供用户操作，例如，Selenium lDE 和QTP就是自动化测试工具。
回到自动化测试模型的概念上，自动化测试模型可以看作自动化测试框架与工具设计的思想。随着自动化测试技术的发展，演化为以下几种模型：线性测试、模块化驱动测试、数据驱动测试和关键字驱动测试。
4.1）线性测试
通过录制或编写对应用程序的操作步骤产生相应的线性脚本，每个测试脚本相对独立，且不产生其他依赖与调用，这也是早期自动化测试的一种形式：它们其实就是单纯的来模拟用户完整的操作场景。
这种模型的优势就是每一个脚本都是完整且独立的。所以，任何一个测试用例脚本拿出来都可以单独执行。当然，缺点也相当明显：
1）开发成本很高，测试用例之间可能会存在重复的操作，需要为每一个用例去录制或编写这些重复的操作。
2）维护成本很高，正是因为测试用例之间存着重复的操作，所以当这些重复的操作发生改变时，就需要逐一地对它们进行修改。
4.2）模块化驱动测试
借鉴了编程语言中模块化的思想，把重复的操作独立成公共模块，当用例执行过程中需要用到这一模块操作时则被调用，这样就最大限度地消除了重复，从而提高测试用例的可维护性。
模块化的结构很好地解决了线性结构的两个问题：
1）提高了开发效率，不用重复编写相同的操作脚本。假如，己经写好一个登录模块，后续测试用例在需要登录的地方调用即可。
2）简化了维护的复杂性，假如登录按钮的定位发生了变化，那么只需修改登录模块的脚本即可，对于所有调用登录模块的测试脚本来说不需要做任何修改。
4.3）数据驱动测试
数据驱动说的直白点就是数据的参数化，因为输入数据的不同从而引起输出结果的不同。
不管我们读取的是定义的数组、字典，或者是外部文件（excel、csv、txt、xml等）， 都可以看作是数据驱动，它的目的就是实现数据与脚本的分离。
这样做的好处同样显而易见，它进一步增强了脚本的复用性。同样以登录为例，首先是重新设计登录模块，使其可以接收不同的数据，把接收到的数据作为登录操作的一部分。 这样就可以很好地适应相同操作、不同数据的情况。当指定登录用户是“张三”时，那么登录之后的结果就是“欢迎张三”：当指定登录用户是“李四”时，登录结果就显示“欢迎李四”。这就是数据驱动所希望达到的目的。
4.4）关键字驱动测试
通过关键字的改变引起测试结果的改变。
目前市面上典型关键字驱动工具以QTP、Robot Framework (RIDE)工具、Selenium IDE为主。这类工具封装了底层的代码，提供给用户独立的图形界面，以“填表格”的形式免除测试人员对写代码的恐惧，从而降低脚本的编写难度，我们只需使用工具所提供的关键字以“过程式”的方式来编用例即可。
关键字驱动测试方法，也叫表格驱动测试方法，是软件自动化测试的一种方法。关键字驱动测试把测试脚本的编程工作分离出去，使得编程经验不足的人也能开发自动化测试脚本。关键字驱动测试让测试脚本的维护工作量减少，即使程序发生很大的改变，也只需要简单的更新和维护即可。
备注：通过它们之间的特点对比也可清晰地认识到，自动化测试不能完全地替代手工测试，自动化测试的目的仅仅在于让测试人员从烦琐重复的测试过程中解脱出来，把更多的时间和精力放到更有价值的测试中，例如探索性测试。
而自动化测试更多的是用来进行冒烟测试和回归测试。