概述
这次分享的主要内容包括以下3个部分：
1、Spider功能介绍；
2、介绍相关背景；
S、pider功能实现。
Spider的主要功能
· 同时查看、修改、共享多台设备API接口数据；
· 接口测试数据存储和回放；
· 同时操作多台设备。
功能展示
回放测试数据并跳转
多设备兼容性测试
背景介绍
移动App的测试经常要对同样一个页面，不同逻辑的页面展示和功能进行测试。一般会通过MOCK API接口返回不同的数据，去测试页面的多种样式的展示；为了覆盖到所有样式的逻辑组合，需要花较多时间去准备测试数据。
上面的三个页面，其实是同一个页面（购买结果页），根据API回传的数据不同，展示不一样的样式和提示文案。这种情况如果不借助工具的话，手工测试会比较麻烦，需要真实购买测试团购单，然后通过修改数据库状态字段模拟购买结果的三种不同状态，这样测一个页面的展示就要花很长的时间。
使用Spider的固化数据功能，在1分钟之内就可以完成购买结果页多种不同状态的展示测试。
客户端请求流程图
首先，App的请求流程如上图所示，移动App把请求发送给Web层的API Server，API Server再去调用服务端各个应用获取数据，并整合之后返回给App，这个时候App才能展示正常的数据。这时如果需要制造或者修改测试数据的话，我们可能要深入到最后一层去修改，需要了解服务端各个应用的调用逻辑和对应的DB读写，增加了测试App的时间成本。如果测试会有数据库写操作的，数据测试一次之后就变更了，下次还得继续改，非常耗时。
接入Spider之后客户端请求流程图
这个时候在App和API中间加一层“Spider请求处理模块”来操作App的数据。App先发请求到Spider，Spider来判断这个请求是否继续往后面走，如果需要返回固化测试数据，则直接将准备好的测试数据序列化之后发送给App。如果不需要返回固化测试数据，Spider会把请求原封不动的转发给API，并将从API的返回结果返回给App。
点评列表页
给大家看一下点评App的列表页，每一个商户标题右侧的小标签都由API接口的某个字段代表，像这么多的情况记的话真的是很难，而且一个个把数据整合起来也是非常花时间的。像这样一个页面，以前列表页的测试可能要需要两三个小时，每一次发版前需要做回归测试的时候，数据到底哪个代表什么可能不太记得了。这时使用Spider储存的测试接口数据，直接点击一下页面就能跳转并返回特定的测试数据了。
