提升测试质量：2026年6大热门功能测试工具盘点

提升测试质量：2026年6大热门功能测试工具盘点

选功能测试工具时，最容易踩的坑不是选错一款，而是把“能跑起来”误当成“能长期守住质量”：一条端到端测试在演示环境里绿了，换到 CI、真实设备和频繁更新的页面后，却开始超时、误报、需要反复修脚本。本文不把六款工具排成缺少依据的“胜负榜”，而是从测试对象、团队技术栈、维护成本和落地边界出发，梳理 Playwright、Selenium、Cypress、WebdriverIO、Appium 与 Katalon Studio，帮助你判断先试哪款、怎么试，以及何时不该上自动化。

一、先讲结论：工具质量不等于测试质量

1. 先按测试对象分组，再谈工具选择

如果团队主要验证浏览器中的业务流程，优先在 Playwright、Selenium、Cypress 和 WebdriverIO 之间比较；如果主要风险来自原生或混合移动应用，则应把 Appium 纳入评估；如果团队希望通过图形化方式组织测试流程、减少直接编写脚本的工作量，可以考察 Katalon Studio。

这不是说它们互相完全替代。前四者都能用于 Web 自动化，但设计侧重点、语言生态和扩展方式不同；Appium 的核心关注点是移动应用自动化；Katalon Studio 则是带有图形化工作流和商业化能力的平台型选择。把六款工具放进一张不分场景的总排名表，容易制造“功能相同、只差分数”的错觉。

我更建议先问：“我们最需要稳定验证的用户路径是什么？”而不是“哪款工具功能最多？”比如，电商团队优先保护结算链路，SaaS 团队可能更关心权限矩阵与关键表单，移动应用团队则要处理设备、操作系统和应用版本差异。测试对象不同，工具的投入回报也不同。

2. 选型的核心是总维护成本，而非首次编写速度

工具的价值不应只看一条脚本写得多快。我会把项目总成本拆成五部分：脚本编写、失败排查、用例维护、运行环境管理和团队协作。某款工具让第一条用例少写了几行代码，却让定位偶发失败变得困难，长期未必省时。

尤其要区分“测试执行失败”与“产品缺陷”。如果测试频繁因为加载时机、数据状态、环境波动而失败，团队会逐渐形成“先重跑几次”的习惯。结果不是质量提升，而是告警被折价，真正的缺陷也更容易被噪声淹没。

3. 本文的六款工具是候选清单，不是权威热度排名

目前可用的选题资料只有搜索结果页和无关页面，不能据此证明某款工具的市场份额、用户数量或排名。因此，本文把“热门”理解为值得纳入团队评估的常见候选，而不是第三方统计得出的六强榜单。

工具定位依据各项目公开的官方文档与产品说明。版本、授权方案、价格、支持范围等会随时间变化，本文不把容易过期的版本号或价格写成固定事实。正式采购或技术定型前，应以工具官方文档、发布说明和价格页面为准，并记录核查日期。

表格只是帮助缩小范围，不代表每款工具只有一种用法，也不能替代真实项目验证。最终决定应基于团队当前的应用类型、技能构成、测试资产和运行环境，而不是工具宣传页上的功能数量。

二、为什么自动化测试常常“数量上去了，信心却没上去”

1. 自动化覆盖率不是业务风险覆盖率

团队汇报时常见一个漂亮数字：自动化用例已经覆盖某个比例的页面或接口。但页面被打开过，不代表用户最容易出错的业务状态都被验证；接口被调用过，也不代表权限、异常输入和跨步骤状态变化都得到保护。

例如，订单流程至少可能涉及未登录访问、库存不足、优惠条件失效、支付失败、重复提交、取消后重试等分支。如果自动化只覆盖“正常下单成功”，代码覆盖率、用例数或页面覆盖数再好看，也不能说明高风险场景被保护住了。

所以我更愿意先画出关键业务路径，标记“失败会造成什么后果”和“问题能否被快速发现”，再决定哪些步骤值得进入端到端自动化。不是每个分支都要用 UI 测试覆盖；有些规则在接口或组件层验证更快、更稳定。

2. 最贵的不是失败，而是无法解释的失败

一次失败如果能清楚指出断言不成立、页面元素不存在，团队可以快速判断是产品问题还是测试问题。更消耗信任的是同一脚本今天通过、明天失败，重跑后又恢复，而且日志、截图和网络信息不足以还原现场。

