这图大概是我三年前画的，今天拿出来依旧是没有过时的。可能市面上有了一些居于这里面某个开源的框架重新写了个新的框架，但再怎么写底层总是逃不过这些框架。
我们看看这图，我们看到自动化测试底下分了三层的测试（单元测试，接口测试，UI测试），是不是就是我们讲的金字塔模型是一样的。 每一层的测试都有对应的框架或者工具供我们选择。
首先单元测试，我们也叫它白盒测试，这层通常都是开发自己做，一般每个开发语言都会有他对应的Xunit， 例如Java 有Junit。 这层开发可能会写一些桩模块或者驱动模块，从而去达到条件覆盖呀，语句覆盖等。这层我们测试人员接触较少。
接着就是接口测试，我们有时也叫他灰盒测试，它是介于白盒和黑盒之间的测试，也就我们第一节讲到它是承接上下的一层。 那接口测试我们又有哪些工具或者框架可以选着呢？ 工具容易上手的例如有SoapUI， 它是一个既可以支持RESTful 类型的接口，也支持SOAP类型的接口，而且工具本身是有一定的扩展性，因为除了简单配置为你还可以通过编写Groovy脚本，但从使用上个人感觉它不太适合团队成员的协作，因为他最终生成的脚本是xml格式，非常不便于合并，再来他是商业工具。
工具除了SoapUI 外还有PostMan ， Jmeter ， LoadRunner 等等，可能你会问这Jmeter 和LoadRunner 不是用于做性能的么？对的！ 我们经常通过这两个工具做服务端的性能，模拟成千上万的请求都可以，那接口模拟1个请求肯定也是可以。但这些工具总归不是专业的接口自动化测试工具，所以做接口自动化也是可以，但总归不是最优选择。 当然PostMan是专业的接口测试工具，但它又不是自动化测试工具，也有一定的弊端，例如无法跟数据库交互等。所以接口自动化测试，我个人推荐找个开源的框架，自己去写代码，这类框架有很多，例如java 有httpclient，RestAssured 还有支持各种语言的unirest等等。
最后就是UI测试，也叫黑盒测试。 这一层的测试我个人又把他分层了三层，这三层的命名可能不太准确，是我自己提出来的。 哪三层？ 工具层，核心层和适配层。
工具层呢又会因为不同操作系统不同架构会用到不同的框架工具，别的我就不讲，就讲讲我们PC端的B/S架构也就是我们的web了。 在做Web自动化市面上提供的工具平台也是非常多，我这里没有一一列出，我就列出了两个常见的工具框架。 一个是QTP现在改名了叫UFT， 这个工具本身是商业工具，提供了一套完整的解决方案，能同时支持B/S 和C/S 架构，但是缺点太重，而且用的是VB语言。
再来一个就是我们下去要讲的WebDriver，WebDriver 可以说在Web自动化中他已经成为一种规范标准了，所以市面上非常多开源的平台工具也好都基本是居于它做的二次开发，所以用得人多，当然学习这个框架对很多测试人员来说还是有一定挑战，因为需要编码。 那关于WebDrier 的详细介绍，看下节。
假设我们工具层选中了WebDriver ，那我们就能做UI自动化测试了么？答案是否定的。 为啥？ 因为WebDriver 只提供了模拟用户操作浏览器的行为，那UI自动化测试，总归是测试呀，是测试就应该有TestCase呀？ 那TestCase 我们怎么管理，这时我们就得考虑核心层了，那TestCase的管理Java我们可以选择Junit 或者TestNG， 后面的课我们都会讲TestNG。
最后当我们真正开始写代码去做UI自动化测试时，我们为了提高代码的可读性或者可维护性我们会引入一些模式。 例如BDD，KeyWork , PageObject ， 数据驱动等等，这就是我定义的适配层。那PageObject 是我们后面一定会讲到的，关键字和BDD 我们后面也会花点时间带把环境搭建起来，写几个demo玩玩，实际感受下它们的优势和劣势。毕竟这两个也是目前很流行的玩法。
