OpenMetadata 治理功能 Playwright E2E 测试覆盖全景指南：Custom Properties、Domains、Glossary、Tags 与 Data Contracts-二趣网

OpenMetadata 治理功能 Playwright E2E 测试覆盖全景指南：Custom Properties、Domains、Glossary、Tags 与 Data Contracts

【免费下载链接】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 测试覆盖文档（openmetadata-ui/src/main/resources/ui/playwright/docs/Governance.md）为骨架，系统梳理治理（Governance）域六大组件——自定义属性（Custom Properties）、指标（Metrics）、域与数据产品（Domains & Data Products）、术语表（Glossary）、标签（Tags）与数据契约（Data Contracts）——共 63 个测试文件、933 条测试、1598 个场景的完整覆盖矩阵。读完本文，你将掌握如何阅读这份自动生成的文档、理解其统计口径（Tests 与 Scenarios 的区别）、定位六大组件各自的测试文件与关键用例，并能结合仓库源码把文档映射到真实的 Playwright spec 与测试工具链，从而在 OpenMetadata 治理功能开发或回归验证中精准选用测试。

文档定位：治理域的 E2E 测试地图

Governance.md是 Playwright E2E 测试文档体系中的治理域专册。它与docs/README.md（总索引）、Discovery.md、Platform.md、Observability.md、Integration.md共同构成 OpenMetadata UI 的端到端测试文档全集。总索引中对治理域的汇总为：6 Components | 933 Tests | 1598 Scenarios，其六大组件明细如下：

组件	文件数	测试数	场景数
Custom Properties	7	354	376
Glossary	24	267	310
Domains & Data Products	18	162	234
Data Contracts	3	96	599
Tags	8	45	63
Metrics	3	9	16

从数量上看，数据契约（Data Contracts）虽然只有 3 个文件，却贡献了 599 个场景，是场景密度最高的组件；自定义属性与术语表则以文件多、用例全著称。这张表直观回答了"治理功能在 UI 层被哪些自动化用例守护"这一问题。

文档是怎么生成的：doc-generator 工具链

这份文档并非手写，而是由仓库内的定制工具自动生成，源码位于openmetadata-ui/src/main/resources/ui/playwright/doc-generator/，由三个模块协作：

generate.js（编排器）：定义DOMAIN_MAPPING，按文件名关键词把测试归入 Governance / Discovery / Platform / Observability / Integration 等域与对应组件。例如治理域映射规则包括Glossary → Glossary、Tag/Classification → Tags、Metric → Metrics、CustomProperty/Customproperties → Custom Properties、Domain/DataProduct → Domains & Data Products、DataContract → Data Contracts等。
playwright-loader.js（数据提供）：通过npx playwright test --list --reporter=json从 Playwright 自身获取测试清单；执行期间生成临时playwright.docs.temp.config.ts确保被忽略的（含 nightly）测试也纳入发现范围；再用 TypeScript Compiler API（typescript包）解析 spec 源码，抽取test.step('Step Name', ...)调用以获得步骤级细节，并读取 JSDoc 注释作为测试描述。
markdown.js（渲染器）：提供generateIndexMarkdown/generateDomainMarkdown模板函数，负责生成最终.md文件。

统计口径：Tests 与 Scenarios 的区别

文档中每个 spec 文件的括号里都标注了两组数字，例如Customproperties-part1.spec.ts(191 tests, 195 scenarios)。其计算逻辑定义在markdown.js中：

Tests：源码中test(...)块的原始数量；
Total Scenarios：(Steps > 0 ? Steps : 1)，即若某测试包含步骤（test.step），每个步骤计为一个场景；若无步骤，该测试本身计为一个场景。

因此"场景数"更能反映测试的真实深度。这也是为什么DataContracts.spec.ts（48 tests）能产生 423 个场景——其核心测试通过大量test.step驱动完整业务流程。

分类优先级与手动生成

文档归类遵循三级优先级：显式标签@<Domain>:<Component>（最高）→ 合法域标签 + 文件名匹配 → 纯文件名回退。如需手动重新生成文档，可在仓库根目录执行yarn generate:e2e-docs，输出写入docs目录。仓库 CI（update-playwright-e2e-docsworkflow）会在主分支上自动检测文档变更并开 PR。