这类“偶发失败”会产生隐性成本：工程师要重新运行流水线、检查环境、比对日志，再决定是否推迟发布。用例数量持续增长后，即使偶发率不高，累计排查工作也会显著挤占功能开发和测试分析时间。

因此，工具评估要观察失败后的可诊断性，例如是否能保存截图、视频、浏览器日志、网络请求或执行轨迹；这些能力的具体形式因工具和配置而异，不能只凭默认安装结果判断。

3. 真实项目的“脏条件”比演示项目重要

演示环境通常数据干净、网络稳定、用户权限简单、浏览器版本固定。上线项目面对的却是数据重复、异步请求、权限变化、弹窗、限流、第三方服务波动和并行执行冲突。

我建议把试用测试放在最接近真实交付的 CI 环境里，而不是只在工程师本机跑通。至少要验证并行运行、失败重试策略、测试数据隔离、报告留存和运行时长。工具在笔记本上的体验很好，并不能推导出团队流水线里也一样省心。

三、六款工具逐一看：优势、边界与验证重点

1. Playwright：适合新建 Web 自动化体系时优先试跑

Playwright 常被纳入现代 Web 自动化候选，适合验证浏览器中的用户流程。其官方文档覆盖多浏览器自动化、测试运行与调试相关能力，团队可以用自己熟悉的支持语言组织测试。选它时，真正需要验证的不是“能不能打开网页”，而是现有语言、浏览器范围、报告和流水线是否能顺利接起来。

一个值得关注的方向是自动等待与定位策略。若测试依赖固定睡眠时间，页面慢一点就失败、快一点又浪费时间；更合理的做法是等待可观察的页面状态。但自动等待也不是消除所有不稳定因素的魔法，测试数据污染、第三方服务抖动和业务状态竞争仍需单独治理。

更适合：新建 Web UI 自动化、团队能维护代码、需要把测试放入 CI 的项目。需要谨慎：已有大量成熟测试资产的团队，不应仅因工具较新就重写全部脚本；迁移成本和新旧体系并行成本也要计算。

试点时建议选一条稳定且业务价值高的流程，验证定位策略、失败证据、并发执行和测试数据清理。若要覆盖多个浏览器，确认实际发布所需的浏览器组合与版本范围，不要把“文档支持”直接等同于“项目环境已验证”。

2. Selenium：生态成熟，既有资产可能比新工具更值钱

Selenium 的长期价值在于成熟的 Web 自动化生态和广泛的工具链使用基础。对已有 Selenium 脚本、团队经验、运行节点或周边报表体系的组织而言，继续维护现有方案有时比全面迁移更经济。

但“生态成熟”不等于“维护自动发生”。测试框架、浏览器驱动、节点配置、依赖版本和运行环境都需要治理。若团队把脚本写法、等待策略、页面对象约定和失败收集各自为政，框架越大，后续变更越难统一。

更适合：已有 Selenium 自动化资产、需要延续既有体系，或有明确的生态与兼容需求。需要谨慎：从零起步又没有统一工程规范的团队，先确认是否愿意承担框架配置与维护工作，不能只因它“用得久”就认定最省成本。

评估时不要把“旧脚本还能跑”作为唯一标准。抽样检查一批核心用例：最近三个月改动频率、失败原因、维护人、运行环境及重复逻辑。若大量用例依赖过时的定位方式或无人理解的公共封装，继续投入前应先做资产清理。

3. Cypress：前端开发体验突出，但要对照项目边界

Cypress 的产品与文档定位强调 Web 应用测试和开发者工作流。对于前端团队，靠近应用代码进行调试、观察测试执行过程，往往更容易形成日常协作习惯。它可以成为“测试写得出来、开发愿意维护”的候选方案。

选型时应具体核对浏览器需求、应用架构、跨域流程、测试类型和团队当前的版本计划。工具能力会随版本演进，过往文章中的限制结论可能已经变化；反过来，宣传页展示的能力也不等于团队项目中的接入工作已经完成。

更适合：以 Web 应用为主、前端工程师参与测试编写和维护的团队。需要谨慎：测试需要覆盖复杂多端组合，或已有框架与执行环境存在特殊约束的项目，应先做针对性验证，而不是只看本地调试体验。

