当前位置： 首页 > news >正文

鸿蒙应用测试实战指南：从单元测试到UI自动化的全链路覆盖

news 2026/8/16 7:12:28

1. 从“能用”到“好用”：鸿蒙应用测试的独特挑战与价值

最近和几个做鸿蒙应用开发的朋友聊天，发现一个挺普遍的现象：大家花了不少心思把功能做出来，UI也调得挺漂亮，但一到测试环节，就有点“抓瞎”。要么是沿用安卓那套老办法，发现有些API不兼容；要么是面对方舟框架、原子化服务这些新特性，不知道从何测起。最后往往就是开发者自己拿着手机点点点，感觉“差不多能用”就发布了。这让我想起早些年安卓开发初期，大家也是这么过来的，但鸿蒙的野心显然不止于做一个“能用”的系统，它对流畅、安全、跨端协同的要求更高，这就意味着对应用质量的要求也上了一个台阶。

所以，今天我们不聊高深的开发理论，就聚焦一个最实际的问题：鸿蒙应用到底该怎么测？这绝不仅仅是找几个Bug那么简单。它关乎用户体验的流畅度、不同设备间的兼容性、原子化服务能否被精准触发、跨端流转是否丝滑，以及应用在系统严格的隐私和安全规范下能否站稳脚跟。一个未经充分测试的应用，在鸿蒙生态里很容易“露怯”，轻则卡顿闪退，重则因合规问题被下架。

基于这个核心痛点，我结合自己这段时间的摸索和实战，整理了一套从工具选型到实操心得的鸿蒙应用测试指南。它不是某个官方文档的复述，而是我踩过坑、验证过有效的方法集合。我会重点介绍几个关键工具包和它们组合使用的场景，目标是让你看完之后，能立刻着手搭建起一个高效、覆盖核心场景的测试流程，让你开发的应用真正配得上“鸿蒙原生”这四个字。

2. 测试环境基石：DevEco Studio与真机/模拟器的深度配置

工欲善其事，必先利其器。测试鸿蒙应用，第一步不是找测试工具，而是把测试环境搭稳。这里最大的两个依赖就是开发工具DevEco Studio和测试载体（真机/模拟器）。很多初级问题都出在环境配置上。

2.1 DevEco Studio：不止是开发IDE，更是测试入口

很多人把DevEco Studio仅仅当作写代码的编辑器，其实它集成了非常强大的测试支持。首先，确保你安装的是较新的版本（例如4.1或以上），因为鸿蒙SDK和工具链更新很快。

项目工程结构中的测试目录：创建一个标准的HarmonyOS应用工程后，你会在entry/src/main的同级目录下发现ohosTest目录。这就是单元测试的“家”。它的结构和main类似，有ets（测试代码）、resources（测试资源）等。我建议在项目初期就建立好对应的测试目录，哪怕先写几个简单的用例，这有助于养成测试驱动开发（TDD）的习惯，而不是事后补窟窿。

关键配置：SDK与HarmonyOS版本对齐。这是最容易出问题的地方。在File > Settings > SDKs里，检查你安装的HarmonyOS SDK版本是否与项目build-profile.json5中compileSdkVersion和compatibleSdkVersion指定的版本一致。不一致会导致模拟器无法启动或API调用失败。我的经验是，将SDK版本固定为与目标用户主流系统版本一致，比如目前可以锁定在API 9（HarmonyOS 4.0）。同时，在Tools > Device Manager中下载对应版本的模拟器镜像。

2.2 真机调试与远程模拟器：如何选择与避坑

测试载体首选真机，因为能反映最真实的性能、触控和传感器表现。通过USB连接鸿蒙手机（需在手机的“开发者选项”中打开“USB调试”），DevEco Studio可以自动识别。但这里有个大坑：有时设备列表里就是刷不出来手机。别急着重装驱动，按这个顺序排查：

  1. 检查USB线是否支持数据传输（有些线只能充电）。
  2. 在手机弹出的USB连接方式中，选择“传输文件”或“HiSuite”模式，而不是“仅充电”。
  3. 在开发者选项里，尝试关闭再打开“USB调试”，或者撤销USB调试授权后重新连接。
  4. 终极方案：重启ADB服务。在DevEco Studio的终端里输入adb kill-server然后adb start-server。