说明：Governance.md页头标记"Last updated: 2026-03-09"，而部分被引用的 spec 文件（如Customproperties-part1.spec.ts）在当前分支中已见拆分演化（可对照现存于e2e/Pages/的CustomProperties.spec.ts、CustomPropertiesApiContract.spec.ts），阅读时建议以文档表格为覆盖索引、以当前分支实际 spec 为执行依据。

组件一：Custom Properties（自定义属性）

自定义属性是 OpenMetadata 扩展实体元数据模型的核心机制，允许在标准字段之外为实体附加自定义字段。该组件共 7 个文件、354 条测试、376 个场景，是治理域中用例数量最多的组件。

覆盖的数据类型（无配置项场景）

Customproperties-part1.spec.ts（191 tests）集中验证不需要额外配置的 10 种基础类型：Integer、String、Markdown、Duration、Email、Number、Sql Query、Time Interval、Timestamp、Hyperlink。测试在多个实体上反复创建并校验每种属性，典型代表如"sqlQuery shows scrollable CodeMirror container and no expand toggle"用例，其步骤链为：创建 sqlQuery 属性 → 设置多行 SQL 值 → 验证.CodeMirror-scroll高度受限且可滚动 → 验证展开/收起开关隐藏 → 清理属性。这类用例不仅验证字段写入，还验证了 UI 渲染细节（如 CodeMirror 容器行为）。

带配置项的属性类型

Customproperties-part2.spec.ts（135 tests）覆盖需要配置项的类型：Enum（多选/单选枚举值）、Table（表格型属性）、Entity Reference、Entity Reference List、Date、Time、Date Time。代表性用例包括：

"entityReferenceList shows item count, scrollable list, no expand toggle"：创建 Entity Reference List 属性 → 设置 5 个用户引用 → 验证属性名中显示数量（5）→ 验证.entity-list-body可滚动 → 验证展开/收起开关隐藏 → 清理属性；
"table-cp shows row count, scrollable container, no expand toggle"：创建表格属性 → 添加 5 行数据 → 验证行数（5）→ 验证.custom-property-scrollable-container可滚动。

配置项的典型取值可参考测试常量openmetadata-ui/src/main/resources/ui/playwright/constant/customProperty.ts：枚举配置enumConfig含values与multiSelect；日期格式yyyy-MM-dd；时间格式HH:mm:ss；实体引用类型['User', 'Team', 'Metric']；表格配置tableConfig含columns列表。同文件还列出了自定义属性的支持实体清单，包括 Database、DatabaseSchema、Table、StoreProcedure、Topic、Dashboard、Pipeline、Container、MlModel、GlossaryTerm、SearchIndex、DataModel、ApiCollection、ApiEndpoint、DataProduct、Metric、Domain、Chart 与 TableColumn——这解释了为什么文档中同一属性类型会在多个实体上重复验证。

高级搜索、搜索设置与安全

CustomPropertyAdvanceSeach.spec.ts（19 tests）：针对 Dashboard 实体，为 16 种属性类型逐一验证其"全部操作符"（all operators）的高级搜索过滤能力，包括 String、Email、Markdown、SQL Query、Duration、Time、Integer、Number、Timestamp、Entity Reference、Entity Reference List、DateTime、Date、Enum、Time Interval、Hyperlink，以及 Table 属性的 Name/Role/Sr No 三列操作符。
HyperlinkCustomProperty.spec.ts（4 tests）：聚焦 XSS 防护——拒绝javascript:协议 URL、接受合法http/httpsURL、无显示文本时直接展示 URL、无值时显示 No Data 占位符。
CustomPropertySearchSettings.spec.ts（3 tests）：验证 Dashboard 与 Pipeline 的自定义属性可被配置进搜索设置，并可通过属性值检索到实体、且字段在搜索设置中持久化。
AdvanceSearchCustomProperty.spec.ts：验证 Duration 类型属性的创建、赋值与高级搜索。
EnumCustomPropertyWidget.spec.ts：验证 Table 右侧面板中 Enum 属性的添加值、验证、移除值的完整交互。

