【测试开发】为什么 UI 自动化总是看起来不稳定？为什么需要引入SessionDirty flag？

为什么企业测试框架在规模化之后往往会引入 SessionDirty flag？

文章目录

[为什么企业测试框架在规模化之后往往会引入 SessionDirty flag？](#为什么企业测试框架在规模化之后往往会引入 SessionDirty flag？)
- 一、企业测试框架的起点：计数驱动模型
- - 这种设计的前提假设是：
- 二、问题从哪里开始出现？
- - [1️⃣ 单次失败就足以污染 Session](#1️⃣ 单次失败就足以污染 Session)
  - [2️⃣ 计数模型无法表达"状态是否可继续复用"](#2️⃣ 计数模型无法表达“状态是否可继续复用”)
- [三、SessionDirty flag 的本质是什么？](#三、SessionDirty flag 的本质是什么？)
- [四、在什么条件下，SessionDirty 会成为必要抽象？](#四、在什么条件下，SessionDirty 会成为必要抽象？)
- - [原因 1：计数只能表达"什么时候"，不能表达"是否"](#原因 1：计数只能表达“什么时候”，不能表达“是否”)
  - [原因 2：失败是一种"状态变化"，不是"事件"](#原因 2：失败是一种“状态变化”，不是“事件”)
  - [原因 3：主流框架/生态中都有等价概念](#原因 3：主流框架/生态中都有等价概念)
- [五、没有 SessionDirty，会发生什么？](#五、没有 SessionDirty，会发生什么？)
- 六、一个成熟框架的典型形态
- [七、没有 SessionDirty 的测试框架，通常会在哪些地方失控？](#七、没有 SessionDirty 的测试框架，通常会在哪些地方失控？)
- - [1️⃣ 失败后的行为变得不可预测](#1️⃣ 失败后的行为变得不可预测)
  - [2️⃣ 生命周期决策被迫外溢到用例层](#2️⃣ 生命周期决策被迫外溢到用例层)
  - [3️⃣ 清理逻辑开始变得重复且相互冲突](#3️⃣ 清理逻辑开始变得重复且相互冲突)
  - [4️⃣ Debug 成本指数级上升](#4️⃣ Debug 成本指数级上升)
  - [5️⃣ 团队开始"习惯性接受不稳定"](#5️⃣ 团队开始“习惯性接受不稳定”)
  - 小结

在企业级 UI / E2E 自动化测试框架中，可以观察到这样一种现象：
不少框架在早期阶段并没有显式的 SessionDirty / SessionInvalid / ForceRestart 等状态标志，但随着规模扩大、用例增多，以及对执行稳定性和效率的要求提高，往往会引入这一类状态抽象。

这并不是"设计偏好"，而是工程实践反复验证后逐渐形成的一种结果。

本文结合企业测试框架的真实演化过程，解释为什么这一抽象最终不可避免。

一、企业测试框架的起点：计数驱动模型

大多数企业测试框架在最初阶段，都会采用类似这样的策略：

text 复制代码

浏览器跑 N 个用例 → 重启一次

典型实现包括：

_currentRunCount >= KeepBrowserRunCount
每跑 X 个 TestCase 重启浏览器
类级 / 进程级复用 WebDriver

这种设计的前提假设是：

浏览器状态是相对稳定、可预测的
污染主要来自"运行时间变长"，而不是单次失败
重启成本很高，应尽量减少

在用例规模小、失败率低时，这套模型确实有效。

二、问题从哪里开始出现？

当测试框架进入"企业规模"后，几个现实问题会逐渐暴露：

1️⃣ 单次失败就足以污染 Session

实际 UI 自动化中，以下失败场景非常常见：

弹窗未关闭（alert / dialog）
页面卡在异常中间态
JS 执行错误导致页面不可交互
Session / token 失效但未跳转登录页

这些情况不需要跑 N 次 ，一次失败就足以让当前 session 不再可信。

2️⃣ 计数模型无法表达"状态是否可继续复用"

此时就会出现经典问题：

同样是失败：

有的失败不会污染 session（断言失败）

有的失败必然污染 session（页面崩溃）

但在"纯计数模型"中：

它们看起来是一样的
都只是 runCount +1

框架无法表达"当前状态是否还健康"这一信息。

三、SessionDirty flag 的本质是什么？

SessionDirty 并不是"重启开关"，而是一个语义标志：

当前 session 是否仍然可信、可继续复用

它回答的不是：

"现在要不要重启？"

而是：

"当前 session 是否已经被破坏？"

一旦这个问题被显式建模，很多混乱会自然消失。

四、在什么条件下，SessionDirty 会成为必要抽象？

原因 1：计数只能表达"什么时候"，不能表达"是否"

runCount：时间/数量维度
SessionDirty：状态/健康维度

真实世界中，是否可复用 ≠ 运行了多久。

原因 2：失败是一种"状态变化"，不是"事件"

如果失败只被当作"结果"，那么：

它只影响报告
不影响生命周期决策

而在成熟框架中：

失败是"状态变化"
会影响后续资源管理策略

SessionDirty 正是这种变化的载体。

原因 3：主流框架/生态中都有等价概念

虽然名字不同，但"上下文被污染"的抽象广泛存在：

JUnit：@DirtiesContext
pytest：失败后 fork / 重建环境
Playwright：新 browser context
Cypress：test isolation

企业框架只是把这些隐含行为显式化了。

五、没有 SessionDirty，会发生什么？

经验上，在缺少这一抽象的情况下，框架更容易逐渐出现：

生命周期逻辑难以维护
失败处理到处散落
重启逻辑重复、冲突
Debug 成本极高
"单跑 OK，串跑挂"的幽灵问题

而这些问题，往往被误判为：

"UI 自动化不稳定"

实际上是：

框架状态模型不完整

六、一个成熟框架的典型形态

当框架引入 SessionDirty 后，生命周期会变得非常清晰：

text 复制代码

TestExecute
  ↓
TestCleanup
  ├─ if failed → sessionDirty = true
  ↓
CleanUp
  ├─ if sessionDirty → restart
  └─ else → reuse

失败不再"抢跑资源释放"
清理路径保持单一
决策逻辑集中、可维护

七、没有 SessionDirty 的测试框架，通常会在哪些地方失控？

在缺少显式 session 状态抽象的情况下，

测试框架并不会立刻"崩溃"，

而是往往在一些关键节点上逐步失控。

这些失控点具有高度的共性，也最容易被误判为"UI 自动化不稳定"。

1️⃣ 失败后的行为变得不可预测

当一次用例失败后，

框架无法判断当前 session 是否仍然可继续复用。

常见表现包括：

有时失败后继续复用浏览器，导致后续用例全部失败
有时失败触发重启，有时却没有，行为不一致
重启逻辑散落在不同层级，难以追踪来源

结果是：

失败本身成为不确定性的放大器。

2️⃣ 生命周期决策被迫外溢到用例层

当框架无法在统一位置判断 session 状态时：

用例层开始直接控制浏览器生命周期
TestCleanup 中混入大量与业务无关的判断
框架边界逐渐模糊，用例代码承担了框架职责

这会导致：

测试代码不再只是"验证行为"，而是在"维持系统可运行"。

3️⃣ 清理逻辑开始变得重复且相互冲突

在没有 SessionDirty 的情况下：

为了"确保干净"，不同地方都会尝试做清理
同一轮生命周期中，可能多次触发重启
为避免重复清理，又不得不引入额外判断条件

最终形成：

为了避免副作用而引入更多副作用的恶性循环。

4️⃣ Debug 成本指数级上升

在这类框架中，以下问题极难定位：

用例单跑正常，串跑失败
在 CI 上失败，本地却无法复现
加日志、加等待、加重启都无法稳定复现问题

根本原因在于：

框架自身的状态已经不可观测。

5️⃣ 团队开始"习惯性接受不稳定"

当问题长期无法被彻底解释时，团队往往会：

将失败归因于"UI 自动化本来就不稳定"
通过重跑、忽略失败来维持流水线
放弃对框架行为一致性的追求

这并不是技术问题，而是：

框架设计缺失导致的工程信心流失。

小结

没有 SessionDirty 的测试框架，

问题并不集中爆发，而是以不可预测、难以调试、逐渐失控的方式呈现。

这些现象并不是偶发 bug，

而是缺少 session 状态建模时的系统性结果。