07｜执行引擎怎么设计？任务的调度、并发、结果回传怎么实现？

开场先给执行引擎的架构定位：它是平台里独立于 Web 服务的一层（worker 集群）——接收任务、执行测试、回传结果，和平台的通信走消息队列或轮询。Web 挂了执行不受影响——这个分离架构是引擎设计的第一个认知。

回答思路

第一步：任务的生命周期管理（状态机）

创建（用户或定时触发，任务进队列）→ 分发（空闲 worker 领取）→ 执行（拉起测试进程、实时上报进度）→ 回传（结果落库、通知推送）。

状态机：排队中、执行中、成功、失败、超时取消——状态机讲全，说明想清楚了异常路径（worker 挂了任务怎么办：超时回收 + 重新分发）。

第二步：讲并发控制的三层

层	控制点
单 worker 内	进程或线程池跑用例
任务级	并发上限 + 排队和优先级——防一个用户的大任务占满资源
资源隔离	不同团队的任务资源配额——防互相饿死

并发三层的控制点报出来，是被真实流量教育过的设计。

第三步：讲结果的实时回传

• 执行日志的流式上报（用户在看板看实时日志——长轮询或 WebSocket）
• 进度的增量更新（跑到第几条）
• 失败的即时通知（关键任务失败马上推，不等全跑完）

实时性是执行体验的核心。

收尾：讲技术选型的参照（三档按规模选）

Celery + Redis 队列（Python 系的标准解）→ 自研调度（任务复杂后的定制需要）→ K8s Job（云原生环境按需拉起执行容器）。

考察重点

维度	说明
企业动机	Web 层好写引擎难做——这题是区分「写过页面」和「做过平台」的硬题，考察异步、并发、容错三个维度的工程能力
过线标准	分离架构 + 任务状态机 + 并发控制三层
区分度	讲 worker 挂掉的任务回收、日志流式回传、资源配额的是真设计过引擎的
加分项	K8s 按需容器的弹性方案
减分项	执行就是「接口里调 subprocess 跑测试」——同步阻塞无队列无状态管理，toy 级方案

来源

整理自知识星球帖《面试情报 08｜测试工具平台开发 20 题》，返回题库。