【架构艺术】自动化测试平台架构设计的一些通用要点

在Game-Of-AutoTest系列的文章当中，曾经深入聊到如何做好游戏自动化测试的技术实践，包括用例编写和任务调度等多个方面。由于工作原因，笔者再一次需要了解自动化测试平台的整体架构，因此也借着这个机会，从更加宏观的角度，再聊一下自动化平台架构设计的一些通用要点。

首先从细粒度的来讲，测试用例testcase管理是基础，一个最简单的测试用例需要包含标题、setup、执行步骤以及teardown等环节。而执行步骤里面，由于要做自动化测试，所以需要拆分成较细的step粒度，每个step粒度可能有不同的操作类型，比如正常和真机交互断言，或者是对外发送HTTP请求这类，都可以算作是一类步骤，所以如果有共性的步骤的话，也可以抽象出步骤集能力，方便多场景共用。再往宏观一点的话，testcase需要打标，需要通过集合、类别、场景以及业务等维度去做统一的管理。作为一个自动化测试平台，需要有这么样一套索引机制，让测试同学更好使用整套产品。

然后是自动化用例的执行，这里首先需要注意执行是有多个粒度的。假使一个大的客户端版本发布，那么这个版本可能对应多个OS的客户端，执行多个场景的用例。那么自顶向下来看，首先有那么一套集成测试任务，下面会挂很多个用例的子任务，每个用例可能在多端运行，如果单端运行失败也需要有历史记录，所以起码得有4张表去描述整一套业务集成测试这个事情。一个用例执行也需要关联很多内容，除了包体信息之外，机器调度、状态周知、环境变量、执行策略以及webhook等各种任务执行相关的元素都是需要考虑的，所以如果有共性的一些东西的话，也可以抽象出来任务模板能力，方便任务复用。

之后是任务调度、执行和监控。调度的话通常逻辑是先访问设备管理服务，给设备上锁，然后要求用例执行服务操作这个设备，执行自动化测试操作。任务执行过程中，就需要考虑如何保障任务执行稳定性，这部分先前的文章有聊，此处不再赘述。如果人力充足且服务数量较多的话，最好是通过MQ的形式在不同服务之间搭桥，驱动执行状态变化，这么做的原因正好是执行是多粒度且状态是相互依赖的，只有最小粒度执行状态变化了，粗粒度的执行才跟着变化，这样就不容易出现卡状态的情况。如果人力不充足的话，最好是统一通过外部定时任务推动任务状态执行跟补偿，这样服务间职责会更加清晰一些。

最后就是需要做好任务执行的trace模块，精确到每一个客户端执行的每一个Step，每一个Step需要记录操作日志、截图、结果以及思考等多类元信息，这样不论是调试用例还是排查线上问题都是非常方便的，能显著提升工作效率。从业务视角，自动化测试的稳定性和结果的可读性会显著动化测试问题是否能快速跟进，进而影响这个事情在业务里是否能长久的推下去。