分层测试_ 字节宝

引言

自动化测试一直是测试领域桂冠上的明珠，几乎所有的测试团队都有建立团队的自动化。测试团队的自动化建设也被认为是团队提效的必经之路，但搭建和使用自动化路但路却并非一帆风顺。搭建自动化但时候有很多框架可以选用，合理但选择适合该团队的框架可以事半功倍，同时选择了框架之后就要受制于框架。使用自动化很多时候因为学习以及维护成本高，让初衷是提效为目的的自动化，成为了加重测试工作量之殇。

现在为了腾讯视频增值团队的分层测试，了解了一些内部和外部的自动化框架，他山之石可以攻玉，这里列出来和大家一起学习。

自动化的认识

为什么要建设自动化？

主要当前QA工作中存在众多的痛点。

手工回归测试工作量大
手工回归测试覆率不足
手工测试的偶然性
靠人的业务外测试难以满足持续集成的迭代效率
发布的代码没有工具衡量准入质量指标

总结而言，自动化测试的目的可以概括为，降本提效和避免手工验证的偶然性。

分层自动化的理念

在理解分层自动化之前，我们先看自动化测试金字塔。自动化测试金字塔理念由Mike Cohn 在《Succeeding with Agile》译注1 书中提出，将自动化分为：Unit Tests（单元测试）、Service Tests（代表服务业务测试：接口测试集成测试）、UI Tests（代表页面级系统测试）。Google在实践中对各层的投入占比是7:2:1，为什么是这个比例，也正如下图中左右两端的指标，越往上层构建自动化测试花费时间越多，验证对象越集成；越集成的测试对象，每次迭代自动化失败的概率则越高。所以这也是为何越上层占比越少的原因。那是不是可以不建设呢？显然也是不可以的，每一层的测试目的不同，达到的作用也不同。合理的分配、建设完善的自动化才能保证被测系统的鲁棒性，同时也是达到测试效率的平衡点。

单元测试（unit）：它可以通过mock框架，模拟各种异常场景，外部依赖最少，且可以做到测试粒度最小的一种测试方法

自动化收益公式

自动化测试的目的是降本提效，既然如此，肯定要考量建设自动化的收益率。

自动化收益=迭代次数✖️手工执行成本-首次自动化成本-维护次数✖️单次维护成本

自动化收益公式只挑选了核心的几个指标（大部分情况下维护次数与迭代次数是正相关，而平台的稳定性导致的失败和自动化发现的问题复现也需要花费很大的时间成本）。影响自动化收益最大的是维护次数和维护成本，总的来说在金字塔越顶端，自动化测试覆盖的对象越集成，维护次数就越高。

除了上面公式里提到的收益外，还包括资哦弄个话作为持续集成环节里的质量把关，发布卡点带来的持续集成流程上的完善。

UI自动化测试

很多测试团队都会建设UI自动化测试，初衷大体是因为UI自动化集成度高，覆盖前端的代码，验证完整链路的系统稳定性。实际上当团队搭建UI自动化平台的时候，往往付出了很多的成本，但收益却较低。主要原因主要有下面这一些。

与“需求”共进难，代码集成太快，UI自动化初次创建成本高，难以及时补充自动化
维护次数多，开发迭代的改动，很容易就需要修改UI自动化脚本
维护成本高，每次改动，都要手工修改代码，调试正常，修改用例，成本较高
平台稳定性差，自动化失败每次花时间定位问题，却发现是平台问题
系统环境不稳定，UI自动化往往集成了多个系统，预发环境问题导致的失败也占据很多
测试数据的不稳定，往往如商品下架
……还有很多，不一一列举，欢迎补充……

UI自动化的实践固然重要，但UI自动化的战略位置是毋庸置疑的。因为UI自动化是最接近用户的一层，当UI自动化测试通过，对于交付给用户使用的系统才有信心是完善的，这是其他层的自动化所难以达到的。既然战略上有UI自动化覆盖的必要性，那么我们怎么更好地建设团队的UI自动化呢？

哪部分适合建设UI自动化

大体上UI自动化的定位是属于回归测试，鉴于上面提出的UI自动化的痛点，哪些地方适合用来建设UI自动化呢？

页面稳定
回归验证频繁
软件维护周期长
核心应用场景稳定，变更不频繁
有平台兼容性测试要求

怎么建设UI自动化

知已知彼，百战不殆。在讨论如何建设UI自动化之前，想先了解行业内的UI自动化测试框架。由于行业内测试方案非常多，iOS和Android双平台的方案加起来大约是近20种。应该如何选择适合我们团队的测试方案呢？我觉得主要考虑以下几个方面：

