一、测试金字塔介绍
测试金字塔最初的原型分三层，底层是单元测试，中间层是 API 测试，上层 是UI 自动化测试。而且底层的单元测试需要做最多的测试工作，越往上测试工作应该越少。根据《谷歌软件测试之道》的经验，三者对于精力投入的比例是：把 70%的精力放在单元测试，20%放在 API 测试，而剩下 10%的精力放在 UI 测试。
测试金字塔的这个理念和时下流行的“测试左移”的理念是一致的。测试左移（Shift Left Testing）是指要把质量保障的活动尽量前移到更早的开发生命周期中。这个理念和测试金字塔的思想是不谋而合的，也就是我们要把测试工作往前移（对应于测试金字塔是往下沉），要把单元测试、集成测试做得更加充分和完善。而上面的 UI 测试只需要针对关键业务进行自动化回归测试即可。
当然，我们知道如果只靠自动化测试是没办法完全保证系统的质量，有些地方还是需要人工的介入、需要人的思维判断才行，比如用户体验测试等。所以后来 Lisa 在金字塔的塔尖再补上了一片“云”，这片“云”就是人工探索式测试（Exploratory Test，简称 ET）。最终就形成了我们在图3右侧看到的样子。由于此模型形状像埃及的金字塔，所以被称之为测试“金字塔”模型。
二、分层自动化测试
除了测试金字塔外，我们经常还听到一个词叫“分层自动化测试”。在国外基本上很少提这个词，但是在国内却总是在不同的场合会听到。如果我们把测试金字塔顶尖上由 Lisa Crispin 补充的那块“云”（探索式测试）先去掉的话，那么分层自动化的内容和测试金字塔基本上是一回事，没有太大的区别。
分层自动化测试从“自动化”这个角度出发，说明了自动化需要按不同的层级来实施，不仅仅只是关注在 UI 层，也需要关注 API 接口层和单元层。UI 层的自动化测试这个理念在过去的二三十年一直处于主导地位，大多数的测试同行在实施自动化测试的时候一开始映入脑海的就是 UI 自动化测试，而且业界也提供了很多成熟的 UI 自动化测试工具，比如商业工具 QTP/UFT、开源工具 Selenium 等等。
但是正如上一节所述，随着 UI 自动化测试本身的痛点日益明显，其脆弱性和复杂性也让人怀疑 UI 自动化测试的投入产出是否合理，因此当 Mike Cohn 提出测试金字塔模型后，让人们改变了以前一直认为 UI 自动化测试为主导的意识，从最初我们所熟悉的 UI 自动化测试扩展到 API 层的自动化测试以及底层的自动化单元测试，使得自动化能够在不同层级的测试中都发挥其作用，降低了测试的脆弱性和复杂性，提升整个测试的效率，这就是我们说的分层自动化测试，如图4 所示：
三、测试自动化与自动化测试的区别
近年来，随着敏捷开发模式的流行，测试领域也在不断地发生变化。由于敏捷开发所谓“小步快跑”的方式迫使测试人员需要在更短的时间完成整个测试过程，而以前的纯手工测试应付这种“短平快”的开发节奏渐渐变得吃力起来，于是提升测试的速度和效率则变成了能否很好支撑敏捷开发的关键。而提升测试速度和效率，自动化就变得比以前任何时候更显得重要了。
当我们谈自动化的时候，经常会听到两个词：自动化测试和测试自动化。相信很多人都认为这两个概念说的是同一个意思。但是在我看来，这俩个概念却是有本质上的区别。那么到底什么是自动化测试？什么是测试自动化？所谓“自动化测试”，一般是指在测试执行过程中，通过自动化的工具或手段来代替人工执行的过程。它强调的是解决“测试执行过程”的效率；而“测试自动化”，是指在测试领域中的任何方面都可以通过各种自动化的方式和手段来加快测试的效率，保证测试的质量，缩短软件交付的周期。所以它强调的范围是整个测试的过程而不仅仅是测试执行过程。比如说测试数据准备的自动化、测试环境搭建的自动化都可以包含在测试自动化这个概念里面。从这个角度来说，测试自动化所包括的范围更广，而我们在项目中，更应该从自动化测试思维转变到测试自动化思维中，从整个测试生命周期 STLC（Software Testing LifeCycle）中去寻找可以自动化的点，全方位的提升测试的效率，这也是外国同行经常使用的一句话：Automate Everything！
四、测试自动化的目的
我们再来谈谈自动化的目的。测试自动化的目的，很多人第一反应就是加快测试的速度。诚然，加快测试速度是其中的一个目的。但是我认为，测试自动化最核心最重要的目的是保证软件的质量。大家知道我们在做测试时，无论是版本升级还是缺陷修复都需要大量的回归测试。而如果仅仅只是靠“人肉”战术，一方面测试人员要应付新功能的测试，另一方面又要进行缺陷的回归测试，往往这时候测试人员会把重点放在新功能上面，而回归测试就会因为时间紧被简化了。简化的后果就是原来应该被回归的范围缩小，从而导致有些缺陷被遗漏掉；另外因为人毕竟不是机器，在经过重复枯燥的点鼠标测试工作后，往往会有“审丑”疲劳，而软件的“丑”有时就被熟视无睹了。所以如果通过自动化来进行回归测试，则可以弥补这方面的问题。一方面机器可以覆盖更广泛的回归测试范围，确保该测的地方都测到；另一方面因为机器不会疲惫、不会像人一样出现疏忽或者出错，从而提升整个软件质量。
当然，第二个目的就是大家所熟知的加快测试速度了。但是这里需要阐明一点的就是加快测试速度不是指加快脚本执行步骤的速度。其实从某种意义上来说，熟练的测试工程师对某一个业务流程的人工操作有可能比机器操作还要快。机器为了脚本健壮性，往往在脚本中会人为设置一些等待时间，避免因为操作比系统反应更快从而导致脚本运行失败。所以这里提到的加快测试速度有两个层面的意思：一是指我们如果通过机器来执行，机器不像人类一样，每天工作 8 小时。如果需要，机器可以 24 小时不间断的运行，当然也就可以利用晚上甚至是凌晨的时间来执行，而这个是人类所没办法做到的；另一方面，随着虚拟化和容器的发展，我们可以很容易的部署多套自动化工具来进行脚本的执行。如果脚本量很大的情况下，我们可以通过容器部署更多的执行机来实现分布式执行测试，从而大大加快整个测试的速度、提升整个测试的效率。
最后，自动化还有一个目的是大家容易忽视的，也就是自动化可以解决人工不能做到的一些测试操作。比如说性能测试，如果需要测 10000 个并发，我们是不可能找 10000 个测试工程师坐在电脑前同一时间去点击系统的。即使能找到 10000 个工程师，但是怎么保证他们真的是“同一时间”呢？通过自动化，却是可以通过模拟这种并发的请求来实现。
五、增强的分层自动化
我们在上一节中已经了解了分层自动化。但是如果我们按照“测试自动化”这个理念重新再思考图4的话，我们会发现其实图4是有所缺失的，因为它只是考虑了测试执行过程，而没有关注包括测试数据准备、测试环境准备等方面。
所以从整个测试的过程来看，图4的描述还不是最完整的分层自动化测试。分层自动化测试不仅仅是 UI 的自动化，而是需要在测试的不同阶段都考虑自动化；同样，分层自动化测试不仅仅只是关注测试执行过程的自动化，还应该需要关注包括数据、环境准备等各个方面的自动化，特别是测试环境的自动化。我们知道测试环境准备特别耗时，有统计数据表明，测试环境的准备时间占整个测试过程的 40%。所以通过自动化来解决测试环境将会大大提升整个测试的效率。因此我们需要对图4 进行优化，补充测试数据及测试环境自动化在最下层，作为自动化测试执行的基础设施，如图5 所示：
不要只做收藏从未停止，行动从未开始的人，很多事情，做着做着就无师自通了。如果在做的过程中还能稍微加点思考，稍微看一些别人的经验和做法，成长会更快，效果也会更好！加油吧，测试人！路就在脚下，成功就在明天！
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