我会把“开发者是否愿意在功能变更时顺手更新用例”作为重要观察点。工具如果离开发流程太远，测试维护就容易变成少数测试工程师的单点职责；工具如果能降低协作摩擦，才可能让测试跟着产品变化持续更新。

4. WebdriverIO：灵活性是一种能力，也是一项维护责任

WebdriverIO 面向 JavaScript 自动化场景，具备框架和扩展生态的属性。对于已经使用 JavaScript 或 TypeScript、需要把不同测试需求组织到同一工程体系中的团队，它值得进入候选名单。

灵活的另一面是选择多。配置、服务、插件和抽象层如果缺少团队约定，项目可能逐渐出现多种写法：不同人使用不同定位方式，不同模块各自封装等待逻辑，运行失败后还要先理解“这个用例究竟按哪套规则写的”。

更适合：有 JavaScript 工程实践、愿意维护统一配置和代码规范的团队。需要谨慎：仅因团队会写少量脚本就选择高度可扩展方案，却没有明确维护人或代码审查规则，可能把学习成本转化成长期治理成本。

建议在试点中刻意加入一次页面重构、一次失败排查和一次流水线并发执行，观察灵活性是否真的带来收益。只测试“第一条脚本写起来顺不顺”不足以验证框架是否适合长期使用。

5. Appium：移动端自动化要把设备条件纳入工具评估

Appium 是移动应用自动化的重要候选，适用于需要通过自动化方式操作移动应用的团队。它的评估重点不应停留在脚本语法，而要覆盖应用类型、操作系统、设备来源、版本组合、启动时间和设备并发等实际条件。

移动端测试与浏览器测试的成本结构不同。设备状态、系统弹窗、网络切换、生物识别模拟、应用安装与卸载、系统版本差异，都可能影响结果。若团队没有设备管理方案，再好的脚本也可能卡在设备占用、环境清理和版本漂移上。

更适合：移动应用是核心交付对象、团队能持续管理设备或云端设备资源的项目。需要谨慎：移动端只是少数辅助场景、当前没有设备维护能力的团队，可以先用少量高风险流程试点，不宜一开始就追求大规模全设备覆盖。

实践中应区分模拟器与真实设备的职责。模拟器适合快速反馈和基础回归，真实设备更适合发现设备差异、系统行为和硬件相关问题。两者不是非此即彼，但预算有限时，设备组合应依据用户分布和故障影响来设计。

6. Katalon Studio：降低创建门槛，不代表没有工程治理

Katalon Studio 可作为图形化与脚本化结合的平台型候选。对于希望让更多角色参与测试设计、集中组织测试资产或减少从零搭建框架工作的团队，图形化工作流可能降低初始门槛。

但“低代码”并不意味着“免维护”。测试对象、公共步骤、数据管理、权限、报告、执行环境和商业授权仍然要有人负责。若测试流程越做越复杂，团队还需判断图形化抽象是否便于代码审查、变更追踪和问题定位。

更适合：希望统一测试工作流、需要让不同技术背景成员参与自动化的团队。需要谨慎：已有完善代码框架、团队偏好自主构建工具链，或预算对授权费用敏感的组织，应仔细核算平台收益与锁定成本。

评估平台型工具时，至少要核对实际需要的功能是否属于免费能力、商业方案或特定套餐，并确认数据导出、团队协作、执行扩展和退出迁移的条件。价格与授权可能变化，应以官方页面和书面报价为准。

四、常见误区：让测试套件变得昂贵又不可信

1. 误区一：用例越多，质量越高

用例数量是产出指标，不是质量结论。大量重复验证相同路径，会增加运行时间和维护负担，却没有相应扩大风险覆盖。新增自动化之前，先问它保护哪条业务规则、能发现什么类型的故障、失败后由谁处理。

当两个用例验证同一个状态、同一组数据，只是页面入口不同，可以考虑是否应保留两者，或把部分断言下沉到更合适的测试层。目标不是删用例，而是让每一条用例的存在理由清楚。

2. 误区二：把端到端测试当成唯一自动化形式

端到端测试能验证完整用户路径，但通常依赖更多服务、数据和页面状态，失败定位也可能更复杂。输入校验、格式转换、权限规则等，可能在单元测试或接口测试层更快得到反馈。