支持不同平台的一套框架，包括iOS和Android；
集成自动化框架，对原有项目的侵入尽量要小，介入成本尽量低；
稳定性要好；
可扩展性好；

UI自动化测试框架一览

框架名称	支持平台	脚本语言(学习成本)	侵入性	备注	底层框架
Macaca	PC&iOS&Android&Hybrid	Js Java Python（理论上可以支持任意语言）	无	阿里巴巴开源框架，Android支持API(>17)	XCUTest()iOS/UIAutomator(Android)
appium	PC&iOS&Android&Hybrid	Python Ruby Java Js OC PHP C#(.Net)	无	Android支持所有版本	UIAutomation(iOS)/UIAutomator Selendroid(Android)
Airtest	Android&iOS&Windows	Python(使用者无需编程能力)	无	基于图像识别原理	Airtest框架(Sikuli)&Poco框架(Uiautomator for python)
GAutomator	iOS&Android	Python	无	针对手游	Uiautomator for python
Cucumber	iOS&Android	Ruby Java .Net	无	以简单的自然语言方式的BDD框架
Espresso	Android	Java	有	主线正在使用espresso进行UI测试和模块间的接口自动化测试	Instrumentation
Robotium	android				Instrumentation
UIAutomation	iOS	JavaScript	无	仅支持Android4.1及以上
UIAutomator	Android
Kiwi	iOS
Subliminal	iOS				UIAutomation
KIF	iOS	OC	有	使用私有API了解App中的视图层级
Frank	iOS	Cucumber	有	要求测试时在应用程序内部编译，强制改变源代码
XCTest	iOS	OC	有
Sikuli	iOS
Instrumentation	Android	Java	有	Android自带测试框架
Robotium	android	Java			Instrumentation

Macaca

https://github.com/alibaba/macaca Macaca是阿里巴巴集团开发的一套完整的自动化测试解决方案。

`Appium`

http://appium.io/ Appium 是一个开源的、跨平台的自动化测试工具，支持IOS、Android和FirefoxOS平台。通过Appium，开发者无需重新编译app或者做任何调整，就可以测试移动应用，可以使测试代码访问后端API和数据库。它是通过驱动苹果的UIAutomation和Android的UiAutomator框架来实现的双平台支持，同时绑定了Selenium WebDriver用于老的Android平台测试。开发者可以使用WebDriver兼容的任何语言编写测试脚本，如Java， OC， JS， PHP，Python， Ruby， C#，Clojure 和Perl语言。appium主要跨平台，并且社区活跃度大，比较被推崇。

`Airtest`

https://airtest.readthedocs.io/zh_CN/latest/

https://github.com/AirtestProject

基于图像识别的跨平台UI自动化测试框架，无需嵌入任何代码即可进行自动化测试，是网易自己团队开发的，基于MIT（麻省理工）研究院的成果 Sikuli ，构思了一种全新的UI测试模式：基于图像识别控件而不是具体内存里的控件对象。适用于游戏和App，支持PC、iOS、Android、Hybrid平台。可使用Python语言甚至使用者可无需具备编程能力。Airtest提供了跨平台的API，包括安装应用、模拟输入、断言等。测试脚本运行后可以自动生成详细等HTML测试报告，可以迅速定位失败等测试点。

`GAutomator`

https://github.com/Tencent/GAutomator

GAutomator是腾讯自家开发的针对手游的UI自动化测试框架。与Airtest有个共同的祖宗：xiaocong大大的 uiautomator for python，让用python调用uiautomator成为可能。GAutomator以引擎中的元素为操作对象(如Unity中的GameObject)，通过操作GameObject实现UI自动化测试。

`Cucumber`

https://docs.cucumber.io/ https://github.com/cucumber/cucumber

https://tech.meituan.com/2017/06/23/mobile-app-automation.html 美团实践

Cucumber是一个能够理解用普通语言来描述测试用例，支持行为驱动开发(BDD)的自动化测试工具，使用Ruby编写，也支持Java和.Net等多种开发语言。

什么叫用普通语言来描述测试用例呢，看下具体的案例，我的“引导页”的测试用例：

代码语言：shell复制

@guidepage
Feature: 引导页
  1.首次安装应用，判断是否展示引导页；
    滑到最后一张，判断是否展示“登录/注册”和“进入首页”两个按钮；
    点击“登录/注册”按钮，判断是否展示登录界面。
  2.滑动到最后一张引导页，点击“进入首页”按钮，判断引导页是否还存在。

  @guide_01
  Scenario: 首次安装应用，展示引导页；滑动到最后一张引导页，展示“登录/注册”和“进入首页”两个按钮
    When 展示引导页
    Then 滑动到最后一页
    Then 展示“登录/注册”和“进入首页”两个按钮
    When 点击“登录/注册”按钮
    Then 展示登录界面

  @guide_02
  Scenario: 点击最后一张引导页“进入首页”按钮，判断引导页是否还存在
    When 滑动到最后一张引导页，点击“进入首页”按钮
    Then 退出引导页

