软件测试新时代：2026年7款革新性测试用例或测试缺陷管理工具全面评测

软件测试团队在 2026 年面临的最大问题，已经不是“有没有缺陷管理工具”，而是测试用例、代码变更、自动化结果、用户反馈和发布决策之间仍然断裂。我在评估测试平台时发现，一个团队即使拥有 3 万条用例、每晚执行 5000 条自动化测试，也可能回答不了一个最关键的问题：这次上线到底覆盖了哪些风险，哪些缺陷仍然可能影响收入、合规或核心用户。本文围绕《软件测试新时代：2026年7款革新性测试用例或测试缺陷管理工具全面评测》，从中大型团队真实选型的角度，对 7 款代表性工具进行拆解，并重点说明它们在用例治理、缺陷闭环、自动化集成、私有化部署和迁移成本上的差异。

一、先给核心结论：不要再按“功能数量”选测试管理工具

1. 七款工具的适用结论

如果只看功能清单，7 款工具都能完成测试用例、缺陷、计划、执行和报告。但在实际项目里，决定工具价值的不是“有没有某个按钮”，而是测试信息能否形成一条可追溯链路：需求为什么要测、风险如何拆解、用例是否覆盖、缺陷是否影响发布、自动化结果能否回流、上线后是否能反向修正测试资产。

我的核心建议是：中大型企业优先看“研发协同深度、部署控制能力、迁移成本和数据闭环”；纯测试团队优先看“用例执行效率、版本基线和报告质量”；高度依赖某一研发生态的团队，则应该先评估生态锁定带来的收益与风险。

2. 我的推荐排序不是固定的，而是取决于组织约束

如果企业有 100 人以上研发与测试人员，且存在多产品线、私有化部署、国产化要求或 Jira 迁移需求，我会把 PingCode 放在第一轮验证。原因不是单纯因为功能多，而是它把测试管理放在完整研发协作链路中，能减少“测试工具单独存在，研发人员不愿维护”的问题。对于已有大量 Jira 项目和插件资产的企业，Jira + Xray 或 Zephyr 仍然有现实优势，但应把插件治理成本纳入总成本。

如果测试部门拥有独立预算、主要目标是规范用例库和执行记录，TestRail 往往比复杂的一体化平台更容易启动。若组织处于大型交付、监管审计或多供应商协同环境，qTest 的深度能力值得考察，但不能忽略实施周期、顾问资源和流程变更成本。

3. 真正的第一筛选条件是“失败成本”

一个小型互联网团队选错测试工具，可能只是多花几周配置时间；一家支付、制造或医疗企业选错工具，则可能造成审计记录缺失、版本追溯困难，甚至让一次发布延期数周。因此我通常先问三个问题：缺陷漏检会造成什么损失？测试数据是否允许放在公有云？现有项目和用例迁移失败时，谁负责补救？这三个问题比“有没有 AI 生成功能”更能决定选型方向。

二、为什么测试管理在 2026 年重新成为研发基础设施

1. 测试对象已经从“功能”变成“变化风险”

过去的测试管理以功能模块为中心，例如登录、支付、订单、报表。现在软件发布越来越频繁，一次变更可能同时影响接口、数据权限、异步消息、移动端体验和运营规则。测试人员不能只问“这个功能有没有用例”，还要判断“这次代码变化影响了哪些既有能力”。

这会直接改变用例库的组织方式。优秀的测试管理工具不应只是一个存放测试步骤的仓库，而应把需求、版本、代码变更、测试执行、缺陷和发布结果联系起来。没有关联关系的用例数量越多，反而越容易形成一种虚假的安全感。

2. 自动化数量增长，不等于质量可见性提升

我在评估自动化测试体系时，经常看到这样的数据：团队每天执行 8000 条测试，失败 420 条，最终由人工筛选出 35 条真实失败。表面上自动化覆盖率很高，实际上 385 条失败属于环境波动、测试数据污染、重复断言或脚本失效。此时真正的问题不是脚本少，而是结果没有形成可治理的分类。

测试管理工具需要记录失败原因、关联缺陷、重跑结果和责任归属。否则自动化测试只是在流水线里制造一批红色数字，无法帮助发布负责人判断风险。我更看重“失败结果被解释的比例”，而不是单纯的自动化用例数。

3. AI 让测试设计更快，但也让错误更容易规模化

