企业官网建设流程全解析

1. 先说清楚：禅道对测试人员来说到底是什么

我见过不少测试新人，入职第一天就被拉进禅道，领导甩过来一句“以后Bug都提到这里”，然后就没有然后了。结果用了大半年，禅道在他们手里就干了一件事——提Bug。用例在Excel里躺着，测试报告靠手工拼，需求变更靠微信群吼。说实话，这不是禅道不好用，是没搞明白禅道在测试工作里应该扮演什么角色。

禅道本质上是一套覆盖“产品-项目-测试”三条线的协作平台。对测试人员来说，它最值钱的地方不是“能记Bug”，而是把用例设计、用例评审、测试执行、缺陷跟踪、测试报告这整条链路串在了一个系统里。你在禅道上完成的每一次操作，都会沉淀成可追溯的数据，最终变成测试结论的支撑证据。搞清楚这个逻辑，你才算真正开始“会用”禅道。

这篇教程面向的是完全没接触过禅道的测试新人，也适合那些刚从Excel管理用例切到禅道的团队。我会从环境准备、用例组织、Bug流转、测试执行与报告、再到跟钉钉/自动化工具的配合，一层层拆开讲。按这个顺序走一遍，你就能在团队里独立承担用禅道管理测试全流程的活了。

2. 环境准备：最快把禅道跑起来的两种方式

2.1 官方一键安装包：Windows和Linux都能用

禅道官网提供了集成安装包，所谓“集成”就是把Apache、PHP、MySQL这些运行环境全部打包好了，你不用自己一个个装。Windows环境下解压后运行 start.bat 就能启动，Linux下解压后执行 zbox start 即可。这个方案特别适合公司内网部署，不用联网装依赖，一台普通服务器就能带起来。

需要注意几个细节。

第一，禅道默认端口是80，如果服务器上已经跑了其他Web服务，端口会冲突。启动的时候可以用自定义端口，Linux下命令是 ./zbox start -p 8080，Windows下要去修改端口配置，改完重启服务。我建议测试环境直接用默认端口或统一约定一个端口，省得以后访问地址到处问人。

第二，Linux安装包启动后，浏览器访问 http://服务器IP/ 就能看到安装界面。如果访问不了，先确认防火墙有没有放行对应端口，再确认进程有没有起来。曾经帮同事排查过一个问题，zbox start 提示成功了，但浏览器就是访问不了，最后发现是服务器上有安全软件把Apache进程给拦了，把目录加白才解决。

第三，安装完成后系统会提示设置管理员账号。管理员账号很关键，后面所有权限分配、组织结构搭建都要靠它，务必把密码记到团队密码本里，别只存在某一个人的脑子里，否则人一走，整个系统就瘫了。

2.2 Docker方式：适合快速体验和二次开发

如果你只是想本地体验一下禅道的功能，或者团队已经有Docker环境，用Docker跑更省事。

docker run -d \ -p 8080:80 \ -v /opt/zentaopms:/www/zentaopms \ --name zentao \ easysoft/zentao:latest

这个命令会把禅道跑在8080端口，数据目录挂载到宿主机的 /opt/zentaopms。挂载数据目录这件事一定不要省略——容器删了数据还在，升级也方便。第一次启动后访问 http://localhost:8080，按安装向导操作即可。

Docker方式的优点是不污染宿主机环境，缺点是数据卷管理不当容易丢失数据，所以务必养成启动容器前先看数据目录是否存在的习惯。

2.3 安装完成后的初始化：组织和权限才是关键

很多人装完禅道，管它三七二十一先建个产品、建个项目就开始提需求提Bug，过两天发现权限乱成一锅粥，谁都能删除线上Bug记录。正确的做法是先花十分钟把组织架构搭好。

在“组织→用户”里批量添加成员，在“组织→权限”里配置权限分组。测试人员一般给“测试”角色就够了，默认权限覆盖用例管理和Bug管理；项目经理给“项目经理”角色；领导需要看报告的话，单独创建一个“只读报表”权限组，只开放“测试→报告”和“统计”相关菜单。

