2026年安卓系统测试工具大比拼：6款顶级工具助你提升app质量

一款安卓应用在模拟器里连续跑完 200 条用例，不代表它能在真实手机上顺利完成一次登录、支付或升级。测试工具真正拉开差距的地方，往往不是“能不能自动点按钮”，而是能否覆盖目标设备、稳定复现故障，并把失败原因缩短到团队可以处理的范围。本文比较 Android Studio Emulator、Firebase Test Lab、BrowserStack App Automate、AWS Device Farm、Appium 和 Maestro 六种方案，并给出按团队规模、测试阶段和预算做选择的判断方法。

一、先讲核心结论：没有一款工具能单独覆盖安卓质量保障

1. 六款工具的定位，不是同一条赛道上的排名

我不会把这六款工具简单排成“第一名到第六名”。它们解决的问题并不相同：有的负责开发阶段快速验证，有的负责云端真机覆盖，有的提供自动化控制框架，还有的把脚本设计成更容易阅读和维护的流程。把它们放在一张榜单里直接比价格或设备数量，很容易得出错误结论。

如果只给一个最实用的搭配建议：开发者本机使用 Android Studio Emulator 做高频验证；需要扩展设备覆盖时，先试 Firebase Test Lab 或 AWS Device Farm；如果团队要长期维护跨设备自动化，再评估 Appium 或 Maestro；若采购重点是托管测试平台的协作、设备管理和报告体验，则把 BrowserStack App Automate 纳入试用。

我的核心判断是：先选测试闭环，再选工具。一条闭环至少包括用例执行、失败证据留存、问题复现和修复后的回归。设备数量再多，如果崩溃日志、屏幕录像、应用版本和系统信息无法对应到同一次运行，测试结果仍然难以变成可执行的修复任务。

表里的“适合”是常见落点，不是硬性限制。比如 Appium 可以在本地设备上执行，云端测试平台也能承载回归流程；实际选择应以团队现有技术栈、目标设备和故障处理能力为准。

2. 如果时间有限，优先按风险而不是工具数量做选择

一个刚起步的应用团队，通常不需要同时采购三套云测平台和维护两种 UI 自动化框架。先把用户最常走、失败损失最高的路径列出来，再判断缺口是设备覆盖、自动化执行、性能观测，还是缺陷复现。

例如，应用主要面向普通消费用户，登录、首页加载和支付链路变化频繁，真实设备上的系统差异与网络状态可能比脚本框架更值得优先验证。若应用依赖蓝牙、摄像头、定位、后台任务或厂商定制接口，模拟器和云端设备的能力边界就必须先做小规模验证。

二、安卓测试的真实场景：工具要覆盖的是风险组合

1. “安卓机型很多”只是问题表象

安卓测试的难点常被概括成设备碎片化，但项目真正面对的是多种变量叠加：系统版本、屏幕尺寸、芯片性能、厂商系统定制、权限策略、网络质量、安装来源和应用升级路径。单看机型列表，并不能判断测试覆盖是否有效。

例如，两台手机都运行同一大版本的安卓系统，后台限制、通知权限提示方式和省电策略仍可能不同。对一款依赖定时同步的应用来说，后台任务能否按预期执行，比首页是否在两台手机上都能打开重要得多。

我建议把设备组合拆成“系统版本、设备能力、厂商特性、用户路径”四个维度。不是每个组合都要全量跑完整套测试，但至少应该明确：哪些组合影响功能正确性，哪些影响性能，哪些只需要抽样观察。

2. 真正昂贵的不是执行一次，而是重复定位同一类失败

测试成本不只包括购买设备或云端分钟数。更容易被忽略的是失败后的诊断时间：某次运行究竟用了哪个 APK、哪个系统镜像、哪种网络条件？测试失败是应用缺陷、设备异常、脚本定位不稳，还是服务端数据不一致？如果每次都要重新拼凑这些信息，自动化省下的执行时间可能会被排查时间抵消。

因此，我会把一次测试运行的最小证据包定义为：应用版本与构建号、设备型号与系统版本、用例名称、开始和结束时间、失败步骤、日志或堆栈、屏幕截图或录像，以及必要的网络和测试账号信息。每个工具都应验证这些信息是否能随报告导出，并能否关联到持续集成任务。

3. 自动化覆盖率不等于质量保障能力

