OpenMetadata 平台端到端测试全景：Playwright E2E 套件架构与 2327 个场景剖析

OpenMetadata 平台端到端测试全景：Playwright E2E 套件架构与 2327 个场景剖析

【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata

本文基于 OpenMetadata 仓库中自动生成的 E2E 测试文档 Platform.md 展开，系统梳理 OpenMetadata 前端平台域（Entities、Settings、Lineage、Users & Teams、SSO、RBAC、Authentication 等 13 大组件）的 Playwright 端到端测试体系。读完本文，你将掌握该平台测试套件的完整目录结构、各套件的功能覆盖边界、测试用例的组织范式，以及如何将这份"活文档"用于日常回归验证与质量门禁。

OpenMetadata 的前端 UI 测试并非散落各处，而是由一套自动生成的文档体系统一索引：位于 openmetadata-ui/src/main/resources/ui/playwright/docs 目录下的Discovery.md、Governance.md、Observability.md、Integration.md与本文主角Platform.md共同构成全景图，而 README.md 则汇总全部统计。Platform 是其中规模最大的一个域：13 Components、86 Files、1622 Tests、2327 Scenarios，覆盖从实体 CRUD、权限矩阵、版本历史到 SSO 配置、人员与团队管理、平台级 Lineage 的全部核心交互。

一、文档定位：自动生成的可检索测试目录

Platform.md 的顶部标注了"13 Components | 86 Files | 1622 Tests | 2327 Scenarios"，并与 README.md 的汇总表完全对应。该文档由仓库内的doc-generator工具链自动生成——在 doc-generator 目录下可以看到generate.js、markdown.js、playwright-loader.js三个脚本，它们负责从 Playwright spec 源码中提取测试用例与场景，渲染为带锚点（#other、#entities、#settings等）的 Markdown 目录。

这份文档的角色是可检索的测试目录（test catalog）：每个测试套件以<details>折叠块呈现，包含：

• 套件名与规模：如Entity.spec.ts (361 tests, 470 scenarios)；
• 源码位置：每条记录都给出该 spec 文件在仓库中的路径；
• 用例表格：按# / Test Case / Description三列列出每个测试用例，含↳子步骤说明。

因此它既是 QA 团队的回归清单，也是开发者理解"平台功能边界"的快速索引：看到某套件名，即可定位对应 spec 源码，进而深入具体实现。

二、测试组织方式：目录结构与统计口径

2.1 spec 文件的物理分布

从文档中引用的 Source 路径可以还原出 Playwright 测试代码的组织规则：

2.2 Tests 与 Scenarios 的口径

文档中 "tests" 与 "scenarios" 是两个不同的量：一个test()可以包含多个↳子步骤/断言组（如InputOutputPorts.spec.ts的 42 个测试展开为 150 个场景），因此Scenarios ≥ Tests。统计时同一套件下按实体类型分组的用例会重复计入场景数，例如Entity.spec.ts中"Domain Add, Update and Remove"会针对 Api Endpoint、Table、Dashboard、Pipeline、Topic、Ml Model、Container、Search Index、Dashboard Data Model、Metric、Chart、Directory、File、Spreadsheet、Worksheet 等每种实体各跑一遍。

2.3 全局前置与数据准备

平台测试依赖auth.setup.ts（authenticate all users）、entity-data.setup.ts（create entity data prerequisites）与entity-data.teardown.ts（cleanup entity data prerequisites）建立公共测试数据基线；dataInsightApp.ts则负责运行 Data Insight 应用直至成功，为依赖洞察数据的用例铺路。这些 setup 文件本身也作为独立"套件"出现在 Platform.md 的 Other 分类中，每个各计 1 个测试。

三、Other：平台杂项与横切能力（29 个套件，264 Tests / 429 Scenarios）

"Other" 汇聚了平台中不归属于某一实体类型的横切功能，是理解平台扩展能力的关键入口。

3.1 ODCS Import/Export（ODCSImportExport.spec.ts，47 Tests / 50 Scenarios）

这是文档中最大的单一功能套件，覆盖 Open Data Contract Specification（ODCS）契约的导入导出全链路，主要维度包括：

