Firebase Test Lab迁移Developer Device Platform：APP加固测试流水线怎么改？｜御盾

Firebase Test Lab已进入弃用周期，并计划于2027年9月30日完全关闭；Google把Developer Device Platform列为迁移方向，而Android Device Streaming仍会作为该平台的核心能力继续提供。 迁移不应只替换一条命令：团队还要逐项核对测试类型、设备目录、运行权限、测试输入、结果工件、费用与发布门禁。Developer Device Platform目前处于Preview / Pre-GA阶段，迁移计划应保留验证与回退空间；本文不表示御盾已执行Test Lab或DDP迁移、云真机运行或加固候选测试，相关设备运行与迁移记录均为NOT_TESTED。

摘要

Google正在将设备访问与测试服务汇集到Google Cloud原生的Developer Device Platform（DDP）。官方列出的能力包括Device Run、Device Streaming API、Agent Skills与Device Catalog；测试团队可根据原有测试类型分别核对对应能力，而不是假设所有Firebase Test Lab功能和行为已经一比一迁移。对APP加固团队，迁移的重点是确保相同业务版本、相同测试条件下，未加固基线与保护候选仍然有可比结果，并将设备Build、候选摘要、业务断言、Crash/ANR和结果工件绑定到同一条记录。

读者对象

本文面向正在使用Firebase Test Lab的Android QA、研发效能、移动安全与发布团队，也适合把真机测试纳入APP加固验收的项目负责人。如果当前只使用Test Lab的某一种测试模式，应从该工作流的输入、设备、权限、输出和计费逐项迁移；如果同时使用虚拟设备、物理设备、Robo或Instrumentation等不同能力，则应分别盘点，不能用一次连接远程真机成功来代表整套测试服务已经迁移。

核心结论

1. Firebase Test Lab预计在2027年9月30日完全关闭；Google建议在该日期前迁移到Developer Device Platform。
2. DDP目前为Preview / Pre-GA；在正式迁移前，需验证目标项目权限、设备目录、支持能力、服务等级、费用与结果保存方式。
3. Android Device Streaming不会随Firebase Test Lab一起弃用，而是DDP的核心能力之一；它与Device Run的用途不同，不能将交互式远程设备连接等同于完整测试运行平台。
4. Test Lab到DDP没有可在本文声称的自动一键迁移或全面行为一致性；既有测试流程需要按能力、命令、数据、工件和CI权限逐项核对。
5. 本文没有执行御盾候选、设备预约、测试命令、云费用或迁移流程；御盾相关测试状态保持NOT_TESTED。

事实依据与脱敏证据

来源：Firebase Test Lab迁移指南、Test Lab弃用FAQ、Firebase Release Notes、Android CLI远程设备命令。以上内容按2026年10月4日可访问的公开文档整理，产品状态、计费与设备目录后续可能调整。

技术拆解：Firebase Test Lab与Developer Device Platform不是同一个名字的更换

Firebase Test Lab以测试服务的方式承载设备测试工作流；DDP则被Google描述为Google Cloud原生的远程设备编排平台。这个产品层级变化意味着迁移除了调整命令，还需要重新审查身份与授权、项目资源、设备预订、运行结果、日志与工件的归档策略。原来在Firebase Console里完成的一项操作，在DDP中可能对应不同的产品入口或权限配置，具体以迁移指南和当前项目中的实际能力为准。

官方列出的DDP能力可以帮助团队先分类，而不是过早承诺“全部兼容”：

• Device Run：在DDP设备实验室运行测试并查看结果，适合核对原有自动化测试提交与结果读取流程。
• Device Streaming API：连接远程Android物理设备，并像设备连接到本地工作站一样与应用交互；具体预约、连接和ADB使用以相应文档为准。
• Agent Skills：帮助AI coding agent查找、预订和交互设备。Skill是工作流指引，不是测试结果，也不应获得超出执行任务所需的权限。
• Device Catalog：用于查找、筛选和检查平台内的设备。设备目录是可用设备的清单，不等于覆盖所有市场机型或OEM版本。

上面的能力不是迁移映射表的最终答案。团队应把当前每个Test Lab工作流拆成执行方式、设备类型、触发参数、权限主体、测试数据、结果读取、失败通知和工件保留，之后再在DDP里验证对应能力是否覆盖。如果某项能力目前没有明确迁移路径，应列为待解决项，而不是用相邻功能替代并标记完成。

