为什么企业测试框架在规模化之后往往会引入 SessionDirty flag？
文章目录
- 为什么企业测试框架在规模化之后往往会引入 SessionDirty flag？
- 一、企业测试框架的起点：计数驱动模型
- 这种设计的前提假设是：
- 二、问题从哪里开始出现？
- 1️⃣ 单次失败就足以污染 Session
- 2️⃣ 计数模型无法表达“状态是否可继续复用”
- 三、SessionDirty flag 的本质是什么？
- 四、在什么条件下，SessionDirty 会成为必要抽象？
- 原因 1：计数只能表达“什么时候”，不能表达“是否”
- 原因 2：失败是一种“状态变化”，不是“事件”
- 原因 3：主流框架/生态中都有等价概念
- 五、没有 SessionDirty，会发生什么？
- 六、一个成熟框架的典型形态
- 七、没有 SessionDirty 的测试框架，通常会在哪些地方失控？
- 1️⃣ 失败后的行为变得不可预测
- 2️⃣ 生命周期决策被迫外溢到用例层
- 3️⃣ 清理逻辑开始变得重复且相互冲突
- 4️⃣ Debug 成本指数级上升
- 5️⃣ 团队开始“习惯性接受不稳定”
- 小结
在企业级 UI / E2E 自动化测试框架中，可以观察到这样一种现象：
不少框架在早期阶段并没有显式的 SessionDirty / SessionInvalid / ForceRestart 等状态标志，但随着规模扩大、用例增多，以及对执行稳定性和效率的要求提高，往往会引入这一类状态抽象。
这并不是“设计偏好”，而是工程实践反复验证后逐渐形成的一种结果。
本文结合企业测试框架的真实演化过程，解释为什么这一抽象最终不可避免。
一、企业测试框架的起点：计数驱动模型
大多数企业测试框架在最初阶段，都会采用类似这样的策略：
浏览器跑 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 后，生命周期会变得非常清晰：
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 状态建模时的系统性结果。
