2026年必看：10大软件测试用什么软件工具全面对比

2026年必看：10大软件测试用什么软件工具全面对比

“软件测试用什么软件工具”没有一个能回答所有团队的标准答案：一个 Web 团队可能缺的是稳定的浏览器回归，一个移动团队可能卡在真机覆盖，一个业务系统团队则可能连需求、用例和缺陷都无法追溯。选错工具，常见结果不是测试能力变强，而是多出一套需要维护的脚本和报表。本文把十类常用工具放进同一条交付链路里比较，并用可复现的试用任务、维护成本和适用边界，帮助你判断先买什么、先做什么，以及什么暂时不要做。

一、先讲结论：工具要按测试任务选，不按榜单选

1. 十种工具覆盖的是不同环节

我做测试工具评估时，第一件事不是比较功能数量，而是把团队的质量活动拆成五段：需求与用例管理、接口验证、Web 自动化、移动端自动化、性能与交付反馈。下面十种工具分别覆盖其中一段或多段，它们不是十个可以互相替换的产品。

• Web 端新项目、希望快速建立端到端回归：优先试 Playwright；已有大量旧脚本或需要广泛语言生态时，把 Selenium 纳入对照。
• 前端团队主导、测试靠近组件和页面：评估 Cypress；但要先验证跨浏览器、多个标签页和复杂认证流程是否符合项目需求。
• 移动应用与真机验证：用 Appium 覆盖原生、混合或移动 Web 场景；设备矩阵较大时，再比较云端真机服务。
• 接口功能回归：先用 Postman 验证接口探索、协作和集合运行；接口规模扩大后，把检查纳入版本控制与持续集成。
• 负载与容量测试：JMeter 适合图形化组装复杂场景和多协议测试；k6 适合脚本化、代码评审和流水线执行。
• Python 项目中的测试组织：pytest 是测试框架，不是用例管理平台；适合通过代码组织单元、接口和部分端到端测试。
• 跨团队测试用例治理：TestRail 这类测试管理工具更关注计划、用例、执行记录和追溯，不负责替你运行所有自动化脚本。
• 浏览器和设备覆盖不足：BrowserStack 这类云端测试服务可以补足设备与浏览器环境，但需要核算并发、分钟数和隐私边界。

我的判断是：先找出最贵的质量瓶颈，再决定工具组合。若缺陷主要来自需求遗漏，增加浏览器自动化通常不是第一步；若构建后回归耗时太长，手工补一套更复杂的用例管理流程也未必有效。

2. 快速对比：先看定位与成本，再看功能清单

下表中的“学习成本”和“维护压力”是相对判断，不是厂商的统一统计值。它们受团队语言栈、应用架构、CI 环境和测试成熟度影响，应当通过自己的小型试点校正。

如果只能先做一个试点，我通常不选“功能最多”的工具，而选一条能在一周内走通的业务路径：从提交代码、执行测试、查看失败证据，到创建缺陷并追踪修复。链路走通，比装上十个工具更能说明投资是否值得。

二、先看真实场景：工具选择为什么会在上线后失效

1. 失败往往不是工具不够强，而是问题定义错了

在常见的交付场景中，团队会把“测试不充分”当作一个整体问题。但问题可能分别是：需求验收条件不明确、接口契约频繁变化、测试环境与生产差异太大、脚本依赖脆弱的页面结构，或失败后没人能判断是产品缺陷还是环境故障。不同原因对应的工具完全不同。

举例来说，支付页面偶发失败，若根因是测试账号余额状态不稳定，改用另一个浏览器自动化工具不会自动修复它。反过来，如果缺陷来自浏览器兼容差异，只在单一浏览器上执行更快的脚本，也无法降低真实用户风险。

2. 我会先画出“失败到反馈”的路径

试点前，我会把一次测试失败拆成五个可观察节点：触发条件、执行环境、失败证据、责任归属和修复验证。若失败后要花很久才能重现，优先补日志、截图、网络请求和环境标识；若大量失败其实是环境波动，就先解决环境稳定性，而不是扩大自动化用例数量。

这套拆解也解释了为什么用例覆盖率不能单独证明质量。覆盖率描述“测了多少”，不等同于“关键风险有没有被触达”，更不等同于“失败能不能在发布前被可靠发现”。

3. 用小试点观察维护成本，而非只看首次演示