工程落地：从现在到关闭日期的迁移阶段

阶段一：盘点当前工作流

先从CI配置、测试脚本、项目设置与团队操作手册中列出所有Test Lab入口。按运行类型分组，记录设备选择方式、测试包输入、测试账号或数据、运行时长、重试规则、失败判定、通知对象与结果保存位置。对手工启动的控制台测试也要记录，不要只检索CI文件。

盘点的输出应当是可审查的清单，例如每行对应一个实际工作流，而不是“我们使用Test Lab做回归”这样无法验证覆盖面的描述。标明负责人、执行频率、重要级别、依赖服务、所需地区或设备能力，以及是否包含真实用户数据。任何私钥、生产令牌和客户数据都不应写入公开迁移文档或给Agent的执行上下文。

阶段二：做能力映射与差异标注

将每项旧工作流与DDP能力对应，区分Device Run、Device Streaming、Device Catalog、Agent Skill等用途。标记为“已映射”“待验证”“无直接对应”或“不再需要”，并注明证据来自官方文档、试点执行还是团队假设。不能因为同属远程设备测试，就默认设备镜像、测试超时、并发配额、结果工件、API响应或账单规则相同。

尤其要区分自动化测试与交互式设备连接。Device Run面向在设备实验室执行测试的流程；Device Streaming提供与远程物理设备交互的通道。二者可能服务于相邻的质量任务，但不应只按界面相似度互换。凡涉及Robo、游戏循环、Instrumentation、自定义脚本或额外附件的旧任务，需查看专门迁移指南与当前服务文档，不能根据本页概括推断。

阶段三：选小范围试点并建立双跑

选择一个低风险但能代表实际流程的试点：固定一份已授权的测试构建、少数目标设备和有明确断言的用例。先在原Test Lab中保留现行基线，再在DDP中单独运行，记录两边所用产品能力、设备型号/Build、参数、权限、开始结束时间、结果和日志工件。双跑期间不要将“都显示通过”直接理解为输出语义相同；需确认失败分类、截图/日志、崩溃信息和重试含义能够满足团队的诊断要求。

对加固兼容回归，使用同一业务版本比较Original、Basic、Target和Final Signed等候选时，要固定测试设备、系统Build、测试数据与关键路径。保护版本是否可用、签名是否符合测试要求、业务账号能否执行路径，都要在开始前确认。如果不同候选同时改变了业务依赖、服务端开关、签名或渠道配置，测试结果就不能简单归因于加固。

试点失败时，将其拆分为环境问题、访问/授权问题、设备可用性、测试输入、测试代码、应用行为或结果工件问题。迁移系统本身的环境失败不应记为应用版本不兼容；同样，测试runner退出也不能直接记作应用通过。每个未完成项都应指定下一步和负责人，避免试点报告留下无归属的“未知”。

阶段四：迁移CI权限、计费和工件保留

切换前重新设计CI身份与权限：哪些工作流可以预约设备、谁能访问Cloud项目、Agent是否允许发起远程操作、何种操作需要人工审批、失败后如何清理预约。将凭据存储在组织批准的秘密管理系统中，不在仓库、构建日志或公开文档中保存访问令牌。Agent可执行受限的重复测试，但最终发布审批仍应由有职责的工程人员承担。

同时确定测试结果与日志留存策略。记录系统Build、设备型号、候选类型、产物摘要、测试场景版本、失败步骤和产物工件地址，保留足以复查的摘要，同时按数据分类要求清除账号信息和敏感日志。若测试会访问后端，使用专用测试租户、合成账号和可回收数据，不要把生产业务数据当成迁移验证材料。

计费也要作为迁移的一部分：DDP要求项目启用Billing，且官方当前说明其价格将在2027年4月30日之后转向新的计价方案。财务负责人应核实当前项目实际适用的费率、免费额度、设备槽选项、并发策略和税费，不应把某一页面上的单价直接当作全部团队的月度账单。按设备数、候选数、场景时长与重跑次数建立预算上限，并为自动化任务设置最大时长、取消策略和异常停机条件。

阶段五：设定切换条件并归档旧链路

切换条件可以包括：关键工作流已经通过DDP试点；必要设备可用；CI身份与授权经过复核；测试结果和工件可检索；费用监控已启用；回滚或人工替代路径已明确。逐条确认责任人和日期，之后再把默认流水线从旧平台切换到新平台。不要等到关闭前最后几周才第一次执行主路径。

