---
title: "术语表"
language: "zh"
url: "https://docs.testany.io/zh/docs/glossary/"
markdown_url: "https://docs.testany.io/zh/docs/glossary.md"
translation: "https://docs.testany.io/en/docs/glossary.md"
last_updated: "2026-03-26T15:39:24+08:00"
---

# 术语表

## 🇦 A-D

| **名称** | **定义** |
| --- | --- |
| <span id="assertion"></span>断言 (Assertion) | 这是指在测试设置中验证特定测试用例的输出是否与预期输出或行为匹配的语句。如果断言为真，则测试用例通过；如果为假，则测试用例失败。断言是创建稳健且有效的自动化测试场景的重要组成部分，因为它们允许对被测试产品或系统的功能进行精确和即时的反馈。 |
| <span id="case-visibility"></span>用例可见性 (Case Visibility) | 在 Testany 平台中，用例可见性指的是对用例应用的访问控制级别，用于确定谁可以查看和操作用例。有两种用例可见性类型：全局可见性和工作区限制可见性。 |
| <span id="cloudprime"></span>CloudPrime | CloudPrime，与TR相对，是由Testany一方管理的运行时。每个租户只有一个CloudPrime运行时。 |
| <span id="command"></span>命令 (Command) | 在 Testany 平台中，**Command（命令）** 是指运行特定测试用例所需的可执行指令或脚本命令。它是触发指定环境中测试执行的具体代码或命令行，通常包含与使用的测试框架相关的参数或选项。  目前，如果执行器是 “Python” 或者 “Pyres”， 会需要填写命令 （Command） |
| <span id="credential-safe"></span>凭证保险箱 (Credential Safe) | “凭证保险箱”是一个代表第三方凭证存储的虚拟对象。 |
| <span id="cumulative-view"></span>累计过滤模式（Cumulative View） | 测试用例目录视图的过滤模式之一。在累计过滤模式下，选中某个目录后，右侧的测试用例列表会包含与该目录以及所有子目录相关的测试用例。换言之，如果某个测试用例能出现在子目录中，则表示它同时拥有子目录及其父目录对应的标签，也会被归入父目录的测试用例列表。  要了解更多关于Testany的测试用例目录视图的过滤模式，请[点击这里](https://docs.testany.io/zh/docs/manage-directory-view-of-test-case.md#两种主要的过滤模式)。 |
| <span id="user-disabled"></span>（用户）禁用 (user) Disabled | 禁用是一种用户状态。在这种状态下，用户将无法登录、访问该租户下的任何资源或对任何资源执行任何操作。此外，用户将无法通过Testany的任何通知渠道（方法）接收任何通知。同时，用户将从所有资源的“全局管理员”、“工作区管理员”、“工作区成员”以及“所有者”、“观察者”字段中移除。禁用是一种不可逆的状态，只能由全局管理员执行。 |

## 🇪 E-K

| **名称** | **定义** |
| --- | --- |
| <span id="environment"></span>环境 (Environment) | “环境”一词指的是用户测试所针对的应用环境，例如Stage, Production等。 |
| <span id="exclusive-view"></span>独有显示模式（Exclusive View） | 测试用例目录视图的过滤模式之一。在独有显示模式下，右侧的测试用例列表仅显示**直接**与所选目录关联的测试用例，不包含子目录的用例。也就是说，只有明确打上该目录标签（而非仅拥有子目录标签）的测试用例才会在列表里出现  要了解更多关于Testany的测试用例目录视图的过滤模式，请[点击这里](https://docs.testany.io/zh/docs/manage-directory-view-of-test-case.md#两种主要的过滤模式)。 |
| <span id="execution"></span>执行 (Execution) | 每次执行都是一个流水线的运行，包括流水线执行的结果。它包含流水线运行的实时状态和结果。 |
| <span id="execution-unit"></span>执行单元 (Execution Unit) | 一个系统控制的运行环境，用于执行测试用例。 |
| <span id="executor"></span>执行器（Executor） | 在 Testany 平台中，**Executor（执行器）** 是负责运行流水线中测试用例的核心组件。它按照用户定义的测试脚本和配置，在指定的测试环境中执行测试任务，处理测试数据，并生成测试结果。Executor 支持多种测试框架，确保与用户测试环境的无缝集成，从而实现高效、可靠的自动化测试执行。 |
| <span id="gatekeeper"></span>门卫 (Gatekeeper) | 在我们的产品中，“门卫”是一个功能，允许用户使用webhook触发特定组的测试。用户可以创建一个门卫并从中接收webhook，然后可以将其集成到各种开发/运维工具中。每当发生用户指定的事件时，门卫将触发预设流水线组的执行。这使用户能够在特定场景中执行测试，促进高效、持续的产品优化和问题监控。 |
| <span id="gatekeeper-key"></span>门卫标识 (Gatekeeper Key) | 门卫密钥是Testany平台上用于标记门卫的唯一标识符。每个门卫在创建时都会收到一个独特的密钥。这个密钥总共由10个字符组成：第一个字符是“G”，表示“门卫”，后跟一个连字符。接下来的三个字符代表门卫对应工作区的密钥值。再后一个连字符，最后四个字符是系统自动生成的数字。例如，一个门卫密钥可能看起来像这样：G-WSK-5678。一旦门卫成功创建，其密钥不能被任何角色修改或删除。无论门卫本身的任何更改或删除，这个标识符都保持不变。 |
| <span id="gatekeeper-owner"></span>门卫所有者 (Gatekeeper Owner) | 在我们的系统中，门卫所有者是有权编辑和管理门卫以触发测试执行的用户。门卫所有者确定触发测试的具体条件，例如定义激活门卫的事件或标准。他们还负责将用户添加到观察者列表中，确保合适的团队成员得到通知并参与流程。这个角色对于在自动化测试中保持高效和有效性至关重要，促进主动的产品优化和问题监控。 |
| <span id="global-admin"></span>全局管理员 (Global Administrator) | 在Testany中，这是一个系统默认角色。要了解更多关于Testany的权限策略，请[点击这里](https://docs.testany.io/zh/docs/mastering-testany-platform-permission-and-user-sta.md)。 |
| <span id="global-visibility"></span>全局可见性 (Global Visibility) | 具有全局可见性（Global Visibility）的用例对租户中的所有活跃用户可见。这些用例可以被任何该租户下的活跃用户（基于现有的权限控制机制）查看和管理，无论其是否属于特定工作区。这种选项非常适合需要在多个团队之间共享用例的协作场景。 |
| <span id="github-app-installation"></span>GitHub App Installation | GitHub App Installation 是指 GitHub App 被安装到某个个人账号或组织后形成的授权绑定。在 Import from Git V2 中，每个 installation 都对应一个按仓库 owner 划分的访问范围，Testany 会据此发现可导入仓库并管理仓库访问。 |
| <span id="import-history"></span>导入历史记录 (Import History) | 导入历史记录是 Testany 为每一次 Import from Git 操作创建的持久化记录。它保存了源仓库、所选分支、版本策略、导入模式、已选文件、运行时、所有者、时间戳以及后续维护所需的生命周期信息。通过查看或修改导入历史记录，用户可以持续管理 Testany 测试用例与底层 Git 源之间的关系。 |
| <span id="import-history-owner"></span>导入历史记录所有者 (Import History Owner) | 导入历史记录所有者指在 Testany 中负责创建和维护某条 Import History 记录的用户。该用户负责这条 Git 关联关系的持续配置与生命周期管理，包括编辑或删除该记录，以及更新与之关联的测试用例。 |

## 🇱 L-O

| **名称** | **定义** |
| --- | --- |
| <span id="managed-import"></span>Managed Import | Managed Import 是 Import from Git V2 的一种模式，Testany 会把仓库代码导入平台管理的 Mirror。执行时读取的是 Mirror 中的脚本，而不是直接从 Git 拉取。在 Track Latest 模式下，Mirror 需要通过手动 Sync 或 GitHub Webhook 来推进，而不是在执行时自动追最新代码。 |
| <span id="manual-trigger"></span>手动触发 (Manual Trigger) | 手动触发（Manual Trigger）是 Testany 中用于按需执行测试的触发模板。用户可以创建手动触发、关联一条或多条流水线，并在需要时立即执行，而无需等待计划调度或外部 Webhook 事件。每次执行都会产生一条可在执行记录中追踪的 Trigger Instance。 |
| <span id="manual-trigger-key"></span>手动触发标识 (Manual Trigger Key) | 手动触发标识（Manual Trigger Key）是手动触发资源的不可变唯一标识。该标识在创建时由平台生成，以 "M" 为前缀，包含工作区标识，并以 4~5 位大写十六进制后缀结尾。它用于页面路由、API 查询和执行追踪。 |
| <span id="manual-trigger-owner"></span>手动触发负责人 (Manual Trigger Owner) | 手动触发负责人（Manual Trigger Owner）是某个手动触发模板资源的责任用户。该用户可在权限策略允许范围内维护触发器元数据、关联流水线和通知配置。该角色不同于手动触发执行人（即对某次 Trigger Instance 实际点击执行的操作人）。 |
| <span id="manual-trigger-executor"></span>手动触发执行人 (Manual Trigger Executor) | 手动触发执行人（Manual Trigger Executor）是发起某一次手动触发执行的用户。在执行数据中，该身份按 Trigger Instance 维度记录，且可能与手动触发负责人不同。 |
| <span id="mirror"></span>Mirror | Mirror 是 Import from Git V2 中 Managed Import 记录使用的平台托管代码副本。Testany 会通过 Sync 或 Webhook 触发的刷新等显式生命周期动作，把这个副本推进到更新的 commit。如果对应的 Managed Import 导入记录被删除，这个 Mirror 也会一并删除。 |
| <span id="output-relay"></span>输出中继 (Output Relay) | **输出中继**功能使得在执行过程中在同一流水线内的测试用例之间无缝传输数据成为可能。它允许一个或多个已完成测试用例（称为“中继用例”）的变量用作后续测试用例的输入。此数据中继实时发生，利用在执行过程中动态获取的值。通过利用输出中继，用户可以高效管理多个测试用例之间的测试数据，而无需人工干预或外部数据源。此功能通过允许测试用例依赖实际执行结果来优化测试自动化工作流，提高下游测试场景的准确性和相关性。它还增强了测试数据管理的整体效率，特别是在需要相互依赖的测试用例的环境中。 |

## 🇵 P-S

| **名称** | **定义** |
| --- | --- |
| <span id="path"></span>路径（Path） | 在 Testany 平台中，**Path（路径）** 是指测试用例脚本在测试脚本zip包中的存储位置，以便平台能够找到并执行测试用例。路径必须与测试环境中脚本的实际存储位置一致。 |
| <span id="plan"></span>计划任务 (Plan) | 在我们的产品中，“计划任务”是一个功能，允许用户预设测试的执行时间和频率。用户可以通过设置精确的日期和时间或设置重复间隔来创建计划。这使用户能够在理想的时间和适当的频率下执行测试，从而实现高效、持续的产品优化和问题监控。 |
| <span id="plan-key"></span>计划任务标识 (Plan Key) | 它是Testany平台上用于标记计划任务的标识符，并具有唯一性。当每个计划任务在平台上创建时，系统会为其分配一个值。这个密钥总共由10个字符组成：第一个字符是“P”，表示“计划任务”，第二个字符是连字符，第三到第五个字符是计划对应工作区的密钥值，第六个字符是连字符，最后四个字符是系统自动生成的数字。（示例：P-TAN-1234）一旦计划成功创建，所有角色都不能修改或删除其密钥。即使计划本身被更改或删除，这个值也保持不变。 |
| <span id="plan-owner"></span>计划所有者 (Plan Owner) | 计划任务所有者是计划任务资源的所有者。该用户负责维护计划任务配置，包括调度规则、关联流水线、元数据（如标签）和通知配置，并受平台权限控制约束。 |
| <span id="pinned-commit"></span>Pinned Commit | Pinned Commit 是一种版本策略，用于把导入记录锁定在某个特定 commit 上。在用户显式切换到另一个 commit，或者改回 Track Latest 之前，这条记录不会继续跟随分支后续的 commit。 |
| <span id="repository-access-scope"></span>仓库访问范围 (Repository Access Scope) | 仓库访问范围是某个 GitHub App installation 暴露给 Testany 的仓库集合。在 Import from Git V2 中，它决定了在选择某个 owner 后，向导中会出现哪些仓库，以及哪些仓库可以真正被导入。 |
| <span id="relay-case"></span>中继用例 (Relay Case) | “中继”是测试用例的一个属性。具有此属性的测试用例可以在其执行完成后将其预先声明的变量值作为输入传递给同一流水线内的其他用例。中继用例促进数据传输和共享，确保测试用例之间的依赖关系得到妥善管理，从而提高测试过程的自动化和效率。**特征**：**数据生成**：中继用例可以负责生成特定的输出数据。**数据传输**：此输出数据会自动传递给指定的下游测试用例。**依赖管理**：中继用例使得测试用例之间的依赖关系得以管理和处理。**自动化**：提高测试流水线中的自动化水平，减少人工干预的需要。 |
| <span id="source-deleted"></span>源端已删除 (source_deleted) | source_deleted 是 Import from Git V2 中的一种 binding 状态，表示之前已跟踪的源文件在当前源端快照或 Mirror 快照中已经不存在。把文件标记为 source_deleted 只会更新 binding 状态，不会自动删除对应的 Test Case。 |
| <span id="sync-link"></span>Sync Link | Sync Link 是一种 Git 关联模式。Testany 会维护 Test Case 与 Git 文件之间的关系，但执行时直接从 Git 读取脚本。在 Import from Git V1 中，Sync Link 是唯一支持的模式；在 Import from Git V2 中，它是可选模式之一。在 Track Latest 模式下，执行会跟随分支最新 commit，但像新增文件、源端删除文件这样的关系变化仍然需要显式处理。 |
| <span id="runtime"></span>运行时 (Runtime) | 在Testany平台的上下文中，运行时指的是一组管理测试启动/停止、测试运行、测试凭证和访问测试日志的专门服务。此外，这些服务被封装在一个Kubernetes操作员中，可以部署在公共云、私有云甚至物理服务器上。运行时直接从Testany平台的调度系统接收命令以运行测试，测试完成后存储日志，并将测试结果（成功、失败、跳过等）发送到Testany平台的通知系统。 |
| <span id="secure-uuid"></span>安全UUID (Secure UUID) | 这是用于密钥名称前缀的UUID。在Testany中注册的每个测试用例都会有一个唯一的安全UUID。它用于TSS从可信凭证保险箱中检索测试密钥。如果您在可信凭证保险箱中存储了一个密钥，密钥名称应遵循<Secure UUID>-<secretName>格式，这意味着，如果密钥名为`client-secret`，则存储在您的可信凭证保险箱中的密钥名为`<Secure UUID>-client-secret` |
| <span id="subscription"></span>订阅 (Subscription) |  |
| <span id="user-suspended"></span>（用户）暂停 (user) Suspend | 暂停是一种用户状态。在这种状态下，用户将无法登录、访问该租户下的任何资源或对任何资源执行任何操作。此外，用户将无法通过Testany的任何通知渠道（方法）接收任何通知。然而，除非由全局管理员修改，否则该租户下用户的所有属性和数据保持不变。暂停是一种可逆的操作，只能由全局管理员执行。当“暂停”属性重置为false时，用户恢复他们在被暂停之前拥有的所有操作权限。 |

## 🇹 T-Z

| **名称** | **定义** |
| --- | --- |
| <span id="test-case"></span>测试用例 (Test Case) | “测试用例”是一组条件或变量，测试人员将根据这些条件或变量来确定应用程序、软件系统或其某个功能是否按最初设定的方式工作。测试用例包括特定的变量或条件，以及预期结果，这有助于测试人员确定系统的性能是否符合其设计和要求。 |
| <span id="test-case-library"></span>测试用例库（Test Case Library） | 在 Testany 平台中，**测试用例库（Test Case Library）** 是指存储、组织和管理测试用例的仓库。它是 Testany Platform 里的顶层结构之一，为用户提供了一个组织化的仓库，用于创建、编辑、分类和维护测试用例，从而实现高效的复用、版本控制和团队协作。 |
| <span id="test-case-owner"></span>测试用例所有者 (Test Case Owner) | 这是我们产品中的一个用户角色，允许用户在 Testany 平台上编辑和管理测试用例。测试用例所有者可以编辑测试脚本，定义输入参数、预期的输出和行为。管理的测试用例包含在测试流水线中，用于持续验证产品或系统的质量和性能。 |
| <span id="test-script"></span>测试脚本 (Test Script) | 这是指测试用例中的可执行脚本，概述了测试过程中要遵循的具体步骤和条件。它包括测试输入、预期结果和断言语句等。该脚本设计用于在自动化测试框架中运行，并且是包含测试用例相关元数据的整体测试用例包的一部分。 |
| <span id="test-case-key"></span>测试用例标识 (Test Case Key) | 测试用例键是 Testany 平台上用于标记测试用例的标识符。每个测试用例在 Testany 平台上注册时，系统会自动分配一个 8 位数字的键值。（示例：20231024）此键将在 Testany 平台上伴随测试用例的整个生命周期，即使测试用例更新，此值也不会更改。 |
| <span id="test-case-meta"></span>测试用例元数据 (Test Case Meta) | 这是指测试用例包中与测试用例相关的元数据。它提供了关于测试用例的重要背景和信息，包括但不限于作者、测试环境、创建日期、状态、优先级、版本以及可能的敏感信息，如访问需要测试的应用程序凭证的方法。此元数据对于有效管理、执行和解释测试结果至关重要，并补充了整体测试用例包中的测试用例代码。 |
| <span id="test-case-step"></span>测试用例步骤 (Test Case Step) | 测试用例步骤是测试用例过程中的一个步骤。一个测试用例可能包含多个测试用例（但我们强烈不推荐）。通常，测试用例步骤是一个 API 调用。 |
| <span id="test-execution"></span>测试执行 (Test Execution) | 该术语指的是运行测试流水线的行为。它涉及启动测试、监控其进度，并可能包括实时跟踪结果。基本上，它是对软件组件进行预定义测试的操作。 |
| <span id="test-execution-engine"></span>测试执行引擎 (Test Execution Engine) | （又名 TEE）Testany 中负责测试执行的服务。 |
| <span id="test-execution-result"></span>测试执行结果 (Test Execution Result) | 这是测试执行完成后生成的结果。它提供了通过、失败以及测试期间捕获的任何其他指标或诊断的全面视图。测试执行结果通常是团队评估质量、性能和可靠性的依据。 |
| <span id="test-execution-uuid"></span>测试执行 UUID (Test Execution UUID) | Testany 平台上的“测试执行 UUID”是一个复合字符串，用于唯一标识每次测试执行运行。它遵循格式 `{test_pipeline_key}-{5_digit_auto_incrementing_number}`。在此格式中，“测试流水线键”表示为“xxx-1234”，并与一个 5 位自动递增数字配对。此唯一标识符确保特定测试流水线内的每次测试运行都是独特的，便于更轻松地跟踪、查询和管理测试结果及相关元数据。 |
| <span id="test-pipeline"></span>测试流水线 (Test Pipeline) | 在我们的产品中，“测试流水线”是用于实施自动化测试的功能。它由一系列预定义的自动化测试用例组成，这些用例由各种测试框架触发，并可以按特定顺序和逻辑执行。测试流水线的目标是持续验证产品或系统的质量和性能。每次执行都会生成测试结果，可以在“执行”中查看并推送给观察者。 |
| <span id="test-pipeline-owner"></span>测试流水线所有者 (Test Pipeline Owner) | 这是我们产品中的一个用户角色，允许用户编辑和管理测试流水线。测试流水线所有者可以选择和安排预定义的自动化测试用例，并定义其执行顺序和逻辑。他们的目标是创建能够持续验证产品或系统质量和性能的测试流水线。 |
| <span id="test-pipeline-key"></span>测试流水线标识 (Test Pipeline Key) | 测试流水线键是 Testany 平台上用于标记测试流水线的唯一标识符。当每个测试流水线在平台上创建时，系统会为其分配一个值。此键总共由 8 个字符组成：前三个是测试流水线对应工作区的键值，第四个字符是连字符，最后四个字符是系统自动生成的数字。（TAN-5678）一旦测试流水线成功创建，所有角色都无法更改或删除此键，即使测试流水线本身被更改或删除，此值也保持不变。 |
| <span id="test-orchestration-engine"></span>测试编排引擎 (Test orchestration Engine) | （又名 TOE）这是我们产品的一个关键组件，用于自动化和管理复杂工作流的执行，如测试流水线。编排引擎协调流水线中每个步骤的顺序、时间和依赖关系，确保测试高效且准确地执行。它可以处理诸如在指定时间触发测试、管理资源、处理错误以及将结果发送给观察者等任务。 |
| <span id="testany-secrets-service"></span>Testany Secrets Service | （又名 TSS）Testany Secrets Service 是一种专门设计的服务，用于从受信任的证书保险箱（如 Azure Key Vault 和 AWS Secrets Manager）中获取秘密。它促进了密钥和证书等敏感信息的安全检索，确保数据安全性和符合行业标准。该服务通过接收请求来提取由密钥标识的特定秘密，并以请求的数据进行响应，从而在安全信息管理中发挥关键作用。 |
| <span id="trigger-id"></span>触发ID (Trigger ID) | 触发ID用于标识触发对象/模板本身。对 Plan 与 Gatekeeper 来说，触发ID就是对象 key（例如 `P-WKS-7351`、`G-WKS-0605`）；对 Manual Trigger 来说，触发ID是 `M-<workspace_key>-<seq5>`（例如 `M-WKS-00001`）。 |
| <span id="trigger-instance-id"></span>触发实例ID (Trigger Instance ID) | 触发实例ID用于标识同一触发ID下的一次具体执行（例如 `00007`）。它与触发ID组合形成触发实例键（例如：`M-WKS-00001` + `00007` => `M-WKS-00001-00007`）。 |
| <span id="trigger-instance"></span>触发实例 (Trigger Instance) | 触发实例（Trigger Instance）表示执行历史中的一次具体触发事件（例如一次手动触发执行、一次计划任务到点触发或一次门卫 webhook 触发）。一个触发实例下可能包含多条流水线执行，而每条流水线执行又可能包含多条测试用例执行。 |
| <span id="track-latest"></span>Track Latest | Track Latest 是一种版本策略，用于让导入记录跟随所选分支上的最新 commit。在 Import from Git V2 中，它决定代码来源如何向前推进，但不会自动应用关系层变化，例如为新增文件自动创建 Test Case，或自动标记源端删除文件。 |
| <span id="trusted-runtime"></span>受信任的运行时 (Trusted Runtime) | （又名 “TR”）受信任的运行时是指由用户自行安装和管理的运行时。TR 与用户订阅的 Testany 平台 SaaS 通信，接收指令并输出结果。每个租户可以同时拥有多个 TR，以满足不同的测试需求。 |
| <span id="user"></span>用户 (User) | 在我们的产品中，“用户”指的是系统中的用户配置文件。它包含用户信息、登录凭证和设置。用户还决定了用户在产品中的权限和访问权，例如他们可以访问和管理哪些工作区、测试流水线和计划。 |
| <span id="watcher"></span>观察者 (Watcher) | 在我们的产品中，“观察者”指的是与测试流水线和计划相关的角色。观察者是接收测试流水线执行结果的主动推送通知的用户。这使得这些用户能够实时跟踪和了解测试的进展和结果，而无需手动检查或查询。特定测试流水线的观察者列表由计划创建者创建和管理。 |
| <span id="webhook-dispatch"></span>Webhook Dispatch | Webhook Dispatch 是 Testany 中的通知功能，通过 HTTP POST 请求将测试执行结果发送到外部系统。可在计划（Plan）和门卫（Gatekeeper）上配置，自动将包含执行详情（状态、测试用例结果、时间戳等）的结构化 JSON 载荷发送到任何兼容 Webhook 的端点，如 Slack、Jira、PagerDuty 或自定义服务。这使得团队通知、工单创建、事件升级或 CI/CD 质量门禁等自动化工作流成为可能。 |
| <span id="workspace"></span>工作区 (Workspace) | 在我们的产品中，“工作区”是一个包含测试流水线、测试执行和计划的隔离工作环境。每个工作区彼此隔离，提供独特的资源和数据环境。通过我们产品定义的基于角色的访问控制（RBAC）策略，全球管理员或工作区管理员授予用户对特定工作区的访问权限。 |
| <span id="workspace-key"></span>工作区标识 (Workspace Key) | 工作区是 Testany 平台上用于标记工作区的标识符。当每个工作区在平台上创建时，系统要求创建者指定一个值。此键由三个字符组成，第一个字符是字母，接下来的两个字符可以是字母或数字。（示例：TA9）然而，键不支持空格、符号、特殊字符或表情符号。此键将在 Testany 平台上伴随工作区的整个生命周期，即使工作区更新或存档，此值也不会更改。具有创建工作区权限的角色可以在首次创建工作区时指定键。创建后，键不能更改或删除。其他角色无权创建、修改或删除此键。 |
| <span id="workspace-admin"></span>工作区管理员 (Workspace Admin) | 在 Testany 中，这是一个系统默认角色。要了解更多关于 Testany 的权限策略，请[点击这里](https://docs.testany.io/zh/docs/mastering-testany-platform-permission-and-user-sta.md)。 |
| <span id="workspace-member"></span>工作区成员 (Workspace Member) | 在 Testany 中，这是一个系统默认角色。要了解更多关于 Testany 的权限策略，请[点击这里](https://docs.testany.io/zh/docs/mastering-testany-platform-permission-and-user-sta.md)。 |
| <span id="workspace-restricted-visibility"></span>工作区限制可见性 (Workspace-Restricted Visibility) | 具有工作区限制可见性（Workspace-Restricted Visibility）的用例仅对其所属工作区的成员可见。这些用例无法被指定工作区之外的用户查看或访问，从而确保数据隔离和保密性。  对于具有工作区限制可见性的用例，如果用户拥有的工作区成员权限与用例所属的工作区存在任何重叠，则该用户可以查看该用例。  要了解更多关于工作区限制可见性，请[点击这里](https://docs.testany.io/zh/docs/mastering-testany-platform-permission-and-user-sta.md)。 |