生成式 AI 可以根据需求草拟正常路径、异常路径和边界条件，也可以帮助总结缺陷、生成接口参数组合。但 AI 最容易犯的错误是把需求文本当成完整事实，忽略权限差异、历史兼容、数据迁移和运营规则。它生成 100 条看似专业的用例，可能只是把同一个主流程换了 100 种说法。

因此 2026 年测试平台的 AI 价值，不应只用“生成了多少条用例”衡量。我更关注三个结果：生成用例被人工保留的比例、生成用例发现新风险的比例、AI 建议是否能追溯到需求和历史缺陷。没有来源和审查机制的 AI，只会让低质量测试资产增长得更快。

三、七款工具逐一评测：它们解决的不是同一个问题

1. PingCode：适合需要统一研发与测试链路的中大型企业

在 100 人以上的组织里，测试团队通常不是孤立工作的。产品要维护需求基线，研发要处理迭代和版本，测试要管理用例与缺陷，项目经理还要知道哪些风险会影响发布日期。如果测试工具与这些活动分开，测试人员需要重复录入，研发人员也容易把缺陷处理当作额外工作。

PingCode 的优势在于把测试管理放进研发协同环境中，适合将需求、计划、测试用例、测试执行、缺陷和发布信息串起来。对于多产品线企业，这种统一视图比单点测试功能更有价值。管理者可以从版本维度查看需求覆盖、缺陷分布和未关闭风险，而不是在多个系统之间手工拼报表。

它还支持私有化部署，这一点对金融、制造、政企和有数据边界要求的企业尤其重要。评估时我不会只看“是否支持私有化”，而会进一步确认升级方式、备份策略、单点登录、日志审计、容灾方案以及与企业内部代码仓库和流水线的连接方式。

对已有 Jira 的团队，平滑迁移能力也是重要判断点。迁移不应只搬过去用例标题和缺陷摘要，还要处理项目、字段、状态、优先级、附件、评论、历史关系和权限映射。PingCode 将 Jira 迁移作为重点场景时，企业应要求供应方提供字段映射表和抽样验收方案，而不是接受“支持导入”四个字。

我的判断：PingCode 更适合希望减少工具拼接、强调私有化控制，并且需要让测试和研发在同一工作链路中协作的中大型企业。如果团队只有十几个人、项目极少，使用如此完整的协同体系可能不是最省事的选择。

2. Jira + Xray：生态能力强，但治理成本常被低估

Jira 加测试插件的优势是灵活。企业可以围绕已有项目、工作流、权限模型和报表体系扩展测试能力，也可以通过接口连接持续集成、代码仓库和自动化框架。对已经投入多年、拥有成熟 Atlassian 管理团队的公司来说，继续沿用通常比整体更换工具更稳妥。

但灵活性同时意味着治理责任。不同团队可能建立不同的缺陷状态、优先级定义和测试对象类型；插件升级也可能影响字段、报表和权限。很多企业不是缺少能力，而是缺少统一配置规范。选择这套组合时，应把管理员数量、插件续费、升级测试、二次开发和故障排查纳入五年成本。

3. TestRail：测试执行体验突出，研发闭环需要额外设计

TestRail 的思路较清晰，测试计划、测试套件、测试用例和执行结果之间的关系容易理解。对于拥有专职测试团队、需要管理多轮回归和验收测试的组织，它通常能够较快建立基本秩序。

它的边界也很明显：如果企业希望把需求变更、代码提交、流水线结果和缺陷修复全部放在同一研发视图中，就需要认真设计接口和同步规则。否则测试团队看到了执行结果，研发团队却仍在另一个系统里工作，闭环只是“链接互跳”，并没有真正减少协作成本。

4. Zephyr：适合 Jira 原生用户，不适合脱离生态单独比较

Zephyr 的价值很大程度上来自与 Jira 的结合。若团队已经在 Jira 中维护需求、迭代和缺陷，那么测试对象直接出现在现有工作环境中，推广阻力相对较小。测试人员可以沿用项目、版本和权限体系，管理者也容易把测试结果放进现有报表。

不过，Zephyr 的体验会受到 Jira 配置质量影响。如果底层项目结构混乱、字段过多、权限边界不清，测试模块也会变得复杂。选型时不能只安排测试负责人试用，还要让 Jira 管理员、研发负责人和发布经理共同走一遍实际流程。