这一步做的越细，后面越省心。权限不是用来卡人的，是防止误操作的，尤其是删除类的操作，尽量收紧。

还有一个容易忽略的点：创建产品、项目、模块这些基础数据时，命名规则最好提前统一。比如产品按“XX管理系统”命名，项目按“XX产品-V1.2迭代”命名，模块按功能域命名。前期不觉得，等你积累了上千条用例、几百个Bug后会发现，清晰的命名能让筛选和统计结果一目了然。

3. 测试用例管理的核心操作：从Excel思维切换过来

3.1 用例字段逐个拆解

在禅道里，一次完整的用例包含这些关键字段：

• 所属产品、所属模块：决定了用例的归档位置。模块没建好，用例就没地方挂。
• 用例标题：一句话说明验证什么，建议格式是“[模块]验证XXX功能在XXX条件下返回XXX结果”。
• 用例类型：功能测试、接口测试、性能测试、兼容性测试等。类型区分清楚，后面统计各维度覆盖率时很有用。
• 优先级：P1-P4，P1是核心流程必须保证，P4是边缘体验。别把优先级往上调成虚高，P1P2太多等于没有优先级。
• 前置条件：执行前需要满足的状态，比如“用户已登录且拥有审批权限”。
• 步骤、预期结果：这是用例的核心，一对多关系。步骤要具体到“点击哪个按钮、输入什么数据”，预期结果要可判定，不要写“系统正常”这种模糊表达，要写“页面跳转到详情页，金额显示为XX元”。
• 关键词：方便搜索，可以填功能模块别名或业务术语。
• 关联需求：如果这个用例对应某个需求ID，关联上。需求变更时可以一键看受影响用例。

我第一次用禅道的时候，觉得字段太多是负担，用久了才知道，这些字段不是给录入员添麻烦的，是给三个月后的你做统计用的。没有模块信息，你就不知道哪个功能域Bug最多；没有类型信息，你就说不清这次测试功能用例和接口用例各执行了多少。

3.2 用例库和测试单，别混为一谈

禅道里有个概念很多人会搞混：用例库和测试单。

用例库是“用例的仓库”，它存放所有设计好的用例，是静态的资产。它不关心这轮测试执行了没有、通过了没有，只负责把用例按产品、模块、类型整理好。

测试单则是某一次测试任务的执行单元。创建测试单时，从用例库里选择本轮要执行的用例，指派给测试人员，然后执行、记录结果、提交Bug。

打个比方：用例库是菜谱，测试单是某一天报出来的菜。菜谱是长期沉淀的，菜单是每顿变化的。搞清楚这个区别后，你就能回答“用例要不要每次都新建”这个问题——不用，从用例库关联过来就行，执行结果记录在测试单里，互不污染。

3.3 批量导入Excel：效率翻倍的技巧

如果你的团队之前用Excel管理用例，第一次上禅道时不需要手工一条条录。禅道自带Excel批量导入功能，在“测试→用例→批量添加→导出模板”里可以下载标准模板。

模板里有固定的列头，按提示填好之后导入。这里有几个常见的坑：

• 模板里的“所属模块”如果不填，导入后用例会跑到产品根目录下，后面整理要一条条挪位置。建议导入前先把模块在系统里建好，模板里填模块路径。
• “步骤”字段在模板里是文本格式，多步骤时用换行或特殊分隔符分隔，具体看模板说明。导入前先导入两三条测试数据，检查渲染效果再全量导入。
• “关联需求”一列如果填了不存在的需求ID，导入会报错或跳过关联，建议先导入用例，再统一回填关联需求。

批量导入后一定要抽检：用例标题是否正常、步骤是否完整、预期结果是否都在。我见过有同事导入了500条用例，半年后才发现有80条预期结果是空的，那些用例等于白建。

3.4 用例评审：怎么在禅道上组织评审

用例评审不是过场。禅道里可以发起“测试→用例→评审”，选定要评审的用例，指派给评审人。评审人给出“通过”或“待修改”的意见，不通过的用例会被打回，由创建人修改后再提交。

