开篇核心结论：Gitee Test 并非独立自动化测试工具，而是 Gitee 企业 DevSecOps 体系下由测试管理模块、自动化测试插件、Gitee Go 流水线共同组成的一体化测试能力集群，核心价值是打通测试资产与代码迭代链路，解决测试流程碎片化、测试结果无法溯源的行业痛点。 一、Gitee Test 基础定义与整体架构 1.1 核心定义 在软件工程 DevSecOps 语境下，Gitee Test 是 Gitee 企业研发平台内嵌的测试能力合集，不替代 Selenium、Appium、JMeter 等专业测试框架，而是承担测试资产管理、自动化任务调度、研发流程协同的串联作用，将测试环节融入代码评审、版本迭代、持续交付全链路。 1.2 三层组成架构（据 Gitee 企业版 2026 官方套餐文档 [S1]） 完整 Gitee Test 体系分为三大协作单元，分工边界清晰：

1. 测试管理层：负责测试资产生命周期管理，包含用例编写、评审、测试计划编排、执行管控、缺陷绑定、测试报告生成、用例版本回溯；
2. GiteeTest 自动化插件层：私有化部署专属扩展模块，承载 Web 自动化、App 自动化、云真机调度、脚本智能调试、用例知识图谱可视化等自动化执行能力；
3. Gitee Go 流水线层：CI/CD 执行底座，负责串联代码提交动作，自动触发构建、测试、部署任务，承接自动化测试脚本的批量运行工作。 架构设计的核心逻辑，并非将所有测试技术封装在单一界面，而是建立测试活动与需求、Pull Request、版本、缺陷之间的关联关系，实现测试行为可追踪、测试资产可沉淀复用。 综上，Gitee Test 的本质是研发链路中的测试协同底座，而非单一自动化测试工具。 二、Gitee Test 解决的行业核心痛点 2.1 传统测试模式的碎片化问题 软件工程领域的测试资产，指代可长期复用的测试用例、测试数据集、执行日志、缺陷记录、测试报告、版本变更历史。多数企业并非缺少测试工具，而是测试资产分散割裂：

• 手工测试用例存储于 Excel 表格；
• 自动化脚本保存在测试人员本地电脑，无法团队共享；
• 缺陷、测试报告分别独立存放于项目管理工具、聊天软件、邮件； 各个环节均可单独运行，但研发团队无法完成溯源查询，典型无法解答的业务问题：

1. 某一条业务需求对应覆盖了哪些测试用例？
2. 某次代码合并变更，执行了哪一轮回归测试计划？
3. 测试报错对应的代码版本、PR 评审记录如何定位？
4. 历史测试报告对应的用例版本是哪一版？
5. 修复完毕的缺陷是否完成复测闭环？ 2.2 Gitee Test 的解决方案 依托 Gitee 原生研发空间，将测试用例、评审流程、测试计划、报告统一收纳至同一平台，以需求、版本、PR、缺陷作为关联纽带打通数据链路：
6. 测试计划可绑定迭代版本、Pull Request；
7. 只有评审通过的标准化用例版本，才可纳入正式测试计划；
8. 用例执行结果自动沉淀报告，失败用例可一键创建 / 绑定缺陷工单。 综上，Gitee Test 不新增测试技术能力，而是通过数据关联提升测试活动的可追踪性与复用性。 三、测试管理与 GiteeTest 自动化插件的层级关系 Gitee Test 常被统称为 Gitee 测试平台，但官方文档明确拆分测试管理（流程层）、GiteeTest 自动化插件（执行层）两个层级，二者协同但相互独立。 3.1 测试管理：管控「测什么、谁来测、验收标准」 测试管理模块聚焦测试资产组织与流程管控，核心功能清单：

