HarmonyOS ArkUI UI 自动化测试演示：从四条用例到清晰的执行反馈

在移动应用开发中，“UI 自动化测试”很容易被理解成一个已经接入测试框架、可以自动启动应用并操作真实控件的完整系统。眼前这个页面采用了更克制的方式：它把四条常见的界面测试用例放在一个可视化面板中，用一枚按钮统一改变执行状态，再用数量、颜色、图标、文案和断言提示把结果展示出来。页面没有接入真实的自动化测试引擎，也没有真的去输入账号、滑动列表或打开详情页；它的价值在于把测试清单、测试动作和测试结果组织成一张容易理解的界面。

这类演示对于学习 ArkUI 的状态驱动界面很有帮助。初始状态下，页面告诉用户有四个用例准备执行，每个用例显示自己的序号、名称和动作说明。点击“运行 UI 测试”之后，四条记录同时变成通过状态，顶部统计从“0 / 4”变为“4 / 4”，按钮文字也从运行变成重新运行。变化并不复杂，但每一个变化都能在页面上找到对应的视觉证据。正因为范围很小，反而适合用来理解一个界面如何把单一状态同步到多个区域。

一、先看清楚这个页面实际解决了什么问题

页面的标题是“UI 自动化测试”，标题栏使用醒目的蓝色背景和白色文字，进入页面后用户第一眼就知道这里展示的是测试相关内容。标题下面是一张概览卡片，左侧用较大的数字显示当前完成数，右侧依次显示准备执行或已经完成的说明，以及“UI 层级定位 · 坐标点击 · 截图比对”这句辅助文字。

辅助文字的作用是说明测试工作通常会关注哪些方面，但它不是一份真实的运行日志。页面没有显示某个控件被定位的过程，也没有展示坐标值、截图差异或断言堆栈。看到这句话时，应该把它理解为测试面板的能力标签，而不是已经发生的底层操作。文章后面所有关于测试的描述，都以页面真正出现的内容为准。

概览卡片下面有四张白色用例卡片。四张卡片的结构完全一致：最左侧是序号或通过图标，中间是用例名称和动作说明，最右侧是“待执行”或“通过”。这种一致性让用户可以快速扫描列表，也让状态切换后的变化非常直观。页面底部放置一枚宽按钮，按钮横跨内容区域，成为唯一的主要操作入口。初始状态的按钮文案是“运行 UI 测试”，执行完成后文案变成“重新运行 UI 测试”。

所以，这个页面的核心不是完成真实的自动化操作，而是展示一套测试面板应该怎样组织信息：先给出总进度，再列出用例，再提供执行入口，最后通过统一的状态反馈告诉用户结果。对于学习 UI 结构和交互闭环而言，这个范围是清楚且完整的。

二、四条用例分别表达了什么

四条记录不是随意排列的文字，它们覆盖了登录、列表和详情三个常见页面场景，也把正常路径、异常输入、滚动加载和返回操作放在同一组清单里。它们的顺序很重要，因为用户可以按照从基础到复杂的方式阅读这组用例。

第一条用例是“登录页-正常流程”。它下面的动作说明是“输入用户名密码 → 跳转首页”。这是一个典型的成功路径：用户在登录页面完成必要输入，点击登录后进入首页。页面没有提供用户名输入框，也没有提供密码输入框，因此这里只展示测试目标和预期动作，不能把它理解为当前页面已经执行了输入或跳转。它更像一条写在测试计划中的可视化条目。

第二条用例是“登录页-空密码”，动作说明是“点击登录不输入密码”。它和第一条正好形成对照。第一条关注正常输入，第二条关注缺少密码时的交互。把这两条放在一起，可以提醒读者：界面测试不仅要验证成功流程，也要验证用户没有填写完整信息时页面如何回应。不过当前页面只在执行后统一显示“断言：预期页面状态已确认”，并没有展示空密码提示、错误颜色或表单校验文本，因此文章不能进一步推断真实登录校验的内容。