实际操作建议：评审组长先按模块把用例分批，每批50-80条，太多了一条条过不完，评审就成了签字仪式。评审时打开用例详情投影到屏幕上，逐条过步骤和预期结果，重点看“可执行性”和“可判定性”。开发参与评审能提前暴露需求理解不一致的问题，这个环节省下来，后面执行时返工成本更高。

4. 提Bug才是日常主战场：一条优质Bug记录的完整打开方式

4.1 先看一条“烂Bug”长什么样

“首页崩了，赶紧看看”——这是我见过的最典型的无效Bug标题。没有模块、没有重现步骤、没有日志、没有截图，收到这种Bug的开发大概率会直接标记“无法重现”然后甩回给你。不是开发不负责，是信息确实不够。

一条合格Bug应该包含：

• 所属产品、所属模块：定位到功能域
• Bug标题：描述“在XX条件下操作XX，导致XX结果”，比如“在弱网环境下点击保存按钮，提示网络错误但实际数据已写入”
• 重现步骤：分步写清楚，从进入页面开始写
• 实际结果：可观察、可对比的具体现象
• 预期结果：依据需求或常识应该出现的现象
• 严重程度：1-4级，1级是系统崩溃、数据丢失；2级是主要功能不可用；3级是一般功能异常；4级是体验、样式问题
• 优先级：和严重程度挂钩但不等同。核心流程上的第三级Bug优先处理，这也是常见分歧点
• 附件：截图、录屏、日志文件，尤其是日志，开发定位问题最依赖的就是它

4.2 Bug的完整生命周期流转

禅道的Bug状态流转是：激活（提交）→ 解决 → 关闭，中间可能有“重新激活”和“延期处理”。

• 测试提交Bug后，状态是“激活”。
• 开发解决后，状态变为“已解决”，并填写“解决方案”（已修复、重复Bug、设计如此、无法重现等）和“解决版本”。
• 测试验证通过后，关闭Bug。
• 验证不通过，重新激活，Bug回到开发手里。

这里面有个关键操作：验证不通过时，不要直接改状态，要在Bug详情里追加评论，说清楚“按原步骤复测，问题依然存在”或“修复了A场景但B场景仍然复现”。评论是给开发看的，也是给以后回溯留证据。

一条Bug的反复激活次数很有诊断价值。如果某个模块的Bug经常被重新激活，说明开发和测试对这个需求的理解存在系统性偏差，这时候就该坐下来对需求，而不是在系统里互相踢皮球。

4.3 把Bug和用例、需求关联起来

禅道支持在Bug里关联“相关用例”和“相关需求”。

关联用例的意思是：这条Bug是在执行哪个用例时发现的。这样后续可以通过Bug倒查用例质量，如果一个用例反复触发Bug，说明这条用例的设计本身覆盖了高风险路径，可以升级为P1用例。

关联需求的意思是：这个Bug影响了哪个需求点。需求变更时，可以一键查出来有哪些未关闭的Bug，帮助评估这次变更的上线风险。

关联操作不强制，但只要是执行用例时发现的Bug，顺手把用例关联上，成本极低，收益却不小。别偷懒。

4.4 怎么让开发不那么反感你提的Bug

我说点大实话。测试和开发的关系，很大程度是由Bug质量决定的。

我自己的经验是：提Bug之前先花两分钟自查一遍——这个Bug能不能稳定重现？如果不能，尽可能补充录制视频和抓取当时的日志。网络异常类问题，先自己切换网络环境复现几次，不要拿一次偶发现象去打扰开发。

“建议类”问题不要选“缺陷”类型，禅道里有“需求”通道可走，或直接跟产品经理沟通。把缺陷和建议混在一起，会拉低Bug库的整体纯度，也让报表数据变形。

更重要的一点：Bug标题里直接写定位结果，别写“页面报错”这种，写“登录接口在账号含特殊字符时返回500，属未做入参校验”。开发收到这种Bug，第一反应是“这测试懂行”，而不是“又要查半天”。

5. 测试执行与报告：让“测试结论”有据可依

5.1 测试单怎么建，执行怎么分配

每个迭代要开始测试时，在“测试→测试单”里创建一个测试单，选好关联产品、执行人、时间段，然后从用例库中关联本轮需要执行的用例。这里建议按模块分批关联，方便分别指派给对应模块的负责人。