我采用的原则是：越靠近用户真实风险的验证，越需要接近业务链路；越基础、越局部的规则，越应该优先在更快的测试层验证。这不是固定比例公式，而是避免所有测试都挤在最慢、最脆弱的一层。

3. 误区三：用重试把不稳定“修好”

重试可以处理个别瞬时环境问题，但如果团队长期依赖重试掩盖失败，最终会丢失真实稳定性信号。更稳妥的做法是记录首次执行结果、重试结果、失败类型与发生频率，并设置明确阈值。

例如，如果某用例每十次执行就有一次首次失败，重试后通过，不能简单报告“通过率百分之百”。应该把首次失败率视为稳定性指标，查明是等待策略、共享数据、设备波动还是产品竞态。

4. 误区四：在工具比较中混用不同指标

“一条用例的编写时间”“整套测试执行时长”“单次失败排查时长”“每月维护人天”不是同一类指标。若把它们混成一个总分，却没有给权重和测试条件，结论看起来精确，实际不可复核。

对比时至少要固定应用版本、测试数据、执行机器、浏览器或设备组合、并发数和重试规则。无法固定条件时，就把结果标为情景观察，不要写成工具的普遍性能结论。

5. 误区五：把工具安装成功当作选型完成

安装成功只证明工具能在某个环境启动，不说明它适合团队长期使用。完整评估应至少经过“写用例、接流水线、制造一次失败、定位根因、修改页面、重新验证”几个环节。

如果没有真实产品变更，测试就无法验证维护性。建议人为安排一个非破坏性的页面变化，例如调整文本、改变组件结构或更新测试数据，观察定位器和公共封装需要怎样修改。这个小实验往往比多跑几次成功用例更能暴露维护风险。

五、专业选型逻辑：先把需求变成可验证的试点

1. 第一步：描述测试对象，不要先写工具偏好

列出系统边界：浏览器应用、原生移动应用、混合应用、后台管理页或多端组合。再标记用户实际使用的浏览器、设备和操作系统范围，并区分“必须覆盖”和“有预算再覆盖”的范围。

如果一个项目同时有 Web、移动端和 API，不代表必须用一个工具包办所有测试。多工具组合会增加技能、报告和维护复杂度，但强行统一也可能带来不合适的抽象。要比较的是端到端总成本，而不是工具数量本身。

2. 第二步：用风险筛选关键路径

为业务路径标注影响、发生概率和发现难度。资金、权限、订单状态、数据删除等高影响路径通常值得优先保护；低频、低影响且手工验证成本很低的路径，未必适合先投入自动化。

可采用团队自己的五级评分，不必把评分包装成科学模型。重要的是统一口径：例如“影响五分”代表故障会阻断核心业务，“发现难度五分”代表现有监控和人工检查不容易发现。评分之后再选少量最有价值的流程进入试点。

3. 第三步：把选型权重写出来

如果团队最看重既有脚本复用，就提高资产迁移权重；如果主要风险是移动设备兼容，则提高设备覆盖与设备资源管理权重；如果需要多个角色协同创建测试，协作和平台成本就不能排在最后。

权重不必追求小数点精度。用“必须满足、明显加分、暂不考虑”三档，往往比没有依据的百分制更清楚。必须条件不满足的候选工具应先淘汰，不要靠总分把关键缺陷平均掉。

4. 第四步：设计公平的短周期试点

试点不是产品演示，而是一次小型工程验证。建议控制范围：一条关键业务流程、一个真实测试环境、一组明确数据和少量参与人员。两周左右通常足以暴露接入与协作问题，但周期要按团队发布节奏调整，不能把“两周”当成通用规定。

试点开始前先约定指标：首次通过率、失败定位时间、单条用例维护时间、流水线耗时、数据清理工作量、跨角色协作次数。每项指标都要说明统计口径，避免试点结束后只挑对某个候选有利的数据讲。

5. 第五步：记录边界，给未来的迁移留退路

把工具版本、浏览器或设备环境、关键配置、数据生成方式和已知问题记下来。还要确认测试用例与业务规则是否过度绑定某个工具的私有格式，公共数据、报告和缺陷追踪是否能导出或接入现有流程。

这不是预设工具一定会被替换，而是承认业务和团队会变化。工具选型的成熟标志，不是“永远不换”，而是知道换工具的代价、边界和迁移路径。