工具演示通常展示最顺利的路径：新建项目、跑通一个用例、生成一张报告。真实项目更应该观察连续两周的变化：页面改动后脚本需要改多少，失败中有多少属于误报，新增一个场景需要多久，换一台机器是否仍能稳定执行。

下图是情景模拟，不是行业统计。假设团队有 30 条核心回归用例，分别记录首轮接入与一次页面结构变更后的工时，用来说明“能跑通”和“养得住”是两类成本。

三、常见误区：最容易买错的不是工具，而是预期

1. 误区一：用“自动化覆盖率”代替风险覆盖

把自动化用例数当作质量成果，会让团队倾向于优先覆盖容易写、容易跑的页面，而不是高风险业务路径。登录、退款、权限变更、账单计算等场景，即使数量少，也可能比几十条低风险展示页用例更值得保护。

我更愿意看三组信息：关键业务路径覆盖了多少、历史高频缺陷是否有回归保护、测试失败中有多少是可复现的产品问题。覆盖率仍然有用，但它应当是解释性指标，而不是单独的绩效目标。

2. 误区二：把所有浏览器测试都压到端到端层

端到端测试接近用户真实操作，但执行慢、依赖多，定位成本也高。输入校验、金额计算和状态转换等逻辑，往往可以在单元或接口层更快验证。若把所有断言都塞进浏览器脚本，测试套件会越来越慢，失败原因也更难判断。

更稳妥的做法是分层：低层测试覆盖大量确定性逻辑，接口测试验证服务边界，少量端到端用例保护关键跨系统旅程。层级比例没有适用于所有项目的固定数字，应该按缺陷分布、系统边界和执行时长调整。

3. 误区三：把脚本能运行误当成测试可持续

一条脚本在个人电脑上成功，不代表它适合团队持续运行。它可能依赖本地浏览器版本、未提交的密钥、固定测试数据或手工启动的服务。成熟度要看脚本能否在干净环境中重复执行，以及失败是否包含足够上下文。

4. 误区四：性能工具跑出并发数，就算完成压测

“每秒请求数”不是孤立的成绩。没有请求成功率、延迟分位数、服务端资源、错误类型和负载模型，单一并发数字几乎无法支持容量决策。一个虚拟用户持续发请求，也不一定代表真实用户的思考间隔、登录路径和数据分布。

性能测试前必须写清测试目标：验证容量上限、比较版本回归、检查长时间稳定性，还是验证突发流量恢复。目标不同，脚本模型、持续时间和通过条件都会不同。

5. 误区五：买了用例管理平台，就自然获得可追溯性

管理工具能保存用例和执行记录，却不会自动保证需求、版本、自动化结果和缺陷之间有可靠关联。如果工程师需要在多个系统重复抄写同一状态，平台可能增加行政负担。采购前要验证接口、权限、字段映射、历史数据迁移和报告导出，而不只是看用例编辑页面。

当测试过程需要经过审计、多人交接或多版本并行时，集中管理的价值会明显上升；小团队若每周只有少量变更，先用代码仓库、问题跟踪和轻量报告，也可能更经济。

四、专业判断逻辑：用六个维度做可复现的选型

1. 先给项目建立评分维度

我通常用六个维度建立候选清单。不要一开始就给工具打“总分”，先记录每项权重和证据，否则总分容易掩盖某个不可妥协的短板。

• 业务适配：能否覆盖关键应用类型、浏览器、协议和设备。
• 工程适配：是否兼容团队语言、框架、版本控制和持续集成方式。
• 可靠性：重复运行是否稳定，失败能否分类，报告是否保留证据。
• 维护成本：用例更新、环境修复和脚本重构是否需要专门人力。
• 协作与治理：权限、审计、测试数据、用例追溯和跨团队流程是否匹配。
• 总拥有成本：许可、基础设施、设备、实施、培训和维护是否都被计算。

2. 把硬门槛和加分项分开

比如，一个团队要求所有数据必须在自有网络内运行，这可能是硬门槛；报告主题颜色则只是加分项。对每个候选工具先做“可用、不可用、待验证”三态判断，再给可用候选评分，能减少因界面吸引力或销售演示造成的偏差。

候选工具的分数最好来自实际任务，而不是产品说明。用同一个仓库、同一组账号、同一条业务流程进行试点，至少记录配置时间、执行时长、失败类型和维护工时，才有横向可比性。