第三条用例是“列表页-滑动加载”，动作说明是“上滑 3 屏加载数据”。它关注列表页面的连续滚动和数据加载反馈。这里的“3 屏”是用例描述中的固定文字，页面没有滚动容器，没有数据列表，也没有加载动画。它的作用是让测试面板看起来覆盖了列表场景，同时让读者理解一个测试动作可以包含连续手势，而不只是一次按钮点击。至于真正滑动几次、每次加载多少条数据，当前界面没有给出答案。

第四条用例是“详情页-返回”，动作说明是“进入详情 → 返回列表”。它描述的是页面导航闭环。用户先从列表进入详情，再回到列表，测试重点通常是返回后列表位置和内容是否符合预期。但是当前页面没有列表、详情页或导航按钮，这条记录仍然只是测试清单里的动作描述。执行完成后它和其他三条一样显示通过，并不代表真的发生了页面跳转。

把四条用例放在一起，可以看出页面有意涵盖四种观察角度：成功路径、输入缺失、连续滚动和返回关系。它们的共同点是都可以转化为“动作加预期状态”的测试条目。页面执行后的统一断言文字“预期页面状态已确认”，正是把这些不同场景压缩成相同结果展示的一种方式。

三、初始状态为什么重要

第一次打开页面时，顶部数字显示“0 / 4”，说明四条用例都还没有进入完成展示。概览文案是“准备执行 4 个 UI 用例”，它把当前页面定位为准备阶段。四张用例卡片的左侧显示蓝色序号 1、2、3、4，右侧显示灰色的“待执行”，中间保留每一条动作说明。

初始状态的层次很清楚。蓝色序号能够让用户识别顺序，但它不是完成标记；灰色“待执行”说明当前没有展示结果；动作说明则帮助用户知道每条记录计划做什么。三种信息被放在不同位置，阅读者不需要从长段文字里寻找进度。

概览卡片的背景是白色，页面背景是浅灰色，内容卡片通过圆角和留白从背景中浮出来。用例卡片也使用白色背景和圆角，卡片之间通过垂直间距分隔。这样的布局让顶部汇总、用例列表和底部按钮形成三个清晰区块。即使不执行任何操作，页面也已经提供了足够的上下文：标题告诉你主题，概览告诉你总数，用例卡片告诉你具体内容，按钮告诉你下一步操作。

初始状态还有一个容易忽略的特点：页面并没有显示失败、运行中或部分通过。它只有“待执行”这一种未完成状态。也就是说，当前演示没有把四条用例拆成独立的执行开关，也没有逐条更新进度；用户点击一次按钮后，页面从整体准备状态直接进入整体完成状态。理解这一点能够避免把它误读成一个具备逐项调度能力的测试工具。

四、点击运行按钮之后发生了什么

点击底部的“运行 UI 测试”后，页面会马上进入完成展示。顶部数字改为“4 / 4”，右侧主文案变成“用例已完成：4 项通过”。四张卡片左侧的数字变成绿色对勾，右侧的“待执行”变成绿色“通过”，每条动作说明也被替换成“断言：预期页面状态已确认”。按钮文字变成“重新运行 UI 测试”。

这里的“马上”是从界面状态观察到的结果。页面没有等待时间、没有中间进度条、没有逐条延迟，也没有失败分支。点击事件只改变一个执行状态，所有依赖这个状态的文本和颜色一起刷新。因此，四条用例看起来像是同时完成的，但不能据此推断底层真的在同一时刻运行了四个测试任务。

按钮文案的变化很有意义。初始文案“运行 UI 测试”是一项动作，完成后文案“重新运行 UI 测试”则告诉用户当前已经有过一次执行结果，再次点击可以重新触发同样的界面状态。由于页面没有清除按钮，重新运行并不会把四条记录逐条重置为待执行后再展示中间过程；它只是再次设置完成状态。对于演示“执行后按钮如何变化”来说，这样的处理足够明确。

