最严重的测试缺陷，往往不是失败，而是一路绿灯的“通过”。一个登录测试因应用界面中悄然多出的一个按钮，选择了错误的点击目标，却连续两周保持通过状态。这套看似正常的流程，最终被指认为测试套件中最危险的隐患。 问题源于一个常见的按钮命名冲突。录制好的登录测试原本会点击标有“Continue”的按钮，但应用随后在一个同意弹窗中加入了第二个“Continue”。该测试的选择器逻辑为“取第一个匹配项”，于是从此点在了错误的位置上。然而，由于错误点击后流程仍会走向一个看似合理的下一步，测试始终显示为绿色通过。更关键的是，没有人会回头去细读一个已经通过的测试。就这样，缺陷在绿灯的掩盖下潜伏了两周。 正是这一经历催生了tapflow流程运行器中的一条新规则：凡工具需要替使用者在多个选项之间作出选择时，它必须显式说明这一点。制定这一规则并不难，真正的难点在于找出所有需要声明选择的位置——整个排查过程比修复问题本身耗时更久，最终共锁定四处。 tapflow的流程文件采用YAML格式，由`tapflow flow run`命令直接重放，全程零大模型调用。相同的输入始终产生相同的步骤、相同的执行顺序，确保流程的可复现性。以下是一个登录冒烟测试的示例流程： ```yaml name: login-smoke appId: com.example.app steps: - clearState - launchApp - assertVisible: "Sign in" - tapOn: { id: "com.example.app:id/email" } - inputText: "user@example.com" - tapOn: "Sign in" - assertVisible: { label: "Orders", timeout: 15 } ``` 整个流程词汇表仅包含十个步骤：clearState、launchApp、tapOn、inputText、pressKey、swipe、scroll、openUrl、assertVisible、assertNotVisible。这种克制是刻意的——每增加一个步骤，就多一分让流程表面含义与实际行为发生偏离的风险。 在选择器解析上，一个裸字符串会按固定顺序匹配：先精确标识符，再精确标签，最后部分标签。一旦某一阶段命中，后续阶段不再尝试。如果某一阶段存在多个匹配元素，tapOn操作会当场失败，并向使用者明确报告冲突情况，例如“2 elements match "New Orders" — add an index or a more specific role/lab”。这种主动暴露歧义的设计，正是为了避免再出现“错误点击却一路绿灯通过”的测试盲区。
热门跟贴