组件二：Metrics（指标）

Metrics 组件共 3 个文件、9 条测试、16 个场景，守护 OpenMetadata 指标实体的建模与维护能力：

Metric.spec.ts（6 tests，位于e2e/Flow/）：指标创建流程、Metric Type 更新、Unit of Measurement（计量单位）更新、Granularity（粒度）更新、metric expression 更新、Related Metrics 更新。
CustomMetric.spec.ts（2 tests）：Table 自定义指标与 Column 自定义指标的创建/删除。
MetricCustomUnitFlow.spec.ts（1 test, 6 scenarios）：完整验证计量单位生命周期——创建指标 → 验证初始单位 → 更新为 Dollars → 移除单位 → 设回 Percentage → 删除指标清理。

组件三：Domains & Data Products（域与数据产品）

该组件 18 个文件、162 条测试、234 个场景，是治理域中交互面最广的组件，覆盖域的层级结构（域/子域/数据产品）、资产归属、RBAC、重命名、自定义属性、公告、版本历史等。

核心页面级测试

Domains.spec.ts（40 tests, 69 scenarios）：域与数据产品的创建、资产增删、关注/取消关注、子域嵌套与关注、域删除后数据产品资产清理、从父域继承 owner 与 expert、资产计数准确性（含子域计数汇总）、域的数据产品数包含子域数据产品、标签与术语表、TagSuggestion 创建带标签的域/子域、重命名域（含多级子域 FQN 传播、标签/术语表/资产/owner 关联保持）、重复域创建校验、域自定义属性持久化、域/数据产品公告的增改删、描述被删除后 UI 优雅降级（@JsonInclude(NON_NULL)场景）等。另有 "Domain Rename Comprehensive Tests"（10 条）专注重命名关联保持、"Domains Rbac"（hasDomain()/noDomain()规则下的资产访问控制）与 "Domain Tree View Functionality"。
DataProducts.spec.ts（8 tests, 43 scenarios）：数据产品列表页初始加载、创建与管理资产、搜索、表格/卡片视图切换、分页（创建 30 个数据产品验证翻页）、空状态、关注/取消关注、TagSuggestion 创建带标签的数据产品。
DomainUIInteractions.spec.ts（20 tests）：域 owner/expert 管理、样式编辑（icon URL）、数据产品重命名/删除/添加 owner、子域删除/重命名、表单校验（特殊字符、最大长度、描述必填）、域内资产搜索、全局下拉过滤 Explore、面包屑导航、删除含子域/资产的域时的警告提示、复制域 FQN。
DomainAdvanced.spec.ts（19 tests）：域 expert 权限、资产跨域移动（含域→子域）、子域访问权限、版本历史、描述编辑、批量添加/移除资产、跨域访问拒绝、域类型行为（Source System / Consumer-aligned）、数据产品间移动资产、域搜索与过滤。
DataProductAndSubdomains.spec.ts（17 tests）：数据产品创建/描述编辑/expert/标签/资产计数、与子域的关联、多兄弟子域、嵌套子域、同级子域导航、子域资产计数反映到父域、删除带数据产品的子域清理。
DomainDataProductsRightPanel.spec.ts（9 tests）：域上下文内点击数据产品卡片打开右侧面板，验证概览、描述编辑、标签、Tier、owner 编辑及"不显示术语表区块"等。
SubDomainPagination.spec.ts：子域计数与分页功能。

特性与权限级测试

