mantis配置成局域网访问。急求！！！

方法1：关闭防火墙，还有就是：防火墙-->高级-->设置-->勾选“web服务器”试试！
方法2:：因为你是EasyPHP-5381里装的，则需要修改Apache的配置文件。
配置方法：
打开apache目录(C:"Program Files"EasyPHP31"apache"conf")，用记事本打开>缺陷管理贯穿于整个软件开发生命周期中 是不可缺少的环节 但在国内一些中小型开发商中没有得到足够得重视 本文结合实际应用 系统地介绍了缺陷跟踪开源软件 Buggit 和 Mantis 以期抛砖引玉 引起重视 在您的项目中 是否有遇到过这样的问题 测试人员报的缺陷被遗忘掉;延期项目终于发布 却遭遇用户频频抱怨 管理人员将矛头指向测试人员;书写不规范的错误报告 使得开发人员不得不一次次找到测试人员来重现;地域分散的开发团队 通过email和文档交流 缺陷状态混乱 相关人员无法及时获得有关的变更信息…… 那么 让测试组织使用数据库来部署产品缺陷的记录和跟踪吧!对于中小软件开发组织 或许不太可能使用动则几千美金一个许可证的商业软件 但免费而又易于维护的软件完全可以满足您 %以上的需要 如果您的组织还陷于无穷无尽的混乱不堪的缺陷之中 不要犹豫 马上行动 免费软件可以很好地管理这个过程 但在实施中对管理上提出的要求则是您应该自我提高的 下面我们看看一个中小型开发组织两年多的实施过程 或许对您有些启发

一 项目背景 组织架构

某公司在全球航运业信息化领先 在全球设有四个研发中心 主要为公司开发航运和物流软件 大多给公司内部和业务有关的客户使用 有些成熟的软件销售给同行或作为中立的平台提供给同行使用 该公司的上海的研发中心使用的是免费或开源的软件跟踪缺陷 有独立的测试小组 工作包括功能测试 压力测试 质量保证和过程改进 使用的是免费软件Buggit 后来为了解决异地开发过程中的缺陷跟踪问题 开始使用Mantis 版本(开源软件 PHP/MySQL/Web Based) 开始用一个实际的项目作试点 并根据项目组不同角色成员的反馈 测试组对系统进行配置和代码的修改加以提高;由于效果很不错 几个月后就推广到其他多个项目

二 缺陷跟踪流程

缺陷包括产品错误 需求和设计变更 新特性或扩展功能(New Feature Enhancement)等 它存在于整个软件开发生命周期之中 使用中心数据库便于项目组和管理人员获取正确 足够的信息 简化了地域分散的组织的信息共享流程 它还可以实现工作流程的自动化 最大限度减少重复工作
不同的组织 缺陷跟踪流程会有所不同 下图是一个典型的缺陷生命周期图


在alpha/beta测试期间 测试人员将发现的Bug 提交到缺陷跟踪系统 该系统至少应包含

失败描述 摘要 重建步骤 隔离信息;

识别信息 顺序的ID号 报告作者 报告归档日期

一个好的系统还需要

严重性等级 以评估在测试条件下 错误在系统中的绝对影响;

优先级 评估顾客实际使用中发生事件的可能性 或对目标顾客的后续影响;

环境 系统软 硬件配置 测试版本号;

附件 错误信息或屏幕截图

提交之后 Bug为 Submitted 状态 变更控制委员会(Change Control Board 视项目规模组织 可以是不同角色的几个人组成或一个人担当)评审决定

是Bug 分配给相关开发人员修复 状态为 Assigned ;

不是Bug或其他原因 关闭 状态为 Closed 解决方式(Resolution)根据实际情况选择;

是Bug 但延迟到下一个版本修复 状态为 Postponed

开发人员将Bug修复后 其状态改为 Resolved 他们应发布到下一个测试版本(Test Build)中 测试人员测试所有 Resolved Bug 没有问题应关闭( Closed 状态) 未修复则要重新打开( Opened 状态)

对于用户提交的Bug 有些系统会增加 Confirmed 的状态 表示经测试Bug确实存在

对其他变更(如需求改变或新增) 以上流程同样适用 但可能需要多次分配(assign) 如需求变更 业务分析员要更新需求文档 系统分析员要更新设计文档 然后程序员改代码

系统最好还有以下功能

Root Cause 根本原因分析 这需开发人员的帮助;

Close Date和Resolution 系统生成关闭日期 可选择或输入问题是如何解决的;

系统自动跟踪记录缺陷历史 可输入注释;

方便的查询功能;

可定制的报表 缺陷趋势图表;

Email提醒

三 缺陷跟踪过程实施

流程制定并评审通过后 就应该选择合适的工具 对一个新组建的组织 也可以先选择工具 再结合特定的工具制定流程 正式实施前应对项目组所有成员进行培训 以提高工具使用效率和成员间的沟通效率

最初我们选择了一个十分简单而又易于维护的工具Buggit 用于项目组内部的Bug跟踪;随着跨地域开发项目的出现 沟通交流复杂性凸现 我们适时选择了Web Based系统 下面看看两个系统的具体实施

使用免费工具Buggit

Buggit 是一个十分小巧的C/S结构的Access应用软件 仅限于intranet 十分钟就可以配置完成 使用十分简单 查询简便 能满足基本的缺陷跟踪功能 还有十个用户定制域 有十二种报表输出

我们在一个十几人的开发团队 使用了两年半时间(版本V Bld for Windows / and NT ) 基本没有数据丢失 有过几次数据库格式错误 一般可恢复 Email通知和缺陷趋势图功能不稳定 该系统的安全性和权限控制十分薄弱 需要团队成员按规范配合

详细信息请访问Buggit主页// ibm /developerWorks/cn/linux/sofare_engineering/l mantis/ pb sys 下图为Buggit主页面和详细缺陷报告



使用 web based开源软件Mantis

Mantis是PHP/MySQL/Web based缺陷跟踪系统 即使没有经验也可以在一天内配置完成

由于我们的研发团队是地域分布式的 有些项目是上海 硅谷和香港的研发中心合作开发 需求 设计 开发 测试和用户反馈来自不同地区 使用电子邮件和文档来跟踪缺陷时 信息共享和错误状态更新都费时费力 随着项目的扩展 文档工作量也越来越大 这时使用web based系统 项目组共用一个中心数据库实现工作流自动化提到议事日程 因为是选择开源软件 所以要考虑系统稳定性和安装配置 维护工作量 这项工作完全由测试组实施 我们在今年一月到四月将 Mantis安装到个人工作的PC机 请不同角色的人试用 反馈效果良好 我们马上决定将系统用于跨地域开发的项目 系统正式安装在开发用的Server 上 *** 作系统是Solaris 配置比Windows下稍复杂一些 使用过程中 根据开发组的反馈 由测试组通过修改源程序放宽了Assign To和缺陷更新的权限 将下一版本中的Bug History和缺陷图表包集成到目前使用的版本 增加了CSV Export数据域 现在我们已将该系统推广到其他几个项目 总共有四十人左右使用 通过公司专线访问 在近一年的时间里 系统运行平稳 性能也比较理想 简化了流程 从而提高了工作效率

Mantis特性

Mantis当前版本为 下一版 处于Beta发布阶段

关于产品详细信息和支持 请访问主页//manti t sourcefe net/ 下图为查看所有Bug和查看详细Bug页面



Mantis基本特性

个人可定制的Email通知功能 每个用户可根据自身的工作特点只订阅相关缺陷状态邮件;

支持多项目 多语言;

权限设置灵活 不同角色有不同权限 每个项目可设为公开或私有状态 每个缺陷可设为公开或私有状态 每个缺陷可以在不同项目间移动;

主页可发布项目相关新闻 方便信息传播;

方便的缺陷关联功能 除重复缺陷外 每个缺陷都可以链接到其他相关缺陷;

缺陷报告可打印或输出为CSV格式 版 支持可定制的报表输出 可定制用户输入域;

有各种缺陷趋势图和柱状图 为项目状态分析提供依据 如果不能满足要求 可以把数据输出到Excel中进一步分析;

流程定制不方便 但该流程可满足一般的缺陷跟踪

四 项目实施经验教训

测试作为项目开发的最后一环 错误 延时 疏忽等都可能在测试阶段表现出来 如何有序管理和分析各种问题对质量控制和过程改进非常重要 使用web based系统就是一个好的实践

在项目组内 对Bug采用数据库系统进行跟踪并不困难 因为主要是测试人员提交Bug报告 测试人员使用最多 相信测试人员对使用中心数据库的好处是很了解的了 只要项目经理支持就很好办了 如果要对其他缺陷 如需求变更 也这样管理就不是那么容易了 在技术上当然没有问题 难在工作方式的改变 虽然用 Email和文档管理无法实现工作流的自动化 也不如数据库系统提供那么多的分析和报告选项 但在小规模的项目中依靠人工管理也可以做得井井有条 我们在多个项目的实施中就遇到这样的情况 有的项目随时都有需求变更 而且变更的数量不少 项目组主动提出想用数据库系统来管理;有的项目刚起步 第一个阶段的开发业务功能不多 推行的时候阻力就很大 我的初级目标是有序地管理错误和变更 在实施手段上有冲突时 不要 *** 之过急 融洽的关系对项目的成功是很重要的 往往是有了成功的案例后 回头推广又变得容易了 实施新过程时最好先局部试点 采用PDCA循环 不断总结经验 再推广

使用缺陷数据库 可以制作得到各种缺陷分析图表 从而预测项目风险或解释测试结果 下面两张图都是Mantis生成的缺陷图 从累积错误打开图 分析错误生成趋势 在发现错误报告未收敛时发布软件 显然风险很大 当然使用图表时还应结合实际 在曲线平坦时 是否开展了测试工作 曲线上升时 错误的严重性等级如何等 从严重性等级的柱状图可分析被测系统的总体状况 在发布管理不规范的组织中 当产品质量问题突出时 测试组可以通过解释这些图来阐述测试结果 从而规范发布过程

第一部分提到的根本原因(Root Cause)域 他有助于使开发人员的注意力集中到引起最严重 最频繁问题的领域 从而消耗最少的资源改进过程取得最显著的成果 这是我在过程改进时最常用到的 / 法则 在项目实施时 实际情况并不理想 因为开发人员忙于改Bug 少有主动写错误发生的根本原因的 这需要开发人员的配合和管理者的支持

缺陷数据的使用应谨慎 不要将错误个人化 应保证数据的真实性 否则数据对过程改进没有意义

实施过程中 大家会对工具提出很多需求 应评估哪些是共同需求 核心需求 系统修改复杂程度 对当前系统和系统升级的影响 测试组在实施过程中 对不同角色人员的工作流程有了深入而准确的了解 同时可以进行工作流程的改进



使用开源系统的利弊

由于开源系统的代码是公开的 用户可自行维护和定制 大家也可以提交新特性和功能扩展要求 而不必受制于商业系统的制造商 开源系统的用户遍布世界各地 Bug反而容易发现 同时公开源代码中低效率的程序也容易被发现和修改 当然越是流行的软件 生命力越强 Bug清除和新特性增加越快

开源系统与其他工具的集成比较差 不如商业系统提供整个软件开发生命周期的工具的集成 如项目管理 需求管理 建模 自动化测试 缺陷跟踪 配置管理等有机集成 实现整个开发流程的自动化 但一般的中小企业 大多没有实力配置全所有系统 另外 不同厂商优势不同 主导系统也不同 有的企业需要根据自身的特点选择不同厂商的工具 所以即使购买商业工具也未必能将所有系统很好地集成

开源系统是免费的 但有人提供收费的系统维护和定制服务

五 小结

本文主要探讨缺陷跟踪管理的流程 工具和实施问题 缺陷跟踪在技术上并不难 而是难在管理上 好的工具有利于管理和交流 优秀的项目组应意识到有效的交流方式是多种多样的 不应该单依赖系统 这样才有利于提高团队的战斗力 而不是把重点放在追求系统功能的十全十美 有些缺陷跟踪系统有Knowledge Base 功能 这对公司知识库的累积也很有效;有的系统对不同用户生成相关的To Do List 方便日常工作;有的对每个发布版本都有详细的缺陷报告 总之 花费时间和精力完善错误管理系统是值得的 这是质量管理和提高的基础

如果用户数使用量网速等条件不变，服务越来越慢的话，可能是历史数据积累造成的。
提交新问题时索引/视图的重建费时较多。
方案有很多的，我简单列几个：
1 优化数据库的配置
2 优化apache的配置
3 服务器硬件升级
4 采用独立的数据库服务器
5 数据的分级管理，定期将不常用的数据（项目）移到另一个库
6 如果有自己另外加的索引或视图，考虑一下是不是删掉更好

---