顶部统计和卡片状态同步改变，说明页面把总状态和局部状态放在同一个状态条件下处理。只要执行状态是未完成，概览、卡片和按钮就使用准备阶段的文案；只要执行状态是完成，三类区域就使用完成阶段的文案。这样的设计避免出现顶部写着“4 / 4”，但卡片还显示“待执行”的不一致情况。

五、页面中一个状态如何影响多个区域

从用户角度看，页面似乎有很多变化：数字变了、说明变了、勾选图标出现了、颜色变绿了、按钮文字变了。实际上，这些变化由同一个执行状态统一驱动。页面并没有为四条卡片分别设置四个独立的完成开关，也没有给概览数字单独设置一个计数器。这样做让演示保持简单，也让状态关系更容易讲清楚。

可以把页面理解成两个状态快照。第一种是“未运行”：完成数为零，准备执行四项，用例序号为蓝色，状态为待执行，动作描述保持原样，按钮邀请用户运行。第二种是“已运行”：完成数为四，四项通过，用例序号变为绿色对勾，状态为通过，动作描述统一为断言结果，按钮邀请用户重新运行。

这两个快照之间没有第三种“部分执行”状态。比如点击一次后第一条变绿、其他三条仍为待执行的画面不会出现；也不存在某条用例失败、顶部显示“3 / 4”的画面。页面的模型是全有或全无：只要进入完成状态，四条一起通过。这样的模型适合用来讲解状态驱动渲染，但不适合代表真实测试平台中的逐项执行、失败重试或实时日志。

一个状态影响多个区域时，最容易出现的问题是文案和颜色漏改。例如只更新顶部数字而没有更新卡片，用户就会怀疑结果是否可信。这个页面把完成状态同时应用于数字、标题、对勾、名称旁状态、断言文字和按钮，从可见效果来看形成了一个完整的反馈闭环。即便它只是演示，也展示了一个实用原则：同一结果在多个视觉位置出现时，必须保持含义一致。

六、卡片布局为什么适合测试清单

每张用例卡片由两行信息组成。第一行横向排列序号或对勾、用例名称和当前状态；第二行展示动作或断言。第一行的名称使用较明显的字号和中等字重，状态文字放在右侧，便于用户在快速浏览时先看到结果。第二行使用较小字号和灰色，作为补充说明，不会抢过标题的视觉重点。

卡片内部有固定的上下间距和内边距，四张卡片的排列节奏一致。因为每个条目的结构相同，用户可以用相同的阅读路径查看所有记录：先看编号，再看名称，再看右侧状态，最后看第二行说明。这种结构比把四条测试内容写成一整段文字更容易核对。

初始状态用蓝色序号表达顺序。蓝色和顶部标题、底部按钮属于同一套主色体系，用户会把它们理解成页面的主要信息和操作。完成状态用绿色对勾和绿色“通过”，绿色成为结果色。灰色“待执行”则退到次要层级，不会和蓝色操作元素混在一起。

卡片没有显示失败红色，也没有显示警告黄色，因为页面没有失败和警告状态。视觉设计不能凭空增加不存在的分支。如果在文章里加入“失败时会显示红色错误信息”就会超出这个页面事实。准确的描述应当是：当前可见状态只有待执行和通过，两种状态分别使用蓝色序号、灰色文字以及绿色结果反馈。

七、顶部概览卡片承担了什么作用

顶部概览卡片把四条记录压缩成一个数字和一句话。未运行时“0 / 4”和“准备执行 4 个 UI 用例”互相解释：左边给出数量，右边说明这些数量代表什么。执行后“4 / 4”和“用例已完成：4 项通过”继续互相解释：左边给出完成比例，右边说明结果为通过。

数字使用较大的字号，与旁边的说明形成明显对比。用户首先看数字就能知道进度，再通过两行文字理解测试面板的主题。辅助文字“UI 层级定位 · 坐标点击 · 截图比对”字号较小、颜色较浅，承担的是背景说明而不是结果显示。它与主文案保持间距，避免把能力标签误读成运行日志。

