【8周通关Python-游戏测试工程师 】303 unittest装饰器+钩子方法

文章目录

• 第三周 周三 Python学习执行方案（游戏自动化测试定向·unittest高级特性+用例前后置优化）
• • 一、 理论学习（35分钟，边学边实操，聚焦游戏测试场景）
  • • ✅ 核心知识点1：unittest 核心装饰器（@skip/@expectedFailure）——用例执行策略控制
    • • 装饰器1：@unittest.skip/reason——强制跳过用例（核心）
      • 装饰器2：@unittest.expectedFailure——标记预期失败用例
    • ✅ 核心知识点2：setUp/tearDown 钩子方法——用例前后置处理核心（今日重点）
  • 二、 游戏测试实战任务（25分钟，核心：优化TestGameLogin测试类+前后置处理）
  • 三、 今日知识点查漏补缺 + 游戏自动化测试扩展技巧
  • 四、 今日打卡与复盘表（直接填写）

第三周 周三 Python学习执行方案（游戏自动化测试定向·unittest高级特性+用例前后置优化）

今日学习时长：60分钟（35分钟理论 + 25分钟实战） 核心目标：掌握unittest框架两大高级特性——装饰器（@skip/@expectedFailure） 和钩子方法（setUp/tearDown）；基于第三周周二的TestGameLogin测试类完成实战优化，在setUp中统一初始化游戏登录测试账号数据，在tearDown中清理测试残留文件，实现用例前置标准化初始化、后置自动化清理，让测试用例更独立、更易维护，贴合工业级游戏自动化测试的实际需求。 前置衔接：完全复用第三周周二的unittest基础用法、TestGameLogin测试类及游戏登录业务函数，所有知识点均围绕「游戏登录自动化测试用例优化」展开，无超纲内容，学完可直接落地现有测试类的改造与升级。 学习价值：setUp/tearDown是自动化测试用例解耦、提效的核心，能解决测试数据重复定义、测试环境残留的痛点；unittest装饰器能灵活控制用例执行策略（跳过/预期失败），适配游戏测试中「功能未开发、用例暂不执行、已知bug用例」等实际场景，是游戏自动化测试工程师必须掌握的框架高级技能。

一、 理论学习（35分钟，边学边实操，聚焦游戏测试场景）

前置痛点回顾 第三周周二实现了游戏登录用例的标准化编写与自动化执行，但在实际游戏测试中，仍面临用例执行效率低、环境管理混乱、执行策略单一的核心问题：

今日理论围绕解决以上痛点展开，核心掌握「unittest两大装饰器用法、setUp/tearDown钩子方法核心逻辑与执行时机」，所有示例均基于游戏登录自动化测试场景，无缝衔接周二的代码。

✅ 核心知识点1：unittest 核心装饰器（@skip/@expectedFailure）——用例执行策略控制

unittest提供了一系列装饰器，用于灵活控制测试用例的执行策略，无需修改用例内部逻辑，只需在方法上方添加装饰器即可实现「跳过执行、预期失败」等效果，游戏测试中只需掌握两大核心装饰器，即可满足90%的执行策略需求。

装饰器的核心优势：无侵入式控制用例执行，不修改用例业务逻辑，仅标记执行规则，框架会自动识别并按规则处理，且在测试结果中单独统计，不影响正常用例的结果判断。

装饰器1：@unittest.skip/reason——强制跳过用例（核心）

核心作用 强制跳过指定测试用例，不执行任何代码，框架会在结果中标记为**s（skip的缩写），并统计跳过数量，适用于游戏功能未开发、用例暂不执行、依赖条件不满足**等场景（如游戏微信登录功能未开发，跳过对应的test_login_wechat用例）。

语法与分类 分为固定跳过和条件跳过两种，游戏测试中固定跳过使用频率更高，条件跳过适用于复杂的依赖判断场景。

# 1. 固定跳过（最常用）：直接指定跳过原因，无论什么条件都跳过
@unittest.skip(\”跳过原因：该功能暂未开发完成，待开发后执行\”)