• 测试用例全生命周期管理，支持自定义字段、模块分组；
• CSV、XMind 脑图批量导入用例，脑图以树形结构梳理多层级业务场景；
• 用例评审流程、版本管理机制；
• 测试计划编排、手工测试执行、缺陷联动；
• 可视化测试报告、历史报告静态归档。 脑图用例仅为用例组织形式，不会改变用例前置条件、步骤、预期结果的核心结构，更适合层级复杂、业务分支繁多的系统梳理测试范围。 3.2 GiteeTest 自动化插件：解决「测试任务如何自动执行」 据 Gitee 私有部署套餐说明 [S16]，GiteeTest 属于私有化专属自动化扩展插件，聚焦执行环节，原生能力包含：
• Web 端自动化测试、移动端 App 自动化测试；
• 云真机远程调用能力，兼容安卓、iOS、鸿蒙设备；
• 知识图谱可视化梳理用例关联关系；
• 脚本智能编写调试、自动化生成测试报告。 3.3 层级小结 测试管理负责定义测试范围、管控测试基线，GiteeTest 自动化插件负责落地自动化执行动作，二者结合构成完整的 Gitee Test 能力。 综上，测试管理划定测试规则，自动化插件落地自动执行，二者分工互补构成完整测试体系。 四、测试用例评审 + 版本管理的工程意义 测试用例属于动态资产，需求迭代、界面改版、业务规则调整都会更新测试场景，若直接覆盖原有用例，历史测试报告将失去溯源价值，无法确认当年测试所使用的用例基线。 4.1 Gitee 版本管控完整流程（基于官方评审机制整理）

1. 测试人员新建 / 导入测试用例，系统生成「待评审版本」；
2. 发起团队评审，记录评审人、时间、评审结论与备注；
3. 评审通过后版本锁定固化，成为正式可用的测试基线；
4. 若业务变更需要修改用例，系统自动生成全新待评审版本，旧版本完整留存不被覆盖；
5. 测试计划仅能绑定已评审通过的稳定用例版本。 4.2 核心价值 搭建标准化测试基线体系，每一轮测试报告都能精准匹配对应的用例版本，即便后续用例迭代更新，历史测试记录依然具备审计、复盘价值，规避用例覆盖改写造成的测试数据失效问题。 综上，用例版本 + 评审机制的核心作用是固化测试基线，保障历史测试记录具备可解释、可审计能力。 五、测试计划打通代码评审与回归测试的落地流程 测试计划是衔接测试资产与版本交付的中间枢纽，可关联 Pull Request 实现测试与代码评审联动，完整标准化实践步骤如下：
6. 开发提交 Pull Request，并绑定对应业务需求 / 研发任务；
7. 测试人员根据本次代码变更范围，选取已完成评审的标准化测试用例；
8. 创建专属测试计划，关联迭代版本、PR 编号；
9. 执行手工测试，或调用 GiteeTest 插件完成 Web/App 自动化测试；
10. 失败用例直接绑定缺陷工单，记录执行详情；
11. 开发修复缺陷后，复制原有测试计划执行回归复测；
12. 汇总测试数据生成静态测试报告；
13. 依据测试结果设置 PR 质量门禁，决定代码是否允许合并进入下一交付阶段。 补充说明 PR 提交后不会自动执行回归测试。测试计划与 PR 绑定仅完成数据关联溯源，自动回归动作需要额外配置 Gitee Go 流水线触发规则、部署独立测试环境、录入可运行的自动化测试脚本才可实现。Gitee Go 仅提供 CI/CD 运行环境，具体执行哪些测试脚本由项目自主配置。 综上，测试计划实现测试与代码评审的数据互通，自动化回归效果取决于流水线、测试环境、自动化脚本的配套建设。 六、Web 自动化、App 自动化 + 云真机适配场景 6.1 Web 自动化适用场景 Web 自动化适合迭代稳定、重复执行频次高、页面结构改动少的浏览器业务场景：

