第4章 测试框架与设计模式

第4章 · 测试框架与设计模式

本章要回答的三个问题：为什么单条用例都能跑通，攒成套件却改不动、看不懂、跑不快？页面对象模型到底解决什么问题，分层的边界画在哪里？测试数据和环境配置散落在用例里，怎么收拢成一处可管的东西？上一章解决"单条可靠"，本章解决"成套可维护"——从能写，走向能养。

为什么会有这一章

自动化项目的死法很少是"写不出来"，几乎都是"养不下去"。第一个月五十条用例岁月静好；半年后五百条，一次前端改版要修三天，修完这条那条又红；新同事接手，读一条用例像读天书；流水线一轮跑四小时，没人愿意等。这些症状的病理是同一个：用例之间复制粘贴，定位器散落各处，数据写死在代码里，环境切换靠改源码。

解药不是更努力地写用例，而是换一种组织方式。测试代码也是代码，软件工程几十年沉淀的组织智慧——分层、复用、依赖注入、数据与逻辑分离——全部适用，只是每一条都要落到自动化场景的特殊约束下重新推敲。本章把这些智慧收拢成四件工程工具：测试运行器的集成、页面对象模型、行为驱动表达、数据与配置管理。四件凑齐，套件才从"脚本的堆"变成"一个工程"。

读完能解决什么

读完本章，你应当能：用主流测试运行器把用例组织成可分层、可跳过、可参数化的套件，并让浏览器生命周期由夹具统一托管；把任意一堆线性脚本重构成页面对象结构，说清楚每层该放什么、不该放什么；判断团队要不要上行为驱动的表达方式，上了该怎么落地才不流于形式；把测试数据迁出代码、把环境配置收拢成带优先级的体系，实现一条命令切换环境。四样能力对应四节，学完它们，你的仓库才配得上"自动化工程"四个字。

各节怎么分工

这张分层图是本章的骨架：用例层说业务、页面对象层管页面、夹具层管资源、数据配置层管输入。箭头画的是依赖方向——上层依赖下层，下层不知道上层。第 7 章讲失败取证时你会发现，截图与日志的挂载点就在夹具层，这章打的底子到时候直接复用。

常见疑问

问：工程只有三十条用例，值得做这些结构改造吗？ 值得，且成本越早越低。结构改造的本质是让变化的代价恒定，三十条时建立的规矩，到三百条时依然生效；反过来，三百条时再改造，每一条用例都要动，成本放大十倍。结构投资的最佳窗口永远是"还来得及"的时候。

问：四节的内容有没有优先级？ 有：4.1 与 4.2 是地基，直接决定工程能否维护，优先做实；4.4 在多环境并行时价值暴涨，宜早不宜迟；4.3 最依赖团队协作土壤，条件不熟可以最后评估。

问：不用 pytest，这些思想还成立吗？ 成立。运行器换名字、夹具换语法，"托管生命周期、断言说话、数据外置、页面分层"四个思想在任何语言与框架里都有对应物——本册教的是思想，pytest 只是载体。

常见疑问

问：这一章的改造会不会影响现有用例的执行结果？ 结构改造的原则是行为不变：4.1 的夹具接管后，用例的输入输出与原来一致；4.2 的页面对象重构后，同一操作走同一路径。改造后跑一轮全量回归对比结果，是验收改造的标准动作——结果一致即改造成功，红屏即回头检查迁移遗漏。

先决条件

本章默认你已完成第 2 章环境搭建，并写过第 3 章风格的定位与等待代码。四节都围绕 Python 生态展开，需要了解 Python 的类与继承语法——页面对象是一组普通类；夹具机制会用到生成器语法（yield），不熟的话先花五分钟看一眼。行为驱动一节涉及自然语言描述与步骤映射的思想，不要求任何相关框架的使用经验。

往下走到哪

本章结束时你手里会是一个结构清晰、数据外置、环境可切的工程骨架。但单机单浏览器的骨架还不够——版本要兼容、执行要并行、环境要多套，下一章把这套骨架搬上规模化执行的舞台：兼容矩阵怎么定、并行怎么开、网格怎么搭。