大家对自动化的理解，首先是想到Web UI自动化，这就为什么我一说自动化，公司一般就会有很多人反对，因为自动化的成本实在太高了，其实自动化是分为三个层面的（UI层自动化、接口自动化、单元测试），不是每个层面的自动化都是遥不可及的，以下标示一下这三个层面的难易程度（网上叫这个为自动化金字塔）：

        基本上可以肯定的是，单元测试是成本最低的，也是最容易推广，见效最大的，但是很多公司不会投入这块，原因是因为现在大部分公司都是人才短缺，特别是成手的研发人员。你说投入到项目实际开发工作的人员都嫌不够，怎么可能抽出相关人力去做单元测试。而以目前大部分公司的测试团队人员构成来说，能做单元测试的基本没有（有也被抽去做开发了），这也是大家一致认为单元测试属于开发职责的原因（除了他们自己没人能做了）。

        单元测试如果做不了，那么接口（API或Service）自动化测试能做不？这个只要有一定的技术基础还是能做的，至少有一部分测试人员是能够做接口测试的（话说性能测试就属于一种接口自动化），如果能自主开发或直接引进一套像样的接口自动化工具或框架（工具上来说，市面上也不少），那么就可以开展这部分的工作，我相信大部分公司能做好的自动化测试，应该也是基于这一层的（所以我们建议有条件的话，自动化测试可以先在这一层面开层，当然前提是真有那么多接口或服务需要测试）。接口自动化测试框架应该具有以下功能，可以根据复杂度和各自项目需求而定：

        1、校验

        这个很好了解，如果没有校验，单纯的执行接口的话，那就谈不上测试了。所以支持对返回值校验是一个必须的功能。

        2、数据隔离

        数据隔离就是指具体的请求接口、参数、校验等数据做到与代码相隔离，便于维护，一旦需要调整接口用例、新增接口用例时可很快速的找到位置，隔离的另一个好处就是可复用，框架可以推广给其他团队，使用者可以使用相同的代码，只需要根据要求填写各自用例即可测试起来。

        3、数据传递

        做到数据隔离可维护后，数据传递是另外一个更重要的需求。

        数据传递是指接口用例之间可以做到向下传参，例如我们通过创建订单接口创建一个订单，该接口会返回一个订单号，接下来我们要进行调用查询订单的接口，从返回的数据中与创建订单用例中的数据进行校验，此时第二个接口的请求数据是需要从第一个接口用例中的返回中提取的。这样的例子比比皆是，所以支持数据传递是又一个必不可少的功能。

        4、动态函数

        实际用例场景中我们可能会有随机生成一个手机号、字符串加密等需求，在数据与代码隔离之后，此时我们就需要代码可以支持做到识别对应关键字时可以执行对应的函数进行填充。例如在数据中填写nowTime()时，具体执行时会被替换成当前时间，填写random(5)时，会被替换成一个五位的随机数等等。

        5、可配置

        有时，我们的需求是用例不单单只能在一个环境上执行，可能需要同一份接口用例可以在QA、预发、线上等多个环境都可以执行。所以框架需要做到可配置，便于切换，调用不同的配置文件可以在不同的环境执行。

        6、日志

        日志包含执行的具体执行接口、请求方式、请求参数、返回值、校验接口、请求时间、耗时等关键信息，日志的好处一来是可以便于在新增用例有问题时快速定位出哪里填写有问题，二来是发现bug时方便向开发反馈提供数据，开发可以从触发时间以及参数等信息快速定位到问题所在。

        7、可视化报告

        用例执行后，就是到了向团队展示结果的时候了，一个可视化的报告可以便于团队成员了解到每次自动化接口用例执行的成功数、失败数等数据。

        8、用例驱动

        （1）用例的驱动模式，涉及到怎么存放测试数据，怎么描述用例，又如何复用；

        （2）考虑到效率的话还要支持并发；

        （3）当然测试报告不能光记录成功和失败，还有用例执行耗时、接口调用耗时、场景的通过率等各项数值的统计。

        说完单元测试、接口测试的自动化，我们现在来说说UI层自动化测试，这也是一直很火并且也是自动化概念先入为主的一块，毕竟市面上有不少成熟的自动化工具，如QTP、Selenium等。这块自动化一定是会有测试团队参与的，就算自动化框架是由开发来完成，那么具体测试工作也是由Tester全程参与的。UI层自动化测试真的不容易推行，无论有多么完善的自动化框架，在这一块维护的成本也是非常高的，特别是懂开发的人不懂测试，懂测试的人不懂开发，这一矛盾现象所带来的内部消耗就不少，再加上项目需求和UI层都在频繁变动，而且Web UI技术越来越复杂和多元化（UI层自动化需要基于对象识别技术），这些都导致很多公司不愿意投入这一块。即使这样，做为一个有上进心的测试人员，我们也是需要多想想这一块，毕竟这是离我们测试最近的一块“技术沃土”了（之一）。

        现在我们来重点谈下Web UI自动化测试（目前的系统大都通过Web UI来展示），一般成熟一点的自动化工具方案大体是这样：

        1、开发语言：Python或Java；

        2、开源测试框架：Selenium WebDriver；

        3、Web元素定位：Xpath+cssSelector+findElement或findElements方法；