测试单建好之后，测试人员进入“测试→执行”页面，就能看到分配给自己的用例列表。每条用例逐条执行，点“执行”按钮，记录实际结果，选择“通过”“失败”“阻塞”等状态。

这里有个细节：执行失败时，系统会提示“是否直接提交Bug”，确认后就自动把Bug内容和当前用例串起来了。这条链路是禅道测试模块的核心价值所在，数据最终都能追溯回用例，而不是开了个Excel各记各的。

5.2 记录执行结果时最容易踩的坑

执行测试不是点个“通过”就完了。我见过很多测试用例执行记录里只有状态，没有备注，过了三个月根本想不起来当时到底验证了什么。

正确做法是：通过的用例，如果执行过程顺利，可以不写备注；凡是做过特殊操作的，比如用测试账号绕过了某个校验、修改了数据库某个值才跑通的，一定要在备注里写清楚。这些信息对下次执行的人很有用，也能帮团队发现用例设计里没覆盖到的边界情况。

失败的用例也一样，除了关联Bug，最好在用例执行记录里备注失败时的数据和环境信息。将来分析“P1用例通过率”的时候，光有状态没有细节，等于只有骨架没有血肉。

5.3 禅道内置测试报告到底能产出什么

测试完一个迭代，领导要的不是你口头说“测完了，感觉还行”，而是一份有数据的测试结论。禅道的“测试→报告”功能就是干这个的。

创建测试报告时，系统会自动拉取这段时间内所选产品/项目的测试单数据，包括：用例执行总数、通过率、失败率、Bug总数、按严重程度和模块的Bug分布、未关闭Bug列表等。你需要做的是：选取统计范围、补充风险分析和结论建议。

根据我的使用习惯，一份能说服领导的测试报告至少包含这几块：

报告不是自动生成的，中间需要你补充“风险说明”和“测试结论”，这两块才是体现测试价值的地方。系统数据是客观事实，风险和结论是你的专业判断。

5.4 统计报表：从数据里看出问题

禅道的“统计”菜单提供了多种维度的报表，我常用的是“Bug密度统计”“Bug激活次数统计”“测试用例执行情况统计”。

Bug密度统计按模块看Bug数量，配合用例数一除，能算出每个模块的缺陷密度。密度高的模块说明设计或实现质量差、测试用例覆盖不足，值得在下个迭代加大测试投入。这个分析在复盘会上拿出来，比“这个模块Bug好多”有说服力多了。

激活次数统计能反应沟通效率。激活次数高的Bug说明测试和开发对同一问题是否修复的判断不一致，这时候不要争谁对谁错，把历史评论翻出来看，通常能发现是需求不明确导致各自理解有偏差，推动需求方把判定标准定义清楚才是正解。

6. 进阶玩法：钉钉通知、自动化对接、团队规范

6.1 钉钉集成：Bug通知自动跳转

很多团队用钉钉做日常沟通，如果禅道和钉钉没打通，开发人员要么半天不看一次禅道，要么每天被“催着去看Bug”。更好的方式是让Bug通知主动飞到钉钉群，点击消息里的链接直接跳到禅道对应的Bug详情页。

禅道通过“后台→通知→钉钉”配置Webhook机器人地址，再在“后台→通知→通知设置”里配置事件类型，例如“新建Bug”“解决Bug”触发消息推送。实际配置时有几个要点：

• 钉钉群要添加自定义机器人，安全设置建议选“加签”，把密钥填到禅道对应位置。
• 推送消息里带上标题、严重程度、提交人、链接地址，链接要能直接访问。如果禅道部署在公司内网，需要确保钉钉消息点击时手机或电脑能访问内网地址，这通常需要配合内网穿透或已经在办公网内。
• 通知规则别全选，否则群里每天几十条消息会变成“狼来了”。我建议只推送“P1/P2级别的Bug新建”和“自己提交的Bug状态变更”，具体按团队偏好调。

6.2 跟自动化测试结合：结果自动回写禅道