3. 用“质量信号到动作”的闭环检验集成

流水线里出现红灯只是信号，不是管理闭环。要问：失败是否能定位到提交或版本？是否附有日志、截图、请求记录？责任人是否明确？修复后是否能重跑相关范围？对阻断发布的规则，团队能否处理误报和临时豁免？

建议把测试失败分成产品缺陷、脚本缺陷、环境故障、数据问题四类。分类方式不需要复杂，关键是每周看比例变化。若环境故障持续占很大比例，新增用例只会放大噪声。

4. 使用成本模型，避免只比较订阅价格

工具成本至少包括许可或云端使用费、接入工程、日常维护、培训迁移、设备资源和故障排查。可以用下面这个简单公式做内部估算，所有变量都应采用团队自己的真实工时和报价。

年度总拥有成本 = 年度订阅与基础设施费用 + 初始接入工时 × 人力成本 + 年度维护工时 × 人力成本 + 培训与迁移成本。

若云端设备平台按并发、分钟数或会话量计费，必须把高峰使用和重跑成本纳入模型。一个看起来便宜的套餐，若团队在发布周频繁排队或超过用量，可能反而增加交付等待。

5. 设定停止条件，防止试点无限延长

试点要预先约定退出标准。例如，关键用例稳定运行达到某个约定周期、失败分类可解释、维护工时低于团队可承受上限、流水线反馈不超过业务容忍时间。具体阈值由项目决定，不要把本文的示意指标当作行业标准。

如果试点失败，也要区分工具不适配、团队尚未具备基础工程条件和测试设计本身不合理。三者的补救方案不同：更换工具、补基础设施，或重写风险场景，不能统统归结为“自动化不适合我们”。

五、十种工具逐一拆解：优势、限制与合适的起步方式

1. Playwright：新建 Web 自动化时优先纳入试点

Playwright 面向浏览器自动化，官方文档提供多语言支持、浏览器项目配置、自动等待、追踪和测试运行能力。它适合需要覆盖 Chromium、Firefox、WebKit 等浏览器项目，并希望在持续集成中运行端到端回归的团队。

它的优势是测试运行和调试体验较完整，减少了不少手工等待操作。但“自动等待”不代表脚本不需要稳定定位策略。若页面频繁改版、测试数据共享，或登录依赖不稳定的外部服务，仍可能出现波动。

试点建议：选择一条跨登录、查询和提交的关键旅程，加入失败截图、追踪文件和明确的测试数据清理。先跑 10 至 20 条高价值用例，再看失败归因和维护工时，不要先追求几百条脚本。

2. Selenium：已有生态和兼容需求的重要选项

Selenium 是成熟的浏览器自动化生态，适合已有 WebDriver 脚本、需要多语言或已有测试基础设施的团队。它并不因为历史较长就自动过时；对有经验的团队来说，现有封装、插件和运行经验可能比迁移到新框架更有价值。

新项目需要重点验证等待、驱动管理、并行执行和报告约定。若这些能力没有统一封装，不同工程师可能写出风格差异很大的脚本，后续维护成本会逐渐显现。

试点建议：把旧脚本迁移成本与新框架接入成本放在同一张表里。对既有项目，不要只比较新工具的首次运行速度，还要计算重写、培训、历史用例迁移和并行运行期间的双重维护。

3. Cypress：适合前端开发参与测试的团队

Cypress 的优势之一是调试流程与 Web 开发工作紧密，前端工程师可以更容易参与测试编写和失败排查。若团队使用现代前端技术栈、希望把测试反馈靠近开发过程，可以纳入对比。

选型时要检查项目是否依赖特殊浏览器能力、多标签页交互、复杂身份验证或特定跨站场景。工具边界可能随版本变化，最终应以当前版本官方文档和实际验证为准，不能只凭旧文章的限制清单做结论。

试点建议：挑出项目中最复杂的两类页面，不要只测最简单的表单；确认测试运行、浏览器覆盖和 CI 结果都符合实际发布流程。

4. Appium：移动自动化的框架选择，不是设备策略

Appium 用于移动应用自动化，能够支持多种移动应用测试场景。它解决的是自动化控制和测试执行问题，并不会自动替团队管理手机库存、系统版本、账号状态或设备兼容矩阵。