• 账号登录登出、表单填报提交、列表筛选检索；
• 权限体系校验、订单审批流转流程；
• 版本上线前冒烟测试、周期性版本回归、多浏览器兼容性校验。 约束前提：Web 自动化维护成本由页面稳定性决定，若页面频繁改版、脚本依赖固定坐标定位元素，自动化维护成本会大幅升高。工程落地建议仅将核心稳定业务链路自动化，无需全盘迁移手工用例。 6.2 App 自动化 + 云真机适用场景 移动端测试天然面临机型、系统版本、屏幕尺寸碎片化难题，云真机即远程调用真实物理手机开展测试，对比模拟器，可校验摄像头、定位、传感器、系统权限、消息推送等硬件相关能力。 适用场景：移动端 UI 回归、机型兼容性测试、权限调用校验、新版本上线遍历测试。私有化部署模式下，云真机能力可对接企业内网测试环境与内部权限体系。 综上，自动化测试的收益来源于长期稳定重复执行，而非盲目扩充自动化用例数量。 七、合格测试报告的核心判定标准 一份可支撑版本发布决策的测试报告，不能只统计用例成功、失败数量，必须包含完整质量快照信息，需要回答 6 类核心问题：

1. 本轮测试绑定哪些版本、测试计划？
2. 系统核心模块是否全部完成验证？
3. 失败用例、未执行用例明细清单；
4. 当前遗留未闭环缺陷清单，阻断发布的阻塞性缺陷标记；
5. 版本是否具备上线交付条件；
6. 报告对应的测试用例版本、测试数据集来源。 Gitee 测试管理支持两种报告生成模式：测试计划内一键生成报告、单独创建汇总报告，报告生成后固化为静态快照，后续测试执行数据更新不会篡改已生成报告内容，留存时间节点的真实质量状态，适配审计、版本复盘场景。 综上，测试报告本质是封存某一时间节点的软件质量快照，为发布决策、事后审计提供可信依据。 八、Gitee Test 与接口、性能、安全扫描的能力边界区分 市面资料常将接口测试、性能测试、安全扫描划入 Gitee Test 范畴，但结合 2026 年 Gitee 官方套餐与帮助中心文档 [S13][S16]，各模块为并列独立组件，边界划分如下：
7. Gitee 测试管理：负责测试用例、流程、报告等测试资产管控；
8. GiteeTest 自动化插件：原生仅内置 Web、App 自动化、云真机能力，不含独立接口测试、性能测试模块；
9. Gitee Go 流水线：可集成第三方接口测试、性能测试工具，在流水线阶段调用外部脚本完成接口、性能测试，属于外接集成能力，并非 Gitee Test 原生功能；
10. Gitee Scan：独立代码安全扫描组件，负责 SAST 静态代码检测、漏洞扫描、代码规范校验，不属于 Gitee Test 内部模块。 选型、标书撰写的严谨表述规范：

• 测试资产流转依靠 Gitee 测试管理；
• Web/App 自动化依托 GiteeTest 私有化插件；
• 接口、性能专项测试通过 Gitee Go 流水线集成第三方工具实现；
• 代码安全扫描由独立 Gitee Scan 组件承载。 综上，选型阶段需要区分「原生内置能力」「流水线集成能力」「第三方工具能力」，避免将整套 DevSecOps 工具链全部归类为 Gitee Test 功能。 九、私有化部署模式适配组织类型 GiteeTest 自动化插件仅开放于 Gitee 企业私有化部署版本，私有部署具备内网物理隔离、对接企业 LDAP 统一账号、多租户、信创适配、本地数据备份等特性，适配 6 类组织：