当没有真机时，远程模拟器是很好的替代。华为提供了云端模拟器资源，在Device Manager里选择Remote Emulator。它的优势是不消耗本地性能，且能模拟手机、平板、车机等多种设备形态。但缺点也很明显：网络依赖强，且启动和运行速度受云端负载影响。我经常遇到“Deveco Studio 鸿蒙模拟器一直在加载进不去”的情况。此时，可以：

  • 检查网络，特别是代理设置，有时需要配置DevEco Studio的HTTP Proxy。
  • 尝试切换不同的远程机房节点。
  • 如果进行的是UI自动化测试，网络延迟可能会导致脚本执行不稳定，这点要有心理预期。

对于需要测试跨端流转的场景，我强烈建议准备至少两台不同形态的鸿蒙真机（如手机和平板），模拟器的流转测试目前还不够完善。

3. 核心测试工具包详解：从单元到UI的全链路覆盖

环境准备好了，我们进入正题：工具包。鸿蒙的测试工具链可以粗略分为四个层次：单元测试、UI自动化测试、专项测试和云测平台。下面我结合具体工具和实战命令，拆解每个环节。

3.1 单元与集成测试：Hypium测试框架的精髓

鸿蒙官方推荐的单元测试框架是Hypium。它集成在SDK中，语法风格类似于JUnit，学习成本很低。但关键在于理解在鸿蒙的上下文（Ability、ExtensionAbility、UI组件）里怎么用。

基础单元测试示例：假设你有一个工具类Calculator.ets，里面有add(a: number, b: number): number方法。在ohosTest/ets/test/Calculator.test.ets中，你会这样写：

import { describe, it, expect } from '@ohos/hypium'; // 引入Hypium import Calculator from '../../main/ets/utils/Calculator'; // 引入被测模块 describe('CalculatorTest', () => { // 测试套件 it('test_add_positive_numbers', () => { // 测试用例 const result = Calculator.add(2, 3); expect(result).assertEqual(5); // 断言 }); it('test_add_with_negative_number', () => { const result = Calculator.add(-1, 5); expect(result).assertEqual(4); }); });

在DevEco Studio中，右键点击这个测试文件，选择Run ‘Calculator.test.ets’即可执行。关键点：测试文件必须放在ohosTest目录下，且命名以.test.ets结尾，框架才能自动识别。

测试UI组件与Ability：这才是Hypium的威力所在。你可以启动一个UIAbility，获取其上下文，然后对页面组件进行查找和断言。