移动自动化最常见的隐性成本来自环境：模拟器和真机行为不同，系统升级可能影响权限弹窗，网络和定位状态也会左右测试结果。若设备准备流程不稳定，脚本框架再好也会产生噪声。

试点建议：先挑选少量代表性设备与系统版本，建立安装、重置、权限和日志收集规范。之后再决定扩展到本地设备农场或云端真机服务。

5. Postman：接口探索和集合回归的实用入口

Postman 适合接口调试、请求组织、环境配置和集合执行。测试人员可以快速验证请求参数、认证方式和响应断言，尤其适合接口仍在快速演进、团队需要共同探索契约的阶段。

接口集合一旦变成关键回归资产，就要管理环境变量、密钥、测试数据和脚本复用。不要把敏感令牌写进集合，也不要把依赖顺序复杂、缺少说明的请求集合当作长期测试架构。

试点建议：选一组有明确前置条件和清理逻辑的接口流程，验证它能否在团队约定的自动化环境运行，并记录失败时如何区分接口错误、认证错误和数据状态错误。

6. JMeter：可视化场景与协议负载测试的成熟选择

Apache JMeter 适用于负载测试和多种协议场景，拥有较长时间的应用经验。对于偏好图形化组织测试计划、需要检查请求链路或维护既有测试计划的团队，它仍然是值得评估的工具。

性能测试时，执行端资源可能成为瓶颈。若压测机自身已经饱和，测试结果就无法代表目标服务容量。团队需要监控压测机 CPU、内存、网络和目标服务指标，并在必要时使用分布式执行。

试点建议：先固定负载模型和数据集，验证执行端不会先达到瓶颈；报告中同时保留吞吐、错误率、延迟分位数和服务端资源，不要只截取一个峰值数字。

7. k6：代码化性能测试与 CI 的合适候选

k6 适合以代码编写负载场景，并把性能验证纳入工程工作流。对熟悉脚本、版本控制和持续集成的团队来说，它方便审查场景变更，也更容易把性能门槛与提交或发布过程关联。

代码化的另一面是需要有人维护负载模型和指标阈值。若团队没有定义业务流量、数据分布和服务目标，脚本再整洁也只是制造了更可重复的错误假设。

试点建议：把一个实际用户旅程转换为负载场景，明确并发模型、思考时间、持续时长及通过条件。先建立基线，再比较版本差异，不要把临时压测结果直接当成容量承诺。

8. pytest：Python 项目的测试组织骨架

pytest 是 Python 测试框架，适合编写和组织自动化测试，并通过插件扩展运行能力。它可以用于单元、接口或集成测试，但它不是完整的测试用例管理平台，也不会自动提供所有应用类型的控制能力。

团队要关注夹具设计、测试隔离、并行执行、失败信息和插件依赖。如果测试之间共享状态，重跑时容易互相影响；如果夹具抽象过度，新成员可能难以理解用例真正验证了什么。

试点建议：先为一个明确的服务模块建立可独立运行的测试目录，统一数据准备和清理方式，再决定是否接入更完整的报告与管理系统。

9. TestRail：当测试执行需要治理时再引入

TestRail 主要解决测试计划、用例组织、执行结果和报告追踪问题。它适合测试活动跨多人、多版本或需要可审计记录的团队。它不等于自动化框架，实际价值取决于与缺陷系统、自动化结果和发布流程的集成质量。

试用时应把日常动作走一遍：需求关联、用例评审、执行分配、失败转缺陷、版本报告和历史查询。若测试人员必须在多个地方重复录入，平台可能提高数据完整性，却降低执行效率。

试点建议：选一个发布周期做小范围治理，测量创建与更新用例的时间、结果录入耗时、重复数据比例和追溯成功率。只有这些指标改善，平台才真正减少流程摩擦。

10. BrowserStack：购买覆盖能力，而不是购买质量保证

BrowserStack 提供云端浏览器和设备测试能力，可帮助团队减少本地设备维护，并扩大环境覆盖。它特别适合需要验证多浏览器、系统版本或真机行为，但内部设备资源不足的团队。

云端环境不能消除兼容性测试设计，也不意味着每条测试都要跑完全部设备组合。组合数量可能迅速膨胀，应该根据用户占比、业务风险、历史缺陷和发布范围选择代表性矩阵。