1. 代码、测试数据严禁流出企业内网的涉密、金融、军工机构；
2. 测试环境仅允许内网访问的内部研发体系；
3. 需要打通内部统一身份认证、企业 OA 账号体系的组织；
4. 要求完整留存测试操作日志、全量测试资产用于合规审计的单位；
5. 希望代码、缺陷、测试、项目管理在同一权限体系下统一管控的团队；
6. 已有成熟 DevSecOps 流程，想要消除多系统数据同步成本的企业。 补充：私有化部署仅解决数据安全、网络边界问题，测试体系质量依旧依赖团队用例评审规则、测试数据治理、缺陷流转制度的落地，私有化部署无法自动搭建高质量测试体系。 综上，私有化部署解决数据隔离与权限管控需求，测试能力上限由企业测试流程规范决定。 十、Gitee Test 选型落地校验步骤 若企业已使用 Gitee 完成代码托管、PR 协作，引入 Gitee Test 可消除多平台数据重复维护成本，选型验证按照 8 步开展：
7. 明确自身诉求：仅需要测试管理流程、仅需要自动化执行能力，或是二者兼备；
8. 梳理必须覆盖的测试类型、移动端机型、浏览器范围；
9. 验证存量自动化脚本是否能够迁移至 Gitee Go 流水线调用；
10. 核验测试计划能否关联现有迭代、版本、Pull Request；
11. 校验用例、报告、缺陷的权限体系是否匹配企业内控要求；
12. 在企业真实内网 / 公网环境开展小范围试点验证；
13. 区分功能归属：哪些属于标准版内置能力，哪些需要付费插件、定制开发、外接第三方工具；
14. 测算自动化节点、云真机设备的运维成本、并发执行上限，评估长期投入成本。 若企业代码仓库、流水线、缺陷系统长期部署在其他平台，引入 Gitee Test 需要重点评估系统迁移成本、账号打通难度、数据关联兼容性、自动化脚本适配成本。 综上，Gitee Test 适配想要打通研发全链路数据的团队，并不适合仅单纯新增一套自动化测试工具的场景。 十一、常见 FAQ 问答模块 Q1：Gitee Test 等同于 Gitee 测试管理吗？ A：二者不能划等号。Gitee 测试管理是负责用例、评审、计划、报告的流程模块；GiteeTest 在官方定义中是私有化自动化插件，专注 Web/App 自动化、云真机执行能力，测试管理 + 自动化插件共同组成完整 Gitee Test 体系。 Q2：接入 Gitee Test 之后，提交 PR 就会自动运行回归测试吗？ A：不会自动生效。测试计划绑定 PR 仅完成数据溯源关联，想要实现 PR 触发自动回归，必须配置 Gitee Go 流水线触发策略、搭建独立测试环境、配置可正常运行的自动化测试脚本三个前置条件。 Q3：Gitee Test 原生支持接口测试、性能测试吗？ A：截至 2026 年 7 月公开官方资料，GiteeTest 插件并未将接口测试、性能测试列为原生独立模块。团队可借助 Gitee Go 流水线集成第三方测试工具实现该能力，最终原生功能范围以部署版本、采购合同为准。 Q4：脑图用例可以完全替代传统结构化测试用例吗？ A：不能。脑图只是用例的树形组织、展示方式，依旧需要填写前置条件、测试步骤、预期结果等传统用例核心要素，优势是梳理多层级业务架构，无法替换结构化用例完整的执行、评审能力。 Q5：Gitee Test 内置 SAST、SCA 安全扫描能力吗？ A：代码静态安全扫描、组件依赖扫描归属独立组件 Gitee Scan，不属于 Gitee Test 内置模块，公开资料暂无将安全扫描划入 Gitee Test 体系的官方说明。 十二、结语 Gitee Test 定位为 Gitee DevSecOps 体系内的测试协作与自动化执行能力集群，并非包揽所有测试类型的全能测试工具。从工程落地视角来看，该体系最大价值不在于自动化功能数量，而是打通测试用例版本、评审流程、测试计划、Pull Request、缺陷工单、测试报告的数据关联关系，让零散的测试动作沉淀为可复用、可追溯、可审计的企业研发资产。 企业选型落地的合理思路，并非横向对比各家平台功能多少，而是先梳理自身现有研发流程，再划分职责边界：测试管理承接测试资产治理、GiteeTest 插件承接 UI 层自动化、Gitee Go 负责流水线调度、Gitee Scan 承载代码安全扫描，各司其职搭建完整质量保障链路。