import { describe, it, expect, TestRunner } from '@ohos/hypium'; import AbilityDelegatorRegistry from '@ohos.app.ability.abilityDelegatorRegistry'; import Want from '@ohos.app.ability.Want'; import { Driver, ON } from '@ohos.UiTest'; const delegator = AbilityDelegatorRegistry.getAbilityDelegator(); const want: Want = { bundleName: 'com.example.myapp', abilityName: 'EntryAbility' }; describe('EntryAbilityTest', () => { it('launch_ability_and_check_ui', async () => { // 注意是异步函数 await delegator.startAbility(want); // 启动Ability const driver = await Driver.create(); // 创建UiTest驱动 const button = await driver.findComponent(ON.text('点击我')); // 查找组件 expect(await button.isClickable()).assertTrue(); // 断言组件可点击 }); });

注意：UI测试需要@ohos.UiTest模块，并且需要在项目的module.json5中为测试模块申请ohos.permission.SYSTEM_FLOAT_WINDOW悬浮窗权限，否则UiTest驱动无法正常工作。这是第一个容易忽略的配置坑。

3.2 UI自动化测试利器：UiTest与Appium的抉择

对于更复杂的端到端（E2E）场景，我们需要UI自动化测试。这里有两个主要选择：官方的UiTest和更通用的Appium。

UiTest是鸿蒙原生框架，与系统深度集成，执行效率高，对鸿蒙特有组件（如原子化服务卡片）支持更好。它的API设计是针对鸿蒙的，上面Hypium的例子中已经展示了其驱动（Driver）的基本用法。它的脚本可以用TypeScript编写，与开发语言同源，对开发者友好。但它目前生态相对年轻，社区资料和现成的封装库较少。

Appium是跨平台的移动端自动化测试“老大哥”，理论上也支持鸿蒙。其优势是生态成熟，有丰富的客户端库（Python、Java、JavaScript等）和庞大的社区支持。但正因为它通过标准WebDriver协议工作，对鸿蒙一些新特性的支持可能滞后，且依赖鸿蒙设备开启“开发者选项”中的“USB调试”，本质上是通过ADB与设备通信。

如何选择？

  • 如果你的团队技术栈偏前端/鸿蒙原生，测试用例需要深度操作鸿蒙特有组件，追求执行速度和稳定性，首选UiTest。
  • 如果你的团队已有成熟的Appium测试框架和用例（比如从安卓迁移过来），或者测试人员更熟悉Python/Java，希望一套脚本跨平台（需处理大量兼容逻辑），可以尝试Appium。但目前需要关注其鸿蒙引擎的完善度，可能遇到一些控件无法识别的问题。

一个UiTest的实战场景：测试登录流程

import { Driver, ON, Component, MatchPattern } from '@ohos.UiTest'; async function testLogin() { const driver = await Driver.create(); // 1. 定位账号输入框并输入 const usernameInput = await driver.findComponent(ON.id('username_input')); await usernameInput.inputText('testUser'); // 2. 定位密码输入框并输入 const passwordInput = await driver.findComponent(ON.id('password_input')); await passwordInput.inputText('123456'); // 3. 定位登录按钮并点击 const loginButton = await driver.findComponent(ON.text('登录')); await loginButton.click(); // 4. 等待并验证登录成功后的页面元素 await driver.delay(2000); // 等待网络请求 const welcomeText = await driver.findComponent(ON.textContains('欢迎')); const isDisplayed = await welcomeText.isDisplayed(); // 使用Hypium的expect进行断言（需在Hypium测试套件中） // expect(isDisplayed).assertTrue(); }

这个例子展示了查找组件（通过ID、文本）、操作组件（输入、点击）和等待的基本模式。关键技巧：对于动态加载的列表或网络请求后的界面变化，一定要使用driver.delay()或更优的waitForComponent()方法进行等待，避免脚本因元素未加载而失败。

3.3 专项测试工具：性能、安全与兼容性

功能跑通了，但应用卡顿、耗电、不安全怎么办？这就需要专项测试工具。

性能测试：DevEco Studio自带的Profiler工具是首选。它可以实时监控CPU、内存、帧率、功耗和网络。测试时，你需要用Profiler连接到运行中的应用（真机或模拟器），然后重复执行核心用户路径（如页面频繁跳转、列表快速滑动、大图加载）。重点关注：

  • 内存泄漏：在反复进入退出某个页面后，观察Java/ArkTS堆内存是否持续增长不回落。可以使用Profiler的堆转储（Heap Dump）功能分析对象引用链。
  • UI丢帧（Jank）：帧率曲线是否平滑，有无频繁掉到60帧以下（对于60Hz屏幕）的情况。卡顿通常与主线程耗时操作（同步IO、复杂计算）有关。
  • 功耗：进行长时间（如30分钟）的背景播放或定时任务测试，观察电流曲线。后台频繁唤醒或使用高功耗传感器（如GPS）是耗电大户。

安全测试：鸿蒙应用上架华为应用市场需要通过安全检测。你可以提前使用华为提供的安全检测服务（线上）或AppScan工具（本地）进行扫描，检查常见的代码漏洞、数据存储安全、权限滥用等问题。例如，检查是否在本地明文存储用户密码、是否过度申请权限、WebView组件是否存在任意URL加载风险等。

兼容性测试：这是鸿蒙测试的重中之重，因为设备形态太丰富了。除了用不同分辨率的手机模拟器，还要关注：

  • 平行视界：平板应用是否适配了平行视界模式，左右窗口显示和交互是否正常。
  • 折叠屏：应用在折叠屏展开/折叠时，布局是否自适应，状态是否保持。
  • 不同API版本：确保应用在compileSdkVersion和更低版本的compatibleSdkVersion上都能正常运行。实操建议：在项目的hvigorfile.ts中配置多目标构建，一次性打出针对不同SDK版本的多个HAP包，分别测试。

3.4 云端测试平台：华为云测（CloudTest）

当你需要覆盖海量真机设备、进行长时间稳定性测试（Monkey测试）或自动化测试脚本的定时任务执行时，本地资源就不够用了。华为云测（CloudTest）平台提供了解决方案。

你可以将打包好的HAP文件上传到云测平台，选择上百款不同的华为真机（涵盖不同型号、系统版本）进行安装、启动、Monkey、性能采集等测试。它还能集成你编写的UiTest脚本，进行批量自动化执行。这对于确保应用在发布前拥有广泛的兼容性至关重要，特别是你个人无法购买所有测试设备的情况下。

使用云测的关键是编写良好的测试脚本和分析测试报告。平台会提供详细的日志、截图、性能数据和崩溃信息。你需要学会从这些报告中快速定位问题，比如某个特定机型上的崩溃堆栈。

4. 构建自动化测试流水线：从脚本到报告

工具是散落的珍珠，我们需要用一条线把它们串起来，形成持续反馈的闭环。这条线就是CI/CD流水线。

4.1 本地自动化脚本串联

在接入CI之前，先在本地实现一键执行所有测试。可以编写一个package.json脚本或一个Shell脚本（test.sh）：

#!/bin/bash # test.sh echo “开始单元测试...” npm run test:unit # 假设你在package.json中配置了该命令运行Hypium测试 echo “开始UI自动化测试...” # 这里可能需要先启动模拟器或连接真机 # 例如通过ADB安装测试HAP，然后使用hdc命令执行测试套件 # hdc shell aa test -b com.example.myapp -m unittest -s class com.example.MyTestSuite echo “生成测试报告...” # 合并JUnit格式的测试结果，用工具生成HTML报告

关键点：确保你的测试脚本是幂等的，即每次执行前都清理旧数据（如卸载旧应用），从一个干净的状态开始，保证测试结果的一致性。

4.2 集成到CI/CD（以Jenkins为例）

在Jenkins上创建一个流水线任务，核心步骤包括：

  1. 代码拉取与编译：从Git拉取代码，运行npm install和hvigorw assemble编译出HAP包和测试HAP包。
  2. 静态代码检查：集成ESLint、ArkTS语言规范检查等。
  3. 部署到测试环境：通过ADB将应用安装到连接好的鸿蒙测试机（或启动模拟器）。这里可以使用Jenkins的Android Emulator Plugin来管理模拟器生命周期。
  4. 执行测试套件：调用上一步写好的自动化脚本，执行单元测试和UI自动化测试。
  5. 收集测试结果：将Hypium生成的XML格式测试结果收集起来。
  6. 生成与归档报告：使用插件（如JUnit Plugin）解析XML，在Jenkins界面生成趋势图。同时，可以将HTML报告、性能Profiler截图等归档。
  7. 清理环境：卸载应用，关闭模拟器。

一个常见的坑是环境隔离。如果多个Jenkins job同时运行，可能会争抢同一台物理设备或模拟器端口。解决方案是使用设备池管理，或者为每个job分配独立的模拟器实例。

4.3 测试报告的艺术：不只是通过/失败

原始的测试通过率数字价值有限。一份好的测试报告应该包含：

  • 分模块/分特性的通过率：一眼看出哪个模块最不稳定。
  • 失败用例的详细日志和截图：UiTest失败时，必须自动截取当前屏幕，这能极大提升排查效率。Hypium和UiTest都支持在断言失败时自动截图。
  • 性能基线对比：将本次测试的关键性能指标（启动时间、内存占用、FPS）与历史基线或标准值对比，用图表展示变化趋势，一旦出现退化立即告警。
  • 测试执行录像：对于复杂的UI交互测试，录下执行过程的视频，回放时能直观看到问题发生时的上下文。

你可以利用开源工具（如Allure报告框架）来聚合这些数据，生成非常直观的测试报告。

5. 高阶场景与疑难杂症排查

掌握了基本流程，我们来看几个更复杂或更容易出错的场景。

5.1 测试原子化服务与卡片（Atomic Service & Card）

原子化服务是鸿蒙的特色，无需安装即可使用。测试它主要关注两点：服务发现与拉起、卡片（Form）的显示与更新。

  • 服务拉起测试：可以使用系统的want机制来触发。在测试代码中，构造一个符合服务约定的Want对象，然后通过abilityDelegator.startAbility()尝试拉起。你需要验证是否能成功拉起，以及拉起的界面是否正确。
  • 卡片测试：卡片是一个独立的UI单元。测试时，你需要先通过formHost接口获取卡片实例，然后验证：
    1. 静态布局：卡片的尺寸、组件位置是否符合设计。
    2. 动态更新：模拟卡片提供方（Provider）更新数据，观察卡片UI是否按预期刷新。这里涉及跨进程通信，测试时要注意模拟网络请求和数据回调。
    3. 卡片事件：测试点击卡片上的按钮等交互，是否能正确跳转到目标页面或执行动作。

由于卡片运行在系统桌面进程，直接使用UiTest驱动可能无法直接定位到卡片内部组件。一种可行的方案是，在卡片提供的UI测试模式下，暴露一些可访问的组件ID供测试代码使用。

5.2 跨端流转测试

这是鸿蒙分布式能力的核心体验。测试跨端流转，关键在于模拟完整的流转链路和控制时序。

  1. 搭建环境：至少需要两台在同一局域网下的鸿蒙设备，并登录同一华为账号，开启蓝牙和Wi-Fi。
  2. 触发流转：在一台设备（A）上运行应用，找到支持流转的UI元素（如视频播放页面的流转按钮）。使用UiTest脚本自动点击该按钮。
  3. 设备选择与连接：系统会弹出设备选择框。自动化测试的难点就在这里——如何自动选择目标设备（B）。目前系统UI的自动化支持可能有限。一种折中方案是，在测试模式下，通过ADB或系统API，预设流转目标设备。
  4. 验证结果：在设备B上，验证应用是否被自动拉起并处于正确的状态（如视频继续播放）。需要验证数据（如播放进度、登录状态）是否同步正确。
  5. 反向流转：再从设备B流转回设备A，验证状态连续性。

这个测试场景非常复杂，且对网络环境敏感。在自动化流水线中，可能更适合将其作为半自动化的验收测试用例，由测试人员在特定环境下手动执行核心场景，而自动化重点覆盖单设备内的功能。

5.3 常见疑难问题排查清单

  • 问题：UiTest脚本在真机上运行失败，提示“找不到组件”或“权限错误”。

    • 排查：首先确认测试HAP包已成功安装。其次，检查测试应用是否申请了必要的权限（特别是SYSTEM_FLOAT_WINDOW）。最后，使用driver.findComponent(ON)时，尝试使用更宽松的匹配条件，如ON.textContains()或ON.id()，并确保组件在当前屏幕可见。

  • 问题：Hypium单元测试通过，但UI自动化测试时应用崩溃。

    • 排查：这通常是异步操作或状态残留导致。检查UI测试脚本中是否有足够的等待（delay或waitForComponent）。确保每个测试用例都是独立的，在beforeEach或afterEach钩子中重置应用状态（如清理数据库、重置偏好设置）。

  • 问题：在远程模拟器上运行测试极不稳定，时好时坏。

    • 排查：这基本是网络问题。将远程模拟器测试安排在网络低峰期进行。对于稳定性要求高的回归测试，尽量使用本地模拟器或真机。考虑将测试用例分层，不稳定的长流程用例放到手动测试或真机集群中执行。

  • 问题：应用在平行视界模式下布局错乱。

    • 排查：检查页面布局是否使用了响应式设计，如媒体查询、栅格系统、以及鸿蒙提供的[AdaptiveBoxContainer](https://developer.harmonyos.com/cn/docs/documentation/doc-references-V3/ts-container-adaptiveboxcontainer-0000001478181445-V3)组件。测试时，需要在平板上手动或通过脚本切换平行视界模式，验证左右窗口的布局逻辑是否正确。

6. 测试策略规划与团队实践建议

最后，我想分享一些超越具体工具和技术的策略性思考。测试不是开发完成后的一道工序，而应贯穿整个生命周期。

1. 测试金字塔在鸿蒙的实践：基础是大量的单元测试（Hypium），覆盖工具类、业务逻辑；中间是集成测试，测试Ability、Service间的交互；顶层是少量的、核心的UI自动化测试（UiTest），覆盖关键用户路径。不要本末倒置，试图用脆弱的UI自动化覆盖所有场景。

2. 特性测试清单：为每个新特性建立一份测试检查清单。例如，开发一个“文件上传”特性，清单应包括：

  • 功能：选择文件、上传、进度显示、成功/失败回调。
  • UI：不同文件大小的提示、网络中断的UI状态。
  • 兼容性：不同文件类型（图片、文档）、不同系统版本。
  • 性能：大文件上传时的内存占用、是否阻塞主线程。
  • 安全：上传接口是否加密、是否有文件类型和大小限制。

3. 团队协作：鼓励开发人员编写单元测试，并作为代码合并的门禁。测试人员专注于UI自动化、专项测试和探索性测试。利用云测平台让产品经理或设计师也能参与兼容性测试的验收。

4. 持续学习：鸿蒙生态发展迅速，新的测试工具和最佳实践会不断出现。定期关注华为开发者联盟的官方文档、论坛和测试技术相关的线上研讨会。

测试鸿蒙应用，是一个从“功能实现”到“体验卓越”的进阶过程。它要求我们不仅理解新的技术框架，更要以终为始，从用户视角和系统规范出发，去验证每一个细节。这套工具包和方法论，是我从无数个调试的夜晚和踩过的坑里总结出来的，希望能为你点亮一盏灯，让你在打造高质量鸿蒙应用的道路上，走得更稳、更快。

http://www.jsqmd.com/news/1403153/

相关文章：

  • Cursor 赋能 RPA 机器人开发：大模型接口调用 + OCR 非结构化数据完整源码实战
  • 泉州 2026 瓷砖空鼓精选靠谱商家推荐：阳台墙砖松动加固维修 - 屋工匠
  • 上海闵行区漏水维修避坑全攻略千万别上当_卫生间漏水区域防水乱象解析，家庭维修避坑参考资料 - 雨婺虹修缮
  • IDEA导入Java Web项目全解析：Maven/Gradle、传统项目与正确打开方式
  • 沈阳壁挂炉维修｜过保故障专业处理｜各区驻点师傅快速上门｜欧米到家持证规范服务
  • 2026年RFID资产管理系统选型分析：主流厂商功能与适用场景对比
  • 长春 2026 瓷砖空鼓精选靠谱商家推荐：阳台墙砖松动加固维修 - 屋工匠
  • 论文低分元凶找到了[特殊字符]Paperxie科研绘图｜5分钟搞定学术高清插图
  • LangChain 与 LangGraph 混合使用实战：优劣势互补与企业级架构落地指南
  • Typora高效高亮与标红文字：自定义CSS与快捷键配置全攻略
  • Windows共享打印机设置与排错全攻略：从原理到实战解决0x00000709等错误
  • python处理csv文件
  • 哈尔滨市防水补漏维修有哪些坑要注意避免_厨卫漏水治理行业陷阱梳理，本市家庭维修参考指南 - 雨婺虹修缮
  • 从零开始的C语言学习：第2节 C语言的常见概念 2
  • 湛江 2026 瓷砖空鼓精选靠谱商家推荐：全屋瓷砖空鼓检测治理 - 屋工匠
  • AI漫剧生成中的角色与场景一致性控制——知漫剧的“全局锁定”机制测评
  • Windows打印机连接错误0x000003e3：RPC服务器不可用的系统化排查与修复指南
  • 徐州 2026 瓷砖空鼓精选靠谱商家推荐：老房墙砖脱落修缮处理 - 屋工匠
  • 电路分析与模拟电路实验箱
  • 宇树上市背后：具身智能技术栈与机器人商业化路径深度解析
  • 益阳市房屋漏水维修怎么防被坑不被套路_卫生间漏水本地业主踩坑实录与避坑重点梳理 - 雨婺虹修缮
  • 程序员为什么越来越离不开 AI？从代码调试到项目开发，真正拉开差距的是使用方式
  • Keil4与Keil5共存方案：解决嵌入式开发环境冲突的完整指南
  • SolidWorks钣金通风口命令实战：参数化风扇罩设计与工程图输出
  • 拉孚暖通节能智能体技术方案
  • 本地部署Gemma 4V：实测截图转HTML，小显存也能跑的多模态AI应用
  • STM32F103C8T6入门实战：从环境搭建到外设驱动开发
  • 数据结构——栈（附图文讲解 | 超详细）
  • 沧州 2026 瓷砖空鼓精选靠谱商家推荐：全屋瓷砖空鼓检测治理 - 屋工匠
  • 赣州 2026 瓷砖空鼓精选靠谱商家推荐：全屋瓷砖空鼓检测治理 - 屋工匠