Web端与App端自动化测试框架

一、Web端与App端的区别

想了解Web端与App端自动化测试框架的区别，那么我们就要先来了解Web和App的区别。Web项目一般都是B/S架构，基于浏览器的，而App则是C/S架构的，必须要有客户端。那么在系统测试的时候就会产生区别。

1.首先从系统架构来看，Web测试只要更新了服务器端，客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是App端是不能够保证完全一致的，除非用户更新客户端。如果是App下修改了服务端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。

2.功能测试方面，在流程和功能测试上是没有区别的，系统测试和一些细节可能会不一样。

3.性能方面，Web端更注重页面响应速度，一般会用JMeter。而App端则还需要关心流量、电量、CPU、GPU、Memory这些了，同样也会用JMeter，另外也有集成好的PerfDog等工具可应用。

4.兼容方面，Web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容，不过一般还是以浏览器的为主。而浏览器的兼容则是一般是选择不同的浏览器内核进行测试（IE、chrome、Firefox）。App的测试则必须依赖Phone或者是Pad，不仅要看分辨率，屏幕尺寸，还要看设备系统。系统总的来说也就分为Android和iOS，不过国内的Android的定制系统太多，也是比较容易出现问题的。

目前主流Web应用大多都采用Brower/Server模式，这种模式的优点在于用户可以直接在浏览器中访问URL而不需要预先安装各种软件的客户端。同时，Web应用的更新速度很快，而且有很好的开放性，如果只是靠手工测试，远不能达到测试的需求，因此自动化测试的实施对于Web应用变得尤为重要。

二、Web端自动化测试

1.自动化测试的定义

用机器自动执行原本应该由手工操作的测试行为，并且执行过程中可以同时进行系统的验证而不需要人为的干预。具体体现在：在机器上运行开发好的测试脚本验证产品的需求。想要通过引进自动化测试来提高测试效率，降低研发成本，就必须要求在测试脚本的设计上做到重用。所以说实施自动化测试的核心在于如何有效地设计测试脚本、处理测试数据、简化脚本维护的复杂性、最大程度地减少脚本维护的工作量。

2.自动化测试框架

自动化测试框架正是一种用于解决自动化测试问题的特殊框架，它不是一种直接使用的工具，而是一组实施自动测试的规范，测试脚本和测试思想的集合，更多地表现为组件实例之间的一组抽象组件和交互方法。良好的自动化测试框架可以有效地组织和管理测试脚本，降低测试脚本的复杂性和可重复性，从而大大提高测试的效率和质量，节约人力资源。

目前基本的自动化测试框架主要分为以下几种类型：

2.1 测试脚本模块化框架（Test Script Modularity Framework)

测试脚本模块化框架将对象拆分为多个相互独立的逻辑模块，并对每个模块都编写一个独立的测试脚本。由于不同模块和其对应的测试脚本之间都是相对独立的，因此即使其中的某个模块发生变化都不会影响其它模块，这样就提高了软件自动化测试的可维护性和可升级性。

2.2 测试库架构框架（Test Library Architecture Framework)

这种框架与脚本模块化框架类似，通过高度模块化的测试用例来提高测试的可维护性。但库架构框架是将被测程序分解为过程和函数，而不是测试脚本。所有测试用例中的常用功能可以作为函数被存储在一个公共测试库中。当测试框架发生变化，只需要将所需要的维护、变更工作交给相应工作人员就可以，从本质上实现业务逻辑与控件识别的抽象分离。与测试脚本模块类似，所有变更带来的工作量，几乎都有自动化测试工程师完成。

2.3 数据驱动测试框架（Data-Driven Testing Framework)

数据驱动测试框架适合于对使用大量测试数据对同一功能进行测试的情况。此框架是通过将数据与脚本分离并将数据存储在数据文件（数据池，ODBC源，CVS文件，Excel文件，DAO对象等)的原理以显著提高脚本的维护和可重复性。这种框架在运行时会自动加载测试数据，在测试运行时动态判断测试结果是否满足预期结果，并最后自动生成相应的测试报告。数据驱动的测试框架优势是可以减少实现测试用例的脚本数量，并且在Workaround开发和维护方面具有非常好的灵活性。

2.4 关键字驱动或表驱动测试框架（Keyword-Driven or Table-Driven Testing Framework)

关键字驱动测试框架可以理解为一种高级的数据驱动测试框架，作为数据驱动的升级版，关键字驱框架中的数据文件包括测试数据和关键字。在这种测试框架只需要非常少的代码就可以产生大量的测试用例，在同一数据表中就可以完成编写测试步骤，编写测试数据，编写并验证结果等任务。其核心思想可以概括为：数据与脚本分离、测试描述与实现分离、界面元素与测试对象分离，即测试数据、测试脚本和测试逻辑相分离。

3.自动化测试工具

自动化测试通常需要配合相关自动化测试工具来实现。但由于软件测试的目的和方法不同，目前市场上存在的测试工具数量相当庞大，因此在实际的项目中，根据测试目的和测试方法选择恰当的测试工具，对减少测试工作量，成功实施自动化测试有着非常重要的意义。表1总结对比了目前几种主流的测试工具。

三、App端自动化测试

