002_po

PO模式是一种在UI自动化测试中常用的设计模式，旨在提高代码的可维护性和可读性。

通过将每个页面封装成一个独立的对象，测试脚本可以更清晰地表达业务逻辑，同时降低因界面变化带来的维护成本。

📌 PO设计准则

页面封装
通过公共方法，代表页面提供的业务
不暴露页面细节
不在PO里做断言

🚁 PO分层

表现层: 包括页面中可见的元素、元素定位
操作层: 对元素的操作: 点击、输入等
业务层: 封装表现层和操作层，对应某个业务，可以是多个页面的组合
测试用例层: 不属于PO，而是使用页面类的方法来组合测试步骤，执行测试并验证结果。

具体设计和实现请参考: https://gitee.com/Jork-S-B/playwright-ui-automation

class BasePage(object):
    def __init__(self):
        self.page = get_page()
        # 根据类名，获取放在yaml文件的元素
        self.locators = get_yaml_data(ProjectPath.configs_path / 'common_elements.yaml').get(self.__class__.__name__,
                                                                                             "未找到类名，请检查")
        # 通过setattr，动态的将元素定位设置类变量
        # 实例直接调用会有警告，可通过__getitem__规避
        for key, value in self.locators.items():
            setattr(self, key, value)

    def __getitem__(self, item):
        return self.locators[item]

📌 面试题

🚁 如何开展UI自动化

确定范围及目标，优先选择重复性高、逻辑清晰、不易变动的用例。
制定测试策略，包括执行频率、测试数据管理。
根据应用类型选择适合的UI自动化工具。
设计测试用例，避免用例间存在依赖。
编写自动化脚本，使用Page Object模式。
集成到CI/CD流程，设置定时任务或触发机制。
监控及维护，根据异常或错误截图修改代码错误，搭配重试机制、等待策略提升稳定性。

🚁 PO模式的核心思想是什么？它解决了自动化测试中的哪些痛点？

核心思想：将页面的元素定位与操作逻辑分离，每个页面对应一个Page类，封装该页面的元素和操作。

解决痛点：

避免重复代码：封装后的方法能在多个用例中用到。
可维护性：当页面元素改变时，只需要修改对应Page类中的定位表达式，无需修改所有用例。
可读性：用例代码更简洁，符合“业务逻辑与实现细节分离”的原则。

🚁 适合做自动化的情况

无需人工交互，有明确预期结果
需多次运行
节省工程师时间的手动流程
资金领域的测试
单元测试
针对不同数据集的测试
关注应用程序的关键路径
需要对多个浏览器或手机运行的测试
用于负载/压测

🚁 如何提高自动化测试稳定性

环境可控 + 代码容错 + 结果直观

环境可控：

1.数据隔离：每个用例用独立数据，搭配setUp、tearDown方法，确保数据不冲突（或者pytest-datadir插件）

2.使用mock代替外部依赖

3.测试环境固定

代码容错：

1.显示等待

2.pytest-repeat重试机制

3.Page Object模式，减少代码改动

结果直观：

1.明确的预期结果

2.使用logging打印日志

3.执行步骤截图保存