需求来源：在项目中，需要对UI进行测试，确保UI逻辑的正确性。在UI逻辑测试中，用例的编写是一个”劳动密集“型任务，需要一边操作，一边编写用例的步骤，为了能够清晰准确的描述操作，还需要很多辅助描述信息。如果考虑到后期的回归测试，以及UI修改变更维护，这个事情将严重影响团队的测试效率。
目标
人工操作是不可避免的，在产品发布后，人工必须将所有功能都执行一次。如果能够将人工执行动作自动转换为用例操作步骤，那么将极大提高测试效率。事实上，已经存在一些类似工具，例如比较知名的QTP。核心概念就是记录-回放。
既然已经存在了相关工具，重新设计的意义何在？主要有两大原因：一，现有工具是国外产品，版权存在限制，在当今国际形式下，存在极大的版权风险；二，现有工具开放性不足，扩展性差，不适合自身使用需求。
与国外现有工具相比，本工具将主要满足以下特点：
- 支持与禅道进行用例管理集成；
- 支持基于图形、句柄、文字识别多种方式进行记录；
- 支持快捷键模式切换；
- 支持快捷键添加结果验证；
- 支持记录、回放扩展，以应对不同应用场景；
- 支持多端应用测试；
- 针对大型项目，能够进行多人协作用例设计；
核心点：
- 扩展性，支持不同执行记录、回放实现；
- 开放性，能够与不同项目管理平台集成；
- 高效性，通过快捷键将用例设定操作集成在被测系统使用过程中；
- 多人协作；
- 统一性，实现多端统一，支持桌面、web、手机APP、嵌入式。
整体设计
流程划分
在记录-回放模式下，主要有三个核心流程：执行记录、记录编辑、记录回放。执行记录，主要根据用户执行，自动生成“记录”，也就是自动化执行的脚本。记录编辑，是针对自动生成“记录”的编辑过程，目的是删除记录中的冗余动作，提升记录的鲁棒性。记录回放，是针对记录的自动执行。
其中，执行记录与记录回放是系统的核心流程，影响了系统的可用性，记录编辑影响了系统的易用性。
业务概念
在系统测试中，用例主要源于需求，同一个用例可以覆盖率多条需求，同一需求也可以由多条用例覆盖满足。需求与用例之间是一种多对多的关系。一个用例由多个执行步骤组成，执行步骤是用例的最小组成单元。在用例描写中，存在前置条件的设定，前置条件可看作一组共用的执行步骤，从这个维度来讲，用例完全由执行步骤组成。
在本系统中，存在四个业务概念：执行步骤、执行逻辑、用例、可变参。执行步骤是可被多个用例复用的基本操作单元。执行逻辑是对执行步骤的组合，包含执行控制逻辑，分支、循环。用例是执行步骤与执行逻辑的组合，精确的描述了执行过程。可变参代表了执行步骤、执行逻辑、用例中可被修改变化的内容，是用例自动化执行的核心，在执行步骤中，可变参体现在输入信息的可变，在执行逻辑中，可变参体现在控制逻辑（例如，循环次数）的可变中。
体系架构
顶层架构
从目标需求（多人协作）与业务逻辑（执行步骤复用）出发，系统整体架构为C/S架构模式，服务器主要用于测试数据（主要指执行步骤、用例）管理，客户端主要用例产生、访问、执行记录数据，以及与第三方管理平台进行数据集成。
顶层数据流架构
系统与第三方系统集成时，主要的交互数据是用例。用例数据将以两种形态存在，一种是由执行逻辑与执行步骤生成的执行描述文件（包含用例唯一ID，以及执行步骤描述）；另一个是精确的逻辑执行文件，包含了即时冻结状态（即支持历史版本使用，当然也支持最新版本标记使用）的执行步骤、执行逻辑、资源文件等。
用例与第三方平台是否同步，由系统使用者决定。第三方平台用户登录信息，只保存于客户端本地数据中，更换机器后，需要重新输入。
系统分层架构
系统主要功能集中于客户端，所以将主要针对客户端进行细节阐述。系统将主要构建为四层，从上到下分别为：业务层、扩展层、业务基础层、基础层。基础层，主要是公共基础服务模块的封装，例如日志。业务基础层，是与项目相关性极大的基础模块封装，例如鼠标事件监控模块。扩展层，是针对业务基础层中模块的扩展，例如基于图像处理的屏幕对象识别扩展实现。业务层,针对业务要求，实现记录-回放。业务层，在细节上，又被划分为三个小层，分别为UI层、业务扩展层、业务逻辑层。
在系统实现中，业务基础层与扩展层包含的主要模块有：交互监控模块、交互控制模块、对象识别模块、记录生成模块、记录执行模块、数据管理模块。业务层包含的主要模块有：执行记录模块、业务交互模块、用例编排模块、业务扩展模块、用例编辑执行系统。
关键业务操作流程
核心操作流程如下：
- 新建/打开项目；
- 新建用例；
- 选择/新建、记录执行步骤；
- 重复3，直到完成所有执行步骤；
- 编辑执行逻辑（工作流引擎图形式）；
几个要点说明：
- 选择一个已经存在的执行步骤时，设置可变参后，自动执行该执行步骤；
- 在已存在的用例中，在某执行步骤前，打开/新建执行步骤时，执行步骤可针对后续执行步骤（一个或多个）设定插入、替换、分支等操作；
- 在记录编辑中，应能单独执行某执行步骤，对于快速编辑记录有重要意义。
关键技术
在本项目中，核心难点是对象的识别与匹配，如何能够高效、准确、高鲁棒的进行对象识别、匹配，是本项目可用性中最大的影响因素。
后注
本文是针对UI自动化工具的一个思考，是一个开端，既不完整也不完善。一个完整的设计，应该具有以下特点：
- 充分的领域调研；
- 需求驱动的架构设计；
- 架构设计不仅是空间完整，还应该是时间完整的。
前两点应该没有疑问，很好理解。针对第三点，空间完整主要指，架构设计应该要包含细节，能够充分展示最终系统的设计细节，而不应该仅仅是几个模块组成、交互图，时间完整主要指，架构设计应该指示演进过程。一个复杂系统，并不是一下完成所有细节，而是经过多次迭代，逐步完善的过程。
针对以上不足，我将在另一篇文章中，进行更加完整的描述。
