SeleniumBase Case Plans 测试用例管理实战以 Calculator 计算器测试 test_6_times_7_plus_12_equals_54 为例【免费下载链接】SeleniumBaseAPIs for browser automation, testing, and bypassing bot-detection. Includes CDP Mode: A stealthy configuration for chromium that passes every bot detection test.项目地址: https://gitcode.com/GitHub_Trending/se/SeleniumBase导读SeleniumBase 是面向浏览器自动化、测试与反机器人检测的 Python 框架而Case Plans测试用例计划是其中一套基于 Markdown 表格的测试用例管理方案。本文以仓库中的实例文档 examples/case_plans/test_calculator.CalculatorTests.test_6_times_7_plus_12_equals_54.md 为骨架结合 examples/test_calculator.py、Case Plans 生成器源码以及 Behave 步骤定义完整拆解从 Case Plan 到可运行测试的全过程。读完本文你将掌握 Case Plans 的文件格式、生成与汇总命令、Markdown 表格书写规范以及 Calculator 示例测试的每一行代码与底层实现原理。一、Case Plan 文件长什么样读懂关联文档关联文档examples/case_plans/test_calculator.CalculatorTests.test_6_times_7_plus_12_equals_54.md是 SeleniumBase 仓库中最典型的已定制化Case Plan 示例全文如下test_calculator.py::CalculatorTests::test_6_times_7_plus_12_equals_54 --- | # | Step Description | Expected Result | | - | ---------------- | --------------- | | 1 | Open https://seleniumbase.io/apps/calculator. br / Perform the following calculation: 6 × 7 12 | The output is 54 after pressing |该文件的结构非常清晰由三个部分组成第一行测试定位符以两个反引号包裹的test_calculator.py::CalculatorTests::test_6_times_7_plus_12_equals_54格式为文件名.py::类名::方法名。这正是 pytest 收集测试的标准 ID 格式是 Case Plan 与具体测试代码一一对应的身份证。第二行分隔线---用于将测试定位符与下方的 Markdown 表格区分开。Markdown 测试表格表头为#步骤序号、Step Description步骤描述、Expected Result预期结果。本用例只含一步打开计算器页面并执行6 × 7 12按下后输出应为54。该 Case Plan 的核心语义是以人类可读的自然语言描述一个测试步骤及其验收标准而真正的自动化验证则由测试代码完成。当渲染在 GitHub 等支持 Markdown 的代码托管平台上时这份表格会直接显示为规整的测试计划无需打开任何 GUI 工具即可被团队成员审阅。二、与 Case Plan 对应的真实测试代码Case Plan 描述的测试在仓库中真实存在其实现位于 examples/test_calculator.pyTest the SeleniumBase Calculator App from seleniumbase import BaseCase BaseCase.main(__name__, __file__) class CalculatorTests(BaseCase): def test_6_times_7_plus_12_equals_54(self): self.goto(seleniumbase.io/apps/calculator) self.click(button[id6]) self.click(button#multiply) self.click(button[id7]) self.click(button#add) self.click(button[id1]) self.click(button[id2]) self.click(button#equal) self.assert_exact_text(54, input#output)对照 Case Plan 逐行解读| Case Plan 步骤 | 对应代码 | 说明 | | - | - | - | | Open 计算器页面 |self.goto(seleniumbase.io/apps/calculator)| 打开官方在线计算器应用 | | 输入 6 |self.click(button[id6])| 点击数字按钮 6 | | 输入 × |self.click(button#multiply)| 点击乘法按钮 | | 输入 7 |self.click(button[id7])| 点击数字按钮 7 | | 输入 |self.click(button#add)| 点击加法按钮 | | 输入 12 |self.click(button[id1])/self.click(button[id2])| 依次点击数字 1 和 2 | | 按 |self.click(button#equal)| 点击等号触发计算 | | 输出为 54 |self.assert_exact_text(54, input#output)| 断言输入框中的文本精确等于54|2.1 选择器风格说明测试代码中混用了两种选择器写法这在 SeleniumBase 中都是合法且等价的button[id6]标准 CSS 属性选择器定位 id 为6的 button 元素button#multiplyCSS ID 简写等价于button[idmultiply]。self.click()是 SeleniumBaseBaseCase提供的高级点击方法内部已封装了等待元素可见、滚动到元素、处理遮挡等常见问题因此这里的每一步点击都无需手写显式等待。2.2assert_exact_text的精确断言语义最后一行断言使用的方法在 seleniumbase/fixtures/base_case.py#L10964 中有明确定义Similar toassert_text(), but the text must be exact, rather than exist as a subset of the full text. (Extra whitespace at the beginning or the end doesnt count.)即assert_exact_text(text, selector)要求元素文本与期望值完全一致首尾空白被忽略而assert_text只要求期望文本是元素文本的子串。从源码实现看它的默认超时时间为settings.SMALL_TIMEOUT内部依次处理了 Shadow DOM 选择器__is_shadow_selector、CDP 模式__is_cdp_swap_needed时转发给self.cdp.assert_exact_text以及 Demo 模式高亮等分支。因此对计算器输出框input#output断言54可以确保运算结果恰好是 54 而不是546或包含其他字符的文本。2.3 运行该测试在仓库根目录执行pytest examples/test_calculator.py -q如需只运行本 Case Plan 对应的这一个方法可用 pytest 的-k过滤pytest examples/test_calculator.py -k test_6_times_7_plus_12_equals_54 -q运行前提是已安装 SeleniumBase 及其依赖详见 help_docs/install.md并且机器上存在可用的浏览器驱动SeleniumBase 会自动下载所需驱动。三、Case Plans 机制Markdown 表格驱动的测试用例管理单个 Case Plan 文件只是载体支撑它的是一整套以 help_docs/case_plans.md 为说明文档、以 seleniumbase/console_scripts/sb_caseplans.py 为实现的测试用例管理系统。其核心设计思想是用 Markdown 表格编写测试计划直接在 GitHub 等支持 Markdown 的代码托管平台中展示并以case_summary.md汇总所有用例。3.1 三个状态等级系统为每个 Case Plan 定义了三种状态见sb_caseplans.py中view_summary_of_existing_case_plans的判定逻辑已定制化customized tables表格中包含真实测试步骤而非占位符——判定条件是文件中不包含| 1 | Perform Action 1 | Verify Action 1 |这一默认占位行⭕使用样板代码boilerplate code仍保留默认生成的占位步骤尚未填写真实内容缺少表格missing a table文件内容过少不满足竖线数 ≥ 9 且短横线数 ≥ 3的最小 Markdown 表格判定条件。本文关联文档所属的test_calculatorCase Plan 即属于 已定制化状态这从仓库根目录 examples/case_summary.md 的汇总表也可以印证12 个 Case Plan 全部为 已定制化表格。3.2 如何生成 Case Plan 样板文件Case Plans 提供 GUI 生成器通过控制台命令启动sbase caseplans该命令在sb_caseplans.py的main()中实现内部通过pytest --collect-only -q --rootdir./收集当前目录下所有测试源码位于 seleniumbase/console_scripts/sb_caseplans.py再用 tkinter 弹出选择界面。你可以通过附加参数限制收集范围规则与 pytest 的用例发现规则一致sbase caseplans # 收集当前目录全部测试 sbase caseplans -k agent # 仅收集名称匹配 agent 的测试 sbase caseplans -m marker2 # 仅收集标记为 marker2 的测试 sbase caseplans test_suite.py # 仅收集指定测试文件 sbase caseplans offline_examples/ # 仅收集指定目录下的测试在 GUI 中选中缺少 Case Plan 的测试后点击Generate boilerplate Case Plans for selected tests missing them系统会为每个测试生成样板文件。生成逻辑generate_case_plan_boilerplates要点如下文件名由测试 ID 转换而来get_test_id()将test_calculator.py::CalculatorTests::test_...中的.py::与::替换为.再拼接.md后缀得到test_calculator.CalculatorTests.test_6_times_7_plus_12_equals_54.md文件存放位置与测试文件所在目录相关测试在根目录时放在case_plans/文件夹测试在子目录时放在子目录/case_plans/文件夹样板内容即帮助文档中展示的占位表格proxy_test.py::ProxyTests::test_proxy --- | # | Step Description | Expected Result | | - | ---------------- | --------------- | | 1 | Perform Action 1 | Verify Action 1 | | 2 | Perform Action 2 | Verify Action 2 |生成后需要像本文关联文档那样把占位步骤改写为真实的步骤描述与预期结果才能完成从 ⭕ 到 的升级。3.3 生成汇总文件 case_summary.md点击 GUI 中的Generate Summary of existing Case Plans按钮对应源码中的view_summary_of_existing_case_plans系统会扫描所有已存在的 Case Plan生成一个汇总文件case_summary.md存放于启动 GUI 的当前目录注意这与单个样板文件生成到case_plans/文件夹的位置不同。汇总文件包含状态统计表与可折叠的用例明细details/summary仓库中的实例如 examples/case_summary.md 所示。四、Markdown 表格书写规范Case Plans 之所以能在代码托管平台正常渲染依赖的是严格的 Markdown 表格语法。帮助文档 help_docs/case_plans.md 特别强调了以下要点管道符、短横线与空格的位置必须正确表头行、分隔行| - | ---------------- | --------------- |与数据行的列数必须一致分隔行中的短横线数量不限但每列至少一个-单元格内换行使用br /例如关联文档中的 Open https://seleniumbase.io/apps/calculator.Perform the following calculation: 6 × 7 12这在 GitHub 渲染时会显示为同一单元格内的两行文本空单元格用| |表示两个管道符之间放一个空格表示该单元格为空测试 ID 用双反引号包裹形如test_calculator.py::CalculatorTests::test_...保证在表格之外也能以等宽字体清晰展示。遵循以上规范即可保证 Case Plan 文件在 GitHub、GitLab 等平台正确渲染为可读性极佳的测试计划表。五、同类测试的多种实现方式Behave BDD 视角test_calculator这一计算器场景在仓库中并非只有 pytest 一种实现。以 examples/behave_bdd/features/steps/calculator.py 为例Behave BDD 风格下每个计算器按键都被封装为 step 定义step(Open the Calculator App) def go_to_calculator(context): context.sb.goto(https://seleniumbase.io/apps/calculator) step(Press ×) def press_multiply(context): context.sb.click(button#multiply) step(Press ) def press_add(context): context.sb.click(button#add) step(Press ) def press_equal(context): context.sb.click(button#equal) step(Verify output is {output}) def verify_output(context, output): sb context.sb sb.assert_exact_text(output, #output)对应的 feature 文件如 examples/behave_bdd/features/calculator.feature可以直接用自然语言书写行为Scenario: ... Given Open the Calculator App When Evaluate [6×712] Then Verify output is 54可以看到无论是 pytest 方法式还是 Behave BDD 式底层调用的断言方法完全相同都是assert_exact_text验证的也是同一个期望结果54。这恰好说明 Case Plan 表格描述的是与实现方式无关的测试意图——同样的计划可以由 pytest、Behave 甚至 CDP Mode 脚本参考 examples/cdp_mode/raw_cdp.py 等示例来落地。六、从 Case Plan 到质量闭环小结回顾整条链路SeleniumBase 的 Case Plans 提供了一套轻量而完整的测试用例管理实践编写计划用sbase caseplans的 GUI 为既有测试一键生成样板 Case Plan或直接手写测试ID --- Markdown 表格三件套定制步骤把样板占位行改写为真实的步骤描述与预期结果如本文关联文档6 × 7 12 54完成 状态升级汇总展示用Generate Summary of existing Case Plans生成case_summary.md在代码托管平台直接呈现全部用例的状态看板落地执行Case Plan 中的每个步骤都有对应的可运行测试代码examples/test_calculator.py验收标准最终由assert_exact_text等断言方法在真实浏览器中自动验证。这种人可读的计划 机器可执行的代码双轨结构让测试文档不再是与代码脱节的静态表格而是与仓库中真实测试一一对应的活文档。若想进一步了解 Case Plans 的完整说明与更多示例可查阅 help_docs/case_plans.md 及 examples/case_plans 目录下的其余 7 份 Case Plan 文件。【免费下载链接】SeleniumBaseAPIs for browser automation, testing, and bypassing bot-detection. Includes CDP Mode: A stealthy configuration for chromium that passes every bot detection test.项目地址: https://gitcode.com/GitHub_Trending/se/SeleniumBase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考