六、具体案例：一个结算流程试点应该怎样算账

1. 场景设定：先保护一条高风险路径

以下案例是用于说明方法的模拟场景，不是某个客户项目的实测记录。假设一家在线服务团队每周发布数次，结算流程涉及登录状态、购物车、优惠校验、库存、支付和订单确认。过去回归主要靠人工完成，测试时间集中在发布前。

团队没有试图一次覆盖所有功能，而是挑出“从有效购物车创建订单到收到订单确认”的主路径，再加上库存不足、优惠失效和重复提交三个高风险异常分支。这样可以让工具试点与业务风险对应，而不是为了展示工具而写一套无关的示例脚本。

2. 设定基线：先记录现状，再评价工具

假设该流程每次手工回归耗时约4小时，每周执行3次，月均按4周计算，则一个月约需48小时。这个数字是情景假设，用于展示计算方法；真实团队应以测试工时记录、发布频率和实际回归范围替换。

工具试点初期会增加编写、数据准备和流水线接入成本，不能把“自动化后每次执行变快”直接当成净收益。还要统计脚本维护、失败排查、测试数据清理和环境恢复所需时间，才能判断自动化有没有实际减少重复工作。

3. 两种方案比较：新建工具与延续既有资产

假设团队已有一批旧 Web 脚本，但失败记录不完整。候选方案不是简单比较“新工具比旧工具先进多少”，而是比较两条路线：一是继续使用既有框架，先重构关键用例；二是选择新候选工具，只迁移结算主路径，保留旧体系一段时间。

每条路线都测同一组业务场景，并固定浏览器、测试数据、CI 机器和并发数。至少记录首轮通过、重试情况、维护改动时间、失败定位时间和一次页面调整后的修复工作量。若两种方案没有按相同条件运行，结果只适合作为参考观察，不能宣称哪个工具更快或更稳。

4. 示例账本：用透明的假设展示盈亏平衡

继续使用情景模拟：假设每月48小时人工回归中，能稳定被自动化替代的部分为70%，即每月约34小时；自动化之后，每月仍需约10小时用于维护和失败排查。扣除每月节省的约24小时后，若初始建设投入为80小时，粗略盈亏平衡时间约为3.3个月。

这里的70%、10小时和80小时均为模拟输入，不是行业基准。真正重要的是公式：初始投入 ÷（每月减少的重复执行时间－每月维护时间）。如果分母小于或等于零，自动化暂时没有在工时层面回本；但若它显著降低漏测风险或加快反馈，团队仍可把这些收益单独评估。

这个算账方式的价值，不在于给出一个漂亮的回本数字，而在于逼团队把维护成本放进预算。若自动化用例维护每月从10小时升到30小时，净节省就会从24小时降到4小时，盈亏平衡期随之明显拉长。

5. 结果怎样判读：看稳定性，也看人工反馈路径

如果自动化每次都能执行，但失败后需要测试负责人花很久判断责任归属，流程收益可能被排查成本抵消。相反，若首轮失败可快速定位、业务缺陷能被及时阻断，即使节省工时没有立即达到预期，工具也可能改善发布信心。

试点结束时，至少回答四个问题：核心场景是否被覆盖？首次执行是否稳定？失败证据能否支持快速判断？发生业务变化时，谁负责更新用例？任何一项没有明确答案，都不适合直接扩大到整个系统。

七、按团队情况行动：从“选工具”转向“做决定”

1. 从零搭建 Web 自动化的团队

先挑 Playwright、Cypress 或 WebdriverIO 中与团队技术栈最匹配的一到两款进入小试点。重点比较团队实际写代码、调试、接入流水线和维护定位器的体验，而不是把三套工具全部投入长期并行建设。

若团队已经有清楚的 JavaScript/TypeScript 规范，WebdriverIO 的扩展能力可能有价值；若希望更直接地把 Web 测试融入开发工作流，可以试 Cypress；若重点是现代浏览器自动化和独立测试运行流程，可以把 Playwright 纳入试点。最终选择要由具体项目验证，不宜只根据这类概括判断。

2. 已有 Selenium 资产的团队

先盘点脚本健康度，而不是先规划全面迁移。将用例分为稳定且关键、稳定但低价值、高价值但经常失败、长期无人维护四类。优先修复核心路径，删减重复验证，再决定哪些资产值得继续维护，哪些适合逐步迁移。

