2．Rational ClearQuest Designer设置CQ
Designer主要进行缺陷提交页面和选项的配置，也是CQ中最重要的部分。这里的功能和配置很多，可以使用Basic或Perl进行编程设置。这里我也只研究明白了一小部分，欢迎大家以后能多多的研究补充。 2．1进入CQ Designer
从菜单中打开Rational ClearQuest Designer（安装目录中的cqdesign.exe），出现的界面中，选择“测试连接维护库”进入刚才设定的维护库。在登陆界面中，User Name输入admin（缺省的超级管理员），Password为空（可以参照2.4修改密码），点击“ok”进入Designer（如下图）。
如果要修改已有的计划（Schema），可以选择需要修改的计划名称（Schema Name），点击“完成”进入修改页面。 我们这里要创建新的计划，所以点击“取消”关闭界面。 2．2建立新计划
在使用过程中，新的计划必须从现有的计划中继承，原计划中的各种配置新计划都可以继承下来。建议配置一个标准的计划，其他的计划都从此计划中继承。 每次修改计划，都需要把计划check out，修改后，保存计划，再把计划check in，计划的Version（版本）加1。 下面是计划的建立步骤： 1．从菜单中选择“File-> New Schema” 2．在schema list窗体中选择 DefectTracking, version 1，然后选择“下一步”. 3．在Schema Name 填写test，comment（注释）中填写“测试计划”，点击“完成” 4．当问你是否创建database ，点“否”。（也可以点击“是”，按照下面建立的数据库方式进行） 5．当问你是否check out database ，点“否”。 6．Test计划建立完毕。 2．3建立数据库
2.2是计划建立的过程，但是此计划并没有数据库的支持，本小节就说明如何去建立数据库并和计划相连。 1．菜单中选择“Database->New Database”，打开新建 Database对话框。 2．Logical Database Name添写test (数据库名称1-4个字节长)，在Comment（备注）中填写“测试数据库”，点击“下一步”。 3．Vendor选择SQL_SERVER；Physical Database Name填写数据库名称test；Database Server Name填写数据库服务器名称或服务器IP地址；剩下的项目，填写test数据库所属用户名和密码，这里都是test。填写完毕后，选择“Production Database”，点击“下一步”。 4．把 Timeout（延迟）和Poll Interval（间隔）都设置为0. 点击“下一步”。 5．从计划列表中选择数据库需要连接的计划，这里是test计划，点击“完成”。 6．显示“Database was created successfully”。 7．询问是否check out，选择“否”。 数据库连接计划完毕。 2．4添加用户和组
在使用CQ的过程中，用户和组是很关键的两个因素。下面介绍如何去添加用户和组。 在CQ Designer中，从菜单中选择“Tools->User Administration”，出现User Administration界面。 在操作完毕后，必须点击右侧OK按钮进行保存，否则所有改动无效。 2．4．1添加组
在用户管理（User Administration）界面中，点击右侧按钮Group Action，在出现的菜单中选择Add Group，出现Add Group界面。
在name中填写需要建立的组名（建立“管理组”）；Active选择是否新建组当前可用；MembershipGroups中选择新建组的子组；MembershipUsers中选择新建组包含的用户；Subscribe中，选择新建组的数据库权限（选择“All existing and future databases”可以有任意数据库的权限，选择“Select databases”可以选择具有特定数据库的操作权限）。 如果需要添加新用户，点击下面的按钮“New User”（参照2.4.2）；如果需要添加别的组，点击“Apply”按钮保存现在的组并添加新的组；全部组添加完毕后，点击“OK”结束新组的添加。 在这里，除了管理组，还按照上面的方法建立“测试组”和“开发组”。 2．4．2添加用户
在用户管理（User Administration）界面中，点击右侧按钮User Action，在出现的菜单中选择Add User，出现Add User界面。
在Login中添入登陆用户名test1；按需要添入其他的内容（只有Login是必添项）； Groups中，选择用户属于哪个组（这里我们选择测试组）；Privileges中选择赋予此用户的权限，通常缺省权限就可以了；Subscribe中选择此用户具有哪些数据库的操作权限。 如果添加多个用户，点击Add User，如果全部用户填写完毕，点击OK。 按照上面的方法，新建测试组用户test2，开发组用户pg1、pg2，管理组用户manage1、manage2备用。 注意：一个用户可以属于多个组。 2．4．3其他功能
更新数据库：添加用户或组，以及修改了用户或组的数据库权限后，必须更新数据库。点击右侧按钮“DB Action”，在出现的菜单中选择Upgrade，出现Upgrade界面，选择需要升级的数据库，点击OK更新数据库。 用户和组的修改等功能，比较简单，都可以从右侧按钮中选择，就不介绍了。 2．5计划设计
打开计划：在Rational ClearQuest Designer界面中，选择菜单“File->Open Schema”，选择需要设定的计划test，点击“下一步”，在Comment中添加本次操作的注释（可以不填写），点击“完成”打开test计划。 我们现在所设计的计划是给缺陷（Defect）管理使用，所以计划中主要设定部分都在Record Types->Defect中，下面所说的各种配置，都在Defect中进行。
计划配置完成后，需要从菜单中选择File->Save Work保存计划，并且File->Check In。 计划修改后，必须从菜单中选择Database->Upgrade Database，出现的提示中选择“是”，在出现的数据库列表中，选中修改的计划所对应的数据库，点击“下一步”，出现的界面（如下图）中选择需要更新的版本，点击“完成”才算结束了计划的修改工作。
2．5．1字段（Fields）设置
点击左侧树中Defect下Fields，在右侧显示出字段表。
字段表中，灰颜色的部分是系统自动设置的不可修改字段；黑颜色的部分是可以修改的字段。 Type列后面的内容都是可以进行编程控制的。 字段表中部分英文对应的常用汉语解释： id：编号。系统自动给每个缺陷一个编号，规则是数据库名称＋8位数字，这个编号就是id。 State：状态。每个缺陷都有相应的状态，State字段记录缺陷相关的状态。状态详情查看2.6.1。 Headline：简述。简单描述缺陷的概要情况。 Description：详细描述。详细说明缺陷发生的位置、操作等情况。 Priority：优先级。表示修复缺陷的重要程度和应该何时修复。 Severity:严重性。表示软件缺陷的恶劣程度。 Submitter：提交人。缺陷是谁提交的，谁就是此缺陷的提交人。 Submit_Date：提交日期。错误提交的日期。 Owner：负责人。指应该处理此条缺陷的人。一般情况下，负责人都是开发组开发此相关模块的程序员。 Symptoms：错误分类。提交的缺陷记录分类。 Note_Entry：解决方案。关于缺陷处理的说明。 Notes_Log：验证结果。解决方案的集合。 Attachments：附件。缺陷的补充说明。习惯上，附件中是一些缺陷状态的抓图。 下面简单的说明一下新字段的添加和修改。 例如：新添加一个“可重现性”字段。 1．在字段表中，点击右键，出现的菜单中，选择Add Field，出现字段添加界面。
2．在Field Name中填写需要添加的字段名称“可重现性”；DB Colunmn Name中填写数据库字段名称kcxx；Type中选择SHORT_STRING类型；其他的缺省就可以了。填写完毕后，点击右上角的×关闭字段添加窗口，字段就建立成功了。 按照上面的方法，添加如下字段备用。
在字段列表中最后一列是Choice List（下拉框列表），此项十分常用。下面说明如何配置Choice List。
选择需要使用下拉列表功能的字段，这里我们选择“可重现性”，选中可重现性字段的Choice List，会出现一个↴，点击↴，出现一个菜单，从菜单中选择CONSRANR LIST，出现下图界面。输入下拉框选项“总能”、“经常”、“间隙”、“不能”、“不知道”。选择Limit To List（选择此条件，在使用下拉框的时候，只能录入下拉框列表内的内容，不允许输入其他的内容），点击OK，完成Chioce List的设置。
下表中说明了其他使用Choice List的字段。
附录：一些项目的解释。 严重性：表示软件缺陷的恶劣程度。致命错误一般指导致系统崩溃的错误；严重错误包括数据丢失、数据损坏、功能未实现等；一般错误包括操作性错误、所谓结果等；轻微错误包括错别字、UI布局等；建议是指软件中值得改良的地方。以上的说明只是建议，具体的分类测试人员可以自行把握判断。 优先级：表示修复缺陷的重要程度和应该何时修复。立即修复，说明此缺陷阻止进一步测试，需要立即修复，否则会导致测试的停滞；必须修复，说明此缺陷在产品发布前必须修复，否则会影响软件的发布和使用；应该修复，说明如果时间允许应该修复此缺陷；考虑修复，说明此缺陷即使不修复修复，但是也能发布。 |