• 格式与校验：从 test-data 文件导入基础/完整契约、draft 状态契约、v3.1.0 时间戳类型、带 SLA 属性的契约；对 malformed YAML、缺失apiVersion/status/kind、错误 apiVersion/kind、空文件等非法输入断言错误提示；
• 模式（Merge / Replace）：对已有契约执行 merge（增量合并 SLA）与 replace（整体替换）两种导入模式，并验证导入弹窗中的模式选择与契约预览；
• schema 校验：导入按钮在空/非法文件下禁用、校验失败禁用、校验进行中显示 loading，字段不存在于实体时给出 warning；
• 多对象契约：多 schema 对象契约展示对象选择器，选中对象后才允许导入；单对象契约不显示选择器；
• 导出与往返：导出 ODCS YAML、导出 OpenMetadata 格式 YAML、round trip（create → export → delete → reimport）数据保持；从 UI 创建契约后导出再以 merge 导入，验证 SLA 保留、描述更新；
• 内容映射：SLA 时区、security/roles、quality rules（含 mustBeBetween）、team owner、markdown 描述的渲染与映射。

配套的ODCSImportExportPermissions.spec.ts（13 Tests）专门验证 RBAC：Admin 与拥有 EditAll 权限的用户可见全部导入/导出选项并可执行导入；Data Consumer、Data Steward、ViewOnly 用户只见导出选项；API 层允许有 view 权限的用户导出。

3.2 Input Output Ports（InputOutputPorts.spec.ts，42 Tests / 150 Scenarios）

围绕 Data Product 的输入/输出端口（Ports Tab）展开，是数据产品与 Lineage 衔接的重要区域：

• 按钮与空态：无资产时只显示 input port 按钮、ports tab 空态渲染、端口计数、lineage 区默认折叠；
• 添加/移除端口：单个/多个/不同类型（table、topic、dashboard）端口添加，取消抽屉、移除单个/全部端口、取消移除、移除最后一个端口回到空态；
• 抽屉行为差异：input port 抽屉展示数据产品外资产，output port 抽屉只展示产品内资产并带 info banner，两者均有 Entity Type 快速过滤；
• Lineage 联动：展开后显示以数据产品为中心的 lineage 图、输入/输出端口节点、ReactFlow 控件、全屏模式（按钮/Escape 退出）、分节独立折叠展开、输入端口列表分页；
• 资产删除告警：删除同时也是 output port 的资产时给出 warning，非 output port 不提示；批量删除只列出 output port 资产；从资产 Tab 移除资产会同步从 output port 移除。

3.3 审计日志（AuditLogs.spec.ts，27 Tests / 68 Scenarios）

• 页面与过滤：页头标题/副标题、Time/User/Entity Type 三类过滤器的应用、清除、同类别替换、多类别共存、User 与 EntityType 内部搜索；
• 搜索与分页：大小写不敏感搜索、分页与页大小选择、列表项结构（头像、用户信息、事件类型、元数据、实体类型徽章、相对时间戳）；
• 导出：打开导出弹窗、选择日期范围后启用导出按钮、导出请求携带当前过滤与搜索条件、非 admin 用户禁止导出；
• 事件验证：通过 API 创建/更新/软删/恢复/硬删 Glossary，逐一断言entityCreated、entityUpdated/entityFieldsChanged、entitySoftDeleted、entityRestored、entityDeleted五类审计事件，并验证 UI 列表中的可见性——这实际上是一套完整的实体生命周期审计端到端验证。

3.4 权限与状态类

