TD数据库常用表.docx

TD数据库常用表以及字段的介绍（一）(2009-04-28 14:15:57) 转载标签： td数据库表it分类：TD测试管理工具 ALL_LISTS表该表包含这些字段：AL_ITEM_ID, AL_FATHER_ID, AL_DESCRIPTION, AL_NO_OF_SONS, AL_SYSTEM, AL_ABSOLUTE_PATH, AL_VIEW_ORDER, AL_MEMO, AL_ATTACHMENT, AL_ITEM_VERSION, AL_VER_STATMP, AL_VTS。其中前两个字段用于构建层次关系，这个表里面放的内容比较杂乱，像案例的类型定义（MANUAL / WR-AUTOMATED）、案例的状态定义（Passed / Failed）、Bug的优先级定义（1-Low / 2-Medium）、Bug的状态定义（Open / Closed）等，都是保存在这个表中。另外，在TD客户端（IE）中，Test Plan页面中显示的左边那棵案例树中的所有目录节点的定义，也都保存在这张表中，目录间的层次关系正是通过AL_ITEM_ID和AL_FATHER_ID字段来关联的，AL_DESCRIPTION字段中则存放目录名，AL_NO_OF_SONS字段中是该目录下面的子目录个数。 TEST表该表用来保存案例的定义，其字段比较多，关键的几个字段：TS_TEST_ID: 案例的IDTS_NAME: 案例名TS_STEPS: 案例的设计步骤个数TS_PATH: 如果是自动化测试案例，该案例对应的自动化测试脚本在当前这个项目所对应的根目录下的相对路径，这里保存的是存放脚本的目录的名字，也可能是多级目录TS_SUBJECT: 在案例树中，案例所在的目录节点的ID，这个字段可以和ALL_LISTS表中的AL_ITEM_ID字段关联起来TS_STATUS: 案例当前的状态TS_RESPONSIBLE: 案例负责人TS_CREATION_DATE: 创建日期TS_DESCRIPTION: 案例描述TS_TYPE: 案例的类型，如 MANUAL、VAPI-XP-TEST、LR-SCENARIO等TS_EXEC_STATUS: 案例的执行结果，按照TD的逻辑，一个案例可以被加到多个测试集中运行若干遍，这里这个字段总是保存案例最后一次被执行的执行结果。不清楚为什么TD要在TEST表中设计这个字段，我只发现这个字段在TD运行测试集后修改案例相关的需求（Requirements）的状态时有用到，其他地方似乎是不会需要访问这个字段的。TS_VTS: 该记录最后一次被修改的时间 DESSTEPS表该表用来放案例的设计步骤，相对来说这个表就比较简单：DS_TEST_ID: 设计步骤对应的案例的IDDS_STEP_ID: 设计步骤的IDDS_STEP_ORDER: 步骤的顺序号DS_STEP_NAME: 步骤名，如果通过IE客户端增加步骤时，默认生成的步骤名是Step nDS_DESCRIPTION: 步骤的内容描述DS_EXPECTED: 期望值CYCL_FOLD、CYCLE、TESTCYCL和RUN这几张表是和Test Set相关的。通过TD提供的案例树，用户可以对案例按照自己的意愿进行一定方式的组织（比如按测试的内容或者背测系统的版本等），而Test Set则提供了另外一种组织案例的手段，它允许用户在一个Test Set中添加若干案例。Test Set有点像测试概念中的Suite，TD的Test Set和案例的关系，算是一种比较松散的Suite-Case关系，TD中允许将一个案例添加到若干个Test Set中，并且运行一个案例在同一个Test Set中被添加多次，而每一次添加都是添加了案例的一个。 CYCL_FOLD表该表用来存放Test Set的目录结构（树的目录节点）。CF_ITEM_ID: 存放目录节点的IDCF_ITEM_NAME: 目录节点的名称CF_ITEM_PATH: 通过CF_ITEM_ID和CF_FATHER_ID这两个字段的值做级联，可以创建出Test Set的目录结构树，但这种创建树的方式相对来说比较繁琐，需要反复的进行级联查询。可能TD的设计者也是为了解决这种不方便的情况，增加了CF_ITEM_PATH这个字段。该字段的值是由ABCD等构成的字符串，Root下的第一级目录为AAAA加上单个的字母A、B、C、D等，ABCD等代表了显示树时该节点在父目录下的顺序。再次级的目录由父目录的CF_ITEM_PATH值后面加A、B、C、D等构成，依次类推。使用CF_ITEM_PATH字段的值，可以更方便的创建目录树，和查询某个目录节点下面的所有子节点（包括次级子节点）。CF_FATHER_ID: 父目录节点的IDCF_VIEW_ORDER: 从名字来看应该是表示该目录节点在同级节点中的显示顺序的，但从IE客户端上实际看到的情况，并不是如此，所以不清楚这个字段的作用CF_VER_STAMP和CF_VTS: 这两个字段可能和目录节点的版本管理有关系，发现在更改节点的名称时，这两个字段的值会发生变化，CF_VER_STAMP的值会顺序递增CF_NO_OF_SONS: 子节点的个数 CYCLE表该表用来存放Test Set，也就是Test Set树中叶子节点。CY_CYCLE_ID: Test Set的IDCY_CYCLE: Test Set的名字CY_OPEN_DATE和CY_CLOSE_DATE: 该Test Set的状态变成Open和Close的日期。一个Test Set被创建的时候，默认的就是处于Open状态的CY_STATUS: Test Set的状态，就两种状态，Open或者CloseCY_DESCRIPTION: 不清楚这个字段有啥用，怎么折腾都没让这个字段出现内容CY_COMMENT: Test Set的说明CY_CYCLE_VER_STAMP和CY_VTS: 和CYCL_FOLD表中的CF_VER_STAMP和CF_VTS类似，在更改Test Set名字的时候这两个字段的值会发生变化。由此也可以看出，TD的数据库设计里面，名字叫 XX_VER_STAMP和XX_VTS的字段（XX是表名的缩写），应该都是起类似的作用CY_FOLDER_ID: 该Test Set所在的目录节点的ID，这个字段和CYCL_FOLD表中的CF_ITEM_ID字段对应 TESTCYCL表该表用来存放Test Set和该Set中的案例间的对应关系。前面也有提到Test Set是一种组织案例的手段，一个Test Set中可以有若干案例，这种包含关系就是在TESTCYCL表中记录的。TC_CYCLE_ID: Test Set的IDTC_TEST_ID: 案例的IDTC_CYCLE: 用TD用了比较长的一段时间了，发现数据库里面这个字段的值一直是空的，从名字来看应该是和CYCLE表中的CY_CYCLE字段对应的，所以估计这个字段在时间的代码开发中没有按当初的设计来使用TC_TEST_ORDER: 案例在Test Set中的出现顺序TC_TEST_INSTANCE: 一个案例可以在同一个Test Set中被添加多次，每次添加的都会增加一个新的记录，这些记录之间没有联系，TC_TEST_INSTANCE字段就是用来区分同一个Test Set中同一个案例的多个添加记录的TC_STATUS: 案例的状态，刚刚添加的案例是No Run状态TC_TESTER_NAME和TC_ACTUAL_TESTER: 前者是该案例的负责人（Responsible Tester），后者是实际执行该案例的人TC_EXEC_DATE和TC_EXEC_TIME: 当案例的状态发生改变时，这两个字段就会被更新，以记录发生改变的时间TC_HOST_NAME: TD最强的功能之一呢，就是可以和MR公司的其他产品如QTP、LOADRUNNER等联合起来使用，TD负责管理案例、执行计划等，而将具体的执行（也就是自动化测试的执行）功能交给各种自动化测试工具去完成，而这些自动化测试工具呢，是不要求一定要和TD安装在同一台PC上的，所以案例可以被指定是在哪台PC上执行，TC_HOST_NAME字段就是用来记录执行案例的PC的名称的 RUN表一个Test Set可以被运行若干遍，一个Test Set中的案例也可以被运行若干遍，每一遍执行的结过都需要进行记录，RUN表就是用来完成这个使命的。RN_CYCLE_ID: Test Set的IDRN_TEST_ID: 案例的IDRN_RUN_ID: 索引IDRN_TEST_INSTANCE: 用于区分同一个Test Set中的同名案例，RN_CYCLE_ID、RN_TEST_ID和RN_TEST_INSTANCE这3个字段的值能唯一确定某个Test Set中的某个案例的一系列运行结果RN_RUN_NAME: TD执行案例时会自动生成这个名字，当然用户也可以通过TD客户