MantisBT从零部署到实战：开源缺陷管理系统的安装配置与团队应用指南

先聊聊我最初接触 Mantis 的场景。那会儿团队里缺陷管理靠的是表格加聊天群测试人员报一个 bug 要打字描述半天开发改完还要截图回复消息一刷屏整个上下文就乱了漏单、错单、返工全是这么来的。后来我们决定上一套缺陷跟踪系统对比了几个方案最终落地的是 MantisBT——大家一般直接叫它 Mantis。前后用到现在从最开始的安装部署到日常配置维护踩了不少坑也积累了一些心得。这篇文章就把 Mantis 从零开始安装、配置到实际使用的完整流程做一个梳理既适合第一次接触缺陷管理工具的新手也适合正在评估工具选型的技术负责人参考。Mantis 本质上是一套开源的 Web 端缺陷跟踪系统核心价值就是“让每个问题都有迹可循”。它不需要昂贵的商业授权部署成本低对服务器要求也不高一台普通 2 核 4G 的云主机就能跑得很稳健。通过浏览器访问任何人不需要装客户端就能参与协作开发、测试、产品都能在一条流程里完成问题流转。最实用的功能包括缺陷提交与指派、状态流转、自定义字段、邮件通知、多项目管理和用户权限控制基本覆盖了一个软件团队从收集问题到跟踪闭环的全部需求。1. 为什么选 Mantis从选型逻辑到适用场景1.1 团队卷入缺陷管理的真实痛点很多中小团队一开始并没有“缺陷管理”的概念开发靠即时聊天工具接收问题测试靠表格记录回归结果。等项目和人数同时上来之后问题才会集中爆发同一类 bug 被重复提交开发无法判断优先级测试搞不清哪些已经修复历史问题更是无从追溯。等到上线前再集中补台账往往要花掉大批量人工而且信息流的失真度极高。缺陷管理系统的核心职责就是充当“唯一事实源”。每个 bug 拥有独立编号、标题、描述、附件、优先级、指派人和状态所有变更记录保留历史谁改了什么、什么时候改的、为什么改一目了然。这正是 Mantis 这类工具的定位它不负责重构你的研发流程只负责让问题信息流保持稳定、可追踪、可统计。1.2 开源缺陷工具对比Mantis、Jira、Redmine、禅道网上关于工具选型的讨论很多不同公司体量和研发模式适合的方案差异很大。我实际用过 Jira、Redmine 和禅道各有特点这里整理一张对比表方便大家判断。工具部署方式学习成本扩展性系统资源占用适合团队JiraSaaS/私有化中高插件生态极强高中大型团队、成熟敏捷流程Redmine私有化中插件多但维护费力中小型团队、项目管理需求重禅道私有化低内置产品-项目-测试体系中国内团队、需要一体化管理MantisBT私有化低插件够用、轻量低中小团队、缺陷管理为核心对比下来Mantis 的优势非常直白部署轻、吃得少、学习门槛低。如果团队核心诉求就是管好 bug不愿为了配合工具改变整个协作流程Mantis 几乎是零摩擦的选择。Jira 确实强大但工作流配置、权限模型和插件体系对小型团队而言是负担禅道一体化程度高但某些团队未必需要它的测试用例和项目集模块反而显得臃肿。Mantis 的定位足够聚焦做到严重偏科不对是严重专一一条缺陷从提交到关闭的完整生命周期。1.3 我建议哪些场景优先考虑 Mantis结合使用经验下面几类场景选 Mantis 不会后悔团队规模在 2~30 人之间需要快速上线缺陷管理不想花太多时间维护工具这是一个很典型的使用阶段。处于创业公司或项目外包状态预算有限希望把资源放在业务开发上而非基建平台上。现有流程已跑通只是缺陷这块依托聊天记录太混乱需要一个轻量系统把信息沉淀下来。需要自定义状态流和字段比如某个项目需要额外的“验证方法”“故障等级”等专属信息。如果团队已经深度使用 Jira 的敏捷看板和需求联动建议就不要迁移了如果团队需要完整的测试用例管理、自动化统计报表和需求关联Mantis 的基础功能偏薄弱需要靠插件补齐不如一步到位选禅道或 Jira。工具选型这事合适比“最强”更重要我在团队里常说一句话先想清楚你要解决什么问题再挑工具。2. 安装部署前的准备工作2.1 环境需求拆解PHP、数据库、Web 服务器MantisBT 是 PHP 应用所以核心依赖是 PHP 环境。以当前主流的 2.25 版本为例要求 PHP 版本不低于 7.3同时需要启用 pdo_mysql、mysqli 或 pgsql 扩展。非要说哪个数据库最省心我推荐 MySQL/MariaDB兼容性最好网上资料和问题案例也最多。Web 服务器方面Apache 和 Nginx 都可以跑。生产环境我习惯用 Nginx PHP-FPM原因很简单并发压力小内存占用低反向代理做起来顺手。如果团队对运维不熟Apache 配合 mod_php 反而是更省事的选择。另外服务器需要具备访问外网的能力因为安装过程中要下载解压包后续插件扩展也要在线获取。一个小提醒Mantis 对 PHP 的内存限制有最低要求建议memory_limit设置为 128M 以上。默认配置经常只有 32M导入较大的数据库脚本或生成统计报表时容易爆内存从而出现白屏或 500 错误。这一条在官方文档中容易忽略但实际运维中非常关键。2.2 获取安装包下载与目录规划下载 MantisBT 非常简单打开官方网站的下载页面选择最新稳定版 tar.gz 包即可。厂商把压缩包统一维护得很规范版本信息和 md5 校验值也很有用习惯上我会在命令行里顺手校验一下哈希以免下载过程中文件损坏。服务器上存放路径我建议放在/var/www/mantis或/data/wwwroot/mantis不要直接放 web 根目录的根上否则之后的升级迁移会很混乱。如果是多项目共用服务器建议每个应用单独建目录Mantis 就是一个独立站点。目录权限上运行 PHP 的用户需要对该目录有读写权限特别是config目录和tmp目录安装向导会往这两个位置写临时文件。2.3 提前创建数据库与账号这一步很多人会漏实际操作中安装向导失败多半是因为数据库权限没给足。建议安装前就通过命令行或管理面板创建好专用数据库和账号而不是用 root 账户直接连。专用账号遵循最小权限原则只需要对 Mantis 库的select/insert/update/delete/create/alter/drop/index权限即可。创建数据库的 SQL 大致如下以 MySQL 为例CREATE DATABASE mantisbt DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE USER mantis_userlocalhost IDENTIFIED BY 你的强密码; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, INDEX ON mantisbt.* TO mantis_userlocalhost; FLUSH PRIVILEGES;注意字符集一定要指定为 utf8mb4否则之后提交的缺陷内容如果包含生僻字、Emoji 符号可能会乱码或保存失败。这个细节是我在实际项目中踩过的坑早期用了默认 latin1测试环境没问题一上线用户从移动端复制了一段带特殊符号的文本整个记录直接存不进去。3. 从零开始安装 Mantis 的完整实操3.1 LNMP 环境快速准备我这里以 CentOS 7 系统为例展示一套最常用的 LNMP 环境搭建流程。如果你的服务器是 Ubuntu/Debian命令换成apt即可核心思路完全一致。# 安装 EPEL 和 Remi 源获取新版 PHP yum install -y epel-release yum install -y http://rpms.remirepo.net/enterprise/remi-release-7.rpm yum install -y yum-utils yum-config-manager --enable remi-php74 # 安装 Nginx、PHP、PHP-FPM 以及扩展 yum install -y nginx php php-fpm php-mysql php-gd php-mbstring php-xml php-json php-zip # 安装 MariaDB 数据库 yum install -y mariadb-server mariadb systemctl start mariadb systemctl enable mariadb mysql_secure_installationPHP 扩展中特别要关注php-mbstringMantis 的多语言界面包括中文简体、中文繁体都依赖这个扩展。如果没装安装向导能走完但登录后台后页面会出现空白或者语言包加载异常。3.2 下载 MantisBT 并设置目录权限cd /var/www wget https://sourceforge.net/projects/mantisbt/files/mantisbt-2.25.7.tar.gz/download -O mantisbt.tar.gz tar -zxvf mantisbt.tar.gz mv mantisbt-2.25.7 mantis cd mantis chown -R nginx:nginx . chmod -R 755 . chmod 777 config chmod 777 tmp这里的config目录初始状态下不存在安装向导会自动创建但前提是 web 用户有写入权限。如果权限不够安装时会提示无法写入配置文件白白浪费时间排查。我给config目录的权限是 777只是安装阶段临时放开安装完成后建议立刻收紧为 750 或者直接通过 chmod 修改毕竟配置文件中包含数据库密码不应该允许任意用户读取。Nginx 配置一个最简单的虚拟主机server { listen 80; server_name mantis.example.com; root /var/www/mantis; index index.php; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass 127.0.0.1:9000; } location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ { expires 7d; log_not_found off; } }配置好后重载 Nginx 和 PHP-FPM浏览器访问http://mantis.example.com就能看到 Mantis 的安装引导页。3.3 浏览器安装向导逐项解读安装界面整体分四步环境检查、数据库配置、管理员设置、确认安装。第一步环境检查会列出 PHP 版本、扩展加载情况和目录写入状态每一项显示 OK 或警告。如果出现“未通过”的红色状态直接按提示解决常见的是php-mbstring未安装或config目录不可写。第二步数据库信息填写数据库类型选择 MySQL Improvedmysqli。主机名填localhost或数据库服务器 IP。数据库名填mantisbt。用户名和密码填刚才创建的专用账号。表前缀建议默认留空或用mantis_前者方便 SQL 直查后者便于识别。这里要注意的是“表前缀”一旦设定后期修改成本很高因为所有 SQL 查询和部分插件都会引用它。首次安装就统一规划好不要用默认的mantis_后又反悔。第三步设置管理员账号。系统默认的管理员用户名就是administrator密码可以在这里直接设置。邮箱务必填写真实可用的地址后续系统通知和密码找回都要依赖这个邮箱。第四步点击“安装”后Mantis 会执行数据库初始化脚本创建大约一百多张表然后提示安装完成。走到这一步安装本质上已经成功了但强烈建议做一件收尾工作删除或重命名admin/目录。cd /var/www/mantis mv admin admin_bak_date这步不做攻击者可以直接访问admin/install.php尝试重装系统覆盖数据库导致灾难性后果。每年都能看到不少因为没删 admin 目录被恶意重装的案例这条算是我列进团队安全红线清单的第一条。3.4 登录后台并完成基础配置用管理员账号登录后会进入 Mantis 的后台管理界面。首先要修改两处地方时区和语言。管理操作路径是“管理”——“全局配置”。时区选择Asia/Shanghai默认时区如果不对缺陷提交时间和邮件通知时间全是错的排查问题时容易让人疯掉。默认语言可以设为chinese_simplified不过我个人更建议先保持auto让系统根据浏览器语言自动切换界面这样开发团队中用英文习惯的同学也不会觉得别扭。还要顺手配置“站点名称”这个名称会显示在页面标题和邮件通知的主题中。项目初期叫“测试环境Mantis”没问题但正式部署时建议用团队统一识别的业务名称比如“某某项目缺陷管理平台”用户从邮件里收到的通知内容也会更规范。4. 核心配置细则用户、项目、邮件与自定义字段4.1 用户管理与权限角色划分Mantis 内置六种角色滑块不对依次是访客、查看者、报告者、更新者、开发者、管理者。默认新建用户的角色一般是“报告者”或“查看者”权限从低到高分配合适的业务动作。实际使用中我的分配原则是产品经理报告者或更新者负责提交缺陷和补充描述。测试人员更新者可以修改状态、指派、添加备注。开发人员开发者可以处理缺陷、修改状态、记录修复备注。技术主管管理者拥有项目配置、用户管理、导出统计的权限。外部客户查看者只读权限用来跟踪他们提交的问题进度。用户管理里有一个很好用的功能是“项目-用户-权限”矩阵可以把同一个用户在不同项目里设置为不同角色。比如某人既是 A 项目的开发又是 B 项目的测试这在实际项目中很常见矩阵配置比一刀切的角色灵活得多。批量创建用户方面Mantis 支持导入功能也可以通过管理界面手动创建。几十人团队手动逐个添加尚可接受人再多建议直接用 SQL 或写脚本调用 API官方提供了 SOAP/REST 接口这个后面细说。4.2 创建项目与自定义字段“项目”是 Mantis 缺陷管理的顶层单元建议一个产品线创建一个项目而不是一个大项目下堆所有模块。项目创建后在“管理”——“项目”——“编辑”里可以设置或者说是关联子项目。自定义字段这个功能特别值得花时间打磨。例如一个 App 项目我通常会定义设备型号下拉框iPhone 15、华为 P60 等系统版本文本框出现频率下拉框必现、偶现、极少版本号下拉框关联每个发布版本严重程度由默认字段承担但可以扩展业务维度字段需要和“项目”进行关联后在该项目的缺陷提交页才会出现。关联方式是“管理”——“自定义字段”——选择字段“管理”——“项目”——该项目——“编辑”在右侧分配字段列表中添加。有个小细节每个字段都可以设置“只在新增时显示”“必填”“默认值”等属性建议必填项不要太狠不然测试人员填起来有情绪反而影响提 bug 的积极性。4.3 邮件通知配置与常见参数邮件通知是 Mantis 的灵魂功能之一用户提交缺陷后相关人被邮件提醒避免每天拿头去刷新页面。SMTP 配置藏在“管理”——“邮件配置”中。$g_phpMailer_method PHPMAILER_METHOD_SMTP; $g_smtp_host smtp.example.com; $g_smtp_username no-replyexample.com; $g_smtp_password 你的SMTP授权码; $g_smtp_port 465; $g_smtp_connection_mode ssl; $g_administrator_email adminexample.com; $g_webmaster_email adminexample.com; $g_from_email no-replyexample.com; $g_from_name Mantis Bug Tracker; $g_enable_email_notification ON;注意很多邮箱的 SMTP 密码不是登录密码而是单独开通的授权码比如网易、腾讯企业邮都这样。配置好后建议先给自己发一封测试邮件确认能收到再告诉团队投入使用。如果邮件发不出去八成是 SMTP 端口被封了465 或 587 换着试试另外 SMTPS 和 STARTTLS 的抓包调试方式也不太一样后面问题部分细讲。4.4 通过 REST API 做二次扩展不少团队用 Mantis 一段时间后会想跟内部系统打通比如自动化测试工具把失败用例自动建缺陷、CI 流水线根据缺陷状态决定是否允许发布。Mantis 从 2.0 版开始提供了比较完善的 REST API通过对/api/rest/路径的 HTTP 请求即可操作问题、项目、用户。# 通过 API 创建一个新缺陷示例 curl -X POST http://mantis.example.com/api/rest/issues \ -H Authorization: Bearer token \ -H Content-Type: application/json \ -d { summary: 登录页面在 iOS 17 下闪现白屏, description: 复现步骤使用 iPhone 15 Pro Max打开登录页快速切换账号输入框时出现白屏约 2 秒后恢复。, project: {id: 1}, category: {id: 1}, priority: {name: high} }API Token 在用户个人资料页面可以生成每个用户可以申请多个 token支持标记用途。我的习惯是给自动化脚本单独建一个专用账号再生成 token避免脚本误操作影响个人账号数据。5. 使用场景实战从一个 bug 的完整生命周期说起5.1 测试人员提交缺陷的规范操作很多团队用 Mantis 效果不好的核心原因不是工具不行而是使用习惯没建立起来。我总结了一套提 bug 的规范模板贴在新人入职文档里标题言简意赅格式“模块-现象”例如“支付-微信支付成功后回调未跳转”。严重程度结合影响范围选择崩溃级、阻塞级、一般、轻微、建议。复现步骤分点写清楚前置条件、操作路径、实际结果、期望结果。附件能截图就截图能录屏就录屏附件是速度最快的信息载体。指派对象清楚归属就指派给对应开发不清楚就指派给直属测试组长。备注补充设备型号、环境地址、账号权限等上下文信息。给新人培训时我反复强调一个逻辑好的缺陷单应该像一份完整的实验报告另一个人不需要和提报人沟通仅凭描述就能复现问题。这样既不浪费开发时间也能减少来回沟通成本。5.2 开发处理与状态流转的精简模型Mantis 默认的状态机包含新建、已指派、已反馈、已承认、已确认、已分配、已解决、已关闭。这套状态机对各种团队流程兼容度很高但状态太多对小型团队反而增加负担。我实际部署时简化成一条流水线新建 → 认可/指派 → 修复中 → 待验证 → 已验证 → 关闭。简化通过“工作流配置”来实现在管理菜单中设置可见状态和转换关系比如“新建”只允许转化为“认可/指派”不允许直接跳到“已关闭”保证每个环节都有责任人。状态流转的核心好处是“责任可追踪”。谁提的 bug、谁认可了、谁负责修、谁验收每一步都有记录复盘会上直接查历史即可。团队成员对状态的职责边界非常明确减少了大量私下沟通成本。回头来看这比任何花哨的统计报表都重要。5.3 定时统计与质量度量Mantis 默认就带有“统计报表”模块可以按项目、按处理人、按状态生成缺陷密度、打开率、平均修复时间等图表。我给部门做周报时经常直接从“统计”——“报表”导出 CSV然后再拿来做汇总。更高级的需求可以用 REST API 把数据拉到自己的报表系统比如定时执行 Python 脚本拉取指定时间段的缺陷由 Python 脚本写入业务库生成团队自有看板。这里给一个简单示例import requests import json from datetime import datetime, timedelta url http://mantis.example.com/api/rest/issues headers {Authorization: Bearer token} params { project_id: 1, page_size: 100, page: 1, filter: date_submitted, from_date: (datetime.now() - timedelta(days7)).strftime(%Y-%m-%dT%H:%M:%S), to_date: datetime.now().strftime(%Y-%m-%dT%H:%M:%S) } resp requests.get(url, headersheaders, paramsparams) issues resp.json()[issues] print(f过去 7 天新增缺陷{len(issues)})有了历史数据之后缺陷趋势分析就能帮助企业做质量预测比如临近发版前一周新增缺陷曲线是否收敛长期不关闭的遗留缺陷占比是否过高这些都对团队迭代节奏有指导价值。6. 常见问题与排查技巧实录6.1 问题速查表下面的速查表来自我和团队这些年实际操作中遇到的真实问题可以直接当成排查手册用。现象可能原因解决方案安装页提示 config 目录不可写web 用户对目录无写权限执行 chown 和 chmod 777安装后收紧权限安装后页面全白或 500PHP 内存不足或缺少扩展检查 php.ini 的 memory_limit确认 mbstring、pdo_mysql 已启用登录后界面语言是英文默认语言设置不对管理 → 全局配置 → 默认语言选 chinese_simplified中文内容乱码数据库字符集不是 utf8mb4建库时指定 utf8mb4必要时转换已有表编码邮件通知收不到SMTP 配置有误或端口被封检查 SMTP 端口、授权码使用 smtp 调试命令验证提交缺陷没有自定义字段字段未关联到项目在项目的编辑页中关联目标字段用户密码忘记管理员重置管理 → 用户 → 选择用户 → 重置密码admin/ 目录提醒已删除确认目录已被移除否则有安全风险统计报表数据空白时间范围无数据或筛选条件错误调整日期范围、检查项目与版本筛选PHP 版本过高警告Mantis 对极端新版本兼容慢建议使用 PHP 7.4~8.1稳定且官方支持6.2 邮件调试的实战心得邮件问题是我被问得最多的一项因为邮箱服务商的环境差异太大。自己排查时可以先脱离 Mantis直接用命令行测一下 SMTP 是否通telnet smtp.example.com 465如果不能连接大概率是网络策略或云服务商封禁了端口。能用命令行发信的证明网络没问题再去检查 Mantis 的配置。还有一类坑是 SMTP 连接方式不匹配SSL 和 TLS 的区别以及端口映射可以参考邮箱服务商提供的具体参数。6.3 数据备份与升级注意点Mantis 的数据全部在数据库里所以备份数据库就是备份整个系统。我习惯每天凌晨用 crontab 做一次完整的mysqldump保留最近 7 天的备份文件然后同步到异地存储。mysqldump -u mantis_user -p密码 mantisbt /backup/mantis_$(date %Y%m%d).sql升级版本前务必备份一次数据库和旧代码目录。Mantis 的官方升级流程很简单下载新版包覆盖旧文件但保留config目录然后访问安装向导它会自动识别当前版本并执行迁移脚本。但代码覆盖前一定先确认你是否有修改过核心文件——如果有升级后可能被覆盖丢失最好用版本管理软件或 diff 工具确认后操作。6.4 捍卫系统安全目录权限、登录策略与 HTTPSMantis 默认提供了基础防护但企业使用最好再加几层强制 HTTPS 访问在 Nginx 层配置 301 跳转避免账号密码明文传输。开启密码复杂度校验在全局安全配置里设置最少位数和复杂度要求。开启登录失败锁定机制比如失败 5 次锁定账号 15 分钟防暴力破解。定期审计用户列表离职员工的账号及时禁用或删除。这些配置在“管理”——“安全”菜单下都有入口十人规模团队也别偷懒省掉安全意识要从小团队建立越早越省事。7. 插件扩展与生态7.1 常用插件推荐与安装方式Mantis 的插件目录在源码包的plugins/下安装插件就是在该目录解压压缩包然后在管理后台的“插件管理”里点击安装。推荐几个实际使用下来口碑不错的插件EmailReporting支持通过邮件创建问题适合客户通过邮件反馈场景。ExcelExport增强导出到 Excel 的功能比内置 CSV 更适配中文办公需求。MantisGraph提供图形统计图表库支持默认的图表模板比较朴素这个能做得更美观点。SavedQuery部分版本有已内嵌的功能如果找不到就装这个插件来自定义筛选视图。插件安装数量不建议贪多每个插件都是一份需要升级维护的代码。我见过生产环境装了十几个插件一次版本升级直接兼容性爆炸折腾了好几天。插件生态虽好但生产环境能少装就少装。7.2 与代码仓库、IM 工具的联动Mantis 支持与 Git、SVN 的高级联动配置源码管理接口后源码提交信息中可以带上缺陷编号系统会自动在对应缺陷下追加备注。我自己最常用的联动方式是自定义 Webhook 脚本把状态变更推送到企业微信群或飞书群这样每个流转动作团队都能实时感知比频繁刷邮件高效得多。推送脚本的思路很简单在 Mantis 的 API 事件钩子里注册回调或者用一个外部脚本定时轮询变更记录检测到状态变化后再调用 IM 机器人发送消息。这些扩展能力说明 Mantis 的开放接口设计得很成功不会把你锁死在一个封闭的产品里。8. 最后分享一点实际运维中的体会用了 Mantis 这几年我有一个很深的体会缺陷管理系统的成功与否一半取决于工具选型另一半取决于团队的日常使用习惯。工具只是容器装进去的内容和流程才是真正的价值。新团队上线 Mantis 时我会在第一个月坚持每周看一次数据抽查若干条缺陷单的填写质量发现问题直接在工作群里给出修改建议。等大家养成规范的操作习惯之后系统的价值会越来越好统计分析也有了真实的数据基础团队的安全感也随之提升。如果你的团队现在还在用聊天记录和表格管理 bug真的建议花一个下午把 Mantis 部署起来。按本文的流程走一遍加上配置邮件通知和简化状态流第二天就能投入使用。后续等到使用成熟再逐步扩展插件、API 和统计功能完全来得及。