随着Android和IOS两大平台的持续发力，现在市面上的移动端操作系统已被Android和IOS占领，其中Android的份额更是在80%以上。以下介绍各大框架优缺点。

1、Monkey是Android SDK自带的测试工具，在测试过程中会向系统发送伪随机的用户事件流，如按键输入、触摸屏输入、手势输入等)，实现对正在开发的应用程序进行压力测试，也有日志输出。实际上该工具只能做程序做一些压力测试，由于测试事件和数据都是随机的，不能自定义，所以有很大的局限性。

2、MonkeyRunner也是Android SDK提供的测试工具。严格意义上来说MonkeyRunner其实是一个Api工具包，比Monkey强大，可以编写测试脚本来自定义数据、事件。缺点是脚本用Python来写，对测试人员来说要求较高，有比较大的学习成本。

3、Instrumentation是早期Google提供的Android自动化测试工具类，虽然在那时候JUnit也可以对Android进行测试，但是Instrumentation允许你对应用程序做更为复杂的测试，甚至是框架层面的。通过Instrumentation你可以模拟按键按下、抬起、屏幕点击、滚动等事件。Instrumentation是通过将主程序和测试程序运行在同一个进程来实现这些功能，你可以把Instrumentation看成一个类似Activity或者Service并且不带界面的组件，在程序运行期间监控你的主程序。缺点是对测试人员来说编写代码能力要求较高，需要对Android相关知识有一定了解，还需要配置AndroidManifest.xml文件，不能跨多个App。

4、UiAutomator也是Android提供的自动化测试框架，基本上支持所有的Android事件操作，对比Instrumentation它不需要测试人员了解代码实现细节（可以用UiAutomatorviewer抓去App页面上的控件属性而不看源码）。基于Java，测试代码结构简单、编写容易、学习成本，一次编译，所有设备或模拟器都能运行测试，能跨App（比如：很多App有选择相册、打开相机拍照，这就是跨App测试）。缺点是只支持SDK 16（Android 4.1）及以上，不支持Hybird App、WebApp。

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

6、Selendroid：也是基于Instrumentation的测试框架，可以测试Native App、Hybird App、Web App，但是网上资料较少，社区活跃度也不大。

7、Robotium也是基于Instrumentation的测试框架，目前国内外用的比较多，资料比较多，社区也比较活跃。缺点是对测试人员来说要有一定的Java基础，了解Android基本组件，不能跨App。

8、Athrun是淘宝出的一个移动测试框架/平台，同时支持iOS和Android。Android部分也是基于Instrumentation，在Android原有的

ActivityInstrumentationTestCase2类基础上进行了扩展，提供一整套面向对象的API。

9、Appium是最近比较热门的框架，社区也很活跃。这个框架应该是是功能最强大的。

a.它的优点：开源；支持Native App、Hybird App、Web App；支持Android、iOS、Firefox OS；Server也是跨平台的，你可以使用Mac OS X、Windows或者Linux；

b.它的哲理是：用Appium自动化测试不需要重新编译App；支持很多语言来编写测试脚本，Java、Javascript、PHP、Python、C#、Ruby等主流语言；不需要为了自动化测试来重造轮子，因为扩展了WebDriver。（WebDriver是测试WebApps的一种简单、快速的自动化测试框架，所以有Web自动化测试经验的测试人员可以直接上手）；移动端自动化测试应该是开源的；

c.它的设计理念：Client/Server架构，运行的时候Server端会监听Client端发过来的命令，翻译这些命令发送给移动设备或模拟器，然后移动设备或模拟器做出响应的反应。正是因为这种架构，所以Client可以使用Appium client libraries多种语言的测试脚本，而且Server端完全可以部署在服务器上，甚至云服务器。Session，每个Client连接到Server以后都会有一个Session ID，而且Client发送命令到Server端都需要这个Session ID，因为这个seesion id代表了你所打开的浏览器或者是移动设备的模拟器。所以你甚至可以打开N个Session，同时测试不同的设备或模拟器。Desired Capabilities，其实就是一个键值对，设置一些测试的相关信息来告诉Server端，我们需要测试iOS、还是Android，或者换是WebApp等信息。Appium Server是Node.js写的，所以可以直接用NPM来进行安装。Appium Clients，Mac OS和Win下提供GUI，不需要装Node.js，方便测试人员操作。

d.相关限制：如果你在Windows使用Appium，你没法使用预编译专用于OS X的.app文件，因为Appium依赖OS X专用的库来支持iOS测试，所以在Windows平台你不能测试iOS Apps。这意味着你只能通过在Mac上来运行iOS测试。

从方面的对比和优缺点分析不难看出。对于需要支持跨平台和需要支持WebView的应用，Appium的优势就比较明显了，因为Appium拥有了以上几大框架的所有优点：跨App，支持Native App、Hybird App、Web App，还支持N种语言来编写你的测试脚本。如果是只针对Android平台的应用，我还是比较推荐UiAutomator，特别是后面推出的UiAutomator2.0，此外，这两年，Google又推出了Espresso，它也应该是一个很优秀的框架，但是个人认为适合编程基础一般或刚入门同学（反正我是有点用不太习惯）。