16｜你的自动化框架怎么分层的？PO 模式解决什么问题？

开场分层从底往上讲——这题区分你是「会写脚本」还是「会建框架」，薪资差距就在这。

回答思路

第一步：四层加数据驱动

层	封装什么
基础层	工具驱动封装（Selenium/Playwright）、等待策略、截图、日志
页面对象层	每个页面一个类，封装元素定位和页面操作
业务层	跨页面的业务流程封装成方法（如「登录加下单」整个流程）
用例层	只写业务语义的步骤和断言，不含任何定位和实现细节

再配数据驱动：用例和测试数据分离，一套逻辑跑多组数据。

第二步：PO 模式的价值讲透

它解决的是「元素定位和用例逻辑耦合」的痛点：页面改版只改页面对象层一处，几十条用例不用动。没有 PO 的自动化，一次 UI 改版就是全量重写——这就是烂尾的根源。把这个因果讲出来，说明你懂自动化为什么死。

第三步：工程配套补齐

pytest 的 fixture 管理环境前后置、conftest 共享、失败自动截图和重跑、Allure 报告、日志分级——这些工程细节决定框架能不能被团队用起来。

第四步：讲一个自己的真实数字

框架大概多少条用例、跑一遍多久、稳定性多少——数字一出，真框架和背概念立刻分开。

收尾：给演进方向

用例分层执行（冒烟集分钟级）、接 CI 定时跑、失败用例自动归类——让框架活在线上，而不是躺在本机。

考察重点

维度	说明
企业动机	测试开发岗的核心题。「会写脚本」的企业要花大价钱养，「会建框架」的来了就能带队
过线标准	分层清晰 + PO 的价值讲到解耦和维护成本
区分度	能讲「UI 改版只改一层」这个维护收益的，是真维护过框架的；只会念分层名词的是网上抄的
加分项	fixture、失败截图、CI 集成这些工程配套，以及真实用例数和稳定性数字
减分项	说 PO 是「一个页面写一个文件」这种字面理解，暴露没写过

来源

整理自知识星球帖《面试情报 02｜软件测试必备 20 题》，返回题库。