试点建议：先抽取最有业务价值的设备组合，比较云端排队时间、会话稳定性、日志完整度、并发限制和费用。对敏感数据，还要检查数据处理、访问控制和组织的合规要求。

六、案例与数据观察：一条购物流程如何决定工具组合

1. 场景设定：购物车到支付确认

假设一个中型电商团队每两周发布一次，核心路径是登录、搜索商品、加入购物车、结算和支付确认。团队目前有人工回归清单，接口测试零散，Web 自动化只覆盖登录。以下是用于说明决策方法的情景模拟，不是某家企业的生产数据。

我们先把风险拆为三层：商品价格和库存规则属于服务逻辑，接口输入与响应属于服务边界，用户从购物车到支付确认的完整旅程属于跨系统流程。这样的拆分避免把所有测试都放到浏览器端执行。

2. 先按风险分层，再分配工具

• 单元与服务层：使用项目现有语言的测试框架验证金额计算、优惠规则和库存状态转换。
• 接口层：用 Postman 或代码化接口测试验证下单、库存扣减、支付回调等关键边界。
• Web 端到端：用 Playwright、Selenium 或 Cypress 试点关键旅程，不对所有页面重复做相同层级验证。
• 性能层：根据流量目标，使用 JMeter 或 k6 生成明确的下单和查询负载，并观察服务端指标。
• 环境覆盖：对高风险浏览器和设备组合使用本地或云端测试环境，减少无差别全量排列。

3. 模拟观察：回归时间下降，不代表质量自动提升

假设团队先选出 24 条关键用例，其中 8 条用于接口层、10 条用于 Web 核心旅程、6 条保留人工探索。试点四周后，人工执行耗时从每轮 18 小时降至 9 小时，自动化维护平均每周增加 3 小时。这里的数字是演示计算方式的情景样本，项目决策必须用团队自己的工时记录替换。

如果自动化让每轮回归节省 9 小时，四周运行四次，粗略节省 36 小时；若四周维护共消耗 12 小时，净节省约 24 小时。这个计算尚未计入初始化投入、误报排查和环境维护，因此只能用于判断试点方向，不能直接作为年度收益结论。

4. 不只看节省，还要看失败是否变得更可解释

试点需要记录自动化失败原因，而不是只记录通过率。假设 40 次失败中，18 次来自测试数据冲突、10 次来自环境波动、8 次是脚本定位失效、4 次才是产品缺陷；那么下一步重点应该是数据隔离、环境稳定性和定位策略，而不是简单扩大用例数量。

以上分类数字同样是示意数据。它展示的是一种重要的管理原则：自动化的价值不仅是减少人工执行，也包括把不确定的失败转成可归因、可处理的质量信号。

七、按团队现状行动：不同起点对应不同的第一步

1. 小团队或刚开始建立测试流程

若团队人数少、产品仍快速变化，先避免引入过多治理工具。建立清晰的缺陷记录、接口检查和关键路径回归，再用轻量框架把重复度高、稳定性高的场景自动化。不要为了“看起来成熟”一次采购多套平台。

建议两周内完成一次小试点：选 5 至 10 条关键用例，建立可重复的测试环境，记录手工执行耗时与自动化维护耗时。若维护明显超过节省，先检查测试设计和页面稳定性，而不是马上换框架。

2. 已有大量手工回归的 Web 团队

先分析过去几个发布周期中最常见的回归缺陷和最耗时的手工步骤。把自动化优先级给到“高频执行、结果明确、数据可控、失败影响大”的场景。选择 Playwright、Selenium 或 Cypress 时，至少用同一条复杂业务路径做并行试验。

试点结果建议同时报告执行时长、误报比例、变更维护工时和缺陷拦截情况。只报告测试数量，很容易把可维护性问题延后到脚本规模扩大以后才暴露。

3. 移动应用和设备覆盖不足的团队

先根据真实用户分布和历史缺陷建立设备矩阵，而不是从设备型号清单开始。选择少量高价值机型，明确每类设备要验证的操作系统版本、网络条件和关键业务路径，再比较 Appium 本地执行与云端设备服务。

当设备管理本身占用了大量工程时间，云端服务可能值得尝试；如果敏感数据、特殊硬件或内部网络限制较强，本地设备方案可能更合适。两种方式并非互斥，关键是计算维护成本和覆盖收益。

