每次发版前，手指头都要点废了

你的应用有 50 个页面，每次发版前，测试同学都要手动把所有核心流程点一遍：登录、加购物车、下单、支付、退出。一个流程走完，十分钟没了。要是改了底层代码，还得来来回回测三遍。

这还不算最惨的。最惨的是你本地跑得好好的，一到自动化打包机上，因为环境差异，直接编译报错，或者跑出来的包装不上。

现在稍微正规一点的团队，都在搞 CI/CD（持续集成/持续交付） 和 自动化 UI 测试。但网上的鸿蒙教程，要么只教你怎么写个 assertTrue(1 === 1) 的弱智单测，要么就是搬运官方的生硬文档。

这篇就带你把鸿蒙的自动化测试（单元测试 + UI 测试）真正落地，并教你如何接入流水线。

https://placeholder-01.jpg/

一、别拿单测不当干粮：Hypium 框架

鸿蒙原生的单元测试框架叫 Hypium。跟 Jest 或者 JUnit 很像。

在你的 entry/src/ohosTest/ets/test 目录下，建个测试文件：

typescript

import { describe, it, expect } from '@ohos/hypium';

export default function abilityTest() {
  describe('CalculatorTest', () => {
    // 测试加法
    it('assertAdd', 0, () => {
      const result = add(2, 3);
      expect(result).assertEqual(5); // 断言结果等于 5
    });
  });
}

function add(a: number, b: number) {
  return a + b;
}

坑点来了：网络请求、数据库操作怎么测？
你在单测里直接 await axios.get(...)，大概率会超时或者失败。单元测试的核心原则是“快、隔离”，绝对不能在单测里依赖真实环境。

解法：Mock（打桩）。 把网络请求模块用 Mock 替换掉。在 ohosTest/mock 目录下配置，让测试用例跑的时候，拦截真实的网络请求，返回假数据。

二、UI 自动化测试：让机器代替你的手

单测测的是逻辑，UI 测测的是交互。

鸿蒙的 UI 测试依赖 @ohos/uitest 和 @ohos/hypium。

写一个自动登录的用例：

typescript

import { describe, it, expect } from '@ohos/hypium';
import { Driver, ON } from '@ohos/uitest';

export default function uiTest() {
  describe('LoginTest', () => {
    it('testLoginSuccess', 0, async () => {
      const driver = Driver.create();
      
      // 等待登录按钮出现（别直接找，可能页面还没渲染完）
      await driver.waitForComponent(ON.id('btn_login'), 5000);
      
      // 输入账号密码
      await driver.findComponent(ON.id('input_account')).inputText('admin');
      await driver.findComponent(ON.id('input_password')).inputText('123456');
      
      // 点击登录
      await driver.findComponent(ON.id('btn_login')).click();
      
      // 等待首页的某个元素出现
      const homeHeader = await driver.waitForComponent(ON.text('首页'), 5000);
      
      // 断言：首页标题存在
      expect(homeHeader !== null).assertTrue();
    });
  });
}

这玩意儿坑极多：

1. 必须给组件加 ID。你去查元素，不能用 ON.text('登录')，因为文案可能会变，或者有多个同名组件。必须在你的 UI 代码里加上 .id('btn_login')。

2. 必须用 waitForComponent。如果你点击登录后，立刻去查首页元素，100% 找不到，因为网络请求需要时间，页面还在转圈圈。必须加显式等待。

3. 弹窗拦截。如果系统弹了个权限框，或者网络异常弹窗，你的测试就卡死了。要在测试用例开头做个检查，如果有弹窗，先关掉。

https://placeholder-02.png/

三、CI/CD 流水线接入：Hvigor 的正确姿势

写完测试，怎么在服务器上跑起来？

鸿蒙的构建工具叫 Hvigor。在根目录下有 hvigorfile.ts。CI 流水线（如 Jenkins、GitLab CI）跑的时候，不能依赖你的 IDE。

你需要用命令行打包和跑测试：

bash

# 清理并安装依赖
ohpm install

# 执行编译打包（Release 模式）
hvigorw assembleHap --mode module -p product=default -p buildMode=release

# 执行测试
hvigorw test

大坑：Node.js 版本与签名环境。
流水线的服务器上，Node.js 版本如果和本地不一致，Hvigor 可能直接报错。另外，流水线打包需要签名证书，千万别把 .p12 和密码明文写在代码仓库里！

解法： 把证书放到 CI 平台的“安全凭证（Secrets）”里，在构建脚本运行时，动态注入到环境变量或临时生成 build-profile.json5。

四、性能测试：别只测功能

除了功能，性能也要自动化。DevEco Studio 提供了 hdc（HarmonyOS Device Connector）命令行工具。

你可以用 hdc 抓取应用运行时的内存和 CPU：

bash

hdc shell top -m 10 -s cpu

或者在流水线里集成 hdc shell hilog，在测试跑完后，抓取日志分析有没有报错或者 Crash。

https://placeholder-03.png/

五、总结

自动化测试和 CI/CD 是团队走向正规军的必经之路。核心记住三点：

1. 单测要 Mock 网络，别依赖真实环境。

2. UI 测试要给组件加 .id()，且必须用 waitForComponent。

3. 流水线配置要动态注入签名证书，千万别提交密钥。

小任务： 把你应用里最核心的一个页面（比如详情页），加上 .id()，然后用 UITest 写个脚本，让它自动滑到底部并点击购买按钮。