• ConditionalPermissions.spec.ts（22 Tests）：条件权限（owner 权限、matchAnyTag 权限）在 Api Service、Storage Service、Dashboard Service、Mlmodel Service、Pipeline Service、Search Service、Database Service、Messaging Service、Database、Database Schema、Container 等 11 类实体上的"只见自有/只见带标签"验证；
• AutoPilot.spec.ts（12 Tests）：在 Rest、Metabase、Mysql、Kafka、Mlflow、Airflow 六类服务上验证 AutoPilot 创建服务后的状态，以及 AutoPilot 创建的 Agent 应被正确删除；
• DescriptionVisibility.spec.ts（12 Tests）：Domain、Data Product、Glossary、Glossary Term 的长描述截断、展开、滚动与折叠恢复，以及定制化 Table 详情页 Description widget 的长描述展示；
• NestedChildrenUpdates.spec.ts（32 Tests）：嵌套列（nested column）的 description/tag/displayName 更新即时生效、无需刷新页面，覆盖 API Endpoint、Data Model、File、Search Index、Table、Topic、Worksheet 七类实体；
• NestedColumnsExpandCollapse.spec.ts（11 Tests）：嵌套列同名场景下展开/折叠不产生重复行，覆盖 Table、Topic、API Endpoint、Data Model、Container、Search Index、Worksheet、File、Table Version History、Table Profiler Tab、Explore Summary Panel 十一个视图；
• ColumnSorting.spec.ts（7 Tests）：Table schema tab 的排序下拉（Alphabetical / Original Order）、列头点击切换升降序、切换排序字段重置为升序、搜索时保持排序状态；
• Collect.spec.ts（7 Tests）：访问 Settings、Explore、Quality、Incident Manager、Insights、Glossary、Tags 七个页面都应触发 collect API；
• CertificationDropdown.spec.ts（6 Tests）：认证徽章下拉在 tag 禁用/分类禁用/重新启用等状态下的显隐逻辑；
• DescriptionSuggestion.spec.ts（5 Tests / 9 Scenarios）：描述建议的查看、关闭、接受（单条/嵌套/全部）、拒绝全部、头像点击获取建议、自动拉取更多建议、切换实体时拉取初始 10 条建议。

3.5 小套件与其他

• MultipleRename.spec.ts（4 Tests）：Glossary、GlossaryTerm、Classification、Tag 连续多次重命名；
• RTL.spec.ts（2 Tests）：落地页 Data Assets 与 Following widget 的 RTL 布局；
• FrequentlyJoined.spec.ts（2 Tests）：高频联表列与高频联表的展示；
• Permission.spec.ts（1 Test / 3 Scenarios）：ViewBasic、EditQuery、EditTest 权限；
• CSVImportWithQuotesAndCommas.spec.ts（1 Test / 3 Scenarios）：含引号与逗号的 Glossary CSV 导入导出往返与转义正确性；
• HealthCheck.spec.ts（1 Test）：OpenMetadata 的 5 项健康检查全部通过；
• Bots.spec.ts（1 Test / 6 Scenarios）：ingestion bot 删除按钮恒禁用、创建 Bot、更新显示名与描述、generateToken API 契约、更新 token 过期、删除 Bot；
• OmdURLConfiguration.spec.ts（1 Test）：更新 om url 配置生效；
• Markdown.spec.ts（1 Test）：Markdown 渲染；
• LanguageOverride.spec.ts（1 Test）：应用语言覆盖浏览器语言；
• ApiDocs.spec.ts、AppBasic.spec.ts：API 文档可用性、installed app API 返回 200。

四、Entities：跨实体 CRUD 与权限矩阵（17 个套件，978 Tests / 1265 Scenarios）

Entities 是 Platform 文档的绝对核心，围绕"每种实体 × 每种操作 × 每种角色"构造了庞大的矩阵化测试体系。

4.1 Entity.spec.ts：361 Tests / 470 Scenarios 的全实体操作矩阵

这是全仓库最大的单一 spec，针对Api Endpoint、Table、Stored Procedure、Dashboard、Pipeline、Topic、Ml Model、Container、Search Index、Dashboard Data Model、Metric、Chart、Directory、File、Spreadsheet、Worksheet等实体逐一遍历下列操作维度：