切换后保留历史Test Lab结果的可读性和索引信息，避免把旧报告、日志和新平台结果混在同一个未标注的目录中。对历史版本的回归结论，保留原来的平台、设备和Build字段；它们说明的是当时那次执行，不应被覆盖成新的DDP状态。DDP目前仍是Preview，迁移后也要持续关注官方状态、支持范围与费用公告。

APP加固兼容验收应该迁移哪些证据

只搬运测试脚本，会丢掉保护候选之间的归因依据。对御盾或其他APP加固项目，建议每一条兼容性记录都绑定以下上下文：

• 版本身份：业务Commit或Release版本、包版本、变体、最终产物摘要与候选类型。
• 设备状态：设备型号、系统版本、系统Build、API级别、ABI与可用硬件能力。未能读取的字段标记为未知，不猜测。
• 场景定义：测试用例版本、前置条件、账号类型、业务断言和数据清理方式。
• 执行信息：实际运行平台、测试时间、是否重试、退出原因、安装/覆盖升级状态与环境故障。
• 观察结果：启动、关键路径、Crash、ANR、崩溃摘要、日志工件和未覆盖事项。
• 复核责任：测试执行者、复核人、结论时间和是否允许进入下一阶段。

这个记录不能只写一个全局PASS。例如Original通过、Basic通过、Target未执行、Final Signed环境不具备，应分开记录；某一Beta或远程设备的结果也不代表正式版、其他OEM build或用户群体已经通过。准确表达范围，会比把稀疏样本包装成“全面兼容”更利于后续故障复现与决策。

御盾的公开兼容性中心已经提供通用验收框架；Android CLI Device Streaming兼容回归页面讨论真实设备回归的候选和证据字段，APP加固PoC验收指南负责更完整的商业验收流程。它们描述的是方法，不代表本文或御盾已执行DDP测试。

迁移决策矩阵

上表是迁移计划中的核对项，不是已执行的DDP能力认证。具体产品功能和可用设备应以当前官方文档、Google Cloud Console与项目设置为准。

风险边界与需要重新评估的事项

DDP处于Preview意味着项目团队应把产品可用性、支持渠道、额度与服务变更作为迁移风险管理的一部分。试点成功也只能说明已验证的测试任务、设备和项目状态可工作，不能证明旧平台每个脚本、设备型号与报告字段都已迁移。设备目录和权限可能按区域、项目设置或产品阶段变化，因此每个切换批次都应保留清晰的适用范围。

对APP加固结果还要分开平台迁移风险和应用保护差异。若Original与加固候选在同一DDP设备上都失败，先调查测试环境、业务基线和设备条件；若差异首次出现在某个保护候选，则再做复测与候选差异审查。单次对照只能缩小排查范围，不能自动证明根因。最终发布仍需针对正式签名包、目标渠道和关键设备按组织发布规则复核。

不要在公开证据页暴露Google Cloud项目标识、访问令牌、客户包名、完整测试账号、原始日志或私人APK。迁移计划里的待办、估算费用、设备计划和未执行结果不应写成产品已验证能力。本文没有使用客户APK、生成测试账号、调用设备预约或提交测试作业。

测试目标与非目标

本页主目标是说明Test Lab迁移至DDP时，怎样保持加固候选回归条件可追溯，并识别迁移平台本身的差异；非目标是宣称DDP与Test Lab完全等价、证明御盾在某设备兼容、评估某个客户项目成本或代替团队执行迁移。以下矩阵用于迁移规划，当前没有执行结果。

攻防视角：自动化执行不等于自动放行

远程设备与Agent扩大了可重复执行的范围，也扩大了测试输入和日志进入云环境的范围。测试团队应使用合成账号和专用测试项目，限制Agent只能访问必要的测试文件和设备操作，不提供生产签名私钥、长期后台Secret或真实客户数据。必要时将关键动作配置为人工确认，并为超时、重复预约和失败重跑设上限。测试结束后按组织要求清理会话和敏感工件。

兼容性门禁需要分离三种职责：平台负责提供设备与执行能力；Agent或脚本负责按定义重复操作并采集获准的数据；发布负责人负责核对断言、异常归因和是否接受候选。成功安装或没有出现Crash，不等于核心业务路径完成，也不代表加固强度、反逆向或所有设备兼容性已经得到证明。