DomainFilterQueryFilter.spec.ts（12 tests）：域过滤器在 Explore 页的可见性、子域资产在父域选择时可见、过滤器跨页面导航持久化、不同资产类型协同、3 层域层级作用域、搜索建议按域过滤、精确匹配加点前缀防误报（exact match and prefix with dot）、快速过滤器共存、域资产页/数据产品页不显示其他域内容。
DomainTierCertificationVoting.spec.ts（8 tests）：域与数据产品的 Tier、Certification 分配/更新/移除，UpVote/DownVote，以及无编辑按钮的只读校验。
DomainDataProductsWidgets.spec.ts（6 tests）：首页 Widget 的域/数据产品资产计数随增删实时更新。
DataProductRename.spec.ts与DataProductRenameConsolidation.spec.ts：重命名保持资产关联、仅更新 display name 不改 name、连续多次重命名、重名报错、重命名与描述/标签/owner 变更组合后的资产保持。
DataProductPermissions.spec.ts、DomainPermissions.spec.ts：allow/deny 操作矩阵与 expert 编辑权限。
SampleDataDomainDataProduct.spec.ts：验证样本数据摄入产生的 TestDomain 与 TestDataProduct。
DataProductDomainMigration.spec.ts：通过 API 迁移数据产品域时资产随迁、无资产时无需确认。
DataProductPersonaCustomization.spec.ts：数据产品页面 Persona 定制（默认全 tab/widget、应用定制、标签自定义渲染）。

组件四：Glossary（术语表）

术语表组件 24 个文件、267 条测试、310 个场景，规模最大，覆盖术语表 CRUD、层级管理、审批工作流、资产关联、导入导出、版本、权限与性能。

页面级核心测试

Glossary.spec.ts（45 tests, 70 scenarios）：以 user/team 作为 reviewer 的术语表与术语创建审批流、术语表/术语更新、数据术语增改验证、列表页批准与拒绝、资产增删、术语重命名后资产页联动、资产选择模态框过滤、拖拽调整层级（含带 reviewer 的已批准术语）、菜单方式跨术语表调整层级、给实体分配术语并核对资产、为术语表/术语发起描述任务与标签任务、删除模态框、异步删除（WebSocket 失败恢复、多次删除混合结果）、嵌套术语展开全部、术语表表格列选择/可见性/拖拽排序、状态过滤、更新后树结构保持、术语内嵌子术语、重复术语校验（含带点术语表名）、权限拒绝、reviewer 修改后术语保持已批准、带域创建术语表、切换语言后删除、描述删除后的优雅处理、全部可选字段创建、行操作（+）按钮建术语、同义词/引用/相关术语/标签/owner 创建、显示名编辑、重命名、取消删除等。
GlossaryAdvancedOperations.spec.ts（27 tests）：互斥开关、多 owner、owner/reviewer 替换、域移除/变更、样式（颜色/icon URL）设置与更新、同义词清空、引用名/URL 编辑与移除、相关术语/owner/reviewer/标签移除、取消创建、双向相关术语链接、超长名/超长描述、名称超限报错。
GlossaryP3Tests.spec.ts（23 tests）：Unicode 名称、样式 API 移除、特殊字符搜索、投票计数、活动流评论/编辑/删除、浏览器前进后退、加载状态、右侧面板、并发编辑、慢网络、会话保持、深层嵌套、快速交互、多并发 API、不存在术语表/术语的错误态、引用 URL 的 http/https 前缀校验。
GlossaryCRUDOperations.spec.ts（13 tests）：带标签/owner/描述创建、互斥开启、同义词/引用、owner/reviewer/标签移除、父术语级联删除、拖拽父术语、tab 导航、行操作建子术语、带标签建术语、同义词移除。
GlossaryAssets.spec.ts（10 tests）：向术语添加 topic/pipeline 资产、资产卡片摘要面板、资产内搜索、移除资产、实体页移除术语标签、批量移除资产、按实体类型过滤、Add Assets 下拉、资产分页。

工作流、状态机与层级