# 2. 条件跳过：满足指定条件时才跳过，不满足则正常执行
@unittest.skipIf(condition, \”跳过原因：当condition为True时跳过\”)
# 示例：游戏版本号小于1.2.0时，跳过异地登录用例
@unittest.skipIf(GameConfig.VERSION < \”1.2.0\”, \”跳过原因：当前版本不支持异地登录功能\”)

游戏测试场景实战示例 基于周二的TestGameLogin测试类，添加微信登录用例并标记为跳过：

import unittest
# 复用周二的game_login业务函数
def game_login(account, password):
CORRECT_ACCOUNT = \”game_auto_001\”
CORRECT_PASSWORD = \”GameAuto@123\”
if account == CORRECT_ACCOUNT and password == CORRECT_PASSWORD:
return \”登录成功，返回用户ID：20001\”
else:
return \”登录失败，提示：账号或密码错误\”

class TestGameLogin(unittest.TestCase):
def test_login_success(self):
\”\”\”正确账号密码-登录成功\”\”\”
actual = game_login(\”game_auto_001\”, \”GameAuto@123\”)
self.assertEqual(actual, \”登录成功，返回用户ID：20001\”)

# 添加微信登录用例，标记为跳过（功能未开发）
@unittest.skip(\”跳过原因：微信扫码登录功能暂未开发，V1.2版本上线后执行\”)
def test_login_wechat(self):
\”\”\”微信扫码登录-登录成功\”\”\”
# 暂未实现具体逻辑，跳过执行
actual = \”登录成功，微信绑定用户ID：20001\”
self.assertEqual(actual, \”登录成功，微信绑定用户ID：20001\”)

运行结果（跳过用例统计）

s.
———————————————————————-
Ran 2 tests in 0.000s

OK (skipped=1)

结果解读：

• s：表示该用例被跳过执行，.表示正常执行成功；
• OK (skipped=1)：总用例执行成功，其中1个用例被跳过，跳过用例不影响整体「OK」结果；
• 框架会自动统计跳过数量，便于后续查看测试覆盖度。

装饰器2：@unittest.expectedFailure——标记预期失败用例

核心作用 标记指定用例为「预期失败」，用例执行后即使断言失败，框架也会标记为**x（expected failure的缩写），并统计为「预期失败」，不纳入正常的失败用例统计；若用例意外执行成功，会标记为X，提示「预期失败但实际成功」。 适用于游戏已知bug对应的用例**（如异地登录提示异常，开发已确认bug，待修复），避免已知bug导致测试结果出现大量失败，影响测试报告的有效性。

语法（无额外参数，直接装饰）

@unittest.expectedFailure

游戏测试场景实战示例 基于游戏登录场景，添加异地登录用例，标记为预期失败（已知bug：异地登录无提醒）：

class TestGameLogin(unittest.TestCase):
def test_login_success(self):
\”\”\”正确账号密码-登录成功\”\”\”
actual = game_login(\”game_auto_001\”, \”GameAuto@123\”)
self.assertEqual(actual, \”登录成功，返回用户ID：20001\”)

# 标记为预期失败（已知bug：异地登录未触发提醒，待修复）
@unittest.expectedFailure
def test_login_remote(self):
\”\”\”异地登录-预期触发登录提醒\”\”\”
actual = game_login(\”game_auto_001\”, \”GameAuto@123\”) # 模拟异地登录执行结果
self.assertEqual(actual, \”登录成功，触发异地登录提醒\”) # 实际返回无提醒，断言会失败

运行结果（预期失败用例统计）

.x
———————————————————————-
Ran 2 tests in 0.000s

OK (expected failures=1)

结果解读：

• .：正常执行成功，x：预期失败用例执行失败（符合预期）；
• OK (expected failures=1)：总用例执行成功，其中1个用例为预期失败，不影响整体「OK」结果；
• 若该用例后续修复后执行成功，框架会标记为X，提示开发和测试人员「bug已修复，可移除装饰器」。

两大装饰器核心区别与游戏测试适用场景对比