常见误区与FAQ：Test Lab迁移与APP加固测试

Firebase Test Lab何时关闭？

Google当前迁移指南和弃用FAQ将2027年9月30日列为完全关闭日期，并说明届时Test Lab Console和API不再支持原工作流。建议团队在该日期前完成迁移计划和真实项目验证；具体进度还应以官方更新为准。

Developer Device Platform是Firebase Test Lab的新名字吗？

不是。Google把DDP描述为Google Cloud原生的远程设备编排平台和迁移方向，并列出Device Run、Device Streaming API、Agent Skills与Device Catalog。它需要按实际测试需求评估，不能只改产品名称或端点后宣称迁移完成。

Android Device Streaming会随着Test Lab关闭吗？

不会。Firebase官方FAQ明确表示Android Device Streaming不弃用，它将作为Developer Device Platform的核心能力继续受到支持。此结论只针对Android Device Streaming；不能由此推断Test Lab Console、API或其他所有服务均继续保留。

Device Streaming能完全替代Device Run吗？

不应假设可以。官方将Device Run描述为在DDP设备实验室运行测试，将Device Streaming描述为连接远程物理Android设备并进行交互。团队应根据现有测试类型、运行机制和结果工件选择相应能力，并用真实项目验证。

迁移是否可以等到2027年9月再做？

不建议把试点推到关闭前。官方已建议在关闭前迁移，且Preview产品的权限、设备目录、计费或支持状态可能需要适配。先做小范围双跑，可以给CI改造、测试结果比对和成本审批留出时间。

DDP会维持Test Lab原有价格吗？

Google当前FAQ说明，在2027年4月30日前DDP费率与Firebase Test Lab对齐；之后计划推出包含按使用量及设备槽订阅的新计价方案，并要求项目启用Billing。各项目的实际账单仍应以最新官方计费页面和控制台为准。

用DDP跑过Original就能证明加固兼容吗？

不能。Original只是对照基线。需要对实际计划使用的保护候选、Final Signed产物、目标设备Build和关键业务路径分别执行，并保存Crash/ANR、日志与未覆盖范围。某一个候选、某一次启动或一台设备不能代表整体兼容性。

御盾是否已经在Developer Device Platform上完成兼容测试？

没有。本页依据Firebase与Android官方公开迁移资料给出规划和验收方法，不是DDP或云真机运行报告。御盾版本、设备预约、安装、升级、业务路径、费用与Crash/ANR结论均为NOT_TESTED。

迁移执行清单：先建立可回退的小试点

1. 列出所有Test Lab工作流和owner，分别记录测试类型、触发方式、设备选择、输入文件、数据、产物和CI权限。
2. 阅读当前DDP迁移指南，建立逐项的产品能力映射；不确定或没有明确替代项的地方标为待核实。
3. 检查目标Google Cloud项目、DDP Preview访问、IAM、Billing与设备目录，不向公开仓库或测试Agent直接放置高权限凭据。
4. 选取一个低风险但重要的测试任务，在旧工作流与DDP上进行有审计记录的双跑，并保存各自平台、设备Build、参数和结果工件。
5. 对APP加固候选保持业务版本与测试条件一致；分别记录Original、Basic、Target和Final Signed，禁止将未跑候选继承相邻结果。
6. 对比分别失败、超时、环境无效、测试脚本异常、候选异常等状态；定义升级与回退标准并由负责人复核。
7. 设置预约清理、最长执行时间、最大并发、预算提醒、日志脱敏和工件保留策略，避免Agent重复调度造成无控制的资源使用。
8. 逐批切换，而非一次删掉旧流水线；保留历史Test Lab报告索引，并标记运行平台变更日期。
9. 在2027年9月30日关闭前完成所有关键工作流验收；同时跟踪DDP Preview状态和2027年4月30日之后计价变更。

迁移完成的判据不是“命令行能连上设备”，而是团队能够从一个明确的Release候选追溯到测试平台、设备Build、业务路径、结果工件、责任人和费用归属。当前御盾没有执行本文所列的DDP迁移或兼容测试，因此项目结果仍是NOT_TESTED。如需设计自有候选的测试范围，可先查看御盾性能与兼容性中心与APP加固PoC验收指南，并仅在获得必要授权与测试环境后执行。