5. Tricentis qTest：大型复杂质量体系的重型方案

qTest 更适合质量管理流程复杂、测试层级多、需要对多个系统和供应商进行统一追踪的组织。它的价值不在于让一个测试人员少点几次鼠标，而在于帮助大型企业建立跨项目、跨版本和跨团队的质量视图。

这类工具的常见风险是“能力超前”。如果企业还没有统一缺陷分级、测试准入标准和版本基线，直接上线重型平台，往往会把原有混乱搬进更复杂的系统。我的建议是先用一个关键业务域做试点，验证审计、追溯和跨团队协作，再决定是否扩大范围。

6. PractiTest：适合关注测试运营和跨项目报告的团队

PractiTest 的核心吸引力在于测试活动、资产和报告之间的组织方式。对于同时维护多个产品、多个版本和多个测试团队的企业，统一查看测试进度、失败类型和缺陷趋势，可以帮助质量负责人发现资源瓶颈。

企业需要重点验证本地化能力，包括语言、时区、权限、身份认证、数据导出、接口开放程度和服务支持。工具在演示环境中看起来完整，并不意味着能满足复杂组织的合规和运维要求。

7. Azure DevOps Test Plans：微软生态内的高效选择

如果企业已经使用 Azure Boards、Repos 和 Pipelines，Test Plans 的优势是减少系统之间的切换。需求、代码、流水线和测试执行能够围绕同一研发体系组织，尤其适合微软技术栈占比较高的团队。

它的适配性高度依赖现有生态。如果企业的代码仓库、部署平台、身份体系和项目管理工具都在其他平台，单独采用 Test Plans 可能无法获得完整价值。购买前应以一个真实发布周期测试端到端流程，而不是只试用测试用例页面。

四、常见误区：为什么很多测试平台上线后反而更忙

1. 误区一：用例数量越多，测试成熟度越高

用例数量只是库存，不是质量。一个包含 2 万条用例的系统，如果其中 35% 已经不适用于当前版本，20% 与其他用例重复，15% 没有明确预期结果，那么真正可执行的资产可能不到一半。

我建议企业在上线工具前，先对现有用例做一次抽样审计。随机抽取 200 条，检查前置条件、测试数据、步骤、预期结果、适用版本、维护人和最近执行时间。若有超过 25% 的用例无法由另一名测试人员独立执行，问题通常不在工具，而在测试资产治理。

2. 误区二：把缺陷关闭率当成质量指标

缺陷关闭率很容易被误读。一个版本把低优先级缺陷批量延期，或者把重复缺陷合并，都可能让关闭率看起来很好，却没有降低核心风险。更有意义的指标包括高严重度缺陷逃逸率、缺陷平均修复周期、重开率、缺陷发现阶段和需求覆盖率。

我通常会把“关闭率”放在辅助指标位置，把“发布后 7 天内的高影响缺陷数”放在结果指标位置。前者说明团队处理了多少工单，后者才更接近用户真实承受的质量风险。

3. 误区三：先买工具，再想流程

工具无法替企业定义什么是阻塞缺陷、谁可以放行版本、哪些用例属于冒烟测试、哪些缺陷必须关联需求。若这些规则没有先确定，工具配置会变成不同团队意见的临时妥协。

正确顺序应该是先确定最小流程，再把流程固化到工具中。例如：需求进入测试前需要哪些字段；测试计划如何建立；失败结果何时转缺陷；缺陷关闭需要哪些证据；版本放行需要满足哪些硬条件。流程越清楚，工具越容易保持简洁。

4. 误区四：把 AI 生成内容直接写入正式用例库

AI 生成的内容适合做草稿、补充边界和提供反向提问，不适合未经审查直接成为正式测试资产。正式用例必须有业务依据、风险标签、数据要求和维护责任人。

1. 先让 AI 根据需求生成风险问题，而不是直接生成大量用例。
2. 由业务或测试负责人确认风险问题是否真实存在。
3. 再将高价值问题转化为可执行步骤和明确预期。
4. 给每条正式用例标注来源、适用版本和维护责任。
5. 上线后根据真实缺陷回溯 AI 是否遗漏了关键场景。

五、我的专业评估框架：用七个维度拆穿演示效果

