2. 需求与用例管理：Jira/禅道的搭建、配置与高效协作流程
需求与用例管理，说白了就是测试团队的「作战地图」。没有它，你连测什么、测到哪一步了都搞不清楚。我见过太多团队，需求靠口头传，用例散落在 Excel 里，最后上线前才发现漏测了一大块。
这一章，我们聚焦两个主流工具：Jira 和 禅道。我会把搭建、配置和协作流程的关键点都掰开揉碎讲清楚。
2.1 工具选型：Jira vs 禅道，怎么选？
先别急着装，想清楚你的场景。我个人的习惯是：小团队、国内环境、预算有限，优先选禅道；跨国协作、流程复杂、需要高度定制，Jira 更合适。
| 对比维度 | Jira | 禅道 |
|---|---|---|
| 部署方式 | SaaS / 私有化（需 Java 环境） | 私有化部署（PHP，一键安装包） |
| 上手难度 | 较高，配置项多 | 较低，符合国内习惯 |
| 需求管理 | 通过 Issue 类型 + 工作流实现 | 内置「需求」「任务」「Bug」模块 |
| 用例管理 | 需安装插件（如 Zephyr、Xray） | 原生支持用例库、用例套件 |
| 报表能力 | 非常强大，可自定义仪表盘 | 基础报表够用，但灵活性一般 |
| 价格 | 按用户收费，不便宜 | 开源版免费，企业版按年付费 |
2.2 禅道搭建与核心配置
禅道的安装非常简单。官方提供了一键安装包，集成了 Apache、MySQL、PHP。你只需要下载、解压、启动服务。
# 以 Linux 为例，下载最新版
wget https://www.zentao.net/dl/zentao/18.5/ZenTaoPMS.18.5.zbox_64.tar.gz
# 解压到 /opt
tar -zxvf ZenTaoPMS.18.5.zbox_64.tar.gz -C /opt
# 启动服务
/opt/zbox/zbox start
# 访问 http://your-server-ip:8080 开始安装向导
安装向导里，数据库密码默认是空，记得改掉。嗯，这里要注意：生产环境一定要修改默认端口和数据库密码，否则就是裸奔。
2.2.1 核心配置：产品、项目、团队
禅道的逻辑很清晰：产品 是需求的来源，项目 是执行需求的载体，团队 是干活的人。
- 创建产品： 进入「产品」模块，点击「添加产品」。产品名称要规范，比如「电商平台 V3.0」。我习惯在描述里写上产品愿景，方便新成员理解背景。
- 创建项目： 进入「项目」模块，关联刚才创建的产品。项目类型选「敏捷」或「瀑布」，根据你们实际流程来。
- 添加团队成员： 在项目设置里，把开发、测试、产品经理都加进来。权限建议按角色分配，测试人员默认给「测试」角色就够了。
2.3 Jira 搭建与核心配置
Jira 的搭建相对重一些，需要 Java 环境。我建议直接用官方提供的 Docker 镜像，省去环境配置的麻烦。
# 使用 Docker 运行 Jira
docker run -d --name jira \
-p 8080:8080 \
-v /data/jira:/var/atlassian/application-data/jira \
atlassian/jira-software:latest
# 访问 http://your-server-ip:8080 进入配置向导
配置向导里，需要设置数据库。小团队用内置的 H2 数据库先跑起来没问题，但生产环境一定要切换到 MySQL 或 PostgreSQL。
2.3.1 核心配置：项目、工作流、权限
Jira 的核心是 工作流。一个 Issue 从创建到关闭，经历了哪些状态，谁可以操作，都由工作流控制。
- 创建项目： 选择「Scrum 软件开发」或「Kanban 软件开发」模板。我个人推荐 Scrum 模板，因为它天然支持 Sprint 和 Backlog。
- 配置工作流： 进入「项目设置」-「工作流」。默认的工作流只有「待办」「处理中」「完成」三个状态。我建议增加「测试中」「已拒绝」「重新打开」等状态。
- 设置权限： 在「项目设置」-「权限」里，把「创建问题」「编辑问题」「解决问题」等权限分配给对应的用户组。测试人员通常只需要「创建 Bug」和「编辑 Bug」的权限。
2.4 高效协作流程：从需求到用例到缺陷
工具搭好了，流程怎么跑？我画了一张图，把核心链路展示出来。
2.4.1 需求流转：从创建到确认
需求不是拍脑袋写出来的。我要求团队必须遵循以下步骤：
- 产品经理创建需求： 在 Jira 或禅道里，需求必须包含「用户故事」「验收标准」「优先级」。验收标准写不清楚，测试就没法写用例。
- 需求评审： 测试、开发、产品三方坐在一起过需求。测试要重点问：「这个功能在异常情况下怎么处理？」「边界值是什么？」
- 需求确认： 评审通过后，需求状态改为「已确认」。测试开始设计用例。
2.4.2 用例管理：从设计到执行
用例是测试的核心资产。我见过很多团队，用例写了一大堆，但执行时发现根本跑不通。为什么？因为用例和需求脱节了。
我的做法是：每条用例必须关联一个需求 ID。在禅道里，创建用例时可以直接选择「所属需求」；在 Jira 里，需要借助插件（如 Xray）实现关联。
# 用例模板示例（禅道格式）
用例标题：用户登录 - 输入正确用户名和密码
所属需求：USER-LOGIN-001
前置条件：用户已注册
测试步骤：
1. 打开登录页面
2. 输入用户名 "testuser"
3. 输入密码 "password123"
4. 点击登录按钮
预期结果：登录成功，跳转到首页
用例评审也很关键。我建议每周抽 30 分钟，测试团队内部过一遍新增的用例。重点看：有没有遗漏场景？步骤是否可执行？预期结果是否明确？
2.4.3 缺陷管理：从提交到关闭
缺陷是测试的「产出物」。但很多测试同学提交 Bug 时，只写一句「页面报错了」。这不行。
我要求团队提交 Bug 必须包含以下信息：
| 字段 | 要求 | 示例 |
|---|---|---|
| 标题 | 【模块】问题描述 | 【登录】输入正确密码后提示「密码错误」 |
| 前置条件 | 描述测试环境、数据状态 | 用户已注册，账号状态正常 |
| 复现步骤 | 步骤清晰，可复现 | 1. 打开登录页 2. 输入账号 3. 输入密码 4. 点击登录 |
| 实际结果 | 描述实际看到的现象 | 页面提示「密码错误」 |
| 预期结果 | 描述应该出现的结果 | 登录成功，跳转到首页 |
| 附件 | 截图、日志、视频 | 错误截图 + 浏览器控制台日志 |
2.5 协作流程中的关键角色与职责
工具和流程都到位了，但人没配合好，一样白搭。我总结了一个角色职责矩阵：
| 角色 | 需求阶段 | 用例阶段 | 缺陷阶段 |
|---|---|---|---|
| 产品经理 | 创建需求、组织评审 | 确认用例覆盖需求 | 确认缺陷是否为需求问题 |
| 开发 | 评估技术可行性 | 评审用例合理性 | 修复缺陷、更新状态 |
| 测试 | 提出可测性建议 | 设计用例、执行用例 | 提交缺陷、验证修复 |
| 测试组长 | 把控需求质量 | 组织用例评审 | 跟踪缺陷闭环 |
你看，每个角色都有自己的职责。我最怕听到的一句话是：「Bug 提了，开发不改，我也没办法。」这时候，测试组长就要站出来，推动缺陷的闭环。
2.6 避坑指南：我踩过的那些坑
最后，分享几个我亲身经历过的坑，希望能帮你少走弯路。
- 坑一：需求变更不通知测试。 产品经理偷偷改了需求，测试还在按旧需求写用例。结果上线前才发现用例和实际功能对不上。后来我要求：需求变更必须通知测试，并在工具里更新需求状态。
- 坑二：用例和缺陷不关联。 测试提交 Bug 时，不关联用例。导致复盘时，根本不知道这个 Bug 是哪个用例发现的。后来我强制要求：提交 Bug 必须关联用例 ID。
- 坑三：权限过于开放。 开发直接修改了测试用例的状态，导致测试不知道用例被改了。后来我设置了权限：只有测试人员可以修改用例状态。