禅道库表关联总结

写在前面：

搞事无非三点：为什么，是什么，怎么做
为什么介绍到了禅道表道关联：测试组这边在beat测试期间要统计每天的bug，对bug进行分类统计后，邮件发送当天进度。于是乎我想到了自动化搞统计和发送邮件。
是什么让我们搞事：“懒”。节约统计时间，将更多的经历放在回归功能上。
怎么做：首先要说到统计bug，那就要了解禅道数据库的关联了(我们用的bug统计工具是禅道)
下面就主要介绍一下，我在统计过程中用到的表

统计的信息包括

首先我汇总了一下需要统计bug的信息，无非几点：bug数量，bug等级，bug的来源( 这个万恶的bug是哪位小可爱写的)，bug的归属(bug所属模块，bug平台，这两个后面会具体介绍一下），而筛选bug的条件无非是项目名称，bug版本和bug激活的时间。下面附上禅让提bug的界面来讲解各个模块

前面说到的bug的归属就是所属平台和所属模块。所属平台就是，这个bug是android的，ios的还是其他的等等。所属模块就是，举个例子在你吃饭的整个流程中发生了bug，但是你吃饭分很多步骤，拿起筷子出现了问题，还是端起碗出现了问题，所属模块就是记录哪一部分的。
最后经过收集大家的需求，测试期间每天的bug统计大概分成5个部分：体验问题，严重问题，bug数统计，bug解决率，未解决bug分布

表

终于到了重头戏就是表，进入禅道库后show tables后

我第一次看到这个数量的时候默念，稳住，我们能赢。首先我们介绍最主要的表，zt_bug。

zt_bug 真真实实记录bug的表

其实扫了一圈这些表名字，第六感就告诉我们这个表一定是记录bug的表。查看一下这个表结构

我仿佛看到了下路选鲁班还带治疗。我大概介绍一下我用到的列的含义
id：这个不用说了，就是bug的id，这个id后面你会发现有个很大的作用，每个bug对应的页面的url都是有逻辑的，例如：/zentao/bug-view-82594.html，而这个82594就是对应的bug id。
product ：bug对应的项目名称。
branch ：bug对应的平台名称。
module ：bug对应的模块名称。
title ：bug对应的标题信息。
status：bug状态。(激活，解决，关闭）
type：bug的类型
severity：bug严重等级
openBy：bug的创建人。
openDate ：bug的创建时间。
openBuild：bug创建的版本
assignedTo：bug指向人（bug指向谁，就是谁的bug）
resolvedBy：bug解决人
resolution：bug的解决方式（暂不解决，延期解决等）
deleted：bug是否删除，ps个人补充一下 开始我做统计时候并没有注意到这个列，发现统计的数据总是有偏差，百思不得其解，后来发现你通过禅道平台删除的bug并不会从数据库中删除，而是会用这个列进行区别，所以统计的时候一定要记得筛选这一列，‘0’表示当前bug未删除，‘1’表示当前bug已经删除。
取出上面列的值会发现很多值看不懂～其实还有很多表与上面列的值对应

zt_product -> product

select一下不难发现，zt_bug中product列是一个数字，而真实中你填写的项目是中文“XXX项目”，那么一定有另一个表将这个数字与“XXX项目”相对应，这个表就是zt_product。下面就是这个表的表结构

在zt_bug中的product内容就是zt_product表中的id列，而真正的“XXX项目”就是zt_product表中的name列，注意这个表也有一个deleted列，注意筛选可能有人创建了项目又删除了，别问我为什么知道。

zt_branch -> branch

zt_bug中branch列与branch中id列相对应。select一下不难发现，zt_bug中brancht列也是一个数字，那么同product

这里有个地方要注意有个product列，为什么要用到这列筛选。问题来了“A项目”的ios和“B项目”的ios都属于平台ios，那么你单纯筛选ios的bug就不能确定到底是那个项目的bug。所以有个product列，来确定具体是那个项目的bug。product列存的是zt_product表的id值

zt_module->module

zt_bug中的module列与module中id列值相对应。module与上面的情况大概相同，但是module还有个很繁琐的地方，就是层级。我上面举例过，这个表是bug的模块表。可能你夹菜这个模块出现问题，但是夹菜模块又分，你伸手，拿起筷子，去夹菜。拿起筷子又分怎么拿起来。所以功能模块之间其实是由归属的关系的。

于是乎这个root,parent,path这些列都是用来确定模块归属的，我没搞这么详细，我只简单的需求name的值就可以了，如果又想把模块具体划分搞得详细一点的，可以参考这几列的值。这几点列的值都是当前表的id值。

zt_build->build

zt_bug中branch列与zt_build列中id相对应。build的情况与上面branch基本一致

这里要额外介绍一列就是bugs这一列的值是当前版本的所有bug id以“，”间隔。例：“554,323,112,3214"

zt_lang->resolution，type，severity

这一个表控制了bug的解决方式，bug的类型和bug的严重程度

section列用来区分上面三个类型的哪一个（typeList，resolutionList，severityList）
key列就是zt_bug中对应列的值，而value就是你禅道平台显示的值。
举个例子：有一个bug，bug类型为体验问题 zt_lang表中，section=‘typeList’,key=‘security’,value=‘体验问题’。zt_bug表中type=security。
有一个bug，bug解决方法为延期解决，zt_lang表中，section=‘resolutionList’,key=‘postponed’,value=‘延期解决’,zt_bug表中resolution="postponed’
有一个bug，bug等级(bug严重程度)为1，zt_lang表中，section=‘severityList’,key=‘1’,value=‘1’，zt_bug表中severity=‘1’

以上就是筛选bug时禅道用到的所有表了