2. Serverless 计算基础：FaaS 与 BaaS 概念、冷启动与热启动、无状态特性对测试任务的影响
在深入资源调度优化之前，必须厘清 Serverless 计算的核心抽象层。自动化测试任务在 Serverless 流水线中的行为，本质上受 FaaS 与 BaaS 的边界、冷热启动的延迟模型以及无状态约束的支配。本章从这三个基础维度展开，并直接关联到测试任务的执行特征。
2.1 FaaS 与 BaaS：测试任务的执行边界
Serverless 架构由两大服务模型构成，它们共同定义了测试代码的运行环境和数据持久化方式：
| 维度 | FaaS（函数即服务） | BaaS（后端即服务） |
|---|---|---|
| 核心职责 | 运行无状态、事件驱动的函数代码 | 提供托管的后端数据与中间件服务 |
| 测试任务中的角色 | 执行测试用例、断言逻辑、报告生成 | 存储测试结果、管理测试配置、提供 mock 数据源 |
| 计费粒度 | 按调用次数 + 执行时长（毫秒级） | 按存储量、请求次数或连接时长 |
| 典型服务 | AWS Lambda、阿里云函数计算、Azure Functions | AWS DynamoDB、阿里云 OSS、Firebase Auth |
| 对调度的影响 | 直接决定测试任务的并发上限与执行成本 | 影响测试数据的读写延迟与一致性 |
实践要点：在流水线中，应将测试逻辑封装在 FaaS 函数内，而将测试夹具（fixture）、历史报告、环境变量等静态资源托管在 BaaS 中。这种分离使得测试函数可以保持轻量，便于快速扩缩容。
2.2 冷启动与热启动：测试任务的延迟模型
FaaS 函数的启动状态直接决定了测试任务的响应延迟。理解冷热启动的差异，是优化资源调度策略的前提。
- 冷启动：当函数实例在请求到达时尚未存在，平台需要完成代码下载、运行时初始化、用户代码加载等步骤。延迟通常在 100ms ~ 5s 之间，取决于运行时大小与依赖数量。
- 热启动：函数实例已被保留在内存中，请求到达时直接执行处理逻辑。延迟通常在 1ms ~ 10ms 级别。
- 温启动：介于两者之间，实例存在但部分资源（如数据库连接池）需要重建，延迟约 10ms ~ 100ms。
测试任务的关键影响：对于高频、短时的小型测试（如单元测试），冷启动延迟可能超过测试执行本身的时间，导致整体流水线效率下降。对于长时间运行的集成测试，冷启动占比相对较小，但资源预热策略仍然重要。
2.3 无状态特性对测试任务的影响
FaaS 函数天然无状态——每次调用都可能运行在不同的容器或沙箱中，本地文件系统、内存变量在调用结束后即被回收。这一特性对测试任务的设计与调度提出了明确约束：
- 测试结果必须外部化：断言结果、日志、覆盖率数据不能依赖函数本地存储，必须显式写入 BaaS（如对象存储、数据库）。
- 测试依赖必须显式注入：环境变量、密钥、测试数据需通过 FaaS 调用参数或 BaaS 服务获取，不能依赖本地配置文件。
- 并发测试的隔离性：由于每个函数实例独立，测试用例天然隔离，无需担心共享状态污染。但这也意味着共享资源（如数据库）需要处理并发写入。
- 重试与幂等性：函数可能因平台故障被重试，测试任务必须设计为幂等，避免重复执行导致数据重复或状态错误。
常见陷阱：将测试中间结果写入函数本地
/tmp 目录，并假设后续调用可以读取。在 Serverless 环境中，/tmp 仅在单次调用生命周期内有效，且不同调用之间不共享。必须使用 BaaS 服务（如 Redis、S3）实现跨调用数据传递。
2.4 综合影响：测试任务调度设计原则
基于上述三个基础概念，可以提炼出 Serverless 流水线中测试任务调度的核心设计原则：
| 原则 | 描述 | 对应基础概念 |
|---|---|---|
| 预热池策略 | 为高频测试函数保持最小活跃实例数，避免冷启动延迟 | 冷启动与热启动 |
| 外部化状态 | 所有测试结果、日志、中间数据写入 BaaS，不依赖本地存储 | 无状态特性 |
| 幂等设计 | 测试函数支持重复执行而不产生副作用 | 无状态特性、FaaS 重试机制 |
| 资源解耦 | 测试逻辑与测试数据分离，数据通过 BaaS 动态注入 | FaaS 与 BaaS 边界 |
| 并发隔离 | 利用函数实例天然隔离性，无需额外加锁 | 无状态特性 |
本章小结：Serverless 计算基础直接决定了自动化测试任务在流水线中的执行模型。FaaS 提供弹性执行环境，BaaS 提供持久化底座；冷启动是延迟优化的主要矛盾；无状态特性要求测试任务必须采用外部化、幂等化的设计范式。后续章节的资源调度优化策略，均建立在这三个基础概念之上。