概览卡片的白色背景和圆角与下面的用例卡片一致，说明这两类信息属于同一个测试面板。顶部卡片更强调汇总，下面卡片更强调细节。页面没有使用复杂图表、环形进度或动态动画，数量直接写成“0 / 4”或“4 / 4”，这让状态更加容易核对。

如果把页面作为产品原型评审，概览卡片还可以帮助观察反馈是否完整：按钮操作之后，用户不必逐条数对勾，只看顶部就知道四项是否完成；如果想知道具体条目，再向下查看卡片。汇总和明细同时出现，兼顾了快速判断和详细核对。

八、按钮交互的范围和边界

底部按钮是页面唯一的交互入口。它有固定高度、整行宽度、蓝色背景和圆角，视觉上非常醒目。初始文案是“运行 UI 测试”，完成状态的文案是“重新运行 UI 测试”。按钮点击之后，页面刷新为完成快照。

按钮没有禁用状态，也没有加载状态。用户可以在完成后再次点击按钮，但页面不会展示新的中间结果；按钮仍然保持完成后的文案，四项仍然显示通过。这里的“重新运行”更像是一个可重复触发的演示动作，而不是实际启动一轮新的自动化会话。

按钮也没有弹出错误提示、确认弹窗或结果详情。用户点击后直接看到状态变化，交互路径很短。这种直接反馈适合教学演示和界面原型，也让读者容易观察状态更新对不同组件的影响。若把它用于真实测试平台，还需要增加运行中、超时、失败、取消和重试等状态，但这些都不属于当前页面。

按钮的颜色和标题栏、序号颜色保持一致，形成了主色统一。完成后，按钮不会变成绿色，因为绿色只用于表示用例结果；按钮仍然是蓝色，说明它依旧是可操作入口。这个细节体现了“操作色”和“结果色”分离的思路：蓝色邀请用户操作，绿色告诉用户结果。

九、如何正确理解页面中的“断言”

执行完成后，每张卡片第二行出现“断言：预期页面状态已确认”。“断言”这个词来自测试语境，表示把实际结果和预期结果进行比较。不过当前页面没有展示具体的实际值，也没有展示比较过程，因此这里的断言是结果说明文字，不是可查看的断言记录。

四条用例的预期内容各不相同。正常登录对应首页跳转，空密码对应登录校验，列表滑动对应加载数据，详情返回对应回到列表。页面将它们都统一显示为“预期页面状态已确认”，是为了在有限空间内表示四项都通过。这种统一文案让列表更加整齐，但也意味着用户无法从完成后的卡片看出每条用例的具体断言细节。

如果需要更详细的测试结果，界面可以在卡片下方补充实际状态和预期状态的对照，但当前页面没有这样做。文章应当把现状讲清楚：完成后能看到统一的确认提示，不能看到真实控件树、截图差异、点击坐标或页面跳转轨迹。这样既不削弱页面演示价值，也不会把视觉标签夸大成真实执行能力。

十、哪些内容当前没有实现

准确说明边界是理解这个页面的关键。当前页面没有登录输入框，因此不会真正输入用户名和密码；没有登录校验逻辑，因此不会真的验证空密码；没有列表滚动区域，因此不会真正上滑三屏并加载数据；没有详情页面和返回导航，因此不会真正进入详情再返回列表。

页面也没有接入 UI 自动化框架，没有设备控制、控件层级查询、坐标注入、截图采集、图像差异计算或测试报告文件。辅助文字虽然提到 UI 层级定位、坐标点击和截图比对，但这些词只是测试面板的说明标签。点击按钮时发生的是本地界面状态切换，不是对其他应用或系统页面的自动化控制。

页面没有网络请求、数据库、持久化记录和后台任务。关闭页面后，四项完成状态不会被保存成一份测试报告；重新进入页面时，页面回到准备执行的初始展示。页面没有失败数据，也没有随机结果，因此每次点击完成按钮都会得到同样的四项通过反馈。