如果你的团队已经在跑自动化测试（接口自动化或UI自动化），可以考虑把自动化结果回写禅道，减少手工同步。

一个比较轻量的做法是：用禅道开放API（禅道从12.x版本开始提供RESTful API）把自动化执行失败的用例对应的Bug自动提交到禅道。自动化脚本截取失败时的截图和日志，拼成Bug描述，通过API创建Bug并关联到对应用例ID。

这样做的好处是省去人工重复提交，但要注意控制重复提交：同一条用例连续多次失败，不应该生成一堆重复Bug。我的建议是脚本里增加去重逻辑——查询该用例是否有未关闭的同类型Bug，有就不再新建，只在原Bug下追加新日志。

注意，禅道API的鉴权和调用方式在不同版本有差异，接入成本不算低，适合有一定开发能力的测试团队。如果团队以手工测试为主，我先劝你稳住，别为了“自动化”而自动化，先把手工流程跑顺。

6.3 测试团队在禅道上的规范化约定

工具用得好不好，一半靠功能，一半靠规则。我建议团队内部定几条硬性约定：

• Bug标题统一格式，必填模块和严重程度，必须在提交前自查是否包含重现步骤。
• 用例状态定期清理，废弃用例及时标记“停用”，不要删，保留历史痕迹。
• 每个迭代结束当天，测试负责人在禅道里归档测试报告，关联到对应项目。
• 每日站会前看一眼“指派给我”的待办，保证Bug不会被晾超过24小时。

这些约定不复杂，但能避免禅道沦为“信息孤岛中的第二个Excel”。规则要落在纸面上，新人入职时花半小时讲一遍，比到时候边用边猜强得多。

6.4 数据维护与升级：别等崩了才想起来

禅道用了一两年后，数据量会明显涨上来。我的几个经验：

• 升级前必须全量备份数据库和附件目录。禅道自带备份功能，在“后台→数据→备份”里可以设置定期备份任务。我见过有人直接在生产环境下点击升级，升级过程报错导致数据库异常，又没备份，最后回滚到很旧的备份，丢了几周数据。
• 定期清理无效附件，比如已关闭Bug里的大体积截图、很久不用的旧版本安装包等。附件占用的是服务器磁盘，磁盘一旦爆满，整个系统响应会变慢。
• 关注PHP和MySQL的资源占用。如果量太大，考虑把数据库迁移到独立MySQL实例，而不是继续用集成环境里的默认配置。这属于运维层面的优化，通常团队里有专人负责。

7. 我在实际使用中的几点体会

最后分享几个用禅道做测试管理这些年攒下的个人感受。

关于用例维护，我的态度是“用例也是代码，需要持续维护”。需求一变，关联的用例必须同步更新。我在团队内部定了条规矩：每个迭代结束，测试人员必须检查这轮需求变更覆盖了哪些旧用例，标注过时或补充新步骤，然后更新用例库。这样永远保持用例库跟代码同步演进，而不是变成一个没人敢动的历史遗留物。

关于禅道的统计功能，我建议不要被数字绑架。自动化率高、用例通过率100%听起来很好看，但如果P1用例只有50条且覆盖不到核心业务链路，数字再漂亮也没有实际意义。报告里解释清楚“测了哪些核心场景、没测哪些、为什么没测”，比一个好看的百分比更能体现专业度。

关于团队推广，最忌讳的是把禅道当监控工具。有管理者恨不得每天看每个人提交了多少Bug、解决了多少Bug，用来算绩效，结果就是测试为了凑数，把一个Bug拆成多条提，开发把已解决又复现的问题直接标记“无法重现”降低数字。禅道的正确用法是让信息流动、让问题被看见、让过程可追溯，不是用来做考勤的。

如果你是从零开始，按照这篇教程的顺序走一遍：搭好环境、配好权限、从Excel导入用例、建一张测试单、提出一条包含完整信息的Bug、生成一份像样的测试报告——你就已经把禅道测试管理的核心路径完整跑通了。剩下那些高级功能，基本都是在这些基础操作之上的细节打磨。过程中遇到什么奇怪的问题随时来问，工具这东西，越用越熟。