文章目录前言为什么要写 UI 测试UiTest 框架概览环境搭建查找组件模拟操作断言验证测试报告写在最后前言你有没有试过改了一行代码结果三个页面炸了我上个月就干过这事——改了个按钮颜色把整个订单流程搞崩了。手动测了两天才把问题找全人都麻了。从那以后我就在想要是有一套自动化测试能替我点点点该多好。折腾了一周 UiTest 框架终于跑通了第一个 UI 自动化测试用例。今天把整个过程分享出来帮你少踩坑。HarmonyOS7 提供了官方的 UI 自动化测试框架UiTest专门用来对 ArkUI 页面做自动化验证。说实话之前我一直觉得写测试是浪费时间直到那次改一行炸三页的事故才真正意识到——没有测试的代码就像没有刹车的车早晚出事。为什么要写 UI 测试先聊聊为什么需要 UI 测试而不是只靠单元测试。单元测试管的是逻辑但用户看到的、操作的是 UI。按钮能不能点页面跳转对不对列表滑到底部会不会崩这些问题单元测试覆盖不了。我之前的项目有个搜索页单元测试全过结果真机上输入法一弹出来就把搜索按钮遮住了。这种问题只有 UI 测试能发现。UI 自动化测试能帮我们做到回归保障改代码不怕旧功能炸持续集成每次提交自动跑测试减少手动测试把重复的点点点交给机器UiTest 框架概览UiTest 是 HarmonyOS7 官方的 UI 自动化测试框架核心能力包括能力说明|组件查找| 通过 id、text、type 等属性定位 UI 组件 ||模拟操作| 点击、长按、滑动、输入文本等 ||断言验证| 检查组件属性、页面状态是否符合预期 ||测试报告| 自动生成测试结果报告 |它的 API 风格跟 Android 的 UiAutomator 有点像但更简洁。如果你写过 Android UI 测试上手会很快。环境搭建写 UI 测试之前得先把环境搭好。步骤不复杂但有几个坑要注意。1. 在模块的oh-package.json5中添加依赖{ devDependencies: { ohos/hypium: 1.0.6 } }2. 在测试目录下创建测试文件测试文件放在entry/src/ohosTest/ets/目录下别放错位置了。ohosTest是专门放仪器测试的目录跟test目录不一样。3. 配置测试运行器在module.json5里确认有测试配置{ abilities: [ { name: EntryAbility, srcEntry: ./ets/EntryAbility.ets } ] }划重点测试文件必须在ohosTest目录下否则框架识别不了。查找组件UiTest 的核心思路就两步找到组件操作组件。找组件是第一步也是最关键的一步。按 id 查找import{Driver,ON}fromohos.UiTest;constdriverDriver.create();constbuttonawaitdriver.findComponent(ON.id(loginButton));这段代码通过组件的id来查找。ON.id()是最精确的查找方式前提是你给组件设了id。按文本查找consttextCompawaitdriver.findComponent(ON.text(登录));当组件没有设 id 时可以通过显示文本来查找。不过这种方式有个隐患——文本改了测试就挂了。所以还是建议给关键组件加 id。按类型查找constlistCompawaitdriver.findComponent(ON.type(List));按组件类型查找适合需要操作某个类型的容器组件时使用。敲黑板查找组件返回的是Promise必须用await。忘了加await是新手最常见的坑。模拟操作找到组件后就可以模拟用户操作了。点击操作constloginBtnawaitdriver.findComponent(ON.id(loginButton));awaitloginBtn.click();click()模拟单击。如果你需要长按用longClick()。滑动操作awaitdriver.swipe(200,500,200,100,500);// 参数起点x, 起点y, 终点x, 终点y, 滑动速度(ms)swipe()是屏幕级别的滑动适合滚动页面、下拉刷新等场景。输入文本constinputCompawaitdriver.findComponent(ON.id(searchInput));awaitinputComp.inputText(HarmonyOS7);往输入框里填文字。注意这个操作会先清空原有内容再输入新内容。组合操作示例——模拟登录流程asyncfunctiontestLogin(){constdriverDriver.create();// 输入用户名constusernameInputawaitdriver.findComponent(ON.id(username));awaitusernameInput.inputText(testuser);// 输入密码constpasswordInputawaitdriver.findComponent(ON.id(password));awaitpasswordInput.inputText(123456);// 点击登录按钮constloginBtnawaitdriver.findComponent(ON.id(loginButton));awaitloginBtn.click();// 等待页面响应awaitdriver.delayMs(1000);}这段代码模拟了完整的登录操作。delayMs()用来等待页面跳转时间根据实际情况调整。断言验证操作完了得验证结果对不对。这才是测试的核心——光操作不验证那叫演示不叫测试。验证组件是否可见import{assert}fromohos/hypium;consthomeTitleawaitdriver.findComponent(ON.text(首页));assert.assertTrue(homeTitle!null,登录后应跳转到首页);这段代码检查登录后是否出现了首页文字。如果组件找不到说明跳转没成功。验证组件属性conststatusTextawaitdriver.findComponent(ON.id(orderStatus));consttextawaitstatusText.getText();assert.assertEqual(text,已完成,订单状态应为已完成);先拿到组件再读取它的文本内容跟预期值对比。assertEqual会在值不匹配时抛出异常测试标记为失败。验证组件数量constlistItemsawaitdriver.findComponents(ON.type(ListItem));assert.assertEqual(listItems.length,10,列表应显示10条数据);注意findComponents带 s返回所有匹配的组件数组。适合验证列表数据是否正确加载。血泪教训断言一定要写清楚错误信息不然测试挂了你看半天不知道哪里出了问题。测试报告测试跑完会自动生成报告。在 DevEco Studio 里右键测试文件 → Run Tests执行完就能看到结果。报告里包含信息说明用例总数总共跑了多少条测试通过数绿色的没问题的失败数红色的需要排查执行时间每条用例耗时失败截图断言失败时自动截图建议把 UI 测试集成到 CI 流水线里每次提交代码自动跑一遍。这样谁改坏了东西第一时间就能发现。写在最后UiTest 框架上手不难关键是把组件 id 规划好。我现在的习惯是所有用户可交互的组件必须设 id按钮用btnXxx输入框用inputXxx统一命名。这样写测试的时候查找组件就轻松了。还有一点别一上来就想覆盖所有场景。先从核心流程开始——登录、支付、关键操作路径把这些保住了再慢慢扩展。测试覆盖率 20% 但都是关键路径比覆盖率 80% 但全是边缘场景有用得多。如果你还没写过 UI 自动化测试今天就可以动手试试。先跑通一个用例你就知道有多香了。