Mock是什么？
Mock是为了构造数据而生，被测服务通常依赖于一系列的外部模块，而外部模块有时构造数据复杂，或者调用返回不好构造，这将影响被测系统的测试进度。为此以数据提供为主要目的的mock server应运而生。
思路灵感来源于：http://tech.meituan.com/mock-server-in-action.html。
简单的图片说明了mock server做的事情：
UI自动化中为什么要引入mock构造数据？
先来看一个例子：
以下是今日头条的热点tab页内容：
这个listview中每个item项中所包含的内容不相同，而UI自动化是基于界面控件展示的，所以假如listview中的某一个item中的内容不同时，这条用例就会失败。
其实造成失败的最终原因是数据是不稳定的。
Mock可以解决UI自动化中的哪些问题呢？或者说收益有哪些？
1.数据来源将变得可靠。
UI自动化只是关注数据在界面上的展示，通过mock server我就可以想要什么数据就可以构造什么数据，数据来源变得可变动，自定义，而且可靠。
2.一些更加贴近业务场景的自动化测试是否也变为了可能呢？
既然数据的来源我们可以控制了，那理论上可以与业务相结合的更密切，覆盖更多的业务场景，测试点也会变得很多，例如模拟网络异常、直接修改POST数据。
3.借鉴app自动遍历工具是否可以查出某些接口问题？客户端逻辑处理问题？
App自动遍历工具是某个大神写的工具：
https://testerhome.com/topics/4645
数据来源我们可以经过处理展示在客户端，可以定制化展示客户端内容，配置好参数与app自动化遍历工具结合的优点：
当然还可以查询出接口变动在客户端展示问题。
4.排查偶现问题是否变得更加简单？
在公司内有时经常会接到业务测试要求自动化操作复现某一偶现闪退问题，而有些闪退问题出现的几率往往比较低。假设数据来源变得可控制，那么这些偶现问题将变得简单，我可以自定义测试不同业务场景下的自动化测试情况，依据业务需求自动化测试可靠的数据下客户端的响应或者出现偶现闪退的几率。
Mock还有哪些局限问题？
1.做过UI自动化测试的同学大概都知道，UI自动化测试有两点是比较蛋疼而且不可控制的：
一个就是数据来源的不可控制，这个我们可以通过mock实现了；另一个就是网络情况不稳定，也可以称UI自动化测试为”不可靠不稳定的UI测试”。
目前对于不稳定情况，我也束手无策，又想保证客户端发起了请求又想保证服务端可以快速、可靠的返回数据，只有走单元测试了。
2.接口的变动、参数修改、变更等，将会导致你要修改部分匹配规则。
接口有时会根据版本迭代或者某些需求而变动，而这往往又需要接口测试人员通知我们改变了哪些内容，好让我们知道我们有哪些规则要改。所以沟通是在所难免的。
3.关于收益和付出。
付出可能也是比较多的，解决的问题如果mock能够搭建完成并且各业务线能够快速上手使用，我想它的收益将是巨大的。权衡来说就好像接口自动化平台一样，前期看不到多少收益，但是搭建起来后它可以解决很多问题。
关于mock的一些计划及想法：
1.环境及host设置以配置文件形式指定，分模块逐步完成业务测试用例抽离，哪些可以自动化用例执行的抽离出来，制定计划完成第一阶段模块自动化用例脚本编写，测试数据准备。
2.数据接口变更，做到接口变更及时了解，具体可以将按照业务线接口拆分，做到心中有数。
3.数据准备后期打算由各业务线测试给我提供。
4.设计一个类似美团(借鉴思路)mock的框架思路，制定属于自己的UI自动化测试架子。
虽然整体思路是有的，但这个东西真正要做起来其实并不是那么简单的，有时可能要上级领导认可肯定它的价值，有其他人支持，提建议等。如果各位看到这篇文章，有些建议的话，欢迎留言。