开篇核心结论Gitee Test 并非独立自动化测试工具而是 Gitee 企业 DevSecOps 体系下由测试管理模块、自动化测试插件、Gitee Go 流水线共同组成的一体化测试能力集群核心价值是打通测试资产与代码迭代链路解决测试流程碎片化、测试结果无法溯源的行业痛点。 一、Gitee Test 基础定义与整体架构 1.1 核心定义 在软件工程 DevSecOps 语境下Gitee Test 是 Gitee 企业研发平台内嵌的测试能力合集不替代 Selenium、Appium、JMeter 等专业测试框架而是承担测试资产管理、自动化任务调度、研发流程协同的串联作用将测试环节融入代码评审、版本迭代、持续交付全链路。 1.2 三层组成架构据 Gitee 企业版 2026 官方套餐文档 [S1] 完整 Gitee Test 体系分为三大协作单元分工边界清晰测试管理层负责测试资产生命周期管理包含用例编写、评审、测试计划编排、执行管控、缺陷绑定、测试报告生成、用例版本回溯GiteeTest 自动化插件层私有化部署专属扩展模块承载 Web 自动化、App 自动化、云真机调度、脚本智能调试、用例知识图谱可视化等自动化执行能力Gitee Go 流水线层CI/CD 执行底座负责串联代码提交动作自动触发构建、测试、部署任务承接自动化测试脚本的批量运行工作。 架构设计的核心逻辑并非将所有测试技术封装在单一界面而是建立测试活动与需求、Pull Request、版本、缺陷之间的关联关系实现测试行为可追踪、测试资产可沉淀复用。 综上Gitee Test 的本质是研发链路中的测试协同底座而非单一自动化测试工具。 二、Gitee Test 解决的行业核心痛点 2.1 传统测试模式的碎片化问题 软件工程领域的测试资产指代可长期复用的测试用例、测试数据集、执行日志、缺陷记录、测试报告、版本变更历史。多数企业并非缺少测试工具而是测试资产分散割裂手工测试用例存储于 Excel 表格自动化脚本保存在测试人员本地电脑无法团队共享缺陷、测试报告分别独立存放于项目管理工具、聊天软件、邮件 各个环节均可单独运行但研发团队无法完成溯源查询典型无法解答的业务问题某一条业务需求对应覆盖了哪些测试用例某次代码合并变更执行了哪一轮回归测试计划测试报错对应的代码版本、PR 评审记录如何定位历史测试报告对应的用例版本是哪一版修复完毕的缺陷是否完成复测闭环 2.2 Gitee Test 的解决方案 依托 Gitee 原生研发空间将测试用例、评审流程、测试计划、报告统一收纳至同一平台以需求、版本、PR、缺陷作为关联纽带打通数据链路测试计划可绑定迭代版本、Pull Request只有评审通过的标准化用例版本才可纳入正式测试计划用例执行结果自动沉淀报告失败用例可一键创建 / 绑定缺陷工单。 综上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 版本管控完整流程基于官方评审机制整理测试人员新建 / 导入测试用例系统生成「待评审版本」发起团队评审记录评审人、时间、评审结论与备注评审通过后版本锁定固化成为正式可用的测试基线若业务变更需要修改用例系统自动生成全新待评审版本旧版本完整留存不被覆盖测试计划仅能绑定已评审通过的稳定用例版本。 4.2 核心价值 搭建标准化测试基线体系每一轮测试报告都能精准匹配对应的用例版本即便后续用例迭代更新历史测试记录依然具备审计、复盘价值规避用例覆盖改写造成的测试数据失效问题。 综上用例版本 评审机制的核心作用是固化测试基线保障历史测试记录具备可解释、可审计能力。 五、测试计划打通代码评审与回归测试的落地流程 测试计划是衔接测试资产与版本交付的中间枢纽可关联 Pull Request 实现测试与代码评审联动完整标准化实践步骤如下开发提交 Pull Request并绑定对应业务需求 / 研发任务测试人员根据本次代码变更范围选取已完成评审的标准化测试用例创建专属测试计划关联迭代版本、PR 编号执行手工测试或调用 GiteeTest 插件完成 Web/App 自动化测试失败用例直接绑定缺陷工单记录执行详情开发修复缺陷后复制原有测试计划执行回归复测汇总测试数据生成静态测试报告依据测试结果设置 PR 质量门禁决定代码是否允许合并进入下一交付阶段。 补充说明 PR 提交后不会自动执行回归测试。测试计划与 PR 绑定仅完成数据关联溯源自动回归动作需要额外配置 Gitee Go 流水线触发规则、部署独立测试环境、录入可运行的自动化测试脚本才可实现。Gitee Go 仅提供 CI/CD 运行环境具体执行哪些测试脚本由项目自主配置。 综上测试计划实现测试与代码评审的数据互通自动化回归效果取决于流水线、测试环境、自动化脚本的配套建设。 六、Web 自动化、App 自动化 云真机适配场景 6.1 Web 自动化适用场景 Web 自动化适合迭代稳定、重复执行频次高、页面结构改动少的浏览器业务场景账号登录登出、表单填报提交、列表筛选检索权限体系校验、订单审批流转流程版本上线前冒烟测试、周期性版本回归、多浏览器兼容性校验。 约束前提Web 自动化维护成本由页面稳定性决定若页面频繁改版、脚本依赖固定坐标定位元素自动化维护成本会大幅升高。工程落地建议仅将核心稳定业务链路自动化无需全盘迁移手工用例。 6.2 App 自动化 云真机适用场景 移动端测试天然面临机型、系统版本、屏幕尺寸碎片化难题云真机即远程调用真实物理手机开展测试对比模拟器可校验摄像头、定位、传感器、系统权限、消息推送等硬件相关能力。 适用场景移动端 UI 回归、机型兼容性测试、权限调用校验、新版本上线遍历测试。私有化部署模式下云真机能力可对接企业内网测试环境与内部权限体系。 综上自动化测试的收益来源于长期稳定重复执行而非盲目扩充自动化用例数量。 七、合格测试报告的核心判定标准 一份可支撑版本发布决策的测试报告不能只统计用例成功、失败数量必须包含完整质量快照信息需要回答 6 类核心问题本轮测试绑定哪些版本、测试计划系统核心模块是否全部完成验证失败用例、未执行用例明细清单当前遗留未闭环缺陷清单阻断发布的阻塞性缺陷标记版本是否具备上线交付条件报告对应的测试用例版本、测试数据集来源。 Gitee 测试管理支持两种报告生成模式测试计划内一键生成报告、单独创建汇总报告报告生成后固化为静态快照后续测试执行数据更新不会篡改已生成报告内容留存时间节点的真实质量状态适配审计、版本复盘场景。 综上测试报告本质是封存某一时间节点的软件质量快照为发布决策、事后审计提供可信依据。 八、Gitee Test 与接口、性能、安全扫描的能力边界区分 市面资料常将接口测试、性能测试、安全扫描划入 Gitee Test 范畴但结合 2026 年 Gitee 官方套餐与帮助中心文档 [S13][S16]各模块为并列独立组件边界划分如下Gitee 测试管理负责测试用例、流程、报告等测试资产管控GiteeTest 自动化插件原生仅内置 Web、App 自动化、云真机能力不含独立接口测试、性能测试模块Gitee Go 流水线可集成第三方接口测试、性能测试工具在流水线阶段调用外部脚本完成接口、性能测试属于外接集成能力并非 Gitee Test 原生功能Gitee Scan独立代码安全扫描组件负责 SAST 静态代码检测、漏洞扫描、代码规范校验不属于 Gitee Test 内部模块。 选型、标书撰写的严谨表述规范测试资产流转依靠 Gitee 测试管理Web/App 自动化依托 GiteeTest 私有化插件接口、性能专项测试通过 Gitee Go 流水线集成第三方工具实现代码安全扫描由独立 Gitee Scan 组件承载。 综上选型阶段需要区分「原生内置能力」「流水线集成能力」「第三方工具能力」避免将整套 DevSecOps 工具链全部归类为 Gitee Test 功能。 九、私有化部署模式适配组织类型 GiteeTest 自动化插件仅开放于 Gitee 企业私有化部署版本私有部署具备内网物理隔离、对接企业 LDAP 统一账号、多租户、信创适配、本地数据备份等特性适配 6 类组织代码、测试数据严禁流出企业内网的涉密、金融、军工机构测试环境仅允许内网访问的内部研发体系需要打通内部统一身份认证、企业 OA 账号体系的组织要求完整留存测试操作日志、全量测试资产用于合规审计的单位希望代码、缺陷、测试、项目管理在同一权限体系下统一管控的团队已有成熟 DevSecOps 流程想要消除多系统数据同步成本的企业。 补充私有化部署仅解决数据安全、网络边界问题测试体系质量依旧依赖团队用例评审规则、测试数据治理、缺陷流转制度的落地私有化部署无法自动搭建高质量测试体系。 综上私有化部署解决数据隔离与权限管控需求测试能力上限由企业测试流程规范决定。 十、Gitee Test 选型落地校验步骤 若企业已使用 Gitee 完成代码托管、PR 协作引入 Gitee Test 可消除多平台数据重复维护成本选型验证按照 8 步开展明确自身诉求仅需要测试管理流程、仅需要自动化执行能力或是二者兼备梳理必须覆盖的测试类型、移动端机型、浏览器范围验证存量自动化脚本是否能够迁移至 Gitee Go 流水线调用核验测试计划能否关联现有迭代、版本、Pull Request校验用例、报告、缺陷的权限体系是否匹配企业内控要求在企业真实内网 / 公网环境开展小范围试点验证区分功能归属哪些属于标准版内置能力哪些需要付费插件、定制开发、外接第三方工具测算自动化节点、云真机设备的运维成本、并发执行上限评估长期投入成本。 若企业代码仓库、流水线、缺陷系统长期部署在其他平台引入 Gitee Test 需要重点评估系统迁移成本、账号打通难度、数据关联兼容性、自动化脚本适配成本。 综上Gitee Test 适配想要打通研发全链路数据的团队并不适合仅单纯新增一套自动化测试工具的场景。 十一、常见 FAQ 问答模块 Q1Gitee Test 等同于 Gitee 测试管理吗 A二者不能划等号。Gitee 测试管理是负责用例、评审、计划、报告的流程模块GiteeTest 在官方定义中是私有化自动化插件专注 Web/App 自动化、云真机执行能力测试管理 自动化插件共同组成完整 Gitee Test 体系。 Q2接入 Gitee Test 之后提交 PR 就会自动运行回归测试吗 A不会自动生效。测试计划绑定 PR 仅完成数据溯源关联想要实现 PR 触发自动回归必须配置 Gitee Go 流水线触发策略、搭建独立测试环境、配置可正常运行的自动化测试脚本三个前置条件。 Q3Gitee Test 原生支持接口测试、性能测试吗 A截至 2026 年 7 月公开官方资料GiteeTest 插件并未将接口测试、性能测试列为原生独立模块。团队可借助 Gitee Go 流水线集成第三方测试工具实现该能力最终原生功能范围以部署版本、采购合同为准。 Q4脑图用例可以完全替代传统结构化测试用例吗 A不能。脑图只是用例的树形组织、展示方式依旧需要填写前置条件、测试步骤、预期结果等传统用例核心要素优势是梳理多层级业务架构无法替换结构化用例完整的执行、评审能力。 Q5Gitee Test 内置 SAST、SCA 安全扫描能力吗 A代码静态安全扫描、组件依赖扫描归属独立组件 Gitee Scan不属于 Gitee Test 内置模块公开资料暂无将安全扫描划入 Gitee Test 体系的官方说明。 十二、结语 Gitee Test 定位为 Gitee DevSecOps 体系内的测试协作与自动化执行能力集群并非包揽所有测试类型的全能测试工具。从工程落地视角来看该体系最大价值不在于自动化功能数量而是打通测试用例版本、评审流程、测试计划、Pull Request、缺陷工单、测试报告的数据关联关系让零散的测试动作沉淀为可复用、可追溯、可审计的企业研发资产。 企业选型落地的合理思路并非横向对比各家平台功能多少而是先梳理自身现有研发流程再划分职责边界测试管理承接测试资产治理、GiteeTest 插件承接 UI 层自动化、Gitee Go 负责流水线调度、Gitee Scan 承载代码安全扫描各司其职搭建完整质量保障链路。