# playwright

**Repository Path**: chicken-c/playwright

## Basic Information

- **Project Name**: playwright
- **Description**: ui自动化测试
- **Primary Language**: Python
- **License**: MulanPSL-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2025-09-14
- **Last Updated**: 2025-09-17

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README


### 解决重复登陆问题
1. 在cases/conftest.py中，有两个fixtrue,分别是login_save_auth和browser_context_args.
2. 前者是我们自定义的一个fixtrue,他的参数中第一个browser参数很重要，他是playwright的默认的browser fixtrue,这是session级别的，也就是整个测试中只会有唯一一个browser
3. 在login_save_auth中我们通过这个browser创建了context和page,来进行登录。登录成功后我们保存了他的登录态信息到auth中。
4. 第二个fixtrue则是playwright内置的一个fixtrue,他的返回值可以决定browser.new_context()时这个新建的context的启动配置参数。我们定义一个重名的fixtrue,然后在内置的配置参数返回的字典中加入我们的加载cookis的字段。
5. 这样我们每次通过 page fixtrue 创建的context就会先加载cookies信息了.

    
### 登录/注册页面的特殊处理
1. browser_context_args **fixture 只会影响默认**的 context。
2. new_context() 是手动创建一个新的 context，它不会自动加载 browser_context_args 中定义的任何参数，除非你在创建时显式传入。
```python
def test_login_page(browser):
context = browser.new_context()  # 不带 cookies
page = context.new_page()
page.goto("https://your-app.com/login")
# 执行登录相关操作
context.close()
```

- 在 pytest-playwright 中，browser_context_args 这个 fixture 只会影响 默认的 context。也就是说，默认情况下，**每个测试用例中通过 page fixture 创建的 context 都会自动带上你在 browser_context_args 里定义的配置**（例如：storage_state）。
- 但是当你手动创建 context 时，它不会自动加载 browser_context_args 中的配置。你需要显式地将 storage_state 或其他自定义配置传递给 new_context()。
 
- browser_context_args 是 pytest-playwright 插件在创建内置 context / page fixture 时自动使用的一组参数。如果你直接在测试里调用 browser.new_context()，不会自动注入 browser_context_args，除非你显式把它传进去或把 browser_context_args 作为 fixture 参数拿到并解包传入。




### Allure报告统一添加模块名和标题

这段 hook 在每次测试的运行阶段读取测试类/模块与测试函数的 docstring，然后通过 allure.dynamic.feature 和 allure.dynamic.title 动态把这些字符串写入到当前测试的 Allure 元数据里，从而使报告显示人类可读、语义化的 feature 和标题。只要确保在 hook 中安全地读取属性并不阻断 pytest 的默认执行流程，它就能稳健地发挥作用。

- item.parent._obj.__doc__

  - item.parent._obj：取得父 collector 对应的 Python 对象（例如测试类对象或模块对象）。

   - .__doc__：取该对象的 docstring（类或模块的说明文本），该文本通常是你写在类定义上方的三引号注释。

   - 如果存在 docstring（非空），则下一行执行：

   - allure.dynamic.feature(item.parent._obj.__doc__)

   - 这行调用 Allure 的 run-time API，为 当前正在执行的测试用例 动态设置 feature 字段。Allure 会把这个 feature 信息记录到当前测试用例的元数据中，最终体现在 Allure 报告的“Feature”栏里。

    - 因为此代码在每个测试的 call 阶段执行，Allure 会把父类（或模块）的 docstring 当作该测试的 feature。

- if item.function.__doc__:

    - item.function 指向被测试的实际 Python 函数对象（测试函数或测试方法）。.__doc__ 是该函数的 docstring（通常写在函数定义顶部的说明）。

    - 若有 docstring，就执行下一行：

    - allure.dynamic.title(item.function.__doc__)
   
    - 这会把函数 docstring 动态设置为 Allure 报告中的 title（即测试用例标题）。因此，报告上会显示你在函数 docstring 写的描述，而不是函数名。


### 自动截图录屏

**“你们的自动化框架在执行和失败收集上是怎么设计的？”**

---

我们这个框架是基于 **pytest + Playwright** 搭建的，并且做了二次封装，把用例执行和失败收集过程集成到了 Allure 报告里。

1. **用例执行**

   * 每个测试用例都会通过 pytest 的 fixture 获取一个 `page` 对象。
   * 这个 `page` 背后是一个 `browser_context`，在 fixture 里我们对 `context.close()` 做了包装，保证关闭时能自动收集额外信息。
   * 业务操作是通过 Page Object 模式封装的，比如输入、点击、导航，测试用例里只写断言。

2. **失败检测**

   * pytest 在执行时会调用 hook `pytest_runtest_makereport`。
   * 我们在这个 hook 里拿到测试结果，如果 `rep_call.failed == True`，就把失败标记到当前用例的 node 上。

3. **失败收集（ArtifactsRecorder）**

   * 在 `did_finish_test` 方法里，如果发现用例失败，就会收集 **三类信息**：

     * 截图（最后页面快照）
     * trace（用户操作轨迹）
     * video（执行过程录屏）
   * 这些文件会保存到 pytest 的 `--output` 目录，并且用 `allure.attach.file()` 的方式挂载到 Allure 报告里。
   * 此外，在 `on_will_close_browser_context` 里，我们还兜底抓一张截图，避免因为上下文关闭导致没有现场信息。

4. **报告呈现**

   * 这样，每个失败的用例在 Allure 报告中都会显示测试步骤，还能直接点开截图、trace、视频，快速定位问题。
   * 成功的用例则不会收集冗余的附件，保证报告体积不会膨胀。

---

## 🔑 关键点总结

* **pytest hook → 检测失败**
* **fixture 生命周期 → 管理上下文和兜底截图**
* **Allure attach → 报告里集成截图/trace/video**

最终效果是：失败时能自动收集所有调试信息，报告可视化非常完整，极大提升了问题定位效率。

---