• Domain 管理：添加、更新、移除，以及域从 Service 向子实体传播（服务分配域 → 子实体继承；服务移除域 → 子实体同步移除）；
• Owner 管理：User 作为 Owner、Team 作为 Owner、多 Owner 乱序列表的状态保持；
• Tier / Certification：Tier 的添加、更新、移除；认证徽章的添加、更新、移除；
• 描述与命名：description 添加与更新、displayName 更新；
• Tag 与 Glossary Term：添加、更新、移除；Tag 选择器与 Glossary 选择器互斥（打开一个会关闭另一个）；子实体（column detail panel）上的 Tag/Glossary 增删；
• 列详情面板（Column Detail Panel）：数据类型展示、嵌套列导航、复杂嵌套结构验证（缩进、count badge 仅统计顶层列、深嵌套 3+ 层、数组类型嵌套列、同层混合简单列+嵌套列）、列级自定义属性、Data Quality tab 的测试用例统计卡与筛选、Incidents tab；
• 自定义属性：table-cp、hyperlink-cp、string、integer、markdown、number、duration、email、enum、sqlQuery、timestamp、entityReference、entityReferenceList、timeInterval、time-cp、date-cp、dateTime-cp共 17 种类型的设置与更新（含右侧面板更新）；
• 协作与通知：Announcement 创建/编辑/删除、Inactive Announcement、实体 UpVote/DownVote、Follow/Un-follow；
• 拒绝策略（Deny Policy）：deny policy rule 生效时用户被禁止编辑描述、Data Consumer 被禁止访问 queries/sample data tab、列详情面板编辑被禁；
• Standalone 删除测试：对 16 类实体逐一验证软删除（soft delete）与硬删除（hard delete）全流程。

4.2 角色化变体：Data Steward 与 Data Consumer

• EntityDataSteward.spec.ts（158 Tests）：Data Steward 角色在全部实体上的 Owner/Tier/描述/Tag/Glossary/displayName 增改、子实体操作、投票与关注；
• EntityDataConsumer.spec.ts（143 Tests）：Data Consumer 角色的差异化行为——允许 Tier/描述/Tag/Glossary 与关注投票，但不允许编辑 Owner（No edit owner permission）、子实体 displayName 编辑被禁止，从权限差异验证 RBAC 边界。

4.3 ServiceEntity.spec.ts：140 Tests / 158 Scenarios

面向Api Service、Api Collection、Database Service、Dashboard Service、Messaging Service、Mlmodel Service、Pipeline Service、Search Index Service、Storage Service、Database、Database Schema、Drive Service的服务级操作（Domain/Owner/Tier/描述/Tag/Glossary/Announcement/displayName、Database 与 Database Schema 的 Certification 与 Follow），外加 12 类服务/库/模式的软硬删除。

4.4 权限矩阵套件

• EntityPermissions.spec.ts（44 Tests）：Table、Dashboard、Pipeline、Topic、MlModel、Container、SearchIndex、DashboardDataModel、Metric、Directory、File、Spreadsheet、Worksheet、Database 的 allow/deny × common operations/entity-specific operations 四象限验证；
• ServiceEntityPermissions.spec.ts（20 Tests）：Api Service、Dashboard Service、Database Service、Messaging Service、Mlmodel Service、Pipeline Service、SearchIndex Service、Storage Service 的 allow/deny 验证——allow 用户可执行 EditDescription、EditOwners、EditTier、EditDisplayName、EditTags、EditGlossaryTerms、EditCustomFields、Delete 全套操作，deny 用户对应的 UI 元素应隐藏或禁用。

4.5 批量操作与导入导出

• ColumnBulkOperations.spec.ts（24 Tests / 60 Scenarios）：列批量操作页面——stats 卡与网格加载、按 metadata status/entity type 过滤、URL 过滤恢复、服务端搜索、乱序响应下保留最新结果、编辑抽屉（未选禁用、pending changes 计数、聚合父行不计入选中数、提交后进度 spinner、Escape 关闭丢弃修改）、批量更新 displayName 并传播到所有出现位置、嵌套 STRUCT 列的展开与子字段编辑、分页；
• BulkImport.spec.ts（6 Tests / 27 Scenarios）：Database service/Database/Database Schema/Table 四级的导出、导入网格编辑与二次导入，含键盘 Delete 选择、范围选择（Ctrl+A 全选、列头整列选择、Shift+click 扩展、单格/范围复制粘贴与 undo-redo）；
• BulkImportWithDotInName.spec.ts（8 Tests / 9 Scenarios）：服务名含点号的导入导出回归（issue #24401），覆盖 CSV 引号转义、双重点号、列名带点与双层引号 FQN、数据库级/Schema 级导入；
• BulkEditEntity.spec.ts（6 Tests / 11 Scenarios）：Database service、Database、Database Schema、Table、Glossary、Glossary Term（嵌套）的批量编辑（含扩展字段 extension edit）。