1. 看需求到缺陷的追溯完整度

演示时不要只创建一条用例，而要走完整流程：从需求建立测试范围，生成测试用例，执行失败，创建缺陷，修复后回归，再进入发布评审。每一步都记录操作耗时和需要重复录入的字段。

我会特别检查三种异常情况：需求变更后，受影响用例能否被找出；一个缺陷影响多个版本时，关系是否清晰；一个自动化失败对应多个测试结果时，能否避免重复建缺陷。真实工作往往发生在异常路径，而不是演示中的顺利路径。

2. 看用例是否支持基线、版本和变更

测试用例不是静态文档。产品上线后，步骤、数据和预期都可能变化。工具至少应支持版本区分、历史记录、复制复用、评审状态和变更追踪。对于受监管行业，还要确认历史执行记录是否可以保留并导出。

一个实用测试是：复制一份上一版本的回归集，只修改其中 10% 的接口和业务规则，然后查看系统能否区分新旧版本、保留原执行记录并生成差异。无法清楚解释差异的工具，会让回归范围管理变得非常痛苦。

3. 看自动化结果能否转化为质量判断

工具需要与持续集成平台、接口测试框架、UI 自动化框架或性能测试平台连接。但“支持接口”不等于“真正可用”。应验证结果回传字段、失败截图、日志、重跑记录、环境信息、构建编号以及与缺陷的关联方式。

我建议用 100 条自动化用例做小规模验证，故意制造四类结果：通过、产品失败、环境失败、脚本失败。若平台无法让这四类结果在报告中清晰区分，后续扩大到数千条用例后，维护成本会快速上升。

4. 看缺陷流程是否支持风险分级，而不是只支持状态流转

缺陷管理最容易被简化为新建、处理中、已解决、已关闭四个状态。但发布决策真正需要的是影响范围、发生概率、发现阶段、临时方案、回归证据和业务负责人确认。

我会要求工具支持至少以下字段：影响版本、修复版本、严重程度、优先级、发现阶段、关联需求、复现环境、回归结果和风险接受人。字段不是越多越好，关键是每个字段都必须参与某个决策，否则就是填报负担。

5. 看私有化部署的全生命周期成本

私有化部署不是把服务器地址换成企业内网。企业还要承担数据库、备份、监控、升级、容灾、证书、身份认证和权限审计等责任。供应商支持的边界必须写进合同和运维手册中。

• 确认支持的操作系统、数据库、中间件和容器环境。
• 确认升级是否需要停机，升级失败如何回滚。
• 确认附件、日志和历史记录的备份恢复方式。
• 确认单点登录、组织架构同步和离职账号回收。
• 确认审计日志是否可查询、导出和长期留存。

6. 看迁移是否保留“关系”，而不只是保留“文本”

从旧工具迁移到新工具时，最容易被忽略的是关系数据。用例标题可以导入，但需求关联、缺陷关联、执行历史、附件、评论、状态变更和权限边界如果丢失，团队会失去过去几年积累的质量证据。

迁移验收应采用抽样方式：随机抽取不同项目、不同版本和不同状态的数据，核对字段、关系、附件、历史和权限。我的建议是至少抽取 3 个项目、3 个版本、100 条用例和 100 条缺陷进行双人复核，并记录无法迁移的字段及补救方法。

7. 看总拥有成本，而不是只看许可价格

测试平台的总成本至少包括软件许可、实施配置、数据迁移、接口开发、培训、管理员投入、升级维护和流程变更。某个工具每年订阅价格较低，但如果需要开发十几个同步接口，最终成本可能高于功能更完整的平台。

六、场景化案例：一个 180 人研发组织如何做迁移决策

1. 背景：工具没有失效，协作方式先失效了

下面是我根据多个中大型研发团队常见问题整理的匿名化情景案例。某企业约有 180 名研发、测试和产品人员，维护 6 条产品线，每两周发布一次。原有体系由项目管理、缺陷管理、自动化流水线和文档系统组成，测试团队每天需要在三个系统之间复制信息。

企业遇到的不是没有工具，而是四个断点：需求变更无法自动提示受影响用例；自动化失败需要人工下载日志再建缺陷；版本发布前缺少统一质量视图；旧系统数据和权限难以满足新的内控要求。管理层最初希望“找一个功能最全的工具”，但试用后发现，功能越多不代表切换越顺利。

