【每日一题】Page Object 模式，哪种写法是跑偏的（附参考答案）

兴趣爱好交流
,
1

题目：关于 UI 自动化的 Page Object（PO）模式，下列说法错误的是（）

A. 页面对象只封装「这个页面上有什么、能做什么」，断言留在测试用例里；把断言塞进页面方法会让页面对象退化成用例的私有脚本
B. 公共操作（打开页面、查找元素、显式等待、截图）沉到 BasePage，具体页面继承并只写自己的定位与业务动作
C. 一个页面类里同时写定位、断言、测试数据、业务流转和 pytest 用例标记，文件数少、页面改版时只改一个文件，所以是 PO 的最佳实践
D. 页面方法的返回值建议是下一个页面对象或结构化数据，让用例读起来像业务叙述；跨页面的完整流程可以再抽一层 BusinessFlow

难度：初级
题型：笔试（单选）

2

:point_right:参考答案/答题要点：

答案：C

  • C 描述的是"上帝类"，恰恰违反 PO 的初衷。PO 的目标是隔离 UI 变化：定位器变更只影响一个页面对象，而不是让用例层、数据层、断言层互相缠绕。文件少不等于分层好，反而会让复用和并行都变差。
  • A：断言归属是用例（Test）层，页面层只保证"操作成功执行"。这条界限是 PO 与关键字驱动最容易混的地方。
  • B：BasePage 收敛等待与异常处理（含失败截图 / DOM 快照），是稳定性的关键抓手。
  • D：链式返回 + 业务流程层，接近 Screenplay / 分层自动化（组件层 → 页面层 → 流程层 → 用例层）的思路。
  • 延伸采分点：用例里出现 by.XPATH 就是腐化信号；定位器优先级（id/稳定业务属性 > CSS > XPath，不用绝对路径和文案）；测试数据外置（参数化 / YAML / 造数服务），不硬编码在页面对象里；PO 只解决可维护性，不解决 Flaky，稳定性还要配合等待策略、环境隔离与失败重试。