4.6 版本历史与恢复

• EntityVersionPages.spec.ts（14 Tests / 70 Scenarios）：14 类实体版本页显示 tag/description 编辑、owner 变更、列 displayName 变更、tier 变更，以及软删除后的版本详情；
• ServiceEntityVersionPage.spec.ts（12 Tests / 48 Scenarios）：服务类实体版本追踪——v0.2 域分配/描述更新/tag 添加（PersonalData.SpecialCategory、PII.Sensitive）、v0.3 owner 与 tier、v0.4 软删除徽章，并断言 diff-added 视觉指示器；
• RestoreEntityInheritedFields.spec.ts（11 Tests）：带继承域（Inherited domain）与数据产品分配的实体在恢复（restore）后字段正确；
• EntityRenameConsolidation.spec.ts（9 Tests）：Glossary/Classification/Tag/Domain 重命名与描述更新合并执行后术语/tag 保持；
• EntitySummaryPanel.spec.ts（18 Tests）：10 类实体的右侧摘要面板渲染、标题链接、owners/domain/tags/description 分区、Tab 切换与 displayName 编辑弹窗；
• QueryEntity.spec.ts（3 Tests / 8 Scenarios）：Query 实体创建、owner/描述/tag 更新、Query 与 QueryUsedIn 更新、过滤、投票、全屏查看与删除、查询时长与分页；
• EntityRightCollapsablePanel.spec.ts（1 Test）：右侧可折叠面板的显示/隐藏。

五、Settings：平台设置域（5 个套件，17 Tests / 21 Scenarios）

• SettingsNavigationPage.spec.ts（6 Tests）：设置侧边导航更新、未保存更改离开时的导航拦截器（Save changes / 保存后不再拦截）、重置功能、导航项拖拽排序、多项同时隐藏；
• DataInsightSettings.spec.ts（4 Tests）：Data Insight 应用的编辑、卸载、安装、运行；
• SearchSettings.spec.ts（4 Tests）：全局搜索设置、实体级搜索设置、恢复默认搜索设置，外加可搜索表的搜索预览；
• LineageSettings.spec.ts（2 Tests / 6 Scenarios）：全局 lineage 配置（upstream depth < 0 时报错、列层/实体层 lineage 验证、上下游展开折叠按钮、重置）、PipelineViewMode 为 Edge 时的 lineage 设置；
• CronValidations.spec.ts（1 Test）：多种 cron 表达式的校验。

六、Personas & Customizations：个性化定制域（5 个套件，50 Tests / 152 Scenarios）

• CustomizeDetailPage.spec.ts（25 Tests / 83 Scenarios）：Persona 定制 UI Tab——显示全部定制选项、导航定制；对 Table、Topic、Dashboard、Ml Model、Pipeline、Dashboard Data Model、API Collection、Search Index、Container、Database、Database Schema、Stored Procedure、API Endpoint、Domain、Data Product、Glossary、Glossary Term 等 17 类实体验证"默认展示全部 Tab/Widget → 应用定制 → 定制生效"三步流程，以及定制 Tab 标签仅在用户定制后渲染；
• PersonaFlow.spec.ts（10 Tests / 16 Scenarios）：Persona 创建（面包屑导航）、描述更新、重命名、移除用户、删除；默认 Persona 的设置/更换/移除对用户刷新后的生效；Team 级默认 Persona（仅 group 类团队可设置、无权限用户不可编辑）；
• CustomizeWidgets.spec.ts（9 Tests / 45 Scenarios）：Activity Feed、Data Assets、My Data、KPI、Total Data Assets、Following Assets、Domains、My Tasks、Data Products 九个落地页 widget 的头/尾导航、过滤器、数据展示与定制；
• CustomizeLandingPage.spec.ts（3 Tests / 5 Scenarios）：默认 widget 存在性、添加/移除/重置布局、widget 拖拽重排；
• CustomThemeConfig.spec.ts（3 Tests）：主题配置更新与重置、hover 与选中颜色、无效 monogram 下customMonogramUrlPath只调用一次。

七、Navigation：导航与分页域（4 个套件，59 Tests / 59 Scenarios）

