在Android客户端的持续交付里，界面文本是否正确、是否缺失、是否错位是质量门禁的隐形短板。很多团队把精力放在业务逻辑自动化上，却忽略了最容易被用户一眼看穿的标签错误。所谓Labels and Text文本标签测试，核心就是针对Activity里所有带文字的控件，校验其文本内容、可见性以及多语言下的表现，而不是只验证页面能打开。
从控件树抽取文本标签的基本原理
Android的视图在运行期会构建一棵View树，每一个TextView、Button、CheckBox本质上都是View的子类，并且都持有text属性或者contentDescription。要测试这些标签，第一步不是写断言，而是把当前屏幕上的控件树dump出来。系统提供的UiAutomator框架可以在不插桩的情况下，通过adb shell uiautomator dump拿到一份XML布局快照，里面包含了每个节点的text、resource-id、bounds等信息。
为什么不直接用代码里的硬编码字符串去比对？因为实际渲染时文本可能经过Spannable拼接、getString格式化或者后端下发的动态配置。只有从控件树里拿到的text才是用户真正看到的。我们可以通过递归遍历XML节点，过滤出所有text长度大于零或者contentDescription不为空的节点，把它们收集成一张标签清单。这一步完全脱离业务代码，因此即使页面还没接好接口也能跑。
下面这段Kotlin代码演示了如何在插桩测试中拿到当前Activity的所有文本标签，并打印出来供后续分析。注意这里操作的是UiDevice提供的控件树，而非源码字符串。
import androidx.test.platform.app.InstrumentationRegistry
import androidx.test.uiautomator.UiDevice
import androidx.test.uiautomator.UiObject2
import android.util.Log
fun collectTextLabels(): List<String> {
val device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())
val root = device.findObject(androidx.test.uiautomator.By.clazz("android.view.ViewGroup"))
val labels = mutableListOf<String>()
fun traverse(node: UiObject2?) {
if (node == null) return
val txt = node.text
if (!txt.isNullOrEmpty()) {
labels.add(txt)
Log.i("LabelTest", "found label: $txt")
}
for (child in node.children) {
traverse(child)
}
}
traverse(root)
return labels
}
用语义注解增强标签的可测试性
单纯收集文本只能知道“有什么字”，但无法知道“该有什么字”。为了让测试更智能，我们可以在开发阶段给关键控件加上自定义的语义标签。例如定义一个@UiLabel注解，用来标记这个TextView在测试用例里的业务含义，比如“登录按钮”“用户名提示”。编译期通过注解处理器把这些信息写进resource或者单独的映射表，测试时就能把控件树里的text和期望的业务标签做绑定。
这种做法比单纯依赖resource-id更稳健，因为resource-id经常因为重构而改变，而业务语义相对稳定。同时，它也能解决国际化测试中的盲区：当切换到英文环境时，如果某个控件的text仍然是中文，或者contentDescription为空，注解期望值和实际值不匹配，测试立即报错。下面给出一个简单的注解定义和处理器思路，以及如何在Python端用uiautomator2做断言。
@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
public @interface UiLabel {
String value();
}
// 在Activity里使用
@UiLabel("login_button")
private TextView btnLogin;
在PC端我们可以用Python快速写校验脚本，不需要发版就能回归。下面的脚本连接设备，获取当前界面所有文本，并检查是否包含我们注解表里登记的必现标签。
import uiautomator2 as u2
d = u2.connect("192.168.0.1")
expected = {"login_button": "登录", "user_tip": "请输入用户名"}
xml = d.dump_hierarchy()
import xml.etree.ElementTree as ET
root = ET.fromstring(xml)
actual_texts = [n.attrib.get("text", "") for n in root.iter() if n.attrib.get("text")]
for key, val in expected.items():
if val not in actual_texts:
print(f"缺失标签: {key} 期望文本 {val}")
将标签测试纳入持续集成的实践方案
把上述能力落到流水线里，关键是不让人工去点。我们可以在每次构建完debug包后，启动一个模拟器，跑一遍核心路径的UI旅程，并在每个页面停留时调用collectTextLabels做快照。快照和基线版本比对，新增的空文本、超长截断、或者语言切换后的原语言残留都会生成报告。这种方案不需要后端配合，也不依赖截图识别，速度远快于肉眼走查。
另一个常见误区是认为文本标签测试只能用Espresso。实际上Espresso适合白盒断言，而Labels and Text测试更偏向黑盒验收，用UiAutomator或uiautomator2反而更灵活。我们在表中对比一下两种思路的适用边界，方便团队取舍。
| 方案 | 侵入性 | 多语言支持 | 维护成本 |
|---|---|---|---|
| Espresso | 高，需编译测试包 | 依赖context资源 | 中 |
| UiAutomator2 | 低，纯adb层 | 切locale即可 | 低 |
最后要注意，文本标签测试不是要取代功能测试，而是补上“看起来对不对”的这一环。当你的应用有十几国语言、上百个页面时，靠人去翻每一个字符串是不现实的。把Labels和Text的抽取、语义绑定、自动断言三件事串起来，就能用几十行脚本守住最表面的用户体验底线。