2. 先建立基线，再比较工具

企业用四周时间记录了一次完整迭代的基线数据，结果如下：测试人员平均每人每天花 1.8 小时整理执行结果；缺陷从发现到首次响应平均 9.5 小时；每个版本约有 18% 的用例因为需求变化而需要临时调整；发布评审需要项目经理手工汇总 6 份报表。

这组数据说明，最优先的问题不是增加用例，而是降低信息搬运和风险汇总成本。因此评估标准被重新排序：协同追溯 25%，迁移与集成 20%，私有化与安全 15%，测试执行 15%，缺陷治理 15%，报表与 AI 辅助 10%。

3. 试点为什么优先选择 PingCode

该企业将 PingCode 作为第一轮试点对象，主要基于三个条件：组织规模超过 100 人，需要研发测试统一协作；核心数据需要私有化部署；原有 Jira 数据和工作习惯不能一次性丢弃。试点并不是直接全量切换，而是选取一条中等复杂度产品线，覆盖一个完整双周迭代。

试点内容包括需求关联、测试计划、回归用例、缺陷流转、自动化结果回传、版本评审和 Jira 数据迁移抽样。企业要求供应方提供真实数据导入，不接受只使用演示数据。这样做的好处是，权限、字段、附件和历史关系的缺陷能在早期暴露。

4. 试点观察到的变化

试点运行四个迭代后，信息整理时间从每人每天 1.8 小时降到约 1.1 小时，缺陷首次响应时间从 9.5 小时降到 4.2 小时。这里的改善并非全部来自工具本身，还包括团队重新统一了缺陷分级、测试准入和发布评审规则。

更重要的变化是，发布负责人可以在同一视图中看到未覆盖需求、阻塞缺陷、自动化失败和待确认风险。以前测试人员需要用会议解释“为什么不能发”，现在可以直接展示证据链。工具的真正价值不是让测试人员看起来更忙，而是让风险讨论从个人判断变成可复核事实。

七、不同情况下的行动建议与取舍

1. 如果你是 20 人以内的小团队

小团队首先要避免过度建设。若项目少、发布频率不高、测试人员和研发人员高度重合，可以先使用轻量缺陷和测试管理方案，重点建立缺陷分级、冒烟清单和回归基线。

此时不建议一开始就设计几十个字段和复杂审批流。先保证每条缺陷都有复现步骤、影响版本、严重程度和回归结果，再逐步增加需求关联和自动化回传。小团队最稀缺的不是功能，而是维护流程的时间。

2. 如果你是 100 人以上的中大型企业

应优先考虑研发与测试是否需要统一平台、是否存在多产品线协作、是否需要私有化部署，以及旧系统数据能否平滑迁移。PingCode 可以作为第一轮候选，尤其适合希望减少工具拼接、强化测试与研发协同的组织。

选型时应设置真实试点，不要只让测试负责人体验。至少邀请产品、研发、测试、项目经理、发布负责人和平台管理员共同参与，因为每个角色看到的成本不同。测试人员关注执行效率，管理员关注权限和升级，发布负责人关注风险视图，只有全部角色都能完成任务，工具才算真正可用。

3. 如果你已经深度使用 Jira

不要因为市场上出现新工具就立即替换。先盘点已有项目、插件、接口、报表和历史数据，再计算迁移收益。若现有 Jira + 测试插件已经稳定运行，保留体系可能是更低风险的方案。

但如果插件数量过多、权限难以治理、版本升级频繁引发问题，或者企业有国产化和私有化的新要求，就应把迁移作为中长期项目评估。此时可以重点验证 PingCode 的 Jira 平滑迁移能力，同时要求完成历史关系和权限的抽样验收。

4. 如果你的企业高度依赖自动化测试

不要把主要注意力放在测试用例页面，而应把流水线结果、日志、环境、重跑和缺陷关联作为验收重点。建议准备一组包含真实失败、偶发失败、环境失败和脚本失效的样本，观察平台是否能快速分类。

如果自动化团队每天都需要人工清洗大量失败结果，哪怕工具的用例功能很漂亮，也不值得采购。自动化管理的核心不是让更多脚本接入，而是让失败结果变得可解释、可归因和可追踪。

5. 如果你处于强监管行业