• Pagination.spec.ts（31 Tests）：Users、Database Schema Tables、Table columns、Service Databases、Classification Tags、Metrics、Notification/Observability Alerts、API Collection、Stored Procedures、Database Schemas、Data Models、Directories、Files、Spreadsheets、Roles、Policies、Bots、Service version page 等 20 余处列表的分页，以及"分页 + 搜索"完整流程、Files/Spreadsheets Tab 切换时重置分页并校验 API payload、切换 Tab 时页面大小保持（GlobalPageSize）；
• Navbar.spec.ts（22 Tests）：从导航栏对 22 类实体（All/Database/Database Schema/Table/Topic/Dashboard/Pipeline/ML Model/Container/Stored Procedure/Data Model/Glossary/Tag/Search Index/Data Product/API Endpoint/API Collection/Metric/Directory/File/Spreadsheet/Worksheet）逐一执行搜索跳转；
• NavigationBlocker.spec.ts（5 Tests）：未保存更改离开时弹窗的四种行为（Save changes 确认、Leave 离开、X 停留保持、保存后不再拦截）；
• GlobalPageSize.spec.ts（1 Test）：列表面页大小跨页面持久化。

八、Lineage (UI)：血缘视图域（3 个套件，59 Tests / 118 Scenarios）

• Lineage.spec.ts（48 Tests / 107 Scenarios）：血缘交互的核心套件，包含：
  • 节点/列选中与边行为：选中节点时高亮 traced 节点边、隐藏列边、灰化非 traced 节点边；选中列时反向行为；
  • 列级血缘分页：多分页下列可见性、无 hover/选中时的边集、hover/点击列时的高亮边集、开启列过滤（filter）后仅显示有血缘的列与新边；
  • 自定义属性 Tab 显隐：table/topic/dashboard/pipeline/mlmodel/container/searchIndex/apiEndpoint/metric/chart 十类实体可见，databaseService/messagingService/dashboardService/pipelineService/mlmodelService/storageService/apiService 七类服务不可见；
  • 血缘创建与导出：从 Table/Dashboard/Topic/MlModel/Container/SearchIndex/ApiEndpoint/Metric 实体创建血缘、创建 pipeline 边、导出 CSV/PNG、移除血缘、验证血缘配置；
  • 列血缘组合：table↔table、table↔topic、topic↔api endpoint、table↔api endpoint；
  • 编辑模式：进入编辑模式自动启用列层、退出清除 traced 节点与列、边抽屉函数数据、特殊字符搜索、环状血缘处理、节点面包屑、侧边栏自定义属性 Tab；
• ImpactAnalysis.spec.ts（10 Tests）：资产级与列级的上下游数量、上下游连接、owner/domain/tier 过滤，以及血缘卡片表格中资产 hover 的实体 popover；
• PlatformLineage.spec.ts（1 Test）：平台级 Lineage 视图。

九、Users & Teams：人员与组织域（12 个套件，111 Tests / 159 Scenarios）

