上一篇我们讨论了为什么要开发自动回归测试平台“Quail”，那么今天，Bird就来告诉大家Quail平台的架构是什么样的？平台的设计理念是什么？

逻辑架构

应用服务
远程调试：提供手机的远程租用功能，实现远程调试App，提升解决bug的效率。
用例管理：提供了“管理用例”、“录制脚本”、“导入用例”的功能，此处用例作为回归测试的输入。
功能测试：提供App的远程功能测试，并记录操作过程，一旦测出bug，可以快速的找到复现步骤。
回归测试：选择用例进行回归，自动记录回归过程（包括截图和性能数据），并自动判断回归结果。
手机资源管理：提供手机物理状态和业务状态的各种管理功能，确保业务的正常进行。
消息队列：不同层次之间的服务通过消息队列进行通讯。

服务器
rDesktop：实现了从web端远程控制手机的功能，并实时显示手机屏幕的内容。
Recorder：rDesktop操作手机屏同时，通过分析用户操作，将之转化为自动化脚本。
PlaybackEngine：用于解释Recorder录制的脚本，并在特定终端进行回放。

终端
rDeskAgent：提供控制手机和抓取终端屏幕视频流的功能。
Connector：提供管理手机的基础功能（与O&M平台配合）。
TestServer：用于回放测试脚本。

手动操作数据流：用户操作=> rDesktop => 手机
图片视频数据流：手机=> rDesktop => 用户界面
自动化控制命令流：用户操作=> Playback Engine => 手机
信息收集数据流：手机=> 应用服务=> 用户界面
脚本录制数据流：用户操作=> rDesktop => 应用服务

用例概念

如图，用例采用直观易懂的“线性”模式，同时加入了“数据驱动”，使用例具备了可扩展性，方便Tester灵活处理脚本。这样的巧妙设计取得了复杂度与灵活性的平衡。

要实现这种灵活性，我们将每一条TestStep分为三大部分：屏幕构成、操作、结果：

●屏幕构成：由截屏图片和Layout组成，通过图片和Layout相结合确定屏幕的构成，提升测试结果的准确性。

●操作：由“手势”和“输入参数组成”，输入参数可以是写死的，也可以进行灵活配置。

●结果：结果依赖于检查点，“录制”和“回放”时的屏幕构成决定这TestStep的执行结果。

总结

通过以上的讲解，相信大家对Quail平台有个大体上的认识，那么在后续的“系列三”中，Bird会向各位小伙伴展示平台使用情况的动态流程图，让你能够更加直观地了解我们的Quail系统。