这些边界并不代表页面没有意义。它把测试面板中最重要的视觉关系做了出来，让开发者可以先验证信息架构和交互反馈，再决定是否接入真正的执行能力。对于阅读者而言，清楚区分“演示界面”与“自动化引擎”比把一个简单按钮描述成完整测试系统更重要。

十一、从用户视角走一遍完整流程

打开页面后，先看顶部蓝色标题栏，确认主题是 UI 自动化测试。向下看概览卡片，数字为“0 / 4”，旁边写着准备执行四个用例。再继续向下查看四张卡片，可以看到四个名称和各自的动作说明，右侧统一为待执行。此时不需要猜测哪个条目已经完成，因为所有条目都使用相同的未完成状态。

接下来点击底部按钮。点击完成后，顶部数字变成“4 / 4”，主文案变成四项通过。第一张卡片的蓝色序号变成绿色对勾，第二张、第三张和第四张也发生同样变化。每张卡片的右侧出现绿色“通过”，第二行动作说明被统一替换成断言确认。按钮文案改成“重新运行 UI 测试”。

完成状态下再次向上或向下查看，用户会发现顶部和卡片表达的是同一件事：四项都通过。页面没有额外弹窗，也没有滚动到某条记录或自动跳转到新页面。再次点击底部按钮，页面保持在完成状态，说明这个操作可以重复触发，但没有独立的运行记录。

这条流程中最有价值的观察点不是按钮本身，而是一次点击如何同时更新多个视觉区域。用户不需要手动刷新页面，也不需要重新打开列表；状态变化会立即反映到数字、文字、图标和颜色上。这个闭环正是声明式界面适合表达测试结果的地方。

十二、从页面结构理解信息组织

页面可以分为四层信息。第一层是标题栏，负责建立主题和颜色基调。第二层是概览卡片，负责展示四条用例的整体进度。第三层是用例列表，负责展示名称、动作和逐项状态。第四层是运行按钮，负责触发执行状态切换。层次之间从上到下符合用户的阅读和操作顺序。

用例名称和动作说明按固定顺序组织，页面逐条展示。这样的组织方式适合四项固定内容：调整一条用例时，可以同时调整名称和动作说明，并保持两组内容的位置对应。当前页面没有输入框、编辑按钮或动态增加用例的入口，所以这些内容属于固定演示数据，而不是用户可以修改的测试计划。

列表采用统一的卡片结构。每一条记录都根据当前位置显示序号或完成图标，根据整体执行状态显示待执行或通过，根据执行状态显示动作说明或断言确认。这种条件展示让同一张卡片承担准备态和完成态两个画面，减少了重复布局。

页面状态只有两个明确分支，维护成本很低。阅读页面时，可以先问三个问题：顶部数字在当前分支是什么、卡片状态文字是什么、按钮文案是什么。只要这三个位置保持一致，用户就能准确判断当前处于准备态还是完成态。对更复杂的测试产品而言，状态会更多，但这个页面已经用最小模型展示了基本规律。

十三、为什么不能把建议扩展写成当前功能

测试场景很容易引出许多生产化话题，例如接入真实设备、读取控件树、模拟手势、采集截图、生成报告、执行并发任务等。这些能力确实与 UI 自动化相关，但当前页面没有出现这些操作入口，也没有展示对应结果。把它们写成页面已经具备的功能，会让读者在实际运行时产生落差。

当前页面最准确的定位是一个“测试用例执行状态演示”。它把四个用例和两种总状态展示清楚；它没有实现测试执行器。读者可以从中学习如何做用例卡片、如何设计总进度、如何用颜色区分状态、如何让按钮文案跟随状态变化。至于真实执行能力，需要另外设计输入、设备控制、等待、失败处理和结果存储，这些都不应混入当前页面的功能介绍。

同样，不能因为辅助文字写了“截图比对”，就直接说页面已经完成截图差异检测；不能因为用例名称写了“滑动加载”，就说页面已经读取了列表数据；不能因为断言文案出现，就说页面已经访问了真实的目标页面。描述界面时，应该把“文字表达的测试意图”和“当前能操作的界面行为”分开。