团队常用“自动化用例数量”证明测试进展，但一百条不稳定的点击脚本，未必比十条稳定覆盖支付、登录和升级的端到端流程更有价值。用例数量没有说明它们覆盖了多少风险，也没有说明失败后能否快速定位。

我的建议是把测试资产分成三层：单元与组件层尽早发现逻辑问题；本地模拟器和少量实体设备验证应用交互；云端真机或实验室验证设备差异与发布风险。UI 自动化通常只应承担关键旅程和高频回归，不宜把所有业务规则都塞进最脆弱、执行成本最高的界面层。

三、常见误区：为什么“跑得起来”不代表选得对

1. 误区一：云端设备越多，测试就越全面

设备数量只是覆盖能力的一个输入，不是测试质量的结论。若测试团队只在随机设备上执行同一条简单启动用例，设备列表即使很长，也未必覆盖低内存、权限拒绝、断网重连、横竖屏切换或升级失败等高风险情景。

更有效的方法是先定义设备选择规则：目标用户占比、历史故障频率、系统版本边界、硬件能力边界和关键厂商特性。设备矩阵应当随产品用户分布和线上故障更新，而不是每年固定复制一张“热门机型表”。

2. 误区二：云真机可以完全取代本地模拟器

云端真机适合扩展覆盖和提供真实硬件行为，但它通常增加了排队、上传构建、网络传输和远程调试成本。开发者写一行代码后，每次都等待云端任务完成，反馈循环会变慢。

本地模拟器的优势是离开发环境近，便于快速验证安装、布局、日志和常见交互；它的不足是无法完整代表实体设备的传感器、厂商省电策略和实际性能表现。两者不是替代关系，更合理的安排是把高频、低成本检查留在本地，把跨设备和硬件相关验证放到真机。

3. 误区三：自动化框架选好，脚本自然就稳定

脚本稳定性受应用可测试性、页面结构、异步等待策略、测试数据、网络依赖和运行环境共同影响。工具能够提供元素定位与动作执行，但不会自动消除页面动画、服务端延迟、账号互斥或环境污染造成的不稳定。

如果同一条用例时而通过、时而失败，先不要急着换框架。应检查定位是否依赖易变文本、等待条件是否表达页面就绪、每次运行是否使用独立数据，以及失败时能否判断是产品故障还是环境波动。

4. 误区四：把实验室测试结果当作线上用户体验

实验室能控制变量，线上却存在真实网络波动、用户操作中断、后台进程回收和服务端负载。实验室测试能发现有明确复现条件的问题，却不能覆盖所有真实用户行为。

应用发布后仍应结合崩溃率、ANR、启动表现、关键流程成功率和版本分布观察质量变化。测试工具负责把风险尽量提前暴露；线上监控则帮助团队发现测试环境没有覆盖到的真实问题，两者要形成反馈闭环。

四、专业选型逻辑：先定义决策条件，再比较工具

1. 用四个问题确定工具要承担什么责任

工具选型前，我会先问四个问题：谁执行测试、在哪个阶段执行、覆盖哪些设备、失败后谁负责排查。答案不清楚时，采购清单通常会越加越长，最后却没有明确的责任边界。

1. 执行者是谁：开发者、测试工程师，还是持续集成流水线？开发者高频使用时，启动速度和本地调试体验很重要；持续集成使用时，命令行接入、并发和结果归档更重要。
2. 在哪个阶段执行：每次提交、每日回归、候选版本验证，还是正式发布前？不同阶段需要不同的设备数量与用例深度。
3. 要覆盖哪些设备：模拟器、实体设备、云端设备，还是内部设备实验室？目标用户设备分布和硬件依赖决定答案。
4. 失败后谁处理：测试报告能否关联代码提交、构建号和缺陷单？如果没人承担失败分类，自动化只会制造更多待确认告警。

2. 建立可解释的评分表，别用单一“综合分”掩盖短板

试用时可以对覆盖能力、执行稳定性、诊断信息、接入成本和总拥有成本分别评分。每项采用一到五分，并要求填写证据。例如“稳定性五分”必须说明在什么设备、跑了多少轮、失败如何分类，而不能只凭一次成功演示。

