Selenium自行整理【三】

1.2、分层的自动化测试

        测试金字塔的概念由敏捷大师 Mike Cohn 在他的《 Succeeding with Agile 》一书中首次提出，如图1-2所示。他的基本观点是：我们应该有更多的低级别的单元测试，而不仅仅是通过用户界面运行的高层的端到端的测试

                                             

        Martin Fowler 大师在测试金字塔模型的基础上提出分层自动化测试的概念，如图1-2所示。在自动化测试之前加了一个“分层”的修饰，用来区别于“传统的”自动化测试。那么什么是传统的自动化测试？为何要提倡分层自动化测试的思想呢？

        所谓传统的自动化测试我们可以理解为基于产品 UI 层的自动化测试，它是将黑盒功能测试转化为由程序或工具执行的一种自动化测试。

         在目前的大多数研发组织当中，都存在开发与测试团队割裂（部门墙）、质量职责错配（测试主要对质量负责）的问题，在这种状态下，测试团队的一个“正常”反应就是试图在测试团队能够掌控的黑盒测试环节进行尽可能全面的覆盖，甚至是尽可能全面的 UI 自动化测试。

         这可能会导致两个恶果：一是测试团队规模的急剧膨胀；二是所谓的全面 UI 自动化测试运动。因为UI 是非常易变的，所以 UI 自动化测试维护成本相对高昂。

         分层自动化测试倡导的是从黑盒（UI）单层到黑白盒多层的自动化测试体系，从全面黑盒自动化测试到对系统的不同层次进行自动化测试，如图 1-3所示。

        

1）单元自动化测试

       单元测试是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如 C 语言中单元指一个函数、Java 中单元指一个类、图形化的软件中

       单元可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。规范的进行单元测试就需要借助单元测试框架，如 java 语言的 Junit、TestNG，C#语言的 NUnit，以及 Python 语言的unittest、pytest 等，目前几乎所有的主流语言都会有其相应的单元测试框架。

        Code Review 中文翻译为代码评审或代码审查，是指在软件开发过程中，通过对源代码进行系统性检查的过程。通常的目的是查找系统缺陷，保证软件总体质量和提高开发者自身水平。与 Code Review 相关的插件与工具有很多，例如 Java 语言中基于 Eclipse 的 Review Clipse 和 Jupiter、主要针对 Python 语言的 Review Board 等。

 

接口自动化测试

        根据个人的理解，Web 应用的接口测试大体分为两类：模块接口测试和 Web 接口测试。

       （1）模块接口测试，主要测试模块之间的调用与返回。当然，我们也可以将其看作是单元测试的基础。它主要强调对一个类方法或函数的调用，并对返回结果的验证，所用到的测试工具与单元测试相同。

       （2）Web 接口测试又可分为两类：服务器接口测试、外部接口测试。

         ● 服务器接口测试：指测试浏览器与服务器的接口。我们知道 Web 开发一般分前端和后端，前端开发人员用 HTML/CSS/JavaScript 等技术,后端开发人员用 PHP/Java/C#/Python/Ruby 等各种语言。用户的操作是在前端页面上，需要后端提供服务器接口，把前端通过调用这些接口来获得需要的数据，通过 HTTP 协议来实现前后端的数据传递。

         ● 外部接口测试：指调用的接口由第三方系统提供。典型的例子就是第三方登录，例如新上线的产品为了免于新用户注册账号的麻烦会提供第三方登录，那么用户在登录的时候调用的就是第三方登录的接口，用户登录信息的验证由第三方完成，并返回给当前系统是否验证通过。

          ● 当然，接口测试也有相应的类库或工具，例如测试 HTTP 的有 HttpUnit、Postman 等。

 

UI 自动化测试

          ● UI 层是用户使用该产品的入口，所有功能都通过这一层提供并展示给用户，所以大多测试工作都集中在这一层进行。为了减轻这一层的测试人力和时间成本，早期的自动化测试工具主要针对该层设计。目前主流的测试工具有 UFT、Watir、Robot Framework、Selenium 等。

          ● 除了 UI 层所展示的功能外，前端代码同样需要进行测试。在前端开发中最主要的莫过于 JavaScript脚本语言，而 QUnit 就是针对 JavaScript 的一个强大的单元测试框架。

          ●图1-3中的测试金字塔映射了不同测试阶段所投入的自动化测试的比例，UI 层被放到了塔尖，这也说明 UI 层应该投入较少的自动化比例。如果系统只关注 UI 层的自动化测试并不是一种明智的做法，因为其

很难从本质上保证产品的质量。如果妄图实现全面的 UI 层的自动化测试，那么需要投入大量的人力和时间，然而，最终获得的收益可能远低于所投入的成本。因为对于一个系统来讲，越接近用户其越容易变化，为了不断适应这种变化就必然需要投入更多的成本。

           ● 既然 UI 层的自动化测试这么劳民伤财，那么我们是不是只做单元测试与接口测试就可以了呢？答案是否定的，因为不管什么样的产品，最终呈现给用户的是 UI 层的功能，所以产品才需要招聘大量的测试人员进行 UI 层的功能测试。也正是因为测试人员在 UI 层投入了大量的时间与精力，所以我们才有必要通过自动化的方式帮助测试人员解放部分重复的工作。所以，笔者更提倡“半自动化”的开展测试工作，把可以自动化测试的工作交给工具或脚本完成，这样测试人员就可以把更多的精力放在更重要的测试工作上，例如探索性测试等。

 

         【至于在金字塔中每一层测试的投入比例则要根据实际的产品特征来划分。在《Google 测试之道》一书中提到，Google 对产品测试类型划分为：小测试、中测试和大测试，采用 70%（小）/20%（中）/10%（大）的比例，大体对应测试金子塔中的 Unit、Service 和 UI 层。】

         【在进行自动化测试中最担心的是变化，因为变化会直接导致测试用例的运行失败，所以需要对自动化脚本进行不断调整。如何控制失败，降低维护成本是对自动化测试工具及人员能力的挑战。反过来讲，一份永远都运行通过的自动化测试用例已经失去了它存在的价值。】