十四、适合观察的 ArkUI 界面规律

这个页面最适合观察的是声明式界面的状态同步。一个布尔结果从未完成变成完成后，多个文本、颜色和按钮文案都跟着刷新。开发者不需要分别寻找每个控件并手动修改显示内容，只需要让界面根据当前状态选择对应的分支。对初学者来说，这比直接阅读复杂的异步测试框架更容易建立正确的状态观。

第二个可观察规律是固定数据与动态状态分离。四个名称和四个动作属于固定展示数据，执行结果属于动态状态。两者放在同一组卡片中，但职责不同：固定数据说明测试计划，动态状态说明当前执行结果。页面因此能够在不改变用例内容的情况下切换整组结果。

第三个规律是视觉反馈的多点一致性。完成状态同时使用数量、标题、图标、颜色和按钮文案表达。任何一个区域单独看都能提供线索，多个区域组合起来则形成更强的确认感。对于测试面板这种用户需要快速判断的界面，多点一致比只变一个数字更可靠。

第四个规律是保留足够的空白和层次。浅灰背景、白色卡片、圆角、固定间距和不同字号，让页面在信息量不大的情况下仍然有清楚的阅读节奏。测试清单的重点不是堆很多字段，而是让每条用例的名称、动作和结果容易对照。

十五、可以怎样检查这个演示页面的可见结果

检查初始画面时，首先确认标题栏文字和蓝色背景清晰可见；然后确认概览数字是“0 / 4”，主文案是准备执行四个用例。继续查看四张卡片，确认名称顺序为登录正常流程、登录空密码、列表滑动加载、详情返回，序号为一到四，右侧均显示待执行。最后确认按钮文字为运行 UI 测试。

检查点击后的画面时，确认概览数字变为“4 / 4”，主文案变成四项通过。四张卡片左侧应出现绿色对勾，右侧应显示绿色通过，第二行应显示断言确认。底部按钮文字应变为重新运行 UI 测试。检查重点是这些变化是否同时出现，而不是寻找页面中并不存在的输入框、滚动列表或详情页面。

检查重复点击时，确认页面不会出现额外卡片、重复提示或数字超过四项。因为页面展示的是固定四条用例，重复触发不会扩展列表。检查重新进入页面时，应该重新看到准备执行状态；当前页面没有持久化结果，因此不应期待上一次的四项通过被保存下来。

检查阅读体验时，可以观察文字是否被卡片边界截断，状态颜色是否与背景有足够对比，按钮是否容易点击，四张卡片之间是否保持一致间距。由于页面只使用固定文字，没有长文本输入和动态数据，主要关注点是布局清晰、状态对照准确以及操作反馈及时。

十六、总结

这个 UI 自动化测试页面用一个非常小的交互闭环，展示了测试面板如何组织信息。页面先用标题明确主题，再用概览卡片展示四项用例的总进度，接着用四张卡片列出登录正常流程、登录空密码、列表滑动加载和详情返回四个测试意图，最后用按钮把页面从待执行状态切换到通过状态。

初始状态的关键词是“0 / 4”“准备执行”“待执行”和蓝色序号；完成状态的关键词是“4 / 4”“4 项通过”“通过”、绿色对勾和断言确认。按钮也根据状态从运行变成重新运行。所有变化都围绕同一个执行结果展开，形成了清楚的反馈关系。

同时，这个页面的边界必须被如实说明：它没有真实登录、密码校验、列表滑动、详情导航，也没有连接自动化测试框架、设备控制或截图比较引擎。页面展示的是固定用例和本地状态反馈，辅助文字表达的是测试领域的说明，而不是底层能力已经运行的证明。