GlossaryWorkflow.spec.ts（10 tests）：术语状态机——无 reviewer 时术语直接 Approved；有 reviewer 时从 Draft 开始；继承术语表 reviewer；状态徽标 hover 显示工作流历史；术语详情页查看历史；非 reviewer 看不到批准/拒绝按钮；owner 非 reviewer 也看不到；非 reviewer 编辑已批准术语会改变状态；父术语级联删除。
GlossaryStatusFilterLargeDataset.spec.ts（19 tests）与GlossaryStatusFilterNestedTerms.spec.ts（19 tests）：在大数据集与嵌套术语两种形态下验证 Draft/Approved/In Review/Deprecated/Rejected 五种状态过滤、多状态组合、分页保持、搜索与状态过滤协同、展开全部、5 层嵌套的扁平化命中结果、父链不匹配时叶子命中等边界。
GlossaryHierarchy.spec.ts（6 tests）：术语移回根、跨术语表移动、带子术语移动、取消移动、5+ 层导航、取消拖拽。
GlossaryPagination.spec.ts：术语/嵌套术语搜索、大小写不敏感、空结果、InReview 与多状态过滤。
GlossaryBulkOperations.spec.ts：批量编辑页导航、多术语选择、禁止父拖入自身子级、互斥开关切换。
GlossaryExpandAllWithStatusFilter.spec.ts（4 tests, 9 scenarios）：展开全部与状态过滤的交互（Draft/Approved 过滤下展开可见性、MixedStatusChild 挂在 ApprovedParent 下的显示）。

权限、导入导出与版本

GlossaryPermissions.spec.ts（9 tests）：allow/deny、仅 EditDescription、仅 EditOwners、仅 EditTags、仅 Delete、仅 Create、ViewBasic 只读、基于团队权限。
GlossaryImportExport.spec.ts（7 tests, 18 scenarios）：导出数据术语详情、导入新增术语、版本历史记录批量导入、循环引用报错、缺失必填字段、无效父引用、部分成功（混合有效/无效术语）、大数据量导出、CSV 层级结构保持。
GlossaryVersionPage.spec.ts（7 tests）：术语表/术语版本变更、owner/reviewer 变更展示、版本间导航、返回当前版本、同义词/引用/相关术语变更的 diff。
GlossaryTermRightPanel.spec.ts（10 tests）：术语资产 tab 的右侧面板上下文操作（tab 显示、描述编辑、名称链接、概览、标签、Tier、owner、域、术语编辑）。
GlossaryNavigation.spec.ts（9 tests）：术语表/术语页 tab 导航、面包屑、嵌套术语深链、空状态、活动流查看与评论。
LargeGlossaryPerformance.spec.ts（9 tests）：大数据量分页、搜索过滤、展开/折叠全部、展开单项、滚动位置保持、状态过滤、术语计数、拖拽排序、海量子术语分页。
GlossaryRemoveOperations.spec.ts、GlossaryTermDetails.spec.ts、GlossaryMiscOperations.spec.ts、GlossaryP2Tests.spec.ts、GlossaryFormValidation.spec.ts：分别覆盖 owner/reviewer/标签增删、同义词/引用/相关术语增删、删除术语表/术语后资产标签清理、子 FQN 随父重命名更新、禁止拖到自身、特殊字符名、工作流历史、Draft 状态、列设置自定义属性选项、空名称/空描述/重复名报错。

源码佐证：e2e/Pages/Glossary.spec.ts中可看到test.describe('Glossary tests', ...)与成对的test.step('Create Glossary', ...)、test.step('Create Glossary Terms', ...)、test.step('Approve Glossary Term from Glossary Listing for reviewer user', ...)等步骤调用，与文档表格中↳步骤行一一对应——这正是 doc-generator 抽取步骤的来源。

组件五：Tags（标签）

Tags 组件 8 个文件、45 条测试、63 个场景，覆盖分类（Classification）与标签的管理、权限角色差异、建议流程与系统级行为。

