WHC系列：Checkmate --- 自托管团队测试管理平台

🎯 What —— 这是什么？

• 🏷️ 一句话定位：把测试用例、执行记录、自动化结果和质量报告集中在一个工作区的自托管测试管理平台
• 🚀 核心优势
  • ✨ 支持目录化用例库、步骤型用例、CSV 导入、Revision、评论和附件
  • ⚡ Suite 可以根据浏览器和环境配置自动生成多条 Run，适合跨环境回归
  • 🤖 支持 DeepSeek 辅助生成中文用例，也能用 API Key 接收 CI/JUnit 自动化结果
  • 📊 Reports 会自动汇总覆盖率、失败排行、优先级、类型和未执行用例
  • 🔒 数据保存在自建 MongoDB 和服务端附件目录，并支持懒猫 OIDC 登录

🛠️ How —— 怎么用？

使用场景：完成一次跨境电商订单发布验收

假设测试团队准备发布一版新的订单履约系统，需要同时检查优惠券和余额组合支付、重复退款、支付超时库存释放、订单拆单以及第三方退款回调。

如果只用表格管理，很容易出现几个问题：用例版本对不上、Chrome 和内置浏览器漏测、失败结果没有沉淀、探索过程中发现的问题没有转成正式用例和人工测试各看各的。

下面我们就拿这组示例来演示：

• 项目：跨境电商订单履约质量验收
• 项目 Key：ORDER
• 目录：结算与支付、退款与售后、库存与履约
• 里程碑：2026-08 订单稳定性发布
• 测试环境：懒猫内置浏览器、Chrome × 预发布环境

配置向导配置Deepseek API Key，然后进入应用

首次打开应用需要配置Deepseek API Key，请对应填写。

进入应用后会先看到 Welcome Back。点击 使用懒猫账号登录 (Sign in with Lazycat) 进行授权登录，

进入后会跳出“tour”界面，直接关闭或者点击“Skip tour”

然后会到 Projects页面，首次空库点击右上角 New Project，填写：

• Name：跨境电商订单履约质量验收
• Key：ORDER
• Description：覆盖结算、支付、退款、库存释放和订单履约关键链路

点击 Create Project 后会自动进入项目工作区。左侧可以看到：

Dashboard / Cases / Suites / Runs / Automation / Sessions / Milestones / Reports / Settings

注意：项目 Key 会成为用例编号前缀，例如 ORDER-1。Key 只能使用 2-10 位字母或数字，创建后不建议随意修改。

建立订单测试用例库

进入左侧 Cases。第一次使用时先点击 New Folder，创建三个目录：

1. 结算与支付
2. 退款与售后
3. 库存与履约

目录创建完成后，再使用 New Case 手工创建用例，或者使用 Import CSV 批量导入。

点击 New Case 后，可以填写：

• Title：用例标题
• Folder：所属目录
• Priority：Low、Medium、High、Critical
• Type：Functional、Regression、Smoke、Acceptance 等
• State：Draft、Active、Deprecated
• Preconditions：前置条件
• Test Steps：每一步操作和对应预期
• Expected Result：最终预期
• Tags：标签
• Automated：是否纳入自动化覆盖率

前三条基础用例分别是：

• ORDER-1 优惠券与余额组合支付成功后生成待发货订单
• ORDER-2 重复提交退款申请时系统应阻止重复退款
• ORDER-3 支付超时后锁定库存应自动释放

填写完成后点击 Save Case。后续编辑会形成新的 Revision，适合追踪测试步骤为什么发生变化。

用 CSV 批量导入订单用例

如果已经在表格里整理了用例，可以点击 Import CSV。

先在 Target Folder 选择目标目录，再点击 Upload file。选择你需要上传的文件（测试文件地址: https://quwenjian.cc/#/?code=RQ8AV）,

ORDER-4 订单拆单后每个子单应继承原支付流水

CSV 可以包含 title、description、preconditions、steps、step expected、expected results、priority、type、status、tags 等字段。其中只有 title 必填；步骤和步骤预期可以按行对应。

用 DeepSeek 补充退款边界用例

如果安装时已经配置 DeepSeek，Cases 页面会显示 Generate with AI。

本次使用的中文提示词是：

退款申请审核通过后，系统需要异步回写原支付渠道到账状态；
覆盖重复回调幂等、渠道延迟超过 10 分钟的用户提示，
以及退款完成后订单关闭与库存回补一致性。

选择目标目录 退款与售后，数量填 3，点击 Generate。

AI 返回后不要直接全部保存，先展开检查步骤、优先级和类型，再点击 Add selected。

本次生成并保存了：

• ORDER-5 重复回调幂等处理
• ORDER-6 渠道延迟超过10分钟的用户提示
• ORDER-7 退款完成后订单关闭与库存回补一致性

注意：AI 用例更适合用来补充边界和提供思路，不建议代替测试人员审核。涉及资金、库存和权限的用例，一定要自己确认预期是否符合业务规则。

建立发布里程碑

进入 Milestones，点击 New Milestone。

本次填写：

• Name：2026-08 订单稳定性发布
• Due Date：2026-08-21
• Description：覆盖支付、退款、库存释放和订单履约关键链路的预发布稳定性验收。