Feature：就是字面意思，主要是描述功能特性。
Scenario：场景，在这里可以简单的理解为一个个的细分case，通常情况下需要多个场景拼接来完成一个具体的test case。
Step：实现场景的步骤代码

`Espresso`

https://developer.android.com/training/testing/espresso/

Espresso是Google的开源自动化测试框架。相对于Robotium和UIAutomator，它的特点是规模更小、更简洁、API更加精确、编写测试代码简单、容易快速上手。因为是基于Instrumentation的，所以不能跨App。

http://km.oa.com/group/24687/articles/show/290640?kmref=author_post

`Robotium`

https://github.com/robotiumtech/robotium

Robotium是基于Instrumentation框架开发的一个更强的框架. 对常用的操作进行了易用性的封装. 用于开发功能性、系统和验收测试场景。它运行时绑定到GUI组件。它安装了一个测试用例套件作为在Android设备或仿真器上的应用程序，并提供用于执行测试的真实环境。

优点：容易在最短的时间内编写测试脚本，易用性高。自动跟随当前activity。由于运行时绑定到GUI组件，所以相比Appium，它的测试执行更快，更强大。不访问代码或不了解app实现，也可以工作。支持Activities、Dialogs、Toasts、Menus、Context Menus和其他Android SDK控件。

缺点：不能处理flash和web组件。在旧设备上会变得很慢。由于不支持iOS设备,当自动化测试同时覆盖 android与iOS的情况时，测试会被中断。没有内置的记录和回放功能.，使用记录功能需要 TestDroid 和 Robotium Recorder 这样的收费工具。

`UIAutomation`

UI Automation是Apple官方早期提供的UI自动化测试解决方案，但接口不够丰富，用JavaScript编写测试脚本，通过标签和值的可访问性获得UI元素，来完成相应的交互操作。一些第三方UI解决方案以UI Automation为基础，对其进行补充和优化，包括扩展型UI Automation和驱动型UIAutomation

`UIAutomator`

跟Espresso一致，利用Android系统的空间结构来做自动化，通常是测试代码直接在安卓手机上运行。但是仅限于Android，而且需要有android开发经验，对技术水平要求较高。

`Kiwi`

https://github.com/kiwi-bdd/Kiwi/wiki/Getting-Started-with-Kiwi-2.0

Kiwi是对XCTest的一个完整替代，使用xSpec风格编写测试。 Kiwi带有自己的一套工具集，包括expectations、mocks、stubs，甚至还支持异步测试。它是一个适用于iOS 开发的Behavior Driven Development（BDD）库，优点在于其简洁的接口和可用性，易于设置和使用，非常适合新手开发者。Kiwi使用Objective-C语言编写，易于IOS开发人员上手。

`Subliminal`

http://inkling.github.io/Subliminal/

Subliminal是另一款与XCTest集成的框架。与KIF不同的是，它基于UIAutomation编写，旨在对开发者隐藏UIAutomation中一些复杂的细节。

`KIF`

http://www.oschina.net/translate/ios-ui-testing-with-kif

KIF是Keep It Functional项目的缩写，是一款iOS app功能性测试框架，使用Objective-C语言编写，对苹果开发者来说非常容易上手，更是一款开发者广为推荐的测试工具。KIF tester使用私有API来了解App中的视图层级。但缺点是运行较慢。

`Frank`

http://www.testingwithfrank.com/

Frank是iOS平台一款非常受欢迎的app测试框架，它使用Cucumber语言来编写测试用例， Frank包含一个强大的“app inspector”--Symbiote，可以用它来获得运行中app的详细信息，便于开发者将来进行测试回顾。它允许使用Cucumber编写结构化英语句子的测试场景。 Frank要求测试时在应用程序内部编译，这意味着对源代码的改变是强制性的。操作方式为使用Cucumber和JSON组合命令，将命令发送到在本地应用程序内部运行的服务器上，并利用UISpec运行命令。

优点：测试场景是在Cucumber的帮助下，用可理解的英语句子写的。强大的Symbiote实时检查工具。活跃的社区支持。不断扩大中的库。

缺点：对手势的支持有限。在设备上运行测试有点难。修改配置文件需要在实际设备上运行。记录功能不可用。

`XCTest` https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/01-introduction.html

