谈谈对自动化测试的理解
前言：
软件测试作为软件生命周期中不可缺少的组成部分，对提高软件质量起着重要作用。随着软件测试的发展，自动化测试技术也得到了很大提高。
本文首先介绍了自动化测试的概念、分类和现状，并分别对不同端上的自动化测试实现原理进行了详细地分析和阐述，通过对目前主流的一些自动化测试框架和工具的比较，指出了当前不同端上实施自动化测试的痛点和困难。
最后通过由数据驱动的自动化测试向关键词驱动的自动化测试的探索，进而由传统模式下的自动化测试转向基于AI的自动化测试的摸索，对自动化测试的未来进行了展望。
一、自动化测试的概念
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
二、适用自动化测试的项目特征
三、软件测试的分类
1、按项目流程：单元测试、集成测试、系统测试、回归测试、验收测试
2、按技术：黑盒测试、白盒测试、灰盒测试
3、按功能：逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试
4、按性能：时间性能测试、空间性能测试
5、按自动化：功能自动化、性能自动化
项目流程 + 自动化 → 分层测试：unit测试（单元测试）、service测试（接口测试）、UI测试
四、自动化测试的现状
1、单元测试（极限编程-测试驱动开发），占比70%
（1）对软件中最小可测试单元进行检查和验证
（2）由开发人员编写，检验测试单元的语义是否正确
（3）一般在构建阶段执行自动化测试脚本
（4）代表工具：XUnit等
2、接口测试，占比20%
（1）测试系统组件间接口的测试
（2）主要是保证接口的正确和稳定
（3）代表工具：Jmeter、Postman等
3、UI测试，占比10%
（1）验证布局是否合理、风格是否一致等等
（2）确保UI功能内部的对象符合预期
（3）代表工具：selenium、robot framework等
4、小结
（1）单元测试借助对应语言的测试框架，可以做到在构建时执行测试脚本，难度较小
（2）接口测试通过定义好每个用例的输入和输出，借助接口测试工具，也可以实现自动化，难度不大
（3）UI测试更多是与界面渲染相关的，包括元素的位置、大小是否正确，元素内容是否正确等等，主要是对界面渲染后的结果进行测试
五、不同端上的UI自动化测试
要判断渲染界面是否满足预期，首先就需要具备操控终端界面的能力，通过定位元素获取元素的信息与预期结果比较。
注意：这仅仅属于功能性测试的范畴，如果包括多媒体内容的话，还需要借助其他手段进行比较。
而操控终端界面的能力也随终端的不同而不同，这里主要是PC端和移动端的区别。
1、PC端：
每个浏览器厂商都会提供相应的driver，它们都实现了Selenium定义的WebDriver's wire protocol，通过这个协议可以操控浏览器做任何事情！
这个driver会启动基于这个协议的web服务，实际上就是在一个端口上监听http请求，根据不同的请求执行不同的操作。
代表框架：
以Selinium为例，实现原理如下：
2、移动端：
与PC端上原理类似，但又有Android与IOS的区别
Android：主要基于UIAutomator和UIAutomator2，更早的可以追溯到instrumentation框架。
（1）instrumentation可以把测试包和目标测试app加载到同一个进程中运行，以此实现对app的控制。
之后封装形成Selendroid架构
（2）UIAutomator是谷歌在Android4.1版本发布时推出的基于Java编写的UI测试框架，与Bootstrap配合使用。
其特点是可以跨进程操作，可以获取屏幕上任意一个app的任意一个控件属性并对其操作。
但不足的是只能用Java编写，且测试脚本必须上传到设备上运行。
（3）UIAutomator2修复了原有版本的bug，还增加了很多新功能
1.设备和开发机可以脱离数据线，通过WiFi互联（基于atx-agent）
2.集成了openstf/minicap达到实时屏幕投频，以及实时截图
3.集成了openstf/minitouch达到精确实时控制设备
4.修复了xiaocong/uiautomator经常性退出的问题
5.代码进行了重构和精简，方便维护
6.实现了一个设备管理平台(也支持iOS) atxserver2
IOS：主要基于UIAutomation，Xcode 7之后引入UITesting
（1）通过UIAutomation操作app时，UIAutomation会给app发送WM_GETOBJECT的消息
如果app处理WM_GETOBJECT消息，实现了UIAutomation Provider，并调用了下面的函数，则该app支持UiaReturnRawElementProvider(HWND hwnd, WPARAM wparam, LPARAM lparam, IRawElementProviderSimple *el)IRawElementProviderSimple就是UIAutomation Provider，包含了控件的各种信息，如Name，ClassName，坐标等。
因此，app想要支持自动化，就必须实现UIAutomation Provider，详情请参看《UI Automation Client Programmer's Guide》
（2）UITesting是苹果公司推出，在Xcode 7引入的UI自动化测试框架，其原理利用了IOS的Accessibility
1.Xcode 自带，不需要搭建环境
2.支持 OC、Swift，学习成本低
3.支持 WebView 测试
4.稳定性好
六、常用的移动端自动化测试框架
下图列举了一部分测试框架在一些指标上的表现，除了这些，还有Robot framework、阿里的macaca框架等也可以考虑。
七、移动端自动化测试的具体实现
一千个嘴把式，不如lai个手把式！
下面这一段自动化测试脚本代码基于Appium实现了在app里截屏的功能：
当然，除了写好测试脚本以外，还有很多工作需要准备
usb要连接好设备，设备需要打开开发者模式
安装好目标测试app的debug包
检查chromeDriver的驱动版本是否与设备匹配
可能遇到其他未知问题......
下面是基于Robot framework的自动化测试脚本片段
八、移动端自动化测试的探索
1、基于数据驱动的自动化测试 → 基于关键字驱动的自动化测试。
从以上具体实现中可以看出，要针对一个测试用例编写出对应的测试脚本，这需要的代码量不算少，并且还需要对每个方法的定义和输入输出十分熟悉。
因此，要实现UI层面的自动化测试，成本很高，甚至超过了收益。
所以，如果可以让测试脚本的编写变的简单，那么将大大改善现状。
2、探索
仔细观察上述具体实现，可以发现，一个测试脚本是可以由多个测试用例组成，而每一个测试用例又可以是由多条语义清晰的指令构成的。
于是这就可以考虑对其进行抽象，这也是策略模式的一种具体应用，主要包括三个方面：
1.界面元素名与测试内部对象名的分离。
将界面上的所有元素映射成相对应的一个逻辑对象，测试针对这些逻辑对象进行，界面元素的改变只会影响映射表，而不会影响测试。
2.测试描述与具体实现细节的分离，把测试描述和测试的具体实现细节分离开来。
测试描述只说明软件测试要做什么以及期待什么样的结果，而不管怎样执行测试或怎样证实结果。
这样做是因为测试的实现细节通常与特定的平台以及特定的测试执行工具有着密切的联系。
这种分离使得测试描述对于应用实现细节是不敏感的，而且有利于测试在工具和平台间的移植。
3.脚本与数据的分离。
把测试执行过程中所需的测试数据从脚本中提取出来，在运行时测试脚本再从数据存放处读取预先定制好的数据，这样脚本和数据可以独立维护，如果对软件测试、接口测试、自动化测试、面试经验交流。感兴趣可以加测试交流群：829792258，还会有同行一起技术交流。
九、移动端UI自动化测试的展望
一个完整的移动端UI自动化流程应该是包括功能和视觉两部分内容的。
在功能方面，尽管利用一些主流框架可以实现自动化，但编写脚本的成本依然很大并且很复杂。
在视觉方面，更是需要依赖图像识别、图像相似度匹配、音频匹配等等技术手段。
所以，目前针对移动端UI的自动化测试还是困难重重，并没有一个成熟的解决方案。