总分可以用于缩小候选范围，但不应替代风险门槛。对银行、医疗、车载或其他高风险应用而言，日志留存、测试环境隔离、数据安全、权限控制和审计能力可能是必须通过的门槛，不应被低价格或漂亮界面抵消。

我通常建议把“是否可接入现有流水线”和“失败是否可复现”设为淘汰项。一个平台即使功能丰富，若团队无法在当前构建流程中稳定上传应用包、运行用例并获取报告，实际收益也会很有限。

3. 试用要模拟真实工作负载，而不是看销售演示

建议用同一版本应用、同一组关键用例和同一批设备，对候选方案做小规模并行试用。每个方案至少跑登录、核心业务操作、异常恢复和升级后回归；如果应用依赖硬件，再额外加入真实硬件相关路径。

记录的不是“运行成功”四个字，而是排队等待时间、实际执行时长、失败复现率、日志完整率、人工排查时间、脚本修改频率和单次有效测试成本。试用过程中出现一次偶发失败并不意味着工具不合格，关键是能否把失败归类并重复验证。

4. 把总拥有成本算完整

云端方案的费用不能只看单价，还要估算并发需求、每月有效运行次数、重跑比例、设备时长、报告保留和团队账户等项目。自建方案则要计入设备采购、系统更新、网络与充电维护、设备故障、实验室管理和测试基础设施开发。

框架的隐性成本也很重要。脚本每月维护多少人时？一次应用改版会影响多少定位器？持续集成失败后需要多少人工确认？如果工具让执行费用下降，却令脚本维护和误报处理翻倍，整体成本不一定更低。

五、六款工具逐一拆解：优势、边界和试用重点

1. Android Studio Emulator：最适合高频本地反馈

Android Studio Emulator 是开发阶段最自然的起点。它与 Android 开发工具链结合紧密，便于安装应用、查看日志、调试界面、切换模拟设备配置，并在本地快速检查常见系统行为。对每天提交多次代码的团队，本地反馈速度通常比远程设备数量更能影响开发效率。

它适合验证布局适配、基础导航、安装启动、常见权限流程和可模拟的系统交互，也适合把冒烟测试放进开发者日常工作。使用模拟器做测试时，最好固定系统镜像、分辨率和启动参数，避免不同开发者本地环境不一致。

它不能证明应用在真实硬件上没有问题。摄像头、蓝牙、定位精度、指纹、安全硬件、厂商后台策略、真实低内存条件和实际无线网络表现，都可能与模拟环境有差异。模拟器能提供有价值的近似，但不能冒充所有实体设备。

试用时要观察冷启动与快照策略是否符合团队开发习惯、模拟设备能否覆盖目标系统边界，以及持续集成环境是否有稳定的无界面运行方式。若 CI 中模拟器启动慢或资源争用严重，应把它作为流水线设计问题单独评估，而不是只归因于测试框架。

2. Firebase Test Lab：适合扩展云端设备覆盖

Firebase Test Lab 的价值主要在云端执行与设备覆盖。团队可以把应用包和测试任务提交到远程环境，在多个设备配置上运行测试，并获取运行结果。对于没有条件自建大型实体设备实验室的团队，它可以作为扩大设备矩阵的一种方式。

它适合放在提交后验证、夜间回归或候选版本检查阶段。选择设备时不建议一开始追求大矩阵，而应从用户分布、近期故障和系统边界出发，挑选少量高风险组合，再逐步扩大覆盖。

限制也要提前验证：测试框架兼容性、设备可用性、等待时间、运行时长、数据导出方式和费用规则，可能随账户方案和服务政策变化。特别是设备测试通过，并不意味着应用在目标用户所有厂商定制系统上都获得充分覆盖。

建议用团队已有的一条稳定冒烟测试做试点，同时记录云端任务从提交到结果可读的完整耗时。若用例需要登录服务端，提前设计账号隔离和测试数据清理，否则并发执行时容易出现账号互踢、数据污染或重复下单等假失败。

3. BrowserStack App Automate：适合重视托管体验与协作的团队

BrowserStack App Automate 面向移动应用自动化和远程设备执行。对于希望减少设备采购与维护工作、需要远程查看运行过程并协同处理测试结果的团队，托管平台的设备接入和运行管理可以节省基础设施建设时间。

它更适合有持续回归需求、需要多人协同，且愿意为托管服务付费的团队。对跨地域团队而言，远程设备访问和统一报告可能比自行搭建实验室更方便；对设备覆盖需求较小的团队，这类平台的订阅能力可能超出实际使用量。