Tag.spec.ts（21 tests, 28 scenarios）：按角色分四组验证——Admin 角色（标签 UI、Certification 页无 Asset 按钮、重命名、样式、描述编辑、删除、资产增删与 EntityType 过滤、带域建标签、owner 增删、启用/禁用开关、分类禁用时开关禁用）、Data Consumer 角色（UI、无 Asset 按钮、描述编辑、资产操作、无 EditAll 权限时开关禁用）、Data Steward 角色（同前）、受限 EditTag 权限（资产操作与受限实体检查）。
TagPageRightPanel.spec.ts（11 tests）：标签资产页的右侧面板——点击资产打开面板、Table 实体 tab 显示、描述编辑、名称链接、概览、未选资产时面板不可见、标签/Tier/owner/域/术语编辑。
Tags.spec.ts（5 tests, 13 scenarios）：分类页基础元素渲染、禁用系统标签不渲染、分类创建校验、标签创建校验、分类术语计数、标签分配到表、通过 Task & Suggestion 流程分配标签到 DatabaseSchema、删除标签、移除分类、按分类显示名搜索标签、系统分类计数、owner 增删、禁用标签禁止从资产 tab 添加资产。
TagsSuggestion.spec.ts（3 tests, 6 scenarios）：Table 实体标签建议的查看/关闭/拒绝/接受、Tier 卡片建议接受、全部拒绝。
SystemCertificationTags.spec.ts：禁用系统认证标签不出现在下拉框、分类禁用时不出现在何系统认证标签。
MutuallyExclusiveColumnTags.spec.ts：向列添加互斥标签时弹出错误 toast。
AutoClassification.spec.ts（nightly）：自动分类数据。
ClassificationVersionPage.spec.ts：分类版本页。

组件六：Data Contracts（数据契约）

数据契约组件仅 3 个文件、96 条测试、599 个场景，却是治理域中单文件场景密度最高的部分，覆盖契约全生命周期、语义规则、继承与 Persona 集成。

契约生命周期：`DataContracts.spec.ts`（48 tests, 423 scenarios）

文档的 1–18 号测试以完全相同的 20 步流程对 18 种实体类型逐一验证，实体清单见源码e2e/Pages/DataContracts.spec.ts顶部的entitiesWithDataContracts数组：Table、Topic、Dashboard、DashboardDataModel、Pipeline、MlModel、Container、SearchIndex、StoreProcedure（StoredProcedure）、ApiEndpoint、ApiCollection、Chart、Directory、File、Spreadsheet、Worksheet、Database、DatabaseSchema。完整步骤链为：

跳转首页并访问实体；
打开契约区块并开始添加契约；
填写契约详情表单（Contract Details）；
填写服务条款详情（Terms of Service）；
填写契约 Schema 表单；
填写第一个契约语义（Semantics）；
添加第二个语义并删除；
保存契约并验证语义；
添加表测试用例并验证质量；
在 Observability 的 bundle 测试套件中验证数据契约测试套件存在；
从数据契约编辑质量期望并验证；
验证 YAML 视图；
导出 YAML；
导出 ODCS YAML；
编辑并验证契约数据；
删除契约；
从 ODCS YAML 导入契约；
删除导入的契约；
从 OM YAML 导入契约；
导出 OM YAML 并删除导入的契约。

其余关键用例：Schema tab 分页且选择保持（翻页后回选列并保存验证）、Tier/Tag/Glossary 的 Contains 与 Not_Contains 语义操作符、嵌套列不可选、旧 Schema 列契约操作、多规则语义、第二语义增删改、Security 与 SLA tab 的添加/更新/移除验证、ODCS 导入模态框 Merge 模式保持契约 ID、Replace 模式覆盖全部字段。另含 18 个 Persona 用例：每种实体在 Contract Tab 被 Persona 隐藏/显示时，契约状态徽标按条件可见。

语义规则：`DataContractsSemanticRules.spec.ts`（40 tests, 120 scenarios）

按规则字段分组验证语义条件评估逻辑，每个字段覆盖操作符的正反断言：

Owner（6 tests）：Is、Is_Not、Any_In、Not_In、Is_Set、Is_Not_Set——同/不同 owner、owner 在/不在列表、有无 owner 的通过/失败。
Description（4 tests）：Contains、Not Contains、Is_Set、Is_Not_Set。
Domain（6 tests）：Is、Is Not、Any_In、Not_In、Is_Set、Is_Not_Set。
Version（6 tests）：Is、Is_Not、<、>、<=、>= 六种比较。
DataProduct（6 tests）：Is、Is Not、Any_In、Not_In、Is_Set、Is_Not_Set。
DisplayName（6 tests）：Is、Is Not、Any_In、Not_In、Is_Set、Is_Not_Set。
UpdatedOn（6 tests）：Between、Not_Between、Less than、Greater than、LessThanEqual、GreaterThanEqual。

继承：`DataContractInheritance.spec.ts`（8 tests, 56 scenarios）

