写用例容易给用例“化妆”难。这是我在搭建Web UI自动化测试框架时最深的体会。跑用例阶段大家关注的是断言和元素定位可一旦用例跑到几十上百条要交给团队其他同事看结果、要应付每周的回归汇报时光秃秃的控制台输出根本拿不出手。这一篇我们专门解决两件事一是给pytest selenium这套体系接入allure测试报告并让报告里的展示信息足够丰富——有功能模块、有操作步骤、有失败截图甚至有严重等级二是顺手封装几个高频操作把driver管理、元素操作、日志输出和数据驱动统一起来免得每条用例里都是重复代码。放心这一篇的每一个配置我都会给全你照着抄就能跑通。1. 先读懂pytest和allure是怎么协作的1.1 allure-pytest的插件机制很多人第一次接触allure时有个误区以为allure是selenium或者unittest的附属品。其实allure是一套独立的结果展示框架它只负责读取JSON格式的结果文件再渲染成HTML报告。中间的桥梁是allure-pytest这个插件。pip install allure-pytest装完之后pytest在每次执行用例时都会自动收集测试的执行状态包括用例名、耗时、断言信息、日志甚至你在用例里手动attach的文本和图片最后生成到一个results目录里。这个目录里面全是以UUID命名的JSON和TXT文件直接看没有任何可读性但allure命令行工具能把这些文件转换成一个带侧边栏、饼图、趋势图的HTML站点。这个机制的好处是结果文件和执行过程解耦。也就是说跑用例的机器上可以没有allure命令行工具只要生成results目录就行报告可以事后在本地或者专门的报告机上生成。这刚好适合公司里的CI流水线——或者你想偷懒的时候也可以直接用allure serve起一个临时HTTP服务来看。1.2 目录规划和报告的说明书给项目做个规范。我现在的自动化项目目录大致是这样的auto_ui_test/ ├── testcase/ # 测试用例集 │ ├── test_login.py │ ├── test_order.py ├── page/ # PO模式页面对象 │ ├── base_page.py │ ├── login_page.py ├── common/ # 公共封装 │ ├── driver_factory.py │ ├── logger.py ├── data/ # 测试数据文件 │ ├── login_data.yaml ├── reports/ # 报告输出目录 │ ├── allure-results # pytest运行生成的原始结果 │ ├── allure-report # allure生成的HTML报告 ├── pytest.inipytest.ini里最关键的是这两行配置[pytest] addopts -s -v --alluredir ./reports/allure-results --clean-alluredir testpaths ./testcase--alluredir用来指定原始结果文件的输出目录--clean-alluredir会在每次执行前清空上一次的残留文件这一步非常重要。我一开始没加这个参数结果跑了十几次用例后报告里混着几十个历史用例光排查就花了一上午。执行完用例以后生成最终HTML报告的命令是allure generate ./reports/allure-results -o ./reports/allure-report --clean这里要提醒一点allure generate的-o参数指定的输出目录如果已经存在且不是空目录命令会报错所以要养成加--clean的习惯。想看临时报告、不落地的话用allure serve ./reports/allure-results更省事它会自动在浏览器里打开。2. 给用例“加剧情”allure装饰器让报告有血有肉2.1 feature、story、title、description把报告切成金字塔刚接入allure时我的报告里只有一片用例名左侧导航栏空荡荡的和pytest输出没什么本质区别。真正让报告产生质变的是如下几个装饰器import allure allure.feature(登录模块) allure.story(用户登录) allure.title(验证正确的用户名密码可以登录) allure.description(输入正确用户名和密码点击登录按钮断言跳转到首页) def test_login_success(): ...这4个装饰器在报告里的层级关系我用生活类比解释一下。feature相当于一个大的功能模块比如“登录模块”“购物车模块”story是模块里具体的用户场景比如“用户登录”“用户登出”title是测试用例的名称description是对用例的详细说明默认会显示在用例详情页的最顶部。报告首页的左上角会有Behavior这一栏它把用例按feature和story分成了树状结构。你只要在装饰器里用中文把feature和story写清楚报告就能变成一份“按功能模块聚合的测试执行清单”而不是一串无意义的用例名。团队里不懂技术的产品同事也能轻松看懂哪块功能是稳的、哪块挂了。2.2 step装饰器把操作拆成可复查的步骤UI自动化失败最让人头痛的场景是报告告诉你某一步断言失败但你根本不知道用例在执行到哪一步才出的错。元素没找到页面标题不对弹窗挡住了按钮这时候step装饰器就派上用场了。allure.step(输入用户名: {0}) def input_username(username): ... allure.step(点击登录按钮) def click_login_btn(): ...用allure.step修饰的调用会以层级步骤的形式展示在用例详情页里每一步有独立的标题、时间、状态甚至支持入参占位符格式化。运行后报告里能看到类似这样的链路输入用户名: admin → 输入密码: 123456 → 点击登录按钮 → 断言跳转结果。这比在代码里写一堆print要正式得多而且步骤是结构化数据失败时可以直接在报告里定位到具体步骤。特别注意一点allure.step和with allure.step(...)是可以嵌套的。我在写复杂流程时会这样组织def test_create_order(): with allure.step(准备测试数据): ... with allure.step(进入创建订单页面): ... with allure.step(填写订单并提交): ...嵌套后的报告是树状展开的非常清晰。2.3 severity、link和动态标题在运行时补充信息UI自动化用例里有些用例影响核心功能挂了必须立刻处理有些用例只是边角料挂了可以晚点再看。allure提供了severity装饰器来标记严重等级from allure import severity_level allure.severity(severity_level.CRITICAL) def test_pay(): ...等级分为BLOCKER、CRITICAL、NORMAL、MINOR、TRIVIAL五个档位。报告首页的用例统计饼图会按严重等级配色展示执行完一眼就能看出最严重的用例分布在哪里。建议把冒烟用例全部标成BLOCKER或CRITICAL这样每次回归时报告的“危险信号”会非常显眼。另外两个实用装饰器是allure.link和allure.issue可以在用例详情里追加外部链接。我用它挂过缺陷管理系统的单号用例挂了点报告里的链接直接跳到对应的bug单省去了翻来翻去查对应关系的功夫。动态标题也是一个很香的功能。特殊场景下用例标题需要从接口返回值或者数据库里读取的用户名拼出来这时候固定写在装饰器里的title就不够用了。可以用如下方式在用例内部动态修改allure.dynamic.title(用户{0}的登录用例) def test_dynamic_title(username): allure.dynamic.title(f用户{username}的登录用例)这个功能在我们做数据驱动时特别有用后面讲到数据封装时你会看到它的实际价值。3. 报告里的细节截图、日志和自定义环境信息3.1 失败自动截图并挂到bug详情里做UI自动化测试没有截图几乎等于白测。页面崩了、样式变了、弹窗遮挡了这些用文字根本描述不清楚一张截图直接锤实问题。allure里加载截图的方式是通过attachimport allure def save_screenshot(driver, namescreenshot): timestamp time.strftime(%Y%m%d_%H%M%S) path f/tmp/{name}_{timestamp}.png driver.save_screenshot(path) with open(path, rb) as f: allure.attach(f.read(), namef{name}_{timestamp}, attachment_typeallure.attachment_type.PNG)手动在每条用例里调用这个方法可行但太麻烦。我建议把截图逻辑挂到pytest的钩子上实现失败自动截图。在conftest.py里这样写import allure import pytest pytest.hookimpl(tryfirstTrue, hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.when call and report.failed: driver item.funcargs.get(driver_ini) if driver: with open(/tmp/failure.png, rb) as f: allure.attach(f.read(), namefailure_screenshot, attachment_typeallure.attachment_type.PNG)钩子机制的原理不复杂pytest每执行一个用例的setup、call、teardown三个阶段都会触发pytest_runtest_makereport钩子。通过判断report.when call且report.failed就能拦截到断言失败但也还没出测试阶段的那一刻此时driver还活着来得及截图。这一步是让报告从“可用”走向“好用”的分水岭强烈建议一开始就加上。3.2 日志怎么和allure穿到一条线上UI自动化用例跑动过程中自动化控制台的日志通常是没人看的。但排查故障时需要定位操作顺序或者是某个页面响应时间太长、加载超时。我用的办法是把日志输出到文件的同时再用attach的形式塞进allure报告def attach_log_to_allure(log_path): with open(log_path, r, encodingutf-8) as f: content f.read() allure.attach(content, namepytest日志, attachment_typeallure.attachment_type.TEXT)配合一个标准的logging封装。这里我贴一个我自己在用的简化版import logging def get_logger(): logger logging.getLogger(auto_ui) logger.setLevel(logging.INFO) if not logger.handlers: handler logging.FileHandler(./logs/auto_ui.log, encodingutf-8) fmt logging.Formatter(%(asctime)s - %(name)s - %(levelname)s - %(message)s) handler.setFormatter(fmt) logger.addHandler(handler) return logger关键在于if not logger.handlers否则每次调用get_logger()都会加一个handler日志会重复打印好多份。这个细节我在实际项目里踩过坑——排查了半天发现一个操作被记录了三次就是因为conftest里多个fixture各自调用了logging.basicConfig或者get_logger。现在这套封装配合allure的attach用例执行完报告详情里既有截图又有一整份时间线一致的日志排查效率翻倍。3.3 在allure报告首页放自定义环境信息打开allure生成的HTML报告首页Overview里有一块Environment条目。默认它是空的但只要你提供了environment.properties文件它就能显示出自定义的字段。这非常适合展示自动化项目的版本、浏览器版本、执行环境地址、执行时间等团队在意的信息。这个文件的内容格式很简单BrowserChrome 126.0 Browser.Version126.0.6478.126 URLhttps://test.example.com OSWindows 11 TestEnv测试环境 Python.Version3.11.4关键是文件放在哪。allure读取的规则是如果在原始results目录下找到environment.properties就会自动引用。所以在生成报告之前需要把这个文件拷贝到reports/allure-results目录下。我习惯在conftest.py里写个session级别的fixture自动生成并放置这个文件pytest.fixture(scopesession, autouseTrue) def write_environment(): with open(./reports/allure-results/environment.properties, w, encodingutf-8) as f: f.write(URLhttps://test.example.com\n) f.write(BrowserChrome 126.0\n)这里要特别叮嘱一句原始results目录在执行用例时会被--clean-alluredir清空。所以这个fixture一定得是autouse且在用例执行前运行也就是session启动时就把它生成出来而不能放在某个用例内部。不然执行完以后文件没了报告里还是空白。4. 不止是报告让框架少写重复代码的封装技巧4.1 driver单例别30条用例开30个浏览器接触了这么多项目我发现最影响UI自动化稳定性的因素不是元素定位而是浏览器进程管理。很多新手写用例时每条用例里都来一套driver webdriver.Chrome()跑完也不quit最后把公司测试机的进程拖垮。我推荐用一个DriverFactory统一管理driver生命周期from selenium import webdriver class DriverFactory: _driver None classmethod def get_driver(cls, browserchrome): if cls._driver is None: if browser chrome: cls._driver webdriver.Chrome() elif browser edge: cls._driver webdriver.Edge() cls._driver.maximize_window() cls._driver.implicitly_wait(10) return cls._driver这个类的核心思路是单例_driver是类变量多条用例调用DriverFactory.get_driver()时拿到的都是同一个浏览器实例不会重复开窗口。适合模块级别的用例复用同一个页面上下文。配合conftest.py里的fixture浏览器最终还是会正确关掉pytest.fixture(scopeclass) def driver_ini(): driver DriverFactory.get_driver(chrome) yield driver driver.quit() DriverFactory._driver None为什么quit之后要把_driver重置为None因为如果不重置下一条模块的fixture调用get_driver()时拿到的还是一个已经关闭的driver对象后面所有元素操作都会抛InvalidSessionIdException。这个坑我在框架初期踩了整整两天。管理driver就是这个道理——打开浏览器很容易但确保它在正确的时间被创建、被销毁才是框架稳定运行的关键。4.2 BasePage把find_element、click、input装进统一入口页面对象模式PO模式在Web UI自动化里的地位不用我多说了。但很多人写Page类时每个页面里都在重复self.driver.find_element(By.ID, xxx).click()这种代码。更好的做法是封装一个BasePage基类把最常用的底层操作统一收敛起来class BasePage: def __init__(self, driver): self.driver driver def find_element(self, locator, timeout10, screenshot_nameNone): element WebDriverWait(self.driver, timeout).until( EC.presence_of_element_located(locator) ) return element def input_text(self, locator, text): element self.find_element(locator) element.clear() element.send_keys(text) def click_element(self, locator): element self.find_element(locator) self.driver.execute_script(arguments[0].scrollIntoView();, element) element.click() def get_text(self, locator): return self.find_element(locator).text封装时有一个细节值得讲一下。你的click_element里我加了一行scrollIntoView这是因为很多情况下元素在页面底部或者被浮动弹层遮挡selenium的点击会直接报ElementClickInterceptedException。先把元素滚动到可视区域点击成功率会明显提升。UI自动化经常遇到这种“明明元素存在但点不了”的诡异问题这类问题的原因大多就是元素不可交互。BasePage一旦封装好LoginPage就干净多了class LoginPage(BasePage): username_loc (By.ID, username) password_loc (By.ID, password) login_btn_loc (By.ID, login_btn) def login(self, username, password): self.input_text(self.username_loc, username) self.input_text(self.password_loc, password) self.click_element(self.login_btn_loc)将来如果用户名的定位方式从ID变成了name只需要改一行——不需要把整个测试用例翻过来找。维护成本大幅下降这其实就是我们做封装的最根本目的把变化框在一个可控的范围内。4.3 数据驱动用yaml文件喂参数用例数量翻倍但代码量不涨UI自动化里最怕的是同一个流程被复制粘贴5遍就是因为用户名密码组合不同。一个登录功能的用例至少得覆盖账密正确、密码错误、用户不存在、用户被锁定这几个场景。用数据驱动的方式一套代码可以喂进多组数据。我的做法是把测试数据放进yaml文件# data/login_data.yaml test_login_data: - username: admin password: 123456 expect: 登录成功 - username: admin password: wrong expect: 用户名或密码错误然后在testcase里读取并做参数化import pytest import yaml import allure with open(./data/login_data.yaml, r, encodingutf-8) as f: test_data yaml.safe_load(f)[test_login_data] allure.feature(登录模块) class TestLogin: pytest.mark.parametrize(data_info, test_data, idslambda d: d[expect]) def test_login_cases(self, driver_ini, data_info): with allure.step(f测试数据{data_info[expect]}): login_page LoginPage(driver_ini) login_page.login(data_info[username], data_info[password]) assert data_info[expect] login_page.get_login_result()所以你看数据量和UI场景翻倍了但代码并没有多写一行。这里穿插一个小技巧ids参数可以让参数化后每条用例在报告里显示为可读的标识否则一堆data_info0、data_info1看多了真的很痛苦。配合前文讲的allure.dynamic.title每条数据用例的报告标题甚至可以显示为“账密正确可登录”“密码错误提示正确”这种业务语言全组看报告时赏心悦目。再补充一个更贴近实际工程的细节yaml文件读取建议在模块级完成而不是每个用例内读取。这样执行用例时文件只会被读取一次不会产生重复的IO开销。如果文件路径写错了模块导入阶段就会直接报错这也能帮你在执行前就发现问题。5. 从几十次执行里筛出来的避坑经验5.1 常见问题速查表现象原因解决办法报告HTML打开后样式全丢report目录和results目录相对位置不对或者直接用浏览器打开了allure-results目录里的HTML用allure generate -o专门输出报告目录不要直接打开results目录里的文件报告里用例数量翻倍旧用例一直残留--clean-alluredir没加pytest.ini的addopts里补上--clean-alluredirallure装饰器不生效报告里没有feature和story装饰器加在了没有实际被pytest收集的方法上或拼写错误确认装饰器写在test_开头的方法上并检查pytest执行时是否真的收集到了这个方法截图在报告中显示的是空白文件或者加载失败attach读取的路径不对或者PNG文件损坏先确认本地文件存在、大小非0再用with open(... , rb)以二进制方式读取失败用例没有截图conftest.py里钩子实现位置不对或item.funcargs拿不到driver确认钩子写在根目录的conftest.py里且driver是作为fixture参数传入用例的pytest执行报“allure报告不存在”服务端没有安装allure命令行工具安装allure-commandline或用allure serve替代generate中文乱码文件编码不一致所有with open都强制指定encodingutf-8日志文件同理5.2 四条“常规文档不会告诉你”的实操心得第一不要把allure generate和执行用例绑死在同一个命令里。我见过很多人喜欢把addopts --alluredir...和后续的处理全部写在一个shell脚本里。其实执行用例和生成报告是两个阶段执行用例发生在CI的构建机器上生成报告则应该是独立的构建产物阶段。把这两个步骤拆开能充分利用CICD的构建缓存代码没变、历史用例结果可以复用报告生成就能跳过无用功。第二allure.attach尽量在循环外调用。有些同事在一个for循环里对每个页面元素都调用一次截图attach几十次下来报告体积直接上到几百MB。截图是宝贵的问题定位素材但不需要每步都截。我建议按“每个操作步骤至多一张失败截图”来控制既保留证据又控制体量。如果确实需要保留整个操作录像可以把save_screenshot换个思路变成save视频但这个后续再说。第三装饰器和数据驱动结合时优先级要搞清楚。allure.feature和allure.story这俩装饰器只能写固定值allure.title也一样。如果你用的是参数化用例动态信息请全部通过allure.dynamic.*在用例内部设置。否则你会发现参数化后报告的用例列表里每一行都是同一个标题根本分不清是哪组数据。第四environment.properties和categories.json这两个文件是让报告显得“专业”的关键。其中categories.json可以自定义报告首页失败和通过用例的分类图标和折叠规则比如把“已知缺陷”和“新发现缺陷”分开展示。这在团队里提交测试周报的时候特别有用因为你可以直接截图allure报告首页作为质量结论。我常用的categories.json结构是这样的[ {name: 功能阻塞缺陷, matchedStatuses: [failed], messageRegex: .*AssertionError.*}, {name: 环境异常, matchedStatuses: [broken]}, {name: 已跳过的用例, matchedStatuses: [skipped]} ]把它放进reports/allure-results目录后重新生成报告首页的结论板块就会按我们的业务口径重新分组。这个文件的内容还可以用脚本来动态生成配合项目里的缺陷分类体系非常实用。这一篇把allure报告的信息展示和框架里的几个高频封装点都铺开了。我在实际项目中最大的体会是自动化测试框架的每一步进化都应该以“别人能不能看得懂、能不能复用”为准绳。报告信息丰富了团队才愿意看你的结果代码封装干净了后续的用例才能写得不辛苦。下一期可以聊一聊更复杂的多浏览器并行执行或者把这份报告生成直接放进CI体系里让每次提交代码都自动跑一遍冒烟用例。
Allure+pytest+selenium打造丰富可读的Web UI自动化测试报告
写用例容易给用例“化妆”难。这是我在搭建Web UI自动化测试框架时最深的体会。跑用例阶段大家关注的是断言和元素定位可一旦用例跑到几十上百条要交给团队其他同事看结果、要应付每周的回归汇报时光秃秃的控制台输出根本拿不出手。这一篇我们专门解决两件事一是给pytest selenium这套体系接入allure测试报告并让报告里的展示信息足够丰富——有功能模块、有操作步骤、有失败截图甚至有严重等级二是顺手封装几个高频操作把driver管理、元素操作、日志输出和数据驱动统一起来免得每条用例里都是重复代码。放心这一篇的每一个配置我都会给全你照着抄就能跑通。1. 先读懂pytest和allure是怎么协作的1.1 allure-pytest的插件机制很多人第一次接触allure时有个误区以为allure是selenium或者unittest的附属品。其实allure是一套独立的结果展示框架它只负责读取JSON格式的结果文件再渲染成HTML报告。中间的桥梁是allure-pytest这个插件。pip install allure-pytest装完之后pytest在每次执行用例时都会自动收集测试的执行状态包括用例名、耗时、断言信息、日志甚至你在用例里手动attach的文本和图片最后生成到一个results目录里。这个目录里面全是以UUID命名的JSON和TXT文件直接看没有任何可读性但allure命令行工具能把这些文件转换成一个带侧边栏、饼图、趋势图的HTML站点。这个机制的好处是结果文件和执行过程解耦。也就是说跑用例的机器上可以没有allure命令行工具只要生成results目录就行报告可以事后在本地或者专门的报告机上生成。这刚好适合公司里的CI流水线——或者你想偷懒的时候也可以直接用allure serve起一个临时HTTP服务来看。1.2 目录规划和报告的说明书给项目做个规范。我现在的自动化项目目录大致是这样的auto_ui_test/ ├── testcase/ # 测试用例集 │ ├── test_login.py │ ├── test_order.py ├── page/ # PO模式页面对象 │ ├── base_page.py │ ├── login_page.py ├── common/ # 公共封装 │ ├── driver_factory.py │ ├── logger.py ├── data/ # 测试数据文件 │ ├── login_data.yaml ├── reports/ # 报告输出目录 │ ├── allure-results # pytest运行生成的原始结果 │ ├── allure-report # allure生成的HTML报告 ├── pytest.inipytest.ini里最关键的是这两行配置[pytest] addopts -s -v --alluredir ./reports/allure-results --clean-alluredir testpaths ./testcase--alluredir用来指定原始结果文件的输出目录--clean-alluredir会在每次执行前清空上一次的残留文件这一步非常重要。我一开始没加这个参数结果跑了十几次用例后报告里混着几十个历史用例光排查就花了一上午。执行完用例以后生成最终HTML报告的命令是allure generate ./reports/allure-results -o ./reports/allure-report --clean这里要提醒一点allure generate的-o参数指定的输出目录如果已经存在且不是空目录命令会报错所以要养成加--clean的习惯。想看临时报告、不落地的话用allure serve ./reports/allure-results更省事它会自动在浏览器里打开。2. 给用例“加剧情”allure装饰器让报告有血有肉2.1 feature、story、title、description把报告切成金字塔刚接入allure时我的报告里只有一片用例名左侧导航栏空荡荡的和pytest输出没什么本质区别。真正让报告产生质变的是如下几个装饰器import allure allure.feature(登录模块) allure.story(用户登录) allure.title(验证正确的用户名密码可以登录) allure.description(输入正确用户名和密码点击登录按钮断言跳转到首页) def test_login_success(): ...这4个装饰器在报告里的层级关系我用生活类比解释一下。feature相当于一个大的功能模块比如“登录模块”“购物车模块”story是模块里具体的用户场景比如“用户登录”“用户登出”title是测试用例的名称description是对用例的详细说明默认会显示在用例详情页的最顶部。报告首页的左上角会有Behavior这一栏它把用例按feature和story分成了树状结构。你只要在装饰器里用中文把feature和story写清楚报告就能变成一份“按功能模块聚合的测试执行清单”而不是一串无意义的用例名。团队里不懂技术的产品同事也能轻松看懂哪块功能是稳的、哪块挂了。2.2 step装饰器把操作拆成可复查的步骤UI自动化失败最让人头痛的场景是报告告诉你某一步断言失败但你根本不知道用例在执行到哪一步才出的错。元素没找到页面标题不对弹窗挡住了按钮这时候step装饰器就派上用场了。allure.step(输入用户名: {0}) def input_username(username): ... allure.step(点击登录按钮) def click_login_btn(): ...用allure.step修饰的调用会以层级步骤的形式展示在用例详情页里每一步有独立的标题、时间、状态甚至支持入参占位符格式化。运行后报告里能看到类似这样的链路输入用户名: admin → 输入密码: 123456 → 点击登录按钮 → 断言跳转结果。这比在代码里写一堆print要正式得多而且步骤是结构化数据失败时可以直接在报告里定位到具体步骤。特别注意一点allure.step和with allure.step(...)是可以嵌套的。我在写复杂流程时会这样组织def test_create_order(): with allure.step(准备测试数据): ... with allure.step(进入创建订单页面): ... with allure.step(填写订单并提交): ...嵌套后的报告是树状展开的非常清晰。2.3 severity、link和动态标题在运行时补充信息UI自动化用例里有些用例影响核心功能挂了必须立刻处理有些用例只是边角料挂了可以晚点再看。allure提供了severity装饰器来标记严重等级from allure import severity_level allure.severity(severity_level.CRITICAL) def test_pay(): ...等级分为BLOCKER、CRITICAL、NORMAL、MINOR、TRIVIAL五个档位。报告首页的用例统计饼图会按严重等级配色展示执行完一眼就能看出最严重的用例分布在哪里。建议把冒烟用例全部标成BLOCKER或CRITICAL这样每次回归时报告的“危险信号”会非常显眼。另外两个实用装饰器是allure.link和allure.issue可以在用例详情里追加外部链接。我用它挂过缺陷管理系统的单号用例挂了点报告里的链接直接跳到对应的bug单省去了翻来翻去查对应关系的功夫。动态标题也是一个很香的功能。特殊场景下用例标题需要从接口返回值或者数据库里读取的用户名拼出来这时候固定写在装饰器里的title就不够用了。可以用如下方式在用例内部动态修改allure.dynamic.title(用户{0}的登录用例) def test_dynamic_title(username): allure.dynamic.title(f用户{username}的登录用例)这个功能在我们做数据驱动时特别有用后面讲到数据封装时你会看到它的实际价值。3. 报告里的细节截图、日志和自定义环境信息3.1 失败自动截图并挂到bug详情里做UI自动化测试没有截图几乎等于白测。页面崩了、样式变了、弹窗遮挡了这些用文字根本描述不清楚一张截图直接锤实问题。allure里加载截图的方式是通过attachimport allure def save_screenshot(driver, namescreenshot): timestamp time.strftime(%Y%m%d_%H%M%S) path f/tmp/{name}_{timestamp}.png driver.save_screenshot(path) with open(path, rb) as f: allure.attach(f.read(), namef{name}_{timestamp}, attachment_typeallure.attachment_type.PNG)手动在每条用例里调用这个方法可行但太麻烦。我建议把截图逻辑挂到pytest的钩子上实现失败自动截图。在conftest.py里这样写import allure import pytest pytest.hookimpl(tryfirstTrue, hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.when call and report.failed: driver item.funcargs.get(driver_ini) if driver: with open(/tmp/failure.png, rb) as f: allure.attach(f.read(), namefailure_screenshot, attachment_typeallure.attachment_type.PNG)钩子机制的原理不复杂pytest每执行一个用例的setup、call、teardown三个阶段都会触发pytest_runtest_makereport钩子。通过判断report.when call且report.failed就能拦截到断言失败但也还没出测试阶段的那一刻此时driver还活着来得及截图。这一步是让报告从“可用”走向“好用”的分水岭强烈建议一开始就加上。3.2 日志怎么和allure穿到一条线上UI自动化用例跑动过程中自动化控制台的日志通常是没人看的。但排查故障时需要定位操作顺序或者是某个页面响应时间太长、加载超时。我用的办法是把日志输出到文件的同时再用attach的形式塞进allure报告def attach_log_to_allure(log_path): with open(log_path, r, encodingutf-8) as f: content f.read() allure.attach(content, namepytest日志, attachment_typeallure.attachment_type.TEXT)配合一个标准的logging封装。这里我贴一个我自己在用的简化版import logging def get_logger(): logger logging.getLogger(auto_ui) logger.setLevel(logging.INFO) if not logger.handlers: handler logging.FileHandler(./logs/auto_ui.log, encodingutf-8) fmt logging.Formatter(%(asctime)s - %(name)s - %(levelname)s - %(message)s) handler.setFormatter(fmt) logger.addHandler(handler) return logger关键在于if not logger.handlers否则每次调用get_logger()都会加一个handler日志会重复打印好多份。这个细节我在实际项目里踩过坑——排查了半天发现一个操作被记录了三次就是因为conftest里多个fixture各自调用了logging.basicConfig或者get_logger。现在这套封装配合allure的attach用例执行完报告详情里既有截图又有一整份时间线一致的日志排查效率翻倍。3.3 在allure报告首页放自定义环境信息打开allure生成的HTML报告首页Overview里有一块Environment条目。默认它是空的但只要你提供了environment.properties文件它就能显示出自定义的字段。这非常适合展示自动化项目的版本、浏览器版本、执行环境地址、执行时间等团队在意的信息。这个文件的内容格式很简单BrowserChrome 126.0 Browser.Version126.0.6478.126 URLhttps://test.example.com OSWindows 11 TestEnv测试环境 Python.Version3.11.4关键是文件放在哪。allure读取的规则是如果在原始results目录下找到environment.properties就会自动引用。所以在生成报告之前需要把这个文件拷贝到reports/allure-results目录下。我习惯在conftest.py里写个session级别的fixture自动生成并放置这个文件pytest.fixture(scopesession, autouseTrue) def write_environment(): with open(./reports/allure-results/environment.properties, w, encodingutf-8) as f: f.write(URLhttps://test.example.com\n) f.write(BrowserChrome 126.0\n)这里要特别叮嘱一句原始results目录在执行用例时会被--clean-alluredir清空。所以这个fixture一定得是autouse且在用例执行前运行也就是session启动时就把它生成出来而不能放在某个用例内部。不然执行完以后文件没了报告里还是空白。4. 不止是报告让框架少写重复代码的封装技巧4.1 driver单例别30条用例开30个浏览器接触了这么多项目我发现最影响UI自动化稳定性的因素不是元素定位而是浏览器进程管理。很多新手写用例时每条用例里都来一套driver webdriver.Chrome()跑完也不quit最后把公司测试机的进程拖垮。我推荐用一个DriverFactory统一管理driver生命周期from selenium import webdriver class DriverFactory: _driver None classmethod def get_driver(cls, browserchrome): if cls._driver is None: if browser chrome: cls._driver webdriver.Chrome() elif browser edge: cls._driver webdriver.Edge() cls._driver.maximize_window() cls._driver.implicitly_wait(10) return cls._driver这个类的核心思路是单例_driver是类变量多条用例调用DriverFactory.get_driver()时拿到的都是同一个浏览器实例不会重复开窗口。适合模块级别的用例复用同一个页面上下文。配合conftest.py里的fixture浏览器最终还是会正确关掉pytest.fixture(scopeclass) def driver_ini(): driver DriverFactory.get_driver(chrome) yield driver driver.quit() DriverFactory._driver None为什么quit之后要把_driver重置为None因为如果不重置下一条模块的fixture调用get_driver()时拿到的还是一个已经关闭的driver对象后面所有元素操作都会抛InvalidSessionIdException。这个坑我在框架初期踩了整整两天。管理driver就是这个道理——打开浏览器很容易但确保它在正确的时间被创建、被销毁才是框架稳定运行的关键。4.2 BasePage把find_element、click、input装进统一入口页面对象模式PO模式在Web UI自动化里的地位不用我多说了。但很多人写Page类时每个页面里都在重复self.driver.find_element(By.ID, xxx).click()这种代码。更好的做法是封装一个BasePage基类把最常用的底层操作统一收敛起来class BasePage: def __init__(self, driver): self.driver driver def find_element(self, locator, timeout10, screenshot_nameNone): element WebDriverWait(self.driver, timeout).until( EC.presence_of_element_located(locator) ) return element def input_text(self, locator, text): element self.find_element(locator) element.clear() element.send_keys(text) def click_element(self, locator): element self.find_element(locator) self.driver.execute_script(arguments[0].scrollIntoView();, element) element.click() def get_text(self, locator): return self.find_element(locator).text封装时有一个细节值得讲一下。你的click_element里我加了一行scrollIntoView这是因为很多情况下元素在页面底部或者被浮动弹层遮挡selenium的点击会直接报ElementClickInterceptedException。先把元素滚动到可视区域点击成功率会明显提升。UI自动化经常遇到这种“明明元素存在但点不了”的诡异问题这类问题的原因大多就是元素不可交互。BasePage一旦封装好LoginPage就干净多了class LoginPage(BasePage): username_loc (By.ID, username) password_loc (By.ID, password) login_btn_loc (By.ID, login_btn) def login(self, username, password): self.input_text(self.username_loc, username) self.input_text(self.password_loc, password) self.click_element(self.login_btn_loc)将来如果用户名的定位方式从ID变成了name只需要改一行——不需要把整个测试用例翻过来找。维护成本大幅下降这其实就是我们做封装的最根本目的把变化框在一个可控的范围内。4.3 数据驱动用yaml文件喂参数用例数量翻倍但代码量不涨UI自动化里最怕的是同一个流程被复制粘贴5遍就是因为用户名密码组合不同。一个登录功能的用例至少得覆盖账密正确、密码错误、用户不存在、用户被锁定这几个场景。用数据驱动的方式一套代码可以喂进多组数据。我的做法是把测试数据放进yaml文件# data/login_data.yaml test_login_data: - username: admin password: 123456 expect: 登录成功 - username: admin password: wrong expect: 用户名或密码错误然后在testcase里读取并做参数化import pytest import yaml import allure with open(./data/login_data.yaml, r, encodingutf-8) as f: test_data yaml.safe_load(f)[test_login_data] allure.feature(登录模块) class TestLogin: pytest.mark.parametrize(data_info, test_data, idslambda d: d[expect]) def test_login_cases(self, driver_ini, data_info): with allure.step(f测试数据{data_info[expect]}): login_page LoginPage(driver_ini) login_page.login(data_info[username], data_info[password]) assert data_info[expect] login_page.get_login_result()所以你看数据量和UI场景翻倍了但代码并没有多写一行。这里穿插一个小技巧ids参数可以让参数化后每条用例在报告里显示为可读的标识否则一堆data_info0、data_info1看多了真的很痛苦。配合前文讲的allure.dynamic.title每条数据用例的报告标题甚至可以显示为“账密正确可登录”“密码错误提示正确”这种业务语言全组看报告时赏心悦目。再补充一个更贴近实际工程的细节yaml文件读取建议在模块级完成而不是每个用例内读取。这样执行用例时文件只会被读取一次不会产生重复的IO开销。如果文件路径写错了模块导入阶段就会直接报错这也能帮你在执行前就发现问题。5. 从几十次执行里筛出来的避坑经验5.1 常见问题速查表现象原因解决办法报告HTML打开后样式全丢report目录和results目录相对位置不对或者直接用浏览器打开了allure-results目录里的HTML用allure generate -o专门输出报告目录不要直接打开results目录里的文件报告里用例数量翻倍旧用例一直残留--clean-alluredir没加pytest.ini的addopts里补上--clean-alluredirallure装饰器不生效报告里没有feature和story装饰器加在了没有实际被pytest收集的方法上或拼写错误确认装饰器写在test_开头的方法上并检查pytest执行时是否真的收集到了这个方法截图在报告中显示的是空白文件或者加载失败attach读取的路径不对或者PNG文件损坏先确认本地文件存在、大小非0再用with open(... , rb)以二进制方式读取失败用例没有截图conftest.py里钩子实现位置不对或item.funcargs拿不到driver确认钩子写在根目录的conftest.py里且driver是作为fixture参数传入用例的pytest执行报“allure报告不存在”服务端没有安装allure命令行工具安装allure-commandline或用allure serve替代generate中文乱码文件编码不一致所有with open都强制指定encodingutf-8日志文件同理5.2 四条“常规文档不会告诉你”的实操心得第一不要把allure generate和执行用例绑死在同一个命令里。我见过很多人喜欢把addopts --alluredir...和后续的处理全部写在一个shell脚本里。其实执行用例和生成报告是两个阶段执行用例发生在CI的构建机器上生成报告则应该是独立的构建产物阶段。把这两个步骤拆开能充分利用CICD的构建缓存代码没变、历史用例结果可以复用报告生成就能跳过无用功。第二allure.attach尽量在循环外调用。有些同事在一个for循环里对每个页面元素都调用一次截图attach几十次下来报告体积直接上到几百MB。截图是宝贵的问题定位素材但不需要每步都截。我建议按“每个操作步骤至多一张失败截图”来控制既保留证据又控制体量。如果确实需要保留整个操作录像可以把save_screenshot换个思路变成save视频但这个后续再说。第三装饰器和数据驱动结合时优先级要搞清楚。allure.feature和allure.story这俩装饰器只能写固定值allure.title也一样。如果你用的是参数化用例动态信息请全部通过allure.dynamic.*在用例内部设置。否则你会发现参数化后报告的用例列表里每一行都是同一个标题根本分不清是哪组数据。第四environment.properties和categories.json这两个文件是让报告显得“专业”的关键。其中categories.json可以自定义报告首页失败和通过用例的分类图标和折叠规则比如把“已知缺陷”和“新发现缺陷”分开展示。这在团队里提交测试周报的时候特别有用因为你可以直接截图allure报告首页作为质量结论。我常用的categories.json结构是这样的[ {name: 功能阻塞缺陷, matchedStatuses: [failed], messageRegex: .*AssertionError.*}, {name: 环境异常, matchedStatuses: [broken]}, {name: 已跳过的用例, matchedStatuses: [skipped]} ]把它放进reports/allure-results目录后重新生成报告首页的结论板块就会按我们的业务口径重新分组。这个文件的内容还可以用脚本来动态生成配合项目里的缺陷分类体系非常实用。这一篇把allure报告的信息展示和框架里的几个高频封装点都铺开了。我在实际项目中最大的体会是自动化测试框架的每一步进化都应该以“别人能不能看得懂、能不能复用”为准绳。报告信息丰富了团队才愿意看你的结果代码封装干净了后续的用例才能写得不辛苦。下一期可以聊一聊更复杂的多浏览器并行执行或者把这份报告生成直接放进CI体系里让每次提交代码都自动跑一遍冒烟用例。
