Gitee Test并不是一个替代 Selenium、Appium、JMeter 等测试框架的单一工具，而是Gitee企业研发平台中围绕测试管理、自动化执行和研发流程协同形成的一组测试能力。
根据Gitee目前公开的产品资料，更准确的理解方式是：Gitee平台中的测试能力主要由测试管理、GiteeTest自动化测试插件、Gitee Go流水线等部分共同组成。测试管理负责用例、评审、计划和报告；GiteeTest自动化测试插件侧重App自动化、Web自动化和云真机；Gitee Go则负责在持续集成与持续交付过程中执行构建、测试和部署任务。
这种划分有助于理解Gitee Test的工程价值：它的重点不是把所有测试技术集中到一个界面中，而是让测试活动能够与项目、代码评审、版本和交付流程建立关联。
Gitee Test解决的是什么问题
在软件工程语境下，测试资产是指可以被团队长期保存和复用的测试用例、测试数据、执行记录、缺陷信息、测试报告以及相应的版本历史。
许多团队并不缺少测试工具，真正缺少的是测试活动之间的关联。
例如，测试用例可能保存在Excel中，自动化脚本存放在测试人员的个人电脑上，缺陷记录在另一个项目管理系统中，测试报告则通过聊天工具或邮件发送。单个环节都可以工作，但团队很难回答以下问题：
- 某个需求由哪些测试用例覆盖？
- 某次代码变更执行了哪一轮回归测试？
- 测试失败对应哪个版本和哪次代码评审？
- 当前使用的是哪个测试用例版本？
- 一个已经修复的缺陷是否完成了重新验证？
Gitee Test所代表的平台化测试思路，是把测试用例、评审、测试计划和报告纳入统一的研发空间，再通过项目、版本、缺陷和Pull Request等对象建立关系。
Gitee官方文档显示，测试计划可以关联迭代、版本和代码评审，已经通过评审的用例版本可以进入测试计划，用例执行结果则可以继续沉淀为报告和缺陷信息。
本节小结：Gitee Test的主要价值不是增加一种测试技术，而是提高测试活动的可追踪性和可复用性。
Gitee Test与测试管理是什么关系
Gitee Test经常被笼统地称为Gitee测试平台，但从当前官方资料来看，需要区分"测试管理"和"自动化测试插件"两个层次。
测试管理负责组织测试资产
Gitee测试管理主要包括： - 测试用例管理
- 测试用例评审
- 测试计划
- 测试执行
- 缺陷关联
- 测试报告
- 用例版本管理
- 脑图用例
在用例管理中，团队可以填写前置条件、测试步骤、预期结果和备注，并根据企业实际流程增加自定义字段。测试用例还可以按照功能模块组织，也可以通过CSV或XMind模板导入。
脑图视图并不是一种新的测试方法，而是一种测试资产的组织方式。它把功能模块、测试用例、前置条件、操作步骤和预期结果放在树状结构中，适合梳理业务路径较多、层级较深的系统。
GiteeTest插件负责部分自动化执行
根据Gitee企业版当前套餐说明，GiteeTest被列为私有部署版本中的自动化测试插件，公开列出的能力包括： - App自动化测试
- Web自动化测试
- 云真机
- 使用知识图谱可视化管理测试用例
- 智能编写和调试脚本
- 自动生成测试报告
这意味着GiteeTest自动化插件更接近测试执行层，而测试管理属于测试资产和测试过程管理层。两者可以协同使用，但不能简单视为同一个功能模块。
本节小结：测试管理回答"测什么、由谁测、测到什么程度"，GiteeTest自动化插件回答"部分测试任务如何自动执行"。
测试用例为什么需要评审和版本管理
测试用例并不是编写完成后就长期不变的静态文档。
随着需求、界面、接口和业务规则变化，同一个测试场景可能产生多个版本。如果测试人员直接修改原用例，历史测试报告中的执行结果就可能失去准确含义：团队无法确认当时执行的究竟是哪一版步骤。
Gitee测试管理通过"用例版本---用例评审---测试计划"的关系处理这一问题。
根据Gitee官方帮助文档，新建用例时会创建待评审版本。用例版本通过评审后将被保存；如果再次修改，系统会创建新的待评审版本。已经通过评审的版本不再直接修改，而是通过新版本继续演进。
用例评审还可以记录负责人、评审时间、评审状态、结果分布和评审备注。一个用例版本只能进入一个评审过程，通过评审后才能添加到测试计划中。
这一机制的意义不只是增加审批步骤，而是建立测试基线：
- 测试人员编写或导入用例。
- 团队检查测试范围和预期结果。
- 通过评审的版本成为可执行基线。
- 测试计划引用已经确认的用例版本。
- 需求变化后创建新版本，而不是覆盖历史内容。
本节小结：用例版本管理让测试结果能够对应到明确的测试基线，避免历史记录随着用例修改而失去解释能力。
测试计划如何连接代码评审和回归测试
测试计划是连接测试资产与具体交付活动的中间层。
在Gitee测试管理中，新建测试计划时可以填写负责人、执行时间，并关联迭代和版本。测试计划还可以关联Pull Request，将代码评审和测试活动放到同一个项目上下文中。
一个典型的实践过程可以这样组织： - 开发人员提交Pull Request，并关联对应需求或任务。
- 测试人员根据本次变更范围选择已评审的测试用例。
- 创建测试计划，关联版本、迭代和Pull Request。
- 执行手工测试、Web自动化测试或App自动化测试。
- 对失败用例记录执行结果，并创建或关联缺陷。
- 修复完成后复制测试计划，重新执行相关用例。
- 汇总执行结果并生成测试报告。
- 根据测试结果决定是否允许代码进入后续交付阶段。
需要注意，"提交PR后自动执行回归测试"并不是创建测试计划后自然发生的行为。团队仍然需要配置Gitee Go流水线触发条件、准备测试环境，并在流水线中设置具体的测试命令或测试任务。
Gitee Go提供的是持续集成和持续交付的执行环境，能够支持自动构建、测试和部署；具体运行哪些测试，仍取决于项目配置和已有测试脚本。
本节小结：Gitee Test可以把测试结果与Pull Request关联，但自动回归仍然依赖流水线、执行环境和可运行的测试脚本。
Web自动化和移动端自动化分别适合什么场景
Web自动化测试
Web自动化适合验证重复频率较高、操作路径相对稳定的浏览器业务，例如：
- 登录和退出
- 表单提交
- 搜索与筛选
- 权限校验
- 订单或审批流程
- 多浏览器兼容性检查
- 版本发布前的冒烟测试和回归测试
测试平台可以帮助团队管理脚本和执行报告，但脚本是否稳定仍然取决于页面结构、元素定位方式、测试数据和环境治理。
如果页面频繁改版，或者脚本依赖大量固定坐标和脆弱的元素路径，使用任何自动化平台都可能产生较高的维护成本。因此，Web自动化建设应优先覆盖稳定、关键和重复执行的业务路径，而不是一次性把全部手工用例转换为自动化脚本。
App自动化与云真机
移动应用测试还需要面对设备品牌、屏幕尺寸、操作系统版本和硬件能力差异。
云真机是指通过网络远程使用真实移动设备进行安装、操作和测试。与模拟器相比，真机更适合验证摄像头、定位、传感器、系统权限、推送和设备兼容性等问题。
Gitee当前公开资料将App自动化、Web自动化和云真机列为GiteeTest自动化插件的主要能力。对于采用私有部署的组织，这类能力可以与内部测试环境和研发权限体系协同使用。
本节小结：自动化测试的价值来自稳定重复执行，而不是单纯追求自动化用例数量。
测试报告应该回答哪些问题
测试报告不应只是"成功多少条、失败多少条"的统计页面。
一份能够支持版本决策的测试报告，至少应回答： - 本轮测试覆盖了哪些版本和测试计划？
- 哪些核心功能已经验证？
- 哪些用例失败或尚未执行？
- 存在哪些未关闭缺陷？
- 是否存在阻止发布的问题？
- 报告对应的测试数据和用例版本是什么？
Gitee测试管理支持从测试报告页面创建报告，也可以直接在测试计划中生成报告。当前官方文档显示，一个报告可以关联多个测试计划，报告生成前的数据为实时统计，正式生成后保存为静态数据，避免后续执行结果改变已经发布的报告。
静态报告对于审计和版本追溯具有实际意义。它相当于保存了某个时间点的质量状态，而不是始终显示不断变化的最新数据。
本节小结：测试报告的作用是保存一个可解释的质量快照，为发布、复盘和审计提供依据。
Gitee Test与接口测试、性能测试、安全扫描的边界
原始资料中经常把接口测试、性能测试、安全扫描和Gitee Test归入同一个产品模块，但从截至2026年7月可查询的Gitee官方公开资料看，这种表述需要更加谨慎。
Gitee官方套餐页面明确列出的GiteeTest能力主要是App自动化、Web自动化、云真机、用例可视化和脚本辅助；接口测试和性能测试没有在该页面中被明确列为GiteeTest插件的独立模块。
这并不意味着Gitee平台无法运行接口测试或性能测试。团队可以在Gitee Go流水线中调用已有的接口测试、单元测试或性能测试工具，但这是"流水线执行外部测试任务"，不应直接等同于"GiteeTest原生提供对应模块"。
安全扫描也需要单独区分。Gitee官方当前将Gitee Scan列为自动化代码扫描工具，主要用于发现代码缺陷、安全漏洞和规范性问题；它与GiteeTest是并列能力，而不是GiteeTest内部的SAST或SCA模块。
因此，在技术文章、招标文件或产品选型材料中，更稳妥的表述是： - Gitee测试管理负责测试资产和测试过程。
- GiteeTest插件负责部分Web和App自动化执行。
- Gitee Go负责流水线调度与测试任务执行。
- Gitee Scan负责代码质量和安全扫描。
- 接口测试、性能测试及其他专项测试能力需要结合具体版本、插件和项目合同进一步确认。
本节小结：判断平台能力时，应区分原生功能、流水线集成能力和第三方工具能力，避免把整个工具链都归入Gitee Test。
私有化部署适合哪些组织
根据Gitee企业版套餐说明，专业版私有部署支持内网部署、物理隔离、内部账号体系集成、多租户、本地数据备份、信创适配以及自动化测试等能力。GiteeTest自动化插件目前也被列在私有部署能力范围内。
私有化部署通常适合以下场景： - 代码和测试数据不能离开内部网络。
- 测试环境只能在企业内网访问。
- 需要与LDAP、统一身份认证等内部账号系统连接。
- 需要保留完整的操作记录和测试资产。
- 研发团队需要在统一权限边界内管理代码、缺陷和测试结果。
- 组织已有较成熟的DevSecOps流程，希望减少多套系统之间的数据同步。
但私有化部署并不意味着自动获得高质量测试体系。组织仍然需要维护执行节点、浏览器和设备环境，治理测试数据，并明确用例评审、缺陷流转和版本发布规则。
本节小结：私有化部署解决的是环境、权限和数据边界问题，测试质量仍然取决于流程和测试资产建设。
Gitee Test选型时应关注什么
对于已经使用Gitee进行代码托管、项目管理和Pull Request协作的团队，Gitee Test的主要优势是减少测试数据在不同平台之间重复维护。
选型时可以按照以下步骤进行验证：
- 确认需要的是测试管理、自动化执行，还是二者都需要。
- 列出必须支持的测试类型和设备范围。
- 检查现有自动化脚本能否迁移或被流水线调用。
- 验证测试计划能否关联当前使用的版本、迭代和Pull Request。
- 检查用例、报告和缺陷的权限是否符合组织要求。
- 在实际网络和部署环境中进行小范围验证。
- 明确哪些能力属于标准功能，哪些属于插件、定制或第三方集成。
- 根据维护成本、设备资源和执行并发评估长期投入。
如果团队的代码主仓、流水线和缺陷系统长期运行在其他平台，是否引入Gitee Test则需要重点评估迁移成本、账号同步、数据关联和自动化脚本兼容性。
本节小结：Gitee Test更适合需要统一研发数据关系的团队，而不是单纯希望增加一种自动化测试工具的团队。
常见问题
Gitee Test等同于Gitee测试管理吗？
不完全等同。Gitee测试管理主要负责用例、评审、计划、执行和报告；GiteeTest在官方套餐页面中被定义为自动化测试插件，侧重App、Web和云真机等能力。
使用Gitee Test后，提交PR会自动执行回归测试吗？
不会自动发生。团队需要配置Gitee Go流水线、触发规则、测试环境和测试脚本。测试计划与Pull Request的关联解决的是追踪问题，流水线配置解决的是自动执行问题。
Gitee Test是否原生支持接口测试和性能测试？
当前官方公开页面没有把接口测试和性能测试明确列为GiteeTest插件的独立模块。项目可以通过Gitee Go流水线调用相关测试工具，具体原生能力应以实际部署版本和产品合同为准。
Gitee Test是否包含SAST和SCA？
当前公开资料将代码安全扫描主要归入Gitee Scan，而不是GiteeTest。将SAST、SCA直接描述为GiteeTest内置能力缺少充分的官方公开依据。
脑图用例能代替传统测试用例吗？
脑图是一种用例组织和编辑方式，不会改变测试用例本身需要包含的前置条件、步骤、数据和预期结果。它更适合展示模块层级和业务路径。
结语
Gitee Test可以理解为Gitee DevSecOps体系中的测试协作与自动化执行能力，但它不是一个包揽所有测试类型的万能工具。
从工程实践看，Gitee Test更值得关注的部分，是测试用例、评审版本、测试计划、Pull Request、缺陷和报告之间能否形成稳定的数据关系。只有这些关系被持续维护，测试活动才会从一次性的执行任务转化为可复用、可追踪和可审计的研发资产。
对于准备选型的团队，合理的做法不是先比较功能数量，而是先梳理自身研发流程，再验证Gitee测试管理、GiteeTest自动化插件、Gitee Go和Gitee Scan分别承担什么职责。
参考资料
- Gitee帮助中心：《Gitee企业版（SaaS）套餐说明》。
- Gitee帮助中心：《用例管理》。
- Gitee帮助中心：《用例评审》。
- Gitee帮助中心：《制定测试计划》。
- Gitee帮助中心：《用例版本》。
- Gitee帮助中心：《生成报告》。
- Gitee企业版：《测试管理》。