“测试”在移动互联网界应该是耳熟能详的词汇了，目前几乎所有开发者在进行研发的过程中都要进行应用的测试，常用的使用模式大致有三类：
完全黑盒
基于脚本
基于录制回放
但使用过的朋友应该知道这三类模式都存在很难解决的缺陷，那么同作为开发的笔者，也是尝试、更换了无数的测试平台与工具，最终对自己的工作效率或者效果提升都不明显，而接下来，笔者将向大家推荐一款最近正在试用的一个自动化测试平台，目前来说效果还不错，经过笔者的研究和梳理总结，整理出了这个平台的构架与理念，希望各位做开发、测试的朋友能够有机会来尝试一番。
逻辑架构
应用服务
远程调试：提供手机的远程租用功能，实现远程调试App，提升解决bug的效率。
用例管理：提供了“管理用例”、“录制脚本”、“导入用例”的功能，此处用例作为回归测试的输入。 功能测试：提供App的远程功能测试，并记录操作过程，一旦测出bug，可以快速的找到复现步骤。
回归测试：选择用例进行回归，自动记录回归过程（包括截图和性能数据），并自动判断回归结果。
手机资源管理：提供手机物理状态和业务状态的各种管理功能，确保业务的正常进行。
消息队列：不同层次之间的服务通过消息队列进行通讯。
服务器
rDesktop：实现了从web端远程控制手机的功能，并实时显示手机屏幕的内容。
Recorder：在rDesktop操作手机屏幕的同时，通过分析用户操作，将之转化为自动化脚本。
Playback Engine：用于解释Recorder录制的脚本，并在特定终端进行回放。
终端
rDeskAgent：提供控制手机和抓取终端屏幕视频流的功能。
Connector：提供管理手机的基础功能（与O&M平台配合）。 TestServer：用于回放测试脚本。
手动操作数据流：用户操作 => rDesktop => 手机
图片视频数据流：手机 => rDesktop => 用户界面
自动化控制命令流：用户操作 => Playback Engine => 手机
信息收集数据流：手机 => 应用服务 => 用户界面
脚本录制数据流：用户操作 => rDesktop => 应用服务
用例概念
如图，用例采用直观易懂的“线性”模式，同时加入了“数据驱动”，使用例具备了可扩展性，方便Tester灵活处理脚本。这样的巧妙设计取得了复杂度与灵活性的平衡。 要实现这种灵活性，我们将每一条TestStep分为三大部分：屏幕构成、操作、结果：
屏幕构成：由截屏图片和Layout组成，通过图片和Layout相结合确定屏幕的构成，提升测试结果的准确性。
操作：由“手势”和“输入参数组成”，输入参数可以是写死的，也可以进行灵活配置。
结果：结果依赖于检查点，“录制”和“回放”时的屏幕构成决定这TestStep的执行结果。
总结
通过以上的讲解，相信大家对Quail平台有个大体上的认识，在后续的文章中，笔者将会通过对平台使用的图片流程来为希望更深入了解Quail的朋友展示更全面的信息。