对于 ArkUI 学习者来说，这个例子值得关注的不是“自动化”三个字本身，而是它如何用声明式方式构建一个独立、可读、易观察的测试状态面板。只要把总进度、明细状态、动作说明和操作入口安排在同一条反馈链路上，即使不接入真实执行器，也能先把界面层的结构和交互逻辑讲清楚。后续如果要扩展真实能力，也应以当前清楚的用例模型为基础，逐步增加运行中、失败、重试和报告等状态，而不是把不存在的能力提前写进页面说明。

十七、四条用例之间的阅读关系

把四条记录当作一个整体阅读，还能看到页面对测试范围的安排。第一条和第二条都围绕登录页，但一个代表正常输入，一个代表密码缺失，它们放在相邻位置，方便比较成功路径和异常输入。第三条转向列表页，测试重点从表单结果变成连续滚动。第四条再转向详情页，关注导航后的返回关系。页面用固定顺序把不同场景串起来，用户不需要打开新的页面或切换标签，就可以完成一次测试清单浏览。

这种排列也让每一条记录的动作说明成为必要信息。只看“登录页-正常流程”，读者知道主题，却不知道要做什么；加上“输入用户名密码 → 跳转首页”，动作和预期方向就更清楚。只看“列表页-滑动加载”，读者知道场景，却不知道操作次数；加上“上滑 3 屏加载数据”，测试意图更加具体。动作文字不是当前页面真正执行的步骤，却是帮助用户理解用例的关键上下文。

完成状态把四种不同动作统一成相同的断言提示，体现的是测试结果汇总，而不是抹掉它们之间的差异。阅读者仍然可以通过用例名称回想每条记录关注的场景，通过“通过”判断这组演示已经完成。这样的信息层次适合小型测试面板：名称保留语义，状态提供结论，动作说明在准备态中帮助理解。

十八、为什么这个演示适合做界面评审

在真正接入复杂能力之前，先把界面评审做好，可以尽早发现很多问题。比如概览卡片是否能让人一眼看懂总数量，四张卡片的名称是否容易区分，动作说明是否过长，状态文字是否会被挤到屏幕边缘，底部按钮是否足够醒目。当前页面只使用固定文字和固定数量，评审者可以专注观察布局与状态，不会被网络等待、数据异常或设备差异干扰。

初始截图和操作后的截图可以用于对照页面变化。对照时应该重点观察四个地方：顶部数字是否从零变成四，概览主文案是否从准备执行变成完成通过，卡片是否统一出现绿色对勾和通过，按钮是否从运行变成重新运行。若这四处变化一致，说明页面的视觉反馈链路是完整的。截图对照在这里是人工观察页面前后效果的方式，不等于页面内部已经执行了图像识别算法。

界面评审还可以关注文字语气。准备态使用“准备执行”和“待执行”，语义偏向邀请操作；完成态使用“已完成”“通过”和“预期页面状态已确认”，语义偏向结果确认。两组文案的语气互相对应，用户不会在未运行时看到已经完成的表述，也不会在完成后仍然看到准备执行的提示。

十九、如果再次点击，页面为什么不出现新的记录

完成后按钮文字变成“重新运行 UI 测试”，这会让用户自然期待一次新的执行。但从可见行为看，再次点击并不会增加运行次数、创建新的结果卡片或出现运行时间。页面仍然保持四项通过和“4 / 4”。因此，“重新运行”在当前演示中表达的是允许重复触发完成状态，而不是保存多次运行历史。

这种行为与页面的固定状态模型是一致的。页面只关心当前是否进入完成展示，不维护运行次数、开始时间、结束时间、失败信息或历史列表。再次点击不会改变结果，因为结果本来就是固定的。理解这一点之后，用户不会把按钮误认为历史记录入口，也不会期待出现第五条或第八条测试记录。

如果将来需要展示真实运行历史，界面需要增加新的信息区域，例如运行批次、开始时间、完成数量、失败数量和查看详情入口。但这些信息当前并不存在，当前文章只需要说明按钮的可见变化和重复点击后的稳定结果。把边界讲清楚，反而能让读者更准确地理解这个页面的定位。