按照上面的1－5步完成后，重新启动Web服务器。完成CQ Web服务器的配置。（这里并不是非要重新启动服务器，重新启动IIS也可以有同样的效果。）
现在打开IE，输入http://机器名/虚拟目录名，这里是http://test/cqweb就会出现下面的页面了。
注意：CQ Web端最合适的显示窗口大小是1024×768，在800×600的时候，最上面的标题栏会显示不完整。
界面中，Schema Repository可以选择我们使用的维护库；Database选择CQ的数据库；RefreshDBList按钮在出问题的时候，可以刷新数据库列表；Login按钮是登陆。
使用的过程中，为了方便，我对Web端进行了大量的汉化工作。界面的处理主要是WWW根目录下的文件和login目录下的文件，了解一点Html语法的都可以自己修改，就不多介绍了。
使用Web端的过程中，可以使用E-mail通知，具体配置参照InstallationGuideClearQuest.pdf第96页的说明。
CQ Web端，可以使用高级查询编辑。其实就是Java环境的查询编辑。使用Java环境，能比单纯的html方式更方便好用。
进入Web端，选择数据库进入。选择工具栏中的“Operations->Advanced Query Editor”，如果是第一次使用，会让你安装Java运行环境（JRE），安装完毕以后就可以使用Advanced Query Editor功能了。里面和CQ客户端很相像。
Advanced Query Editor很难安装上，好像只有服务器机器才比较容易安装。我配置了很多的机器，只有两台服务器安装成功了。
7．IE设置
Web端使用是基于浏览器的，IE或者Netscape都可以。但是缺省的浏览器权限可能在使用过程中不够，就需要在浏览器端进行相应的设置。Netscape用的人应该很少，我这里也没有Netscape浏览器，所以下面只介绍IE的设置。
1． 打开IE。
2． 选择菜单中“工具->internet选项”，出现internet选项窗口。
3． 在“安全”页中，选择“本地intranet”，点击“自定义级别”，出现“安全设置”窗口。
4． 我用的是IE6.0，和InstallationGuideClearQuest.pdf第98页中设置的有些不一样，而且我现在的机器是已经设置好的了，没有一个初始的IE可以配置。不过我记得，这里设置或不设置差别不是很大。如果在使用过程中出现问题，不能允许部分功能，在不理会安全性的情况下，不妨把所有的东西都启用。
5．在“高级”页中，把“总是以UTF-8发送URL”选项清除。在通过Web端提交缺陷的时候，如果使用了中文名称的附件，选择使用UTF-8发送URL的时候，就无法打开此附件。把此选项清除，使用中文名称的附件就不会有问题了。（在IE5中可能相反，需要把此项选中。总之记住，在无法打开中文名称附件的时候，把此选项选成相反的就可以了。）
6．此条可设可不设。如果在使用过程中，如果总是出现刷新问题（总是出现同样的页面，必须不停的点击刷新），可以把IE缓存设小些。选择“常规”页，点击Internet临时文件的“设置”按钮，出现设置页面。设置页面中，选择“每次访问此页时检查”，使用的磁盘空间设置为最小值1MB，就不会出现不刷新的问题了。
7．全部设置完成后，在Internet选项页，点击“确定”保存设置。
五、Rational ClearQuest客户端配置
配置完毕后，还必须有提交缺陷的地方，ClearQuest客户端，就是提交缺陷的程序，所有ClearQuest的配置，实际都是为了这里的使用。这一章和第四章没有任何的关系，即使没有Web端设置，客户端一样可以使用。
从开始菜单中选择Rational ClearQuest（安装目录中clearquest.exe），打开CQ客户端。
首先选择连接的维护库，这里我们选择“测试连接数据库”。
在登陆界面，我们选择使用admin登陆，数据库选择test。
在CQ操作界面中，左侧是工作台（工作台可以建立查询、报表、图表等内容），右侧是显示区（显示查询、图表）。带红框的就是提交缺陷的按钮。点击“New Defect”就可以提交缺陷了。
1．提交缺陷
点击“New Defect”按钮，出现提交Defect界面。其中ID自动给出；由于是提交错误，所以状态（State）是等待处理；其他的都是需要填写的，其中红颜色标记的是必须填写的项目（在第三章2.6.3 Behavior中各相关字段中设置）。
全部填写完毕后，点击OK就完成了缺陷的提交。
1．1 属性项目说明
ID：自动分配给记录的一个标识。
状态：显示当前记录的状态。（具体的状态说明，参照第三章2.6.1相关说明）
简述：对错误的概要描述。最好不要过长。
模块：错误发生的位置。模块内容在测试之前就建立完毕。如果需要添加修改模块，请寻找相关的测试人员。
严重性：表示软件缺陷的恶劣程度。致命错误一般指导致系统崩溃的错误；严重错误包括数据丢失、数据损坏、功能未实现等；一般错误包括操作性错误、所谓结果等；轻微错误包括错别字、UI布局等；建议是指软件中值得改良的地方。以上的说明只是建议，具体的分类测试人员可以自行把握判断。
优先级：表示修复缺陷的重要程度和应该何时修复。立即修复，说明此缺陷阻止进一步测试，需要立即修复，否则会导致测试的停滞；必须修复，说明此缺陷在产品发布前必须修复，否则会影响软件的发布和使用；应该修复，说明如果时间允许应该修复此缺陷；考虑修复，说明此缺陷即使不修复修复，但是也能发布。在软件测试的过程中，严重性和优先级可能会有变化，由缺陷记录的提交人自行掌握。
负责人：指应该处理此条缺陷的人。一般情况下，负责人都是开发组开发此相关模块的程序员。负责人可以修改相应模块缺陷记录的状态，
错误分类：提交的缺陷记录分类。点击右下角的 ，会出现列表，里面有一些可选项：可以多选，也可以自己填写，点击“Add”就添加上了。填写完毕后，点击“ok”按钮保存错误分类。
详细描述：详细说明错误发生的位置和操作状态。这里一定要说清楚，否则程序员很难明白错误是怎么发生的。如果有相关的附件，这里也最好可以说明一下。
1．2 附件属性说明
习惯上，附件中是一些缺陷状态的抓图。因为有的时候，缺陷使用语言表达不清楚，这时有一个错误发生时的状态抓图看着就很清楚了。
抓图方法为：点击键盘“PrintScreenSysRq”按键，点击开始菜单->程序->附件->画图，在画图中，点击键盘Ctrl+V，屏幕抓图就显示在画图中了。可以在画图中进行一些简单的处理：比如把发生错误的地方用画笔圈起来，或者加上一些中文注释等，看个人的喜好和发挥了。图形处理完毕后，保存到本地目录。建议保存格式为jpg或gif，不要轻易保存为bmp格式的图片，bmp格式图片太大，很容易给服务器造成不必要的负担。
点击附件中的“Add”按钮，出现附件上传窗口，选择本地保存的附件文件，点击“打开”按钮，出现添加注释的界面（注释可以不填写），点击“OK”附件上传完毕。
如果有其他的文件需要上传，参照上面的步骤进行。
1．3 高级属性说明
一些可以选择的内容。比如测试人员所使用的操作系统；此问题是否可以重复出现；错误的提交时间和日期；软件的版本号等。
高级属性中如果开发人员还需要其他的项目内容，可以找测试人员添加。
2．修改记录
在ClearQuest的变更流程中，有三类用户：
第一类是管理组成员，主要指测试小组的领导或开发部门项目经理，管理组成员主要进行决策判断活动。
第二类是测试组成员，指具体的测试人员，测试缺陷记录主要由测试组成员提交。
第三类是开发组成员，主要是开发部门负责修改测试记录的程序员。
在测试缺陷记录提交后，这三类用户有不同的操作权限。
在各类人员处理缺陷记录的过程中，都应该填写解决方案。
要修改记录，首先要进入缺陷记录查看里面的详细内容（点击查询表中待修改记录），再从右面的Actions下拉按钮中选择需要修改的状态，按照下面各类组成员的操作步骤处理完毕后，点击“Apply”保存修改。下面的图片是开发组成员处理缺陷时的状态抓图，测试组成员和管理组成员Actiosn的状态和下图有差别。
（图3.8）
2．1 测试组成员对测试记录的操作权限
测试组成员对自己的测试记录有修改权限。如果经过开发组成员把相关缺陷记录修改处理后，测试组成员可以确定缺陷记录是关闭，再次出现或者是提交管理员。
测试组成员遇到“已修改”状态的记录，重新进行验证。如果错误已经被修改，Action状态选择“关闭”，如果此错误没有被处理，Action状态选择“再次出现”
测试组成员遇到“暂不修改”状态的记录，Action状态选择“提交管理者”转给管理组成员判断处理。
测试组成员遇到“无法再现”状态的记录，重新进行验证。如果错误不再发生，Action状态选择“关闭”；如果错误仍然存在，把错误内容写详细些，Action状态选择“再次出现”。
测试组成员遇到“间接修复”状态的记录，重新进行验证。如果错误不再发生，Action状态选择“关闭”；如果错误仍然存在，Action状态选择“再次出现”。
测试组成员遇到“使用错误”状态的记录。如果不是错误，Action状态选择“关闭”；如果认为是错误，重新进行说明，Action状态选择“再次出现”。
测试组成员遇到“系统限制”状态的记录，Action状态选择“提交管理者”转给管理组成员判断处理。
2．2 开发组成员对测试记录的操作权限
开发组成员对测试记录有处理权限。包括：已修改、暂不修改、无法再现、间接修复、使用错误、系统限制权限。
状态说明：
已修改：错误修改完毕后，开发组成员把状态设置为已修改。
暂不修改：错误由于某种原因暂时不处理。
无法再现：测试人员提交的错误无法在开发人员那里重现。
间接修复：在修改其他地方的时候把此缺陷记录修复，或者新版本自动修复了此问题缺陷。
使用错误：测试人员由于操作等原因理解误会了某些地方。开发人员可以用使用错误来处理这些不是问题的记录。
系统限制：确实是问题，但是由于开发工具的限制等原因暂时无法处理错误，开发人员可以标记为系统限制。
2．3 管理组成员对测试记录的操作权限
管理组成员对测试记录有决定判断的权限。
只有管理组成员才可以删除记录。
对于状态为“等待分配”的记录，管理员可以进行判断：如果不是问题，就关闭；如果是问题，就再次出现此记录。
文章来源于领测软件测试网 https://www.ltesting.net/