验证数据产品契约向资产的继承语义：

完整继承：资产从数据产品完整继承契约（详情/ToS/语义/SLA 全部继承）；
部分继承：资产自有契约与数据产品契约合并；
编辑继承 SLA：资产从继承状态添加自有 SLA 时 PATCH 必须用/add而非/replace；
编辑继承契约：点击编辑继承契约应打开"添加"表单而非"编辑"，保存后创建新契约而非更新父契约，且数据产品契约不被修改；
删除禁用：完全继承的契约删除按钮禁用；
运行验证：继承契约使用基于实体的验证；
移除资产：资产移出数据产品后不再显示继承契约；
回退：删除资产自有契约后回退显示数据产品继承契约。

在仓库中如何定位与运行这些测试

目录结构

文档：openmetadata-ui/src/main/resources/ui/playwright/docs/Governance.md（及同级README.md、Discovery.md、Platform.md、Observability.md、Integration.md）；
生成器：openmetadata-ui/src/main/resources/ui/playwright/doc-generator/{generate.js, playwright-loader.js, markdown.js}；
测试用例：openmetadata-ui/src/main/resources/ui/playwright/e2e/Pages/（页面级）、e2e/Flow/（流程级）、e2e/Features/（特性级，含Glossary/、Permissions/、LandingPageWidgets/等子目录）、e2e/VersionPages/（版本页）、e2e/nightly/（夜间测试）；
支撑工具：playwright/constant/（测试常量，如customProperty.ts、domain.ts、dataContracts.ts）、playwright/support/（实体类工厂，如support/entity/TableClass.ts、support/glossary/Glossary.ts）、playwright/utils/（如utils/dataContracts.ts提供saveContractAndWait、exportContractYaml、triggerContractValidation等数据契约操作封装）。

运行方式

在仓库根目录按 Playwright 项目约定运行，例如：

# 列出测试（与文档生成器同源的发现机制） npx playwright test --list --reporter=json --config openmetadata-ui/src/main/resources/ui/playwright # 运行治理域中的特定 spec npx playwright test e2e/Pages/DataContracts.spec.ts --config openmetadata-ui/src/main/resources/ui/playwright # 重新生成全部 E2E 文档 yarn generate:e2e-docs

运行前提可参考openmetadata-ui/src/main/resources/ui/playwright/PLAYWRIGHT_DEVELOPER_HANDBOOK.md（开发手册）与仓库根目录AGENTS.md/DEVELOPER.md中的环境准备说明。绝大多数治理测试需要先通过 ingestion 摄入示例数据（如SampleDataDomainDataProduct.spec.ts依赖样本数据中的 TestDomain/TestDataProduct），因此建议基于官方本地开发环境（docker-compose-quickstart或docker-compose-postgres）运行。

小结：如何用好这份文档

Governance.md的本质是一张"治理功能 UI 测试覆盖索引"。日常使用建议：

回归选测：按组件表锁定范围——动到自定义属性相关代码就关注 Custom Properties 的 7 个文件；动到数据契约流程就关注 Data Contracts 的 3 个文件（尤其是DataContracts.spec.ts的 20 步流程与DataContractsSemanticRules.spec.ts的操作符矩阵）。
理解口径：文件括号内的两个数字分别代表test()块数量与步骤级场景数量，后者更能反映测试深度。
溯源源码：文档表格中的每一条测试都能在e2e/对应 spec 文件中找到test.describe/test/test.step三层结构，步骤行的↳前缀即来自 AST 解析；常量与实体工厂则沉淀在constant/与support/中，可作为编写新测试的模板。
注意快照滞后：文档由 CI 自动生成，若当前分支存在 spec 拆分/重命名，以文档为索引、以分支实际文件为准。

治理域六大组件的 933 条测试与 1598 个场景，共同构成了 OpenMetadata 在"为数据和 AI 建立可信上下文与业务语义"这一核心目标上最完整的 UI 层质量防线——无论是自定义属性的字段扩展、术语表的审批治理，还是数据契约的生命周期与继承语义，这张测试地图都能帮你快速定位能力边界与回归入口。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析