4. 有明确容量目标或发布性能门槛的团队

先让产品、开发和运维共同确定目标指标，例如关键接口的延迟分位数、错误率和预期负载区间，再决定用 JMeter 还是 k6。若测试计划依赖复杂的可视化编排，可优先比较 JMeter；若团队强调代码评审和持续集成，可优先评估 k6。

不要在生产环境未经评估地发起高负载测试。先校验测试数据、压测端能力、流量边界和停止条件，并确保相关服务负责人知道测试窗口。

5. 测试活动需要审计或跨团队追溯的组织

当团队需要证明某个版本执行过哪些测试、谁批准了豁免、哪些失败转成缺陷时，测试管理工具的价值会增加。企业规模越大，权限、组织结构、数据保留、单点登录、集成和迁移往往越重要。

试用 TestRail 这类工具时，最好选一个完整发布周期，核算用例维护、执行录入和报告整理的时间是否下降。平台若只增加填写动作，却没有减少重复沟通或追溯成本，流程就需要重新设计。

6. 选型执行清单

1. 写下最希望解决的三个质量问题，并用最近几个发布周期的数据排序。
2. 确认项目技术栈、应用类型、部署方式、合规约束和必须覆盖的环境。
3. 挑选两到三个候选工具，使用同一业务任务和同一数据条件进行试点。
4. 记录接入、执行、排查、维护和培训工时，并分类统计失败原因。
5. 设定明确的扩面、继续观察或停止条件，避免试点变成没有期限的探索。
6. 确认数据安全、权限、日志保留、导出能力和供应商支持边界。

八、取舍与结论：先买反馈速度，再买覆盖广度

1. 什么时候选开源方案，什么时候考虑商业服务

开源工具通常给团队更多部署和扩展自由，但相应地需要承担维护、集成、升级和问题排查。商业服务可能减少部分基础设施负担，并提供设备环境或协作能力，但需要评估持续费用、数据边界、可迁移性和服务依赖。

如果团队具备工程能力、测试需求明确且环境可控，开源框架往往是合理起点。如果团队主要瓶颈是设备供给、协作审计或运行环境维护，商业服务可能更节省时间。不要把开源等同于零成本，也不要把付费等同于省心。

2. 什么时候应当暂缓自动化

如果业务流程每周都在改变、验收规则没有达成一致、测试环境经常重置失败，或者关键测试数据无法隔离，先暂停大规模脚本投入。此时更有价值的工作可能是补充验收条件、稳定环境、设计数据工厂或完善日志。

暂缓不等于拒绝自动化，而是先补齐自动化成立的条件。等关键流程趋稳后，再从重复性高、判定明确、人工成本高的场景开始，成功率会更高。

3. 我的最终建议：把工具当成反馈系统的一部分

十种工具没有统一冠军。Playwright、Selenium 和 Cypress 解决浏览器自动化问题；Appium 面向移动应用；Postman 面向接口验证；JMeter 与 k6 面向性能测试；pytest 帮助组织 Python 测试；TestRail 管理测试活动；BrowserStack 扩展云端环境覆盖。把它们放在自己的任务链路中比较，才有意义。

更值得长期投资的不是工具数量，而是失败反馈是否更快、更可信、更容易行动。工具能否帮助团队定位问题、复现失败、追踪修复，并判断是否达到发布条件，决定了它的实际价值。

下一步可以从最近一次发布复盘开始：列出最耗时的回归步骤、最常见的缺陷类型和最难重现的失败，再挑一条高风险路径做小范围试点。用真实工时、真实失败和真实维护记录替代宣传页上的功能清单，你会更容易选出真正适合团队的工具组合。

4. 参考资料与数据边界

本文的工具定位依据各项目或服务公开文档中的主要用途，包括 Playwright、Selenium、Cypress、Appium、Postman、Apache JMeter、Grafana k6、pytest、TestRail 与 BrowserStack 的官方文档。具体功能、版本、价格、部署方式和套餐限制可能变化，采购或技术决策前应以对应官方资料及试用结果复核。

文中的工时、失败类型和案例数据均已标注为情景模拟或示意数据，不代表行业平均值，也不构成工具性能保证。团队落地时应使用自己的流水线记录、缺陷数据、设备覆盖情况和工时统计建立基线。