采购前应重点核对可用设备与系统版本、并发数、单次任务时长、报告和录像保留、网络条件、私有应用上传方式、账户权限，以及测试数据的安全边界。设备目录会变化，不宜只依据宣传页面上的总数量做判断。

试用应选一条真实 CI 流水线，而不是只在浏览器里手动启动一次测试。观察构建包上传、测试触发、结果回传和失败重跑是否可以自动化完成，同时核对团队能否将运行记录关联到代码提交和缺陷处理流程。

4. AWS Device Farm：适合评估云端设备测试与既有云流程的衔接

AWS Device Farm 提供移动应用在设备环境中的测试能力，适合团队评估云端实体设备执行与自动化流程的衔接。如果组织已在云端构建、存储或运行发布流程，评估同一生态中的服务整合可能更顺手，但“同属一个云生态”本身不是选择理由。

它适合需要设备矩阵测试、希望把移动端测试纳入云端流水线，或已有相应云服务治理经验的团队。应验证其测试框架、设备选择、排队与并发、报告导出、访问权限和区域要求是否符合当前项目。

要特别留意总成本与操作复杂度。云服务的计费方式、资源配置和账户权限需要团队理解；对没有专职测试基础设施人员的小团队，配置与维护的学习成本可能高于预期。先用小规模试点测出一轮真实工作负载，再估算月度开销，比直接采购高配方案稳妥。

如果组织有严格的数据边界，应在试用阶段验证上传的应用包、测试账号、运行录像和日志如何处理、谁能访问以及保留多久。合规问题不能等到测试平台已经进入发布流程后才补做。

5. Appium：适合需要控制力与可扩展性的自动化团队

Appium 是移动端自动化框架，优势在于可编程、可组合，并能融入团队已有的测试工程体系。对有自动化经验、需要复杂测试数据管理、希望维护自有执行逻辑的团队，它提供了较大的工程控制空间。

它尤其适合将 UI 自动化作为长期资产建设的团队。测试人员可以围绕应用结构设计页面对象、复用动作、管理等待策略，并将运行结果接入现有报告和持续集成系统。跨平台团队也可能因框架复用需求而评估它，但跨平台不等于所有脚本可以无差别共享。

代价是团队需要承担脚本架构、驱动与环境兼容、设备管理、并发调度、重试策略和失败分类。Appium 能让团队掌控更多环节，也意味着更多环节需要团队负责。若只有少数关键路径，维护一套庞大通用框架可能不如保持简单。

试用时先看团队对定位、等待、并行运行和失败截图的处理是否一致，再看不同设备上的执行稳定性。不要用脚本行数衡量框架建设成果；更值得跟踪的是关键流程稳定运行比例、误报率和每月维护时间。

6. Maestro：适合快速表达关键用户流程

Maestro 以较易阅读的移动端流程描述吸引团队，适合把登录、搜索、表单提交、购买或内容发布等用户旅程写成可读的自动化步骤。对希望尽快建立冒烟回归、而不是先投入大量通用框架开发的团队，这种表达方式有较低的起步门槛。

它的优势是让产品、测试和开发更容易讨论“用户到底做了什么”，减少自动化脚本被少数工程人员独占的情况。对于页面结构相对稳定、关键路径清晰的应用，可以先从少量高价值流程开始试跑。

边界在于，真实应用可能包含复杂原生组件、特殊系统弹窗、权限分支、深度链接和多进程交互。是否能覆盖这些场景，要拿自己的应用验证，不能只根据简单演示推断。对需要复杂条件逻辑、细粒度数据控制或大量底层操作的项目，可能仍需结合其他测试手段。

试用时要把“异常路径”纳入评估，而不是只验证顺利完成流程。例如用户拒绝权限、网络中断、服务端返回错误、键盘遮挡按钮、进程被系统回收后重新进入，这些情况往往更能说明工具和用例设计是否适合产品。

六、案例与数据观察：怎样比较而不制造虚假精确

1. 用一个假设项目说明测试矩阵如何落地

设想一款面向消费用户的订阅应用，每周发布一次，关键流程包括安装启动、注册登录、订阅购买、恢复购买和账号退出。团队有 6 名移动开发与测试成员，已有持续集成，但没有专职设备实验室。以下数字是示范用的情景规划，不代表任何真实企业的测量结果。

