测试管理这件事,很多团队的做法是:自动化脚本跑完看一眼日志,手动测试靠 Excel 或 Wiki 记录,Bug 跟踪扔给 Jira。工具之间割裂,测试计划、执行记录和缺陷数据散落在不同系统里,回溯时全靠人肉拼凑。Kiwi TCMS 试图把这些环节收拢到一个系统中——手动测试用例管理、自动化测试结果汇总、Bug 跟踪器联动、权限控制和可视化报告,全部在一个平台内完成。
16.0 是一个主版本更新,意味着有不向后兼容的改动。如果你已经在用旧版本,升级前需要仔细看变更清单。
这个系统解决什么问题
Kiwi TCMS 的核心定位是"测试用例管理 + 测试执行记录 + 报告",而不是替代 pytest 或 Selenium 这类自动化执行框架。它做的是上层汇总:
- 手动测试:创建测试计划,按用例逐条执行并记录结果(Passed / Failed / Blocked)。
- 自动测试:通过插件或 API 把自动化框架的执行结果推送到 Kiwi,统一看板。
- Bug 联动:测试失败时直接关联 Bug 跟踪器(支持 Jira、Bugzilla、GitLab 等),一条失败记录可以自动创建或链接已有缺陷。
- 权限控制:按产品线、项目、角色划分谁能看什么、谁能改什么。
- API 层:几乎所有操作都有 REST API 对应,方便和 CI/CD 流程对接。
对于"自动化脚本跑完结果只在终端日志里"的团队,Kiwi 提供了一个集中存储和检索的入口。
16.0 版本的关键变动
作为主版本号跳升,16.0 带来了几类值得留意的改动:
安全更新——开源系统面向内部团队使用时,安全容易被忽视,但 Kiwi 长期维护安全补丁,这次也包含相关修复。如果你的实例暴露在公网(哪怕是 VPN 内),升级是最省心的应对方式。
不向后兼容的变更——主版本号跳升的信号就是"有东西改了,旧流程可能跑不通"。具体变更需要查阅官方 release notes,但常见情况包括:API 字段调整、数据库迁移要求、配置项重命名或移除。升级前务必在测试环境验证现有自动化脚本和 API 调用是否仍然正常。
多项改进——搜索页面、报告可视化、插件兼容性等方面的增强。搜索页面的改进对日常使用影响最直接:测试用例数量上千后,筛选和检索效率直接决定工作体验。
新翻译——Kiwi 支持多语言界面,新翻译意味着更多语言的覆盖或已有翻译的修正。对中文团队来说,界面本地化程度影响非开发人员(如产品经理、QA 手测人员)的上手门槛。
实操:用 Docker 快速拉起 Kiwi TCMS 并通过 API 创建测试用例
Kiwi TCMS 官方提供 Docker 部署方式,这是最快的体验路径。以下示例可以直接复制运行。
第一步:启动 Kiwi TCMS
# 克隆官方 docker-compose 配置
git clone https://github.com/kiwitcms/Kiwi.git kiwi-tcms
cd kiwi-tcms
# 切换到 16.0 对应的标签或分支(具体 tag 名以官方仓库为准)
# git checkout v16.0
# 启动服务
docker-compose up -d
# 等待约 30 秒后检查服务状态
docker-compose ps
启动完成后访问 http://localhost:8080,用默认管理员账号登录(初始账号密码在 docker-compose 或启动日志中查看,通常需要执行初始化命令):
# 创建超级用户(首次部署时)
docker-compose exec kiwi python manage.py createsuperuser
第二步:通过 API 创建测试用例
Kiwi 的 API 是 RPC 风格(基于 JSON-RPC),也有 REST 端点。以下用 Python 脚本演示如何通过 API 自动创建测试用例——这在"把自动化测试结果推送到 Kiwi"的场景中是第一步。
"""
Kiwi TCMS API 示例:创建测试用例并关联到测试计划
运行前修改 BASE_URL、USERNAME、PASSWORD
依赖:pip install requests
"""
import requests
BASE_URL = "http://localhost:8080"
USERNAME = "admin"
PASSWORD = "your_password_here"
session = requests.Session()
# 1. 登录获取 CSRF token 和 session cookie
login_url = f"{BASE_URL}/accounts/login/"
resp = session.get(login_url)
csrf_token = session.cookies.get("csrftoken")
resp = session.post(
login_url,
data={"username": USERNAME, "password": PASSWORD, "csrfmiddlewaretoken": csrf_token},
headers={"Referer": login_url},
)
print("登录状态:", resp.status_code)
# 2. 通过 JSON-RPC API 创建测试用例
rpc_url = f"{BASE_URL}/json-rpc/"
csrf_token = session.cookies.get("csrftoken")
payload = {
"method": "TestCase.create",
"params": [
{
"summary": "登录页面——空密码提交应返回错误提示",
"text": "前置条件:用户已注册。\n步骤:1. 打开登录页 2. 输入用户名 3. 密码留空 4. 点击提交\n预期:页面显示'密码不能为空'错误提示",
"case_status_id": 1, # 1 = Confirmed,具体 ID 需根据你的实例确认
"category_id": 1, # 默认分类,可在管理后台查看
"priority_id": 2, # 2 = Normal
"author_id": 1,
}
],
"id": 1,
}
resp = session.post(
rpc_url,
json=payload,
headers={
"X-CSRFToken": csrf_token,
"Referer": BASE_URL,
"Content-Type": "application/json",
},
)
result = resp.json()
print("创建用例结果:", result)
case_id = result.get("result", {}).get("id")
if not case_id:
print("用例创建失败,请检查参数和权限")
exit(1)
# 3. 创建测试计划并把用例加入计划
plan_payload = {
"method": "TestPlan.create",
"params": [
{
"name": "v2.5 回归测试计划",
"text": "覆盖登录模块核心路径",
"type_id": 1, # 1 = Unit,可根据实际调整
"product_id": 1,
"product_version_id": 1,
"author_id": 1,
}
],
"id": 2,
}
resp = session.post(
rpc_url,
json=plan_payload,
headers={"X-CSRFToken": csrf_token, "Referer": BASE_URL, "Content-Type": "application/json"},
)
plan_result = resp.json()
print("创建计划结果:", plan_result)
plan_id = plan_result.get("result", {}).get("id")
# 4. 把用例关联到计划
if plan_id and case_id:
link_payload = {
"method": "TestPlan.add_case",
"params": [plan_id, case_id],
"id": 3,
}
resp = session.post(
rpc_url,
json=link_payload,
headers={"X-CSRFToken": csrf_token, "Referer": BASE_URL, "Content-Type": "application/json"},
)
print("关联用例到计划:", resp.json())
运行前需要修改 BASE_URL、USERNAME、PASSWORD,以及确认 case_status_id、category_id、priority_id 等枚举值是否与你的实例匹配(可以在管理后台的对应列表页查看 ID)。
这个脚本演示了完整的"登录 → 创建用例 → 创建计划 → 关联"流程。在实际 CI/CD 中,你可以把 TestCase.create 替换为 TestExecution.add 来记录自动化测试的执行结果。
和自动化框架对接的思路
Kiwi 本身不执行测试,但它提供了插件机制把结果拉进来:
- Kiwi TCMS 的 pytest 插件(
kiwitcms-pytest):在 pytest 运行结束时自动把每个 test item 的结果推送到 Kiwi 对应的测试计划。 - 其他框架插件:社区有针对 Selenium、Jenkins 等的集成方案,核心逻辑都是"执行完 → 调 API → 写结果"。
如果你不想用现成插件,最轻量的对接方式就是在 CI 脚本末尾加一段 curl 或 Python 调用,把失败用例的名称和日志推到 Kiwi。关键是让测试结果从"只在 CI 日志里"变成"有结构化记录、可检索、可关联 Bug"。
升级前的检查清单
16.0 有不向后兼容的改动,升级前建议按以下步骤排查:
- 阅读完整 release notes——在 GitHub 项目的 Releases 页面查看从 15.4 到 16.0 的所有变更,重点关注标记为"breaking"的条目。
- 在测试环境部署 16.0——不要直接升级生产实例。用 Docker 起一个新实例,导入一份测试数据的备份,验证现有流程。
- 检查 API 调用——如果你有脚本或 CI 插件通过 API 推送数据,逐个验证调用是否仍然返回预期结果。字段名变更、必填参数调整是最常见的破坏点。
- 检查插件版本——
kiwitcms-pytest等插件可能需要同步升级才能兼容 16.0 的 API。 - 数据库备份——主版本升级通常涉及数据库迁移,备份是回滚的前提。
- 安全补丁确认——如果旧版本有已知安全漏洞且你的实例非内网隔离,优先升级。
Kiwi TCMS 不是唯一选择——TestRail、Qase、Zephyr 等商业或半商业产品也做测试管理。但 Kiwi 的优势在于开源可自托管、API 完整、插件生态有社区支撑。代价是你需要自己维护部署和升级。对于已经把测试流程跑在开源工具链上的团队,Kiwi 是一个值得试的拼图块。