保存后卡片会显示截止日期。

建议一个发布版本建立一个 Milestone，后面创建 Suite、Run 和 Session 时都关联它。这样到发布前可以快速确认哪些测试已经完成。

配置浏览器和测试环境

进入 Settings → Configurations，依次添加：

Group	Value
浏览器	懒猫内置浏览器
浏览器	Chrome
环境	预发布环境

Settings 里还有一些可选项可以参考：

• Members：Lead、Tester、Viewer
• Custom Fields：项目自定义字段
• Shared Steps：多个用例可以复用的步骤
• API Keys：给 CI 提交自动化结果
• Jira / Issue Trackers：失败结果转缺陷
• Webhooks：Run 完成或结果提交后通知其他系统

创建跨浏览器测试套件

进入 Suites，点击 New Suite。

本次使用：

• Name：2026-08 退款到账与库存回补矩阵
• Milestone：2026-08 订单稳定性发布
• Cases To Include：By Folder
• 目录：退款与售后、库存与履约
• 浏览器：懒猫内置浏览器、Chrome
• 环境：预发布环境

弹窗底部会直接计算：

Will generate 2 runs.

点击 Create Suite 后，系统会生成：

1. 懒猫内置浏览器 / 预发布环境
2. Chrome / 预发布环境

这比手工复制两份测试计划更可靠。后续增加操作系统或更多环境时，Checkmate 会继续按照组合数量生成 Run。

执行 Run 并记录真实结果

进入 Runs，打开需要执行的 Run，点击 Execute。

步骤型用例可以先给每一步标记 Passed 或 Failed，再填写实际结果、缺陷说明和截图，最后选择整条用例状态：

• Passed
• Failed
• Blocked
• Retest
• Skipped

提交后会自动跳到下一条未执行用例，同时保存计时、步骤结果、评论和附件。

• Passed：3
• Failed：1
• Skipped：1
• Executed：5
• Pass Rate：60%

Run 页面还提供：

• Rerun：用同一批用例创建一条新的未执行 Run
• Close Run：关闭并锁定结果
• Comments / Watch：讨论和关注这次执行

用 Exploratory Sessions 记录探索测试

不是所有问题一开始都能写成固定步骤。比如退款到账延迟、消息最终一致性、偶发库存补偿，更适合先用探索式测试。

进入 Sessions，点击 New Session，本次示例填写：

• Title：退款到账时效与订单状态一致性复核
• Charter：验证退款受理、第三方到账回写、订单关闭与库存回补的状态一致性，关注延迟到账、重复回调和用户提示。
• Time-box：45 分钟
• Milestone：2026-08 订单稳定性发布

进入 Session 后点击 Start，可以记录：

• Note：普通观察
• Bug：确认的问题
• Question：需要产品或研发确认
• Idea：改进建议

还可以粘贴截图、上传附件，并使用 Save As Case 把有价值的发现转成正式用例。完成后点击 Complete。

用 Reports 看发布质量

最后进入 Reports，这里会把人工执行、用例库和失败历史汇总起来。

本次案例数据是：

• Total Cases：8
• Executed：5
• Never Executed：3
• Coverage：63%

继续往下还能看到：

• 按 Priority、State、Type 的分布
• 从未执行和超过 90 天未执行的用例
• Most Failing 失败排行
• 两条 Run 的结果对比
• Shareable Links 公开只读报告

点击 Export Cases CSV 可以导出用例。

后续怎么坚持用

对小团队来说，不建议一开始把所有集成都配满。先坚持这个最小流程：

1. 需求进入开发后：在 Cases 补充或更新用例。
2. 准备提测时：建立 Milestone 和 Suite，生成浏览器/环境矩阵。
3. 每日回归时：在 Runs 执行并记录实际结果、截图和缺陷。
4. 遇到模糊问题时：用 Sessions 做 30-60 分钟探索，再把稳定结论转成 Case。
5. 发布评审前：从 Reports 查看覆盖率、失败排行和未执行用例。

💡 实用技巧

• 目录按业务链路分，不要按测试人员分：人员会变化，结算、退款、库存这些业务边界更稳定。
• 一个步骤只做一个动作：Action 和 Expected 一一对应，失败时更容易定位。
• Failed 一定写实际结果：不要只标红，要写“发生了什么、预期是什么、是否有截图”。
• Suite 用于可复用矩阵，Run 用于一次执行：跨浏览器、跨环境优先用 Suite；临时验证可以直接 New Run。
• 探索发现及时转用例：能稳定复现的问题不要只留在 Session 里。
• AI 生成后必须审核：模型擅长补边界，但不了解你们所有业务规则。
• 临时 API Key 用完即删：不要长期复用个人验收密钥。
• 发布前看 Never Executed：总用例多不代表覆盖完整，未执行清单通常更值得关注。

🧩 Conclusion —— 一句话总结

Checkmate 的核心价值，是把“用例怎么写、在哪些环境执行、实际结果是什么、探索发现如何沉淀、发布覆盖是否完整”串成一个自托管闭环；它比普通表格更适合持续回归，也让人工测试和自动化测试终于能够在同一个质量视图里协作。