项目首先把每次提交的检查控制在本地模拟器和少量稳定用例，目标是及时发现明显回归；夜间任务增加云端设备覆盖；候选版本则增加真实设备上的升级、权限和购买恢复检查。流程的重点不是所有用例跑遍所有设备，而是把最贵的验证留给风险更高的阶段。

2. 用有效测试成本替代“单次运行价格”

假设某条用例执行一次需要 6 分钟，但第一次运行失败后有 40% 概率被重跑；每次失败还需要 12 分钟人工判断。另一个方案执行时间稍长，却附带完整录像和日志，把人工判断缩短到 5 分钟，那么后者可能拥有更低的有效成本。

可以用下列公式估算单条用例的有效耗时：执行耗时 × 平均运行次数 + 失败概率 × 人工诊断耗时。这个公式不是采购计价标准，却能提醒团队把重跑与诊断纳入比较，而不是只看平台展示的设备分钟数。

上述数据是便于演算的情景模拟。实际试用中应按团队最近数周的失败记录更新失败概率和诊断耗时，并区分产品缺陷、环境异常与脚本脆弱。否则公式看起来精确，输入却没有业务依据。

3. 数据观察要能指导动作，而不只是汇报数字

试点报告可以记录五类指标：关键用例通过率、跨设备失败复现率、失败证据完整率、从失败到初步定性的时间，以及每周脚本维护工时。每个指标都应定义分母和统计周期，例如“失败证据完整率”是有日志、设备信息和截图的失败占全部失败的比例，而不是主观判断。

如果通过率高但失败复现率低，优先检查环境与脚本稳定性；如果复现率高但修复慢，可能是日志关联或责任流转不顺；如果设备覆盖高但线上仍集中出现某类问题，可能是设备矩阵没有反映真实用户分布。指标的价值在于触发下一步调查。

公开资料可以用于核实工具支持的框架、服务边界与计费说明，但不能代替项目实测。正式评估时应查看 Android Developers 关于模拟器与测试的文档、Firebase Test Lab 官方文档、BrowserStack App Automate 文档、AWS Device Farm 文档、Appium 文档和 Maestro 文档，并记录核对日期。各平台的设备目录、系统版本、价格与功能可能调整，文章中的选型原则应与当前官方说明一并核验。

七、不同团队的行动建议：从最小可行覆盖开始

1. 独立开发者或小团队：先让本地反馈变快

如果团队规模小、应用还在快速迭代，优先把 Android Studio Emulator 的开发体验打磨好，并建立少量关键路径冒烟测试。先保证构建、安装、启动、登录和核心页面可重复验证，再选择少数目标实体设备做人工或自动化抽测。

这类团队最容易踩的坑是过早维护复杂的跨设备脚本。代码结构和页面变化频繁时，脚本维护成本可能迅速增加。建议每条自动化用例都回答一个问题：它减少了哪类风险，失败时会提供什么证据，是否比手工检查更划算？

2. 中型产品团队：本地验证与云端扩测分层

已有持续集成、每周持续发布的团队，可以采用“提交时轻测、夜间扩测、发布前重点检查”的分层策略。提交时保证快，夜间任务扩大系统与设备范围，候选版本集中验证支付、升级、权限和异常恢复等高风险流程。

选 Firebase Test Lab、BrowserStack App Automate 或 AWS Device Farm 时，建议先根据目标设备、现有流水线和数据治理要求筛选，再做等量试用。不要同时把所有自动化迁到云端；先迁一组稳定的关键用例，观察四周后再决定扩容。

3. 大型或强监管团队：控制可审计性与环境边界

大型团队通常要额外考虑访问权限、测试账号隔离、日志留存、数据脱敏、采购合规和发布审批。云端平台需要验证数据处理与访问控制，内部设备实验室则要设计设备维护、系统镜像、网络隔离和使用排期。

对于高风险业务，可把自动化平台能力拆成几类采购门槛：环境可追踪、报告可留存、构建版本可关联、失败可复现、访问可审计。任何一项不满足，都应先形成风险评估和补偿措施，而不是通过平均分掩盖。

4. 自动化刚起步的测试团队：从用户旅程而不是页面数量开始

