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 8080Windows下要去修改端口配置改完重启服务。我建议测试环境直接用默认端口或统一约定一个端口省得以后访问地址到处问人。第二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-P4P1是核心流程必须保证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列表等。你需要做的是选取统计范围、补充风险分析和结论建议。根据我的使用习惯一份能说服领导的测试报告至少包含这几块报告模块具体内容测试范围本轮测试覆盖了哪些模块、哪些类型的用例执行概况计划用例数、实际执行数、通过率、阻塞数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、生成一份像样的测试报告——你就已经把禅道测试管理的核心路径完整跑通了。剩下那些高级功能基本都是在这些基础操作之上的细节打磨。过程中遇到什么奇怪的问题随时来问工具这东西越用越熟。