　　具体实施细节来讲重点是针对Web UI自动化测试的特点，将各层包装，分而治之的思想，各自相互独立，职责定义清楚，下面简要说明下：

        1、测试用例业务流操作实现及测试数据分离管理；

        2、页面元素定位及页面元素的操作分离；

        3、可视化的日志查询系统；

        4、跨浏览器支持如：IE,Firefox,Chrome；

        5、可视化的的测试报告，可以具体查询到日志/截图等；

        6、实现了通过Excel的数据驱动管理；

        7、邮件发送管理，可以自定义具体时间及接受者等；

        以上是一般Web UI自动化测试的一些实践要求，当然也是相对简易的，复杂的就是实现平台化管理，每天测试工程师，只需要选择具体项目、所测的测试用例集，然后执行，输出测试报告，邮件自动发送到相关开发/测试，框架的开发维护上也能够持续集成。

        说完了这三个层面的自动化测试，那么我们再来分析一下，到底应该优先开展哪个层面的自动化测试，到底是哪个投入产出比最高，以下分享一篇网上文章的部分内容，人家已经给了答案：

        众所周知，软件测试的边际成本会随着缺陷探测率的提高而提高，这就是软件测试的基本公理之一"测试的不可穷尽性"的经济学体现。这一规律也适用于自动化测试，也就是说随着自动化覆盖率的提升，自动化的成本也呈现指数式上升。按照这个思路进行拓展，可以分析下单元测试，集成测试和UI测试的自动化成本曲线如图2所示。与通常理解的一致，为了达到相同的自动化率(x0)，UI的成本最高、其次是API，Unit则最低。

        经济学中有另外一个著名的理论叫做边际效益递减。当做一项投资，随着投资量的增加，单位投资增量所带来的单位收益是越来越少的，甚至在某个临界点之后，这个收益有可能是负数。而这个零界点，就是投资收益最大的点。在这个点之前的所有投资，都可以扩大总收益，而在超过之后继续进行投资，就不那么明智了。

         图2  自动化成本/收益曲线

        按照这个思路，在图2上，针对三种不同类型的自动化测试，可以获得三个零界点。而总收益最大的点在接口测试上，随后是单元测试，UI测试则最低。

        如果从测试效果上看，接口测试和UI/单元测试相比，有很多优势。 对于单元测试来说，通常单元测试是针对代码进行的测试，而接口测试是在测试一个活的，经过部署的系统。 另外，单个接口测试与单个单元测试用例相比，也可以覆盖更多的代码。更重要的是，接口测试也可以是面向业务的测试，通过接口进行业务层面的测试。

        而相比UI自动化用例，接口测试更加的简单直接，执行效率更高。 除了部分如企业级应用软件，可能很多业务在前端进行之外，很多情况下，绝大部分通过UI完成的业务操作完全可以通过API端完成。某些情况下，API（接口）的测试条件覆盖率甚至可以多过UI。

        综合上述的分析，笔者认为在自动化测试的初级阶段，适合奔小康的测试团队的自动化模式应该是中间层的接口最大，两端的UI和Unit测试适度实施。从图形上看，就是一个橄榄型（中间的接口测试效益比最高）。如果再加上一部分的手工测试，那就是一个不倒翁了。（题外话：接口测试可以由开发团队来做，也可交由测试团队去开展）

        按照这个模式，将大部分自动化投资用于接口测试，可以获得最高的投资回报。再结合持续测试与持续集成等最佳实践，在团队之间彼此共享测试用例、测试框架或者平台，通过接口测试这一承上启下的测试类型，可以自下而上地逐步翻越过纸杯蛋糕模式中的那堵墙。（备注：纸杯蛋糕模式，是一种反金字塔的自动化模式，开发和测试各自为政，线性的开展测试，无法并行协同测试，相当于有道部门墙，开发的自测环节和测试开展的测试环节，没有建立关联和资源共享---重复测试、度量目标不一致、过度自动化）