先挑三到五条高价值用户旅程，确保覆盖正常路径和一两个关键异常分支。Maestro 可作为快速表达流程的候选，Appium 则适合团队希望建立更可编程、可扩展体系时评估。两者都应以应用实际页面和系统交互验证，不要仅凭语法风格做决定。

建议为每条用例定义清晰的成功条件。例如购买流程不能只判断“按钮被点击”，而要确认订单状态、页面反馈和服务端测试数据一致。只有业务结果明确，自动化才真正验证了质量，而不是验证脚本能否完成点击。

八、不同场景下的取舍：按风险与资源选择组合

1. 预算紧、设备需求少：接受有限覆盖，避免假装全面

预算有限时，可用模拟器覆盖高频功能验证，再购买或借用少量目标实体设备做硬件相关抽测。此时应明确没有覆盖的风险，例如某些厂商后台策略或特定系统版本，不要把“测试通过”宣传成“全安卓兼容”。

这类方案牺牲的是广泛设备覆盖，换来较低成本和较快迭代。通过记录真实用户设备分布与线上缺陷，可以逐步补齐高风险设备，而不是一次性追求昂贵的全量矩阵。

2. 发布时间紧、覆盖压力大：用云端扩测，但保留最小本地回路

发布窗口短、设备覆盖要求高时，云端平台能帮助并行执行更多设备组合。但仍要保留本地或 CI 的快速冒烟测试，否则简单问题也会排队等待远程执行，团队反馈速度反而变慢。

云端并发越大，越要治理测试账号、数据隔离和失败分类。否则并行任务会互相污染，表面上增加执行量，实际上产生更多假失败和人工复核。

3. 应用依赖硬件或厂商能力：增加真实设备比例

若产品依赖蓝牙、NFC、摄像头、定位、后台常驻或特定厂商服务，模拟器只能承担部分验证。应挑选真实目标设备，设计断连、拒绝权限、后台切换、重启恢复和弱网等场景，并明确设备固件与系统版本。

这类场景下，自建设备实验室可能提供更高的环境控制能力，云端真机则有利于快速扩展。两者如何组合取决于设备取得难度、远程控制能力、数据敏感性和维护人力；不能仅凭单次测试价格作结论。

4. 脚本维护负担已很高：先修测试设计，再考虑迁移

如果自动化经常因为定位变化、动画等待或账号冲突而失败，迁移到另一框架未必解决根因。先减少对易变 UI 文本的依赖、增加稳定标识、使用明确的业务状态判断、隔离测试数据，并把产品缺陷与测试故障分开统计。

当这些治理已经完成，脚本仍受到框架能力、设备控制或团队技能限制，再用真实用例评估替换成本。更换工具本身也会带来迁移、培训和双轨维护成本，必须算入决策。

九、最终结论：测试工具的价值，是让风险更早、更清楚地暴露

1. 我会怎样做最终选择

若我从零搭建安卓测试流程，会先用 Android Studio Emulator 建立快速开发回路，再把高风险关键旅程自动化。随后按用户设备分布选一小组云端或实体设备扩测，比较 Firebase Test Lab、BrowserStack App Automate 和 AWS Device Farm 的实际接入、设备能力、结果证据与总成本。

自动化框架方面，我会让一条真实用例分别试跑 Appium 或 Maestro 候选，而不是基于抽象功能列表决定。团队已有成熟工程能力、需要更多控制时，优先评估 Appium；需要快速表达少量关键流程时，评估 Maestro；如果应用场景超出工具边界，就用专项测试与人工验证补齐。

2. 下一步：用两周试点代替一次性大采购

1. 列出三条关键用户旅程和三个高风险设备或系统组合。
2. 确定同一份应用构建包、测试数据和失败证据标准。
3. 选择一套本地方案和一套云端或真机方案进行试点。
4. 记录有效执行耗时、失败复现率、证据完整率和人工诊断时间。
5. 复盘真实用户风险与未覆盖边界，再决定扩展设备、框架或平台。

最终值得坚持的判断只有一个：不要为“测试跑了多少台设备”付费，而要为“高风险问题能否被发现、复现并修复”投入。工具只是质量体系的一部分。清晰的风险矩阵、稳定的测试数据、完整的失败证据和线上反馈闭环，通常比盲目扩大设备列表更能提升安卓应用质量。