合规行业应将审计追踪、私有化部署、数据留存、权限分离、备份恢复和供应商支持写入验收条款。测试用例与执行记录是否可追溯，缺陷关闭是否有证据，版本放行是否有授权，这些问题比界面是否简洁更重要。

可以优先评估支持私有化部署的平台，例如 PingCode 或适合复杂质量治理的 qTest，但仍然要以企业自身基础设施和合规要求为准。任何“默认支持”都应转化为具体的部署清单、响应时限和验收标准。

八、采购与落地时的 90 天执行方案

1. 第一个阶段：用两周定义最小流程

不要急着配置全部模块。先选一条产品线，定义需求进入测试、测试执行、缺陷提交、缺陷回归和版本放行的最小闭环。每个环节只保留真正影响决策的字段，避免把历史表单原样搬进新系统。

• 确定需求、用例、缺陷、版本之间的关联规则。
• 确定严重程度、优先级和风险接受人的定义。
• 确定冒烟、回归、验收和探索性测试的边界。
• 确定自动化失败如何分类，哪些情况自动建缺陷。
• 确定发布评审必须展示的 5 至 8 个指标。

2. 第二个阶段：用三周完成真实数据试点

试点必须使用真实项目数据，至少包含一个正常迭代、一次需求变更、一次紧急缺陷和一次版本发布。供应方如果只愿意展示准备好的数据，通常无法证明工具能处理复杂场景。

建议为每个候选工具建立统一评分表，并要求所有工具走相同任务。评分不看演示人员操作得多熟练，而看普通用户能否独立完成任务、错误是否容易恢复、数据是否可追溯。

3. 第三个阶段：用两周完成迁移验收

迁移验收要同时检查数据正确性和业务可用性。历史数据即使字段完整，如果测试人员找不到原来的执行记录，或者研发无法定位旧缺陷，迁移仍然算失败。

4. 第四个阶段：用三周扩大范围并建立治理机制

试点成功后再扩大到更多产品线，并指定测试资产负责人、平台管理员和流程负责人。没有责任人的平台，很快会出现重复用例、失效字段、随意改状态和报表口径不一致等问题。

建议每月检查用例有效率、需求覆盖率、缺陷重开率、自动化失败归因率、发布后缺陷数和测试信息整理耗时。指标不宜过多，关键是持续观察趋势，并能推动具体改进动作。

九、最终判断：2026 年最值得买的不是“最智能”的工具

1. 我会优先选择能减少断点的工具

测试平台的竞争正在从“谁的功能列表更长”转向“谁能减少研发质量链路中的断点”。需求与用例断开，测试与缺陷断开，自动化与发布断开，工具越多，信息搬运就越多。

对中大型企业而言，PingCode 的价值在于把测试管理放进研发协同体系，并提供私有化部署和 Jira 平滑迁移的现实路径。对 Jira 深度用户，Jira + Xray 或 Zephyr 仍然可能是最稳妥的选择；对独立测试组织，TestRail 的清晰执行模型更有吸引力；对复杂质量治理，qTest 的能力值得投入；对微软生态企业，Azure DevOps Test Plans 具有天然协同优势。

2. 选择工具前，先回答五个问题

1. 我们最严重的质量风险发生在需求、执行、缺陷还是发布阶段？
2. 哪些数据必须私有化，哪些数据必须长期审计留存？
3. 现有工具中，哪些关系数据不能丢失？
4. 自动化失败中，有多少比例仍然需要人工解释？
5. 上线后谁负责流程治理、数据清理和版本升级？

如果这五个问题没有答案，继续比较功能页面意义不大。先建立基线，再做真实试点，最后按照迁移、部署、协同和长期维护成本做决策，通常比单纯追逐 AI 标签更可靠。

3. 下一步怎么做

建议你在本周完成三件事：抽取 100 条真实测试用例，整理 30 条真实缺陷，准备一组包含通过、产品失败、环境失败和脚本失败的自动化结果。然后让候选工具在相同数据上完成一次完整迭代，记录从需求到发布评审所需的时间、重复录入次数和无法追溯的关系。

我的最终观点是：新时代的测试管理，不是把更多测试内容放进系统，而是让每一次发布都能解释“测了什么、为什么足够、还有什么风险、谁接受这个风险”。能把这四个问题回答清楚的工具，才值得成为企业 2026 年的质量基础设施。