写过测试项目的人大概都遇到过这种尴尬项目是拼起来的——被测系统用别人的开源 Demo用例零散地写在一个文件里跑完结果在控制台一闪而过设计文档和代码各说各话。面试时想讲清我怎么设计用例、怎么保证前后一致、失败怎么归因很难拿出完整的证据链。所以我把测试工程需要的三块拼图放进了同一个仓库并且让它们强一致角色是什么在哪被测系统ParaBank Lite —— 登录 / 注册 / 转账的简易银行系统parabank_lite.py、templates/parabank/自动化用例56 条 pytest Selenium 用例按登录 15 / 注册 22 / 转账 19 分三个套件pytest_suites/测试平台展示套件与用例、触发执行、看执行记录、失败归因、手工验证台app.py、static/单一事实来源业务规则、等价类划分、用例表、预置数据testcase_spec.py项目用 Flask SQLite 自建被测系统用 pytest Selenium 写自动化用例再配一个可视化的测试管理平台。开箱可跑MIT 协议。图 1 仓库首页三块拼图与改一处即可全局同步的设计一、核心设计用例表是唯一的事实来源这是整个项目里我最想讲的一点。很多测试项目的文档和代码是两份互相抄的东西改了一边忘了另一边时间一长就对不上。这个项目的做法是让 testcase_spec.py 成为唯一的来源——业务规则、等价类划分、56 条用例的数据与预期结果、预置演示数据全部写在这一个文件里。被测系统的校验逻辑、平台库里的用例目录、pytest 套件、以及 docs/ 下的用例文档统统由它派生。用例表一变check_consistency.py会把不一致的地方全部指出来22 项校验横跨五个层面用例表自洽等价类覆盖、优先级分布、用例编号唯一性被测系统的校验层是否真的覆盖了每条规则平台库里的用例目录是否与用例表同步pytest 实际收集到的用例是否对得上docs/ 下的设计文档是否与用例表一致。外加一条最硬的平台实际执行出来的失败集合必须正好等于缺陷清单。图 2 单一事实来源与三层结构一份用例表派生被测系统校验、平台目录、pytest 套件与文档二、一次执行的完整链路在平台上点一下执行整套件背后会发生这些事平台起一个 pytest 子进程pytest 用 Selenium 驱动无头 Edge打开被测系统逐条跑断言pytest-json-report产出 JSON 报告平台解析报告把结果写进test_results表前端轮询实时回填通过率、状态分布、失败归因和近 7 天趋势。失败原因会被归类成ASSERT_/TIMEOUT_/NOELEMENT_/NETWORK_/DRIVER_五类并带上堆栈与耗时不用再翻日志找原因。图 3 一次执行从触发、执行、入库到可视化的完整链路三、平台长什么样平台前端是 Vue Element Plus ECharts主要有这么几块仪表盘用例总数、通过率、状态分布、近 7 天趋势测试套件 / 用例列表56 条用例用例编号即 pytest 的参数化 ID执行记录 / 结果明细汇总看板加每条用例的状态、失败原因、堆栈与耗时手工验证台自己填参数跑一次真实操作只记录系统实际返回不做文档断言——适合探索式验证。图 4 平台概览用例数、通过率、状态分布与近 7 天趋势下方是 56 条用例列表四、被测系统ParaBank Lite被测系统是自己写的简易银行系统只做登录、注册、转账外加账户概览与流水页面该有的提示文案一条不少目的就是让用例有真实的断言对象。预置数据由用例表派生的种子脚本自动重建每次跑用例前还会自动复位——比如主账号 alice01 / Pass123 同时持有 A / B / C 三个账户初始余额分别是 100000.00 / 0.00 / 100.00转账用例就在这组数据上做加减。图 5 被测系统 ParaBank Lite 登录页五、56 条用例是怎么来的用例表严格按业务规则文档和《等价类划分与测试用例.xlsx》落地先划等价类、再定边界、最后落成用例每条都标了优先级模块规则数等价类数用例数P0P1P2套件登录78153120login_suite注册69228140register_suite转账710197111transfer_suite合计20275618371—六、缺陷注入让失败归因有东西可看为了让平台的失败归因、失败明细、状态分布这些能力真的有东西可看被测系统里刻意注入了 3 处缺陷——每一处都注明违反了文档里的哪条规则、预期让哪几条用例失败缺陷违反的规则预期失败用例归因BUG-01 登录未区分账号不存在与密码错误2.1(5)(6)LOGIN_002、LOGIN_003ASSERT_BUG-02 金额上限边界写成≥ 50000 即超限2.3(2)TRAN_005ASSERT_BUG-03 漏做仅允许一个小数点校验2.3(4)TRAN_013ASSERT_预期结果56 条用例52 通过 / 4 失败失败集合必须正好等于上表——多红一条或少红一条check_consistency.py都会报错。把parabank_lite.py里的INJECT_DEFECTS改成False重启就能得到一个完全符合文档、56 条全绿的被测系统。七、快速开始环境要求Windows也兼容 Linux / macOS、Python 3.11、本机装有 Chrome 或 Edge。驱动不用自己装Selenium Manager 会自动匹配内网环境可用PB_DRIVER_PATH指定。# 方式 AWindows 一键启动首次自动建 venv 并装依赖 run_windows.bat # 方式 B手动 python -m venv .venv .venv\Scripts\python.exe -m pip install -r requirements.txt .venv\Scripts\python.exe app.py启动后有两个入口测试平台http://127.0.0.1:5000/被测系统http://127.0.0.1:5000/parabank/login本机无头 Edge 实测耗时登录套件约 15s、注册套件约 31s、转账套件约 39s全套 56 条约 85 秒。八、技术栈Python 3.11 · pytest 9.x · Selenium 4.x · Flask 3.x · SQLite · Vue Element Plus ECharts写在最后这个项目从 0 到 1 肝了一段时间代码完全开源MIT 协议。如果你也在准备软件测试 / 测试开发方向的面试或者想找一个开箱可跑的测试工程练手希望它能帮你把简历上那块完整测试闭环的拼图补上。觉得还行的话求一个 Star ⭐这是持续更新的最大动力。仓库地址GitHub - hjxandcxq/parabank-lite-test-platform: 自建被测系统 39 条 pytest/Selenium 用例 Flask 测试平台用例表单一事实来源22 项一致性校验 · GitHub有部署问题、或者想交流用例设计与一致性维护的做法欢迎评论区留言 开源 | ParaBank Lite 自动化测试平台：自建被测系统 + 56 条 pytest/Selenium 用例
写过测试项目的人大概都遇到过这种尴尬项目是拼起来的——被测系统用别人的开源 Demo用例零散地写在一个文件里跑完结果在控制台一闪而过设计文档和代码各说各话。面试时想讲清我怎么设计用例、怎么保证前后一致、失败怎么归因很难拿出完整的证据链。所以我把测试工程需要的三块拼图放进了同一个仓库并且让它们强一致角色是什么在哪被测系统ParaBank Lite —— 登录 / 注册 / 转账的简易银行系统parabank_lite.py、templates/parabank/自动化用例56 条 pytest Selenium 用例按登录 15 / 注册 22 / 转账 19 分三个套件pytest_suites/测试平台展示套件与用例、触发执行、看执行记录、失败归因、手工验证台app.py、static/单一事实来源业务规则、等价类划分、用例表、预置数据testcase_spec.py项目用 Flask SQLite 自建被测系统用 pytest Selenium 写自动化用例再配一个可视化的测试管理平台。开箱可跑MIT 协议。图 1 仓库首页三块拼图与改一处即可全局同步的设计一、核心设计用例表是唯一的事实来源这是整个项目里我最想讲的一点。很多测试项目的文档和代码是两份互相抄的东西改了一边忘了另一边时间一长就对不上。这个项目的做法是让 testcase_spec.py 成为唯一的来源——业务规则、等价类划分、56 条用例的数据与预期结果、预置演示数据全部写在这一个文件里。被测系统的校验逻辑、平台库里的用例目录、pytest 套件、以及 docs/ 下的用例文档统统由它派生。用例表一变check_consistency.py会把不一致的地方全部指出来22 项校验横跨五个层面用例表自洽等价类覆盖、优先级分布、用例编号唯一性被测系统的校验层是否真的覆盖了每条规则平台库里的用例目录是否与用例表同步pytest 实际收集到的用例是否对得上docs/ 下的设计文档是否与用例表一致。外加一条最硬的平台实际执行出来的失败集合必须正好等于缺陷清单。图 2 单一事实来源与三层结构一份用例表派生被测系统校验、平台目录、pytest 套件与文档二、一次执行的完整链路在平台上点一下执行整套件背后会发生这些事平台起一个 pytest 子进程pytest 用 Selenium 驱动无头 Edge打开被测系统逐条跑断言pytest-json-report产出 JSON 报告平台解析报告把结果写进test_results表前端轮询实时回填通过率、状态分布、失败归因和近 7 天趋势。失败原因会被归类成ASSERT_/TIMEOUT_/NOELEMENT_/NETWORK_/DRIVER_五类并带上堆栈与耗时不用再翻日志找原因。图 3 一次执行从触发、执行、入库到可视化的完整链路三、平台长什么样平台前端是 Vue Element Plus ECharts主要有这么几块仪表盘用例总数、通过率、状态分布、近 7 天趋势测试套件 / 用例列表56 条用例用例编号即 pytest 的参数化 ID执行记录 / 结果明细汇总看板加每条用例的状态、失败原因、堆栈与耗时手工验证台自己填参数跑一次真实操作只记录系统实际返回不做文档断言——适合探索式验证。图 4 平台概览用例数、通过率、状态分布与近 7 天趋势下方是 56 条用例列表四、被测系统ParaBank Lite被测系统是自己写的简易银行系统只做登录、注册、转账外加账户概览与流水页面该有的提示文案一条不少目的就是让用例有真实的断言对象。预置数据由用例表派生的种子脚本自动重建每次跑用例前还会自动复位——比如主账号 alice01 / Pass123 同时持有 A / B / C 三个账户初始余额分别是 100000.00 / 0.00 / 100.00转账用例就在这组数据上做加减。图 5 被测系统 ParaBank Lite 登录页五、56 条用例是怎么来的用例表严格按业务规则文档和《等价类划分与测试用例.xlsx》落地先划等价类、再定边界、最后落成用例每条都标了优先级模块规则数等价类数用例数P0P1P2套件登录78153120login_suite注册69228140register_suite转账710197111transfer_suite合计20275618371—六、缺陷注入让失败归因有东西可看为了让平台的失败归因、失败明细、状态分布这些能力真的有东西可看被测系统里刻意注入了 3 处缺陷——每一处都注明违反了文档里的哪条规则、预期让哪几条用例失败缺陷违反的规则预期失败用例归因BUG-01 登录未区分账号不存在与密码错误2.1(5)(6)LOGIN_002、LOGIN_003ASSERT_BUG-02 金额上限边界写成≥ 50000 即超限2.3(2)TRAN_005ASSERT_BUG-03 漏做仅允许一个小数点校验2.3(4)TRAN_013ASSERT_预期结果56 条用例52 通过 / 4 失败失败集合必须正好等于上表——多红一条或少红一条check_consistency.py都会报错。把parabank_lite.py里的INJECT_DEFECTS改成False重启就能得到一个完全符合文档、56 条全绿的被测系统。七、快速开始环境要求Windows也兼容 Linux / macOS、Python 3.11、本机装有 Chrome 或 Edge。驱动不用自己装Selenium Manager 会自动匹配内网环境可用PB_DRIVER_PATH指定。# 方式 AWindows 一键启动首次自动建 venv 并装依赖 run_windows.bat # 方式 B手动 python -m venv .venv .venv\Scripts\python.exe -m pip install -r requirements.txt .venv\Scripts\python.exe app.py启动后有两个入口测试平台http://127.0.0.1:5000/被测系统http://127.0.0.1:5000/parabank/login本机无头 Edge 实测耗时登录套件约 15s、注册套件约 31s、转账套件约 39s全套 56 条约 85 秒。八、技术栈Python 3.11 · pytest 9.x · Selenium 4.x · Flask 3.x · SQLite · Vue Element Plus ECharts写在最后这个项目从 0 到 1 肝了一段时间代码完全开源MIT 协议。如果你也在准备软件测试 / 测试开发方向的面试或者想找一个开箱可跑的测试工程练手希望它能帮你把简历上那块完整测试闭环的拼图补上。觉得还行的话求一个 Star ⭐这是持续更新的最大动力。仓库地址GitHub - hjxandcxq/parabank-lite-test-platform: 自建被测系统 39 条 pytest/Selenium 用例 Flask 测试平台用例表单一事实来源22 项一致性校验 · GitHub有部署问题、或者想交流用例设计与一致性维护的做法欢迎评论区留言