IBM Rational ClearQuest说明.doc

IBM Rational ClearQuest 使用说明 2005.4目 录 一、 缺陷管理过程 1 （一） 软件工程与缺陷管理 1 1、 缺陷跟踪管理的目标 1 2、 缺陷的描述 1 3、 缺陷管理的角色与流程 3 4、 缺陷跟踪管理系统 4 （二） ClearQuest的缺陷管理 4 二、 ClearQuest安装与配置 5 （一） 安装 5 1、 服务器端： 5 2、 客户端： 5 3、 Web端： 6 （二） 数据库生成、连接与维护 6 1、 数据库 6 2、 生成计划库 7 3、 中文与代码页设置 10 4、 生成缺陷数据库 10 （三） Web配置 10 三、 ClearQuest使用 11 （一） 基本概念 11 1、 计划：Schema 11 2、 计划库：Schema Repository 11 3、 字段：Fields 11 4、 状态、动作与行为： 12 5、 表单：Forms 12 （二） 管理与设计 12 1、 生成计划 13 2、 生成缺陷数据库 22 3、 用户管理 23 （三） 客户端使用 25 1、 项目/模块管理 26 2、 缺陷管理 27 3、 统计图表 34 缺陷管理过程 软件工程与缺陷管理 软件测试是软件工程中一个重要的过程，而缺陷跟踪管理是测试工作的一个重要部分，测试的目的是为了尽早发现软件系统中的缺陷，因此，对缺陷进行跟踪管理，确保每个被发现的缺陷都能够及时得到处理是测试工作的一项重要内容。 缺陷跟踪管理的目标 缺陷会引起软件运行时产生的一种不希望或不可接受的外部行为结果，软件缺陷常被称为“Bug”，但这里我们主要以ClearQuest中的提法“Defect”来表达这一概念。软件测试过程简单说就是围绕缺陷进行的，对缺陷的跟踪管理一般而言需要达到以下目标： 确保每个被发现的缺陷都能够被解决 缺陷的解决可能有以下几种情况： 一是缺陷被修正，二是保留到未来的某一版本修正，三是决定暂时不修正。无论哪一种情况，都应该保证对每个被发现缺陷的处理方式必须能够在开发组织中达到一致； 收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段 决定测试过程是否结束有很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式； 收集缺陷数据并在其上进行数据分析，作为组织的过程财富 在一个运行良好的开发组织中，缺陷数据的收集和分析是很重要的，因为从缺陷数据中可以得到很多与软件质量相关的数据，从而使得组织的软件开发过程不断得到优化。 对每一个软件开发人员来说，上述的第一条是最容易受到重视的一点，而对第二和第三条目标却很容易忽视。因此，好的缺陷管理应该保证每个缺陷的状态都能得到正确的跟踪与处理、并能对历史数据进行分析和加工，从而得到对软件开发过程优化有益的信息。 缺陷的描述 要及时准确地对缺陷进行管理，首先应对缺陷作出正确的描述。对缺陷的描述应该包含以下的内容： 可追踪缺陷标识： 要对缺陷进行跟踪管理，必须通过对每个缺陷赋予一个ID来进行标识。这个ID号必须是惟一的。 缺陷基本信息 在缺陷被发现到处理的完整生命周期里，要对其进行跟踪与管理，除了要对缺陷进行标识外还需要对缺陷特征进行详细的记录。要对历史缺陷进行统计分析，也需要记录需要统计的缺陷详细数据。缺陷的基本信息可以考虑主要包括以下部分： 缺陷状态：缺陷状态是对缺陷进行跟踪管理的最主要的信息，可分为“待分配”、“待修正”、“待验证”、“待评审”、“关闭”等； 缺陷标题：描述缺陷的标题； 缺陷的严重程度：描述缺陷的严重程度，可分为“致命”、“严重”、“一般”、“建议”四种； 缺陷的紧急程度：描述缺陷的紧急程度，说明缺陷是否需要立即解决，可进行分级； 缺陷提交人：缺陷提交人的名字（邮件地址）； 缺陷提交时间：缺陷提交的时间； 缺陷所属项目/模块：缺陷所属的项目和模块，最好能较精确的定位至模块； 缺陷负责人：缺陷指定的解决人，在缺陷“提交”状态为空，在缺陷“分发”状态下由项目经理指定相关开发人员修改； 缺陷指定解决时间：项目经理指定的开发人员修改此缺陷的deadline 缺陷处理人：最终处理缺陷的处理人； 缺陷处理结果描述：对处理结果的描述，如果对代码进行了修改，要求在此处体现出修改； 缺陷处理时间：缺陷处理的时间； 缺陷验证人：对被处理缺陷验证的验证人； 缺陷验证结果描述：对验证结果的描述（通过、不通过） 缺陷验证时间：对缺陷验证的时间。 以上信息的生成是在测试过程的不同阶段生成的，同时信息的修改也分别属于不同的软件工程角色，因此在缺陷跟踪管理中应该引入权限机制。 缺陷的详细描述及测试环境说明 缺陷的详细描述是缺陷提交人对缺陷的详细描述，以便开发人员能对缺陷情况有正确的了解。缺陷的详细描述的详细程度与描述的准确性直接影响开发人员对缺陷的