如果旧框架运行稳定、团队熟悉且维护成本可控，继续使用可能是合理选择。迁移的理由应是明确的工程收益，例如诊断能力不足、浏览器或 CI 接入存在硬限制，不能只用“技术栈更新”作为充分理由。

3. 移动应用团队

先确认自动化的目标设备集合，以及模拟器和真实设备分别负责什么。将 Appium 试点放在一条跨页面、包含关键状态变化的流程上，同时评估设备占用、安装启动、系统弹窗处理、并行能力和故障恢复。

若团队没有设备管理和测试数据清理机制，先补齐环境治理，往往比增加脚本数量更有效。若只需验证少数稳定的高风险流程，可从小型设备矩阵开始，按照真实用户分布逐步扩展。

4. 技术能力差异较大的团队

可以把 Katalon Studio 等图形化工作流方案纳入评估，但同时邀请未来实际维护测试的角色参与。试点不能只看业务人员能否录制操作，还要看脚本变更是否可审查、公共步骤是否复用、失败能否定位，以及商业授权是否适合团队规模。

若图形化能力让更多人参与测试设计，却让少数工程师承担全部故障排查，团队只是把门槛从“创建”转移到了“维护”。应将角色分工和知识交接写进试点结果。

5. 发布频率高、回归压力大的团队

优先自动化那些频繁执行、结果可判定、数据可控、业务影响大的回归场景。不要一开始覆盖所有页面，也不要把所有手工测试都转成自动化。先让关键回归进入每次合并或发布前的反馈流程，再根据维护成本决定扩张速度。

还要区分快速反馈集与完整回归集。快速集应保持足够短，能在开发流程中提供及时结果；完整集可以更广，但要安排合理的执行时机和失败处理责任。工具能否支持团队需要的分组、报告与流水线策略，应在试点阶段验证。

八、最后怎么取舍：工具选型必须允许“不选”

1. 哪些情况适合立即推进

如果某条业务路径反复人工回归、每次执行步骤稳定、结果判定清晰，而且失败影响明显，可以启动小范围自动化。此时工具的价值不只是省掉重复点击，还包括把关键业务规则持续放进发布反馈链路。

若团队已有代码规范、CI 环境、测试数据管理和明确维护责任，推进条件更成熟。即便如此，也应先用一条流程测出维护成本，再决定是否扩张。

2. 哪些情况应该先修流程，而不是先买工具

如果测试环境经常不可用、业务数据无法隔离、测试结果依赖人工临时准备，工具只会更快地重复失败。若页面和业务规则持续大幅调整，却没有用例维护责任人，自动化脚本也容易变成过期负担。

遇到这些情况，先统一测试数据策略、环境恢复方式、业务规则文档和失败处理流程。等输入条件具备之后再评估工具，才能分辨问题究竟来自工具能力还是工程基础。

3. 哪些情况不值得强行自动化

一次性活动页面、变化极快且生命周期很短的功能、结果难以稳定判定的探索性场景，可能不适合先做 UI 自动化。手工探索、接口级验证、监控告警或更轻量的检查，有时成本更低。

不自动化不是放弃质量，而是把有限工程资源放到更有收益的位置。团队应能解释为什么某类测试暂时保留人工执行，以及由谁、在什么节点完成验证。

4. 最终选择建议

新建 Web UI 自动化，可以从 Playwright、Cypress、WebdriverIO 中按技术栈和工作流挑选少数候选；已有成熟 Selenium 资产，优先算清延续与迁移的总成本；移动应用为主，重点验证 Appium 与设备管理的组合；需要图形化平台化工作流，则评估 Katalon Studio 的协作收益、授权条件和退出成本。

这些是缩小候选范围的判断，不是产品排名。定型前，应按统一环境完成真实流程试点，核对官方文档、当前版本、支持范围和授权条款。测试质量来自可持续的风险覆盖、稳定的执行和可解释的失败，而不是某个工具名称本身。

下一步可以先做三件事：选出一条故障影响最大的业务路径；用一张表记录现有人工耗时、失败原因和维护责任；再让一到两款候选工具在真实 CI 环境里完成同一组试点。能稳定执行、能快速定位、业务变化后有人维护，才是值得留下来的方案。