2. 研发人员通过 Eclipse 的 Subclipse 插件生成基于当前服务器上代码的增量补丁，详见应用补丁部分。
3. 研发人员在 Bugzilla 上新建一个优先级为“研发”类型的新记录（图4），作为本研发流程的基点。
图 4 提交 Bug:TestProduct
4. 研发人员将补丁上传到“研发”记录的附件中（在附件中递交补丁将在后面介绍），并开启补丁的标签功能，比如研发人员张三和 QA 李四搭档研发，张三在配置标签的时候就会指定李四来复查，在下拉菜单中选中‘？’，并在后面的字段填上李四（图5）。
图 5 标记
此时，补丁的状态字段就会显示为 —— zhangsan:复查?(lisi)（图6）。假如研发人员重新想置空标签或不指定具体的 QA，只需在下拉菜单中选中空格即可。
图6 标记为需要复查
5. 对于 QA 来说，他能够利用标签的另外两个值来表明补丁的状态。假如 QA 发现补丁中存在缺陷或 bug，就将标签置为‘-’，表示没有通过复查（图7）。
图7 标记为拒绝
然后，针对补丁，报告 bug（在 bugzilla 上创建优先级为“复查”的新记录来报告补丁的 bug），并将他（们）指派给研发者张三。同时，配置这条记录的阻塞（block）字段，将他置为代码审查请求记录的编号（图8）。假如这里报的 bug 没有修复的话，代码审查请求记录是无法被关闭（closed）的。
图8 阻塞记录
6. 研发者修复了 QA 报告的 bug 之后，制作新版本的补丁文档上传。
7. QA 查看新补丁是否仍存在问题，若确认无误，能够关闭“复查”记录（图9）。
图9 关闭
8. QA 重复上述过程，直到补丁中没有缺陷。当李四认为复查已通过，便可将标签置为‘ ’，表明补丁通过了复查，这时附件状态就会显示为——李四:复查 。然后， QA 将相应的“研发”记录状态置为“已解决”，解决方案置为“修复”（图10），告诉 committer 这个补丁已能够递交到服务器。
图10 标记为已修复
9. 最后，项目组内的 committer 会搜索任何已解决（Resolved）的“研发”记录，把通过的补丁递交到 Harmony 的服务器上，再关闭相应的“研发”记录。
对已提交问题的通配符搜索
研发过程中，会产生大量的 bug 报告，如何从这些数据中获得我们需要的记录？bugzilla 提供了两种不同复杂度的搜索方式，第一种方式仅提供了状态、产品和关键字三个字段来进行搜索，他只能进行最基本的搜索功能，方便研发人员进行一些快速的搜索。Bugzilla 同时也提供了更为强大和全面的搜索功能，支持对搜索的定制。无论是研发人员还是 QA 都能够针对自己关注的问题，选择相关的字段，配置搜索条件（图11）。对于搜索的关键字，无需输入完整信息，系统会返回任何以该关键字为子串的匹配结果。
图11 通配符搜索
Bugzilla 的搜索还提供了一个很有价值的功能，他能够保存每次的搜索配置，只要您为当前的搜索配置一个易记名字（图12），就能保存当前搜索配置供下次使用，省去了无谓琐碎的重复配置。假如条件有变动，还能编辑搜索条件。
图12 搜索结果
当需要重复相同的搜索时，无需再次配置搜索条件，只需点击保存的名字就能够获得同样的搜索结果（图13），为研发人员提供了巨大的便利。
图13 保存搜索结果
研发中我们还能够通过 RSS 阅读器来订阅搜索结果，定制搜索条件获得数据时，在搜索的 http 地址后面加上"&ctype=rss"便可获取符合 RSS 标准的 XML 数据。通过 RSS 客户端软件订阅，便可和数据保持同步，无需通过 sendmail 来通知最新的变化。
报表的生成
研发进行了一段时间后，项目经理需要对项目进展连同任何研发人员的工作状况进行汇总，bugzilla 报表统计功能省去了枯燥的数据录入，方便汇总统计。Bugzilla 能够生成两种形式的报表（Report）进行统计。一种是以表格的形式，这是默认支持的。更有一种形式是通过直方图来表示结果，更加直观，他需要在编译 bugzilla 前，添加图像模块。两种形式报表的生成过程大致相同，我们以表格形式生成项目汇总报告为例，来介绍该功能。生成报表过程中条件的筛选类似高级搜索中搜索条件的定制。Bugzilla 报表生成功能提供了较大灵活性，用户能够配置三个坐标轴的字段值（图14）。
举简单的例子，我们研发总结时需要比较各个研发小组任何“研发”记录的总数，就能够通过如下方式来产生汇总数据
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