XCTest是苹果在iOS 7和Xcode5引入的一个简单而强大的测试框架，它的测试编写起来非常简单，并且遵循xUnit风格。XCTest的优点是与Xcode深度集成，有专门的Test导航栏，但因为受限于官方测试API，因此功能不是很丰富。

`总结（iOS）`

iOS自动化测试框架继承关系如上图所示。XCTest与 Xcode 的 IDE 直接集成,使用简单, 但其不支持stub和mock, 所以单使用XCTest框架的较少.。Cucumber和Kiwi是一个iOS平台十分好用的行为驱动开发BDD的测试框架，有着非常漂亮的语法，可以写出结构性强，非常容易读懂的测试（两者区别在于前者也支持android）。UI Automation是Apple官方提供的UI自动化测试的解决方法,但接口不够丰富。KIF、Frank、Calabash都是通过使用代码的形式来模拟事件触发，使得被测代码就像是由用户行为所触发的一样。但这样的代价是插入一个额外层的复杂度。 IOS测试框架中支持BDD的有calabash 和Kiwi以及Cucumber。可选用的单元测试框架有Kiwi，Specta，Quick等，而KIF，Subliminal和Calabash更适用于UI级验收测试。

`Instrumentation`

https://developer.android.com/reference/android/app/Instrumentation.html

Instrumentaion 是Android自带的一个测试框架，是很多其它测试框架的基础，可以在同进程中加载被测组件。它有很多丰富的高层封装，使用者可以使用基于instrumentation的其他框架，避免过多二次开发量。但Instrumentation不支持跨应用，导致基于instrumentation的框架都继承了这个缺点。

`Robotium`

https://github.com/robotiumtech/robotium

参考文献：

Macaca github：https://github.com/macacajs
Macaca原理介绍：https://github.com/alibaba/macaca
Macaca中文官网：https://macacajs.github.io/zh/
appium官网：http://appium.io/
Airtest 源码：https://github.com/AirtestProject
Airtest官网指引：http://airtest.netease.com/tutorial/Tutorial.html http://airtest.netease.com/
Airtest官网文档：http://airtest.netease.com/docs/cn/index.html
Airtest中文文档：https://airtest.readthedocs.io/zh_CN/latest/
关于Airtest的使用探索：https://www.jianshu.com/p/32d08455e86f
如何评价网易开源的Airtest：https://www.zhihu.com/question/269270386
全面解读Airtest：https://www.oschina.net/question/3820517_2278684
基于KIF的iOS UI自动化测试和持续集成：https://tech.meituan.com/2016/09/02/ios-uitest-kif.html
客户端自动化测试研究：https://tech.meituan.com/2017/06/23/mobile-app-automation.html
行为驱动开发：https://zh.wikipedia.org/wiki/行为驱动开发
移动App自动化测试框架对比：https://mp.weixin.qq.com/s/pu1TKZhNW2L2BmvpjGzLCw
移动端UI自动化测试--Appium和Cucumber的完美结合：https://www.jianshu.com/p/c3db8e5dc306
iOS UI Testing 指北：https://nixwang.com/2018/09/30/ios-ui-testing/
移动App自动化测试工具发展历程：https://testerhome.com/topics/19368
iOS Automated Tests with UIAutomation：http://blog.manbolo.com/2012/04/08/ios-automated-tests-with-uiautomation
如何使用UIAutomation进行iOS自动化测试：https://www.cnblogs.com/vowei/archive/2012/08/10/2631949.html
Cucumbergithub地址：https://github.com/cucumber/cucumber-jvm https://github.com/cucumber/cucumber/wiki/Step-Definitions https://github.com/cucumber/cucumber/wiki/Step-Argument-Transforms
Cucumber官网：https://cucumber.pro/
Kiwi github地址：https://github.com/kiwi-bdd/Kiwi/wiki/Getting-Started-with-Kiwi-2.0
espresso使用教程：https://developer.android.com/training/testing/espresso/

gui ios 单元测试腾讯云测试服务自动化测试

0 人点赞

分层测试

引言

自动化的认识

UI自动化测试

哪部分适合建设UI自动化

怎么建设UI自动化

UI自动化测试框架一览

Appium

Airtest

GAutomator

Cucumber

Espresso

Robotium

UIAutomation

UIAutomator

Kiwi

Subliminal

KIF

Frank

XCTest https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/01-introduction.html

总结（iOS）

Instrumentation

Robotium

`Appium`

`Airtest`

`GAutomator`

`Cucumber`

`Espresso`

`Robotium`

`UIAutomation`

`UIAutomator`

`Kiwi`

`Subliminal`

`KIF`

`Frank`

`XCTest` https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/01-introduction.html

`总结（iOS）`

`Instrumentation`

`Robotium`