• Users.spec.ts（29 Tests / 34 Scenarios）：Admin 用户管理（更新本人信息、创建/删除用户、重复邮箱校验、软硬删除与恢复、profile 页删除恢复）；Data Consumer 的 token 生成/吊销/过期更新、Glossary 与 Tags 只读、设置页操作、表格详情页权限、重置密码；Data Steward 的信息更新、token、设置页、权限检查、重置密码；用户 Profile 的 feed 头像跳转、persona 下拉分页与默认 tag、persona 切换/排序/刷新回退；多团队继承角色与策略下的页面性能；
• Teams.spec.ts（19 Tests / 31 Scenarios）：团队全生命周期（创建、加 Owner、改邮箱、加/移除用户、加入/离开团队、改显示名与描述、软/硬删除）、公开/私有团队、不软删直接永久删除、搜索、导出团队、团队资产、从表格删除用户、带点团队名的面包屑、总用户数渲染、Show Deleted 开关的 include 参数；EditUser 权限下的增删用户；Data Consumer 无编辑权限；Owner 视角的建队权限；
• TeamSubscriptions.spec.ts（17 Tests / 44 Scenarios）：团队订阅（None 显示、编辑弹窗开关、MS Teams/Slack/Google Chat/Generic 四种 webhook 配置与图标、URL 校验、endpoint 必填/禁用逻辑、类型切换、移除、刷新持久化），以及 Admin/Owner/成员/Data Consumer/Data Steward 的权限分层；
• TeamAssetsRightPanel.spec.ts（10 Tests）：团队资产 Tab 点击资产打开右侧面板、Tab 正确性、描述/Tag/Tier/domain/glossary/owner 上下文内编辑；
• TeamsDragAndDrop.spec.ts（9 Tests）：团队层级拖拽（BusinessUnit/Division/Department 合法组合、Group 不可作为目标等非法组合报错、表级拖拽、删除）；
• UserDetails.spec.ts（9 Tests）：不同角色下团队/域/角色层级浏览、域分配与移除、子域树展开、非 admin 可编辑本人 displayName 与描述但不可编辑 persona/roles、My Data Tab 搜索；
• OnlineUsers.spec.ts（7 Tests / 8 Scenarios）：Settings > Members > Online Users 的在线用户列表（仅 admin 可见、导航更新活动时间、bot 不展示、时间窗口过滤、last activity 格式、displayName 展示）；
• UserProfileOnlineStatus.spec.ts（5 Tests）：用户 Profile 的在线徽章、"Active recently"（1 小时内）、非活跃不显示、邮箱下方位置、实时更新；
• TeamsHierarchy.spec.ts（3 Tests）：嵌套团队层级、Add User 页面层级展示、删除父团队；
• PersonaDeletionUserProfile.spec.ts（1 Test / 4 Scenarios）：删除 Persona 后用户 Profile 仍正常加载；
• UsersPagination.spec.ts（1 Test）：软删除用户分页与 API 调用；
• UserCreationWithPersona.spec.ts（1 Test）：创建带 Persona 的用户并在 Profile 验证。

十、SSO：单点登录配置域（1 个套件，37 Tests / 37 Scenarios）

SSOConfiguration.spec.ts是单文件大套件，覆盖 SSO 配置页的完整表单行为：

• Provider 矩阵：Google、Auth0、Okta、Azure AD（confidential client 与公开客户端两种形态）、SAML、LDAP 的字段显隐——例如 OIDC Callback URL 对 Google/Auth0/Okta/Azure AD 只读，SAML 的 SP Entity ID 与 ACS URL 只读，LDAP/SAML 隐藏jwtPrincipalClaims，SAML/LDAP 隐藏publicKeyUrls，Auth0 隐藏clientAuthenticationMethod而 Okta 显示，Auth0 隐藏 tenant 而 Azure 显示；
• 高级配置折叠：OIDC 的 advanced config 默认折叠、点击展开、展开后显示高级字段；confidential OIDC provider 隐藏publicKeyUrls、隐藏serverUrl、隐藏preferredJwsAlgorithm/responseType/tokenValidationAlgorithm；
• LDAP 角色映射：authReassignRoles 搜索下拉、角色添加/移除/重复检测/解析、非 LDAP provider 不显示角色映射组件；
• 回退导航：SSO 已配置时返回键回到 /settings，未配置时停留在 /settings/sso。

十一、RBAC：权限体系域（4 个套件，19 Tests / 34 Scenarios）

• SearchRBAC.spec.ts（11 Tests）：ApiEndpoint、Table、Store Procedure、Dashboard、Pipeline、Topic、MlModel、Container、SearchIndex、DashboardDataModel、Metric 的搜索 RBAC；
• AddRoleAndAssignToUser.spec.ts（3 Tests）：创建角色 → 创建用户并分配角色 → 验证角色生效；
• Policies.spec.ts（3 Tests / 11 Scenarios）：策略页全流程——添加含非法条件的策略、默认策略与角色展示、编辑策略描述/显示名、添加/编辑/删除规则、删除最后一个规则并校验、从管理按钮删除策略；
• Roles.spec.ts（2 Tests / 9 Scenarios）：角色页——添加/编辑角色、不选数据添加、编辑显示名、为角色增删策略、最后一个策略不可移除、删除角色。

十二、Onboarding / App Marketplace / General / Authentication

• Onboarding（1 套件，3 Tests）：Tour.spec.ts验证引导流程可经帮助区、欢迎屏、URL 直达三种入口触发；
• App Marketplace（2 套件，5 Tests / 11 Scenarios）：DataInsightReportApplication.spec.ts（安装/编辑/运行/卸载 Data Insight Report 应用）、SearchIndexApplication.spec.ts（应用页访问、最后执行查看、运行配置查看、编辑、卸载、安装、运行 Search Index 应用）；
• General（1 套件，13 Tests / 32 Scenarios）：LearningResources.spec.ts覆盖学习资源管理的管理端（必填字段校验、创建、行预览播放器、表/卡片视图切换）与页面端（血缘页与 Glossary 页的学习图标、抽屉打开、资源卡播放），以及资源搜索与 resourceType/category/pageId/status 四种过滤参数的正确传递、清除过滤与无参重载；
• Authentication（2 套件，7 Tests / 7 Scenarios）：Login.spec.ts（注册后登录、非法凭据登录失败、忘记密码后新密码登录、刷新可用、token 过期自动续期）、LoginConfiguration.spec.ts（登录配置更新与重置）。

十三、从测试矩阵反推平台能力边界

纵向通读这 2327 个场景，可以提炼出 Platform 域测试设计的三条主线，这也是本仓库对"平台稳定性"的工程化表达：

1. 实体 × 操作的笛卡尔积矩阵：以Entity.spec.ts为代表，将 Domain/Owner/Tier/Certification/Description/Tag/Glossary/Custom Properties/Announcement/Vote/Follow 等通用操作投射到十余种实体类型上，保证任何新增实体都能复用同一套验收标准；
2. 角色 × 权限的差分验证：Admin、Data Steward、Data Consumer、ViewOnly、EditAll 等角色对同一操作的可见性/可执行性差异被显式断言（如 ODCS 导入导出、团队订阅、Owner 编辑、deny policy 下的隐藏/禁用 UI），把 RBAC 从"接口权限"下沉为"UI 交互权限"；
3. 状态机与生命周期闭环：实体软删/硬删/恢复、版本历史多版本 diff、审计事件五连（created/updated/softDeleted/restored/deleted）、ODCS 导入导出往返、重命名+更新合并，均以"状态流转 + 数据保持"的端到端方式锁死回归。

此外，大量场景验证了前端与 API 的契约：搜索/过滤/导出请求的 payload 参数（如 AuditLogs 导出的过滤条件、BulkImport 的 FQN 转义、Collect 端点触发），为前后端联调提供了可回归的契约基线。

十四、如何阅读与使用这份文档

1. 按域索引功能：需要确认某个平台功能是否被测试覆盖时，先按目录锚点（Other/Entities/Settings/Personas & Customizations/Navigation/Lineage (UI)/Users & Teams/SSO/RBAC/Onboarding/App Marketplace/General/Authentication）定位套件，再看用例表；
2. 从文档到源码：每个套件块中的 Source 路径即 spec 文件位置（如e2e/Pages/Entity.spec.ts），可顺藤摸瓜阅读实现；与之配套的开发者手册 PLAYWRIGHT_DEVELOPER_HANDBOOK.md 与隔离策略 QUARANTINE.md 提供了测试编写与治理约定；
3. 统计口径认知：注意 tests 与 scenarios 的差别（一个测试可含多个子场景），以及 setup/teardown 文件被计为独立套件的事实，避免误读规模；
4. 文档再生成：该目录由 doc-generator 的脚本从 spec 源码自动生成，属于"活文档"——随测试代码演进而更新，阅读时以源码为准、文档为辅；
5. 回归参考：作为发版前的平台回归清单，可按组件粒度选取套件执行，也可将场景描述直接转化为手工验收步骤。

总而言之，Platform.md 是一份把"平台功能面"翻译成"可执行验收清单"的高密度索引：既有 2327 个场景的量化规模，又有精确到实体、角色、状态的细粒度覆盖。对开发者而言，它是理解 OpenMetadata 平台能力边界与测试工程实践的入口；对 QA 与平台管理员而言，它则是一份可以直接指导回归测试与功能验收的操作地图。

【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata