软件测试结果分析与评估测试评估过程的输入与活动课件.ppt

1、软件测试结果分析与评估软件测试结果分析与评估 测试评估过程的输入与活动测试评估过程的输入与活动 软件测试的评估方法软件测试的评估方法 测试日志测试日志 测试报告测试报告 集成集成Rational ClearQuest跟踪缺陷和变更跟踪缺陷和变更请求请求 测试评估活动的目的是统计和分析测试结果，确定是否达到软件发布的标准。具体内容包括以下几方面：确定实际测试执行的有效性。测试执行是否完全？执行失败是否因为不符合前置条件？分析测试输出以确定结果。在执行测试过程中，查看测试结果报告中的数据来检验该执行是否是可接受的。查看统计后的结果以检查对测试计划、测试输入、配置等的覆盖程度。6.1 测试评估过程的

2、输入与活动测试评估过程的输入与活动6.2 软件测试的评估方法软件测试的评估方法6.2.1 覆盖评测覆盖评测 最常用的覆盖度量是基于需求的测试覆盖和基于代码的测试覆盖。测试覆盖是对需求（基于需求的）或代码的设计/实施标准（基于代码的）全面的评测，如测试用例的核实（基于需求的）或所有代码行的执行（基于代码的）。覆盖策略陈述测试的一般目的，指导测试用例的设计。1基于需求的测试覆盖基于需求的测试覆盖 基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识，如已计划的（p）、已实施的（i）、已执行的（x）和成功的（s）测试覆盖。测试覆盖通过以下公式计算：测试覆盖=T(

3、p,i,x,s)/RfT 在制定测试计划活动中，将计算测试覆盖以决定已计划的测试覆盖，其计算方法如下：测试覆盖（已计划的）=Tp/RfT 在实施测试活动中，由于测试过程正在实施中（按照测试脚本），在计算测试覆盖时使用以下公式：测试覆盖（已实施的）=Ti/RfT 在执行测试活动中，使用两个测试覆盖评测，一个确定通过执行测试获得的测试覆盖，另一个确定成功的测试覆盖（即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）。这些覆盖评测通过以下公式计算：测试覆盖（已执行的）=Tx/RfT2基于代码的测试覆盖基于代码的测试覆盖 基于代码的测试覆盖用于评测测试过程中已经执行的代码的多少，与之相对的是要

4、执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已作定义。基于代码的测试覆盖通过以下公式计算：测试覆盖=Ie/TIic 如将该比率转换为百分数，则可以通过以下的方式来描述基于代码的测试覆盖：x%的测试用例（上述公式中的I）已经覆盖，成功率为y%6.2.2 质量评测质量评测 测试覆盖的度量评价了测试的完备性，而对测试过程中发现缺陷的评估提供了软件质量指标。缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数

5、值上的分布。缺陷分析提供了一个软件可靠性指标。对于缺陷分析，常用的主要缺陷参数有4个：u状态：缺陷的当前状态（打开的、正在修复或关闭的等）。u优先级：必须处理和解决缺陷的相对重要性。u严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。u起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。6.2.3 性能评测性能评测 评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。这些评测主要在评估测试活动中进行评估，但是也可以在执行测试活动中使用性能评测评估测试进度和状态。主要的性能评测包括：u 动态监测在

6、测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。u 响应时间/吞吐量测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。u 百分位报告数据已收集值的百分位评测/计算。u 比较报告代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。u 追踪报告主角（测试脚本）和测试对象之间的消息/会话详细信息。6.3 测试日志测试日志 回顾测试评估过程的输入与活动的介绍，我们可以看到测试日志是测试评估过程的一项重要的输入制品。使用TestLog窗口可以：打开测试日志查看测试结果。过滤测试日志的数据以查看满足过滤条件的信息。对测试用例进行分类，复查和更新所有未评估的测试用例。提交日志中失败的

7、事件所对应的缺陷。测试日志自动填写build、配置以及Rational ClearQuest缺陷表中的测试脚本信息。利用测试脚本开发工具打开基于脚本的日志事件的测试脚本。预览和打印Test Log窗口的活动测试日志数据。结合其他测试脚本生成工具，使用比较器（Comparator）分析结果。1 Test Log窗口介绍窗口介绍2 在在TestManager中打开测试日志中打开测试日志 选择“File”*“Open Test Log”。在测试资产工作区的“Results”标签中展开Build 树，选择一个日志，双击即可打开该日志。3 查看测试日志结果查看测试日志结果 在执行一个测试用例、测试脚本或

8、套件之后，可以在Test Log窗口中快速评估测试结果。查看测试用例结果查看测试用例结果1）按照不同的标准对测试用例进行分类2)根据不同的标准显示测试用例3)显示一个测试用例的事件细节 查看一组测试套件的测试日志查看一组测试套件的测试日志 测试套件的测试日志记录了一组套件执行的所有信息。该日志包含了build、日志文件夹、日志名称信息、套件验证的信息、测试脚本以及任何与该测试套件有关的警告和错误。要想查看一个测试套件的日志，可以右键点击TestLog窗口中一组测试套件的开始事件，然后选择“View Suite Log”。在一个打开的测试套间日志中，选择“File”-“Print”可以打印该测试

9、套件的日志。查看事件细节查看事件细节 每个事件的详细信息可以从Test Log窗口的“Details”标签中获得。在Details标签中，可以：收缩或展开事件列表。找出一个特殊的结果、事件类型、协议、失败原因、验证点或命令，或者寻找一个特定事件属性的名称和值。4 查看一个测试脚本查看一个测试脚本 可以在相应的创建测试脚本的工具中查看与日志事件关联的测试脚本。要查看一个测试脚本，首先打开一个测试日志，选择“Details”标签，右键点击一个测试脚本的开始或者结束事件，在菜单中选择“Open Script”。5 测试日志的其他操作测试日志的其他操作 在Test Asset Workspace（测试

10、资产工作区）中选择“Results”标签，右键点击一个测试日志，在弹出的菜单中可以选择重命名一个测试日志、查看一个测试日志的属性（名称、描述、build、和日志文件夹）。可以创建一个日志过滤器来减少在Test Log 活动窗口中显示的数据量。例如，可以创建一个过滤器只显示验证点或测试机启动。选择“File”“Print”可以打印在活动测试日志中显示的信息，以分析测试结果。如果要在打印出的报告中获得更多的细节，点击“Event Type”栏中的（）号，展开详细的信息。如果要减少细节数量，点击Event Type栏中的（）号，收缩信息。6.4 测试报告测试报告 TestManager 提供了灵活的

11、报告工具以方便用户创建各种类型的和格式的报告。同时TestManager还提供了许多预定义的报告，用户可以便利地使用这些定制好的报告分析性能和测试用例的结果。TestManager 提供了3 种类型的测试报告：测试用例报告（Test Case Reports）跟踪计划实施的过程以及测试用例的执行。列表报告（Listing Reports）显示了保存在一个Rational项目中的测试资产。性能测试报告（Performance Testing Reports）分析在指定条件下的某个服务器的性能。1 测试用例报告测试用例报告 测试用例报告跟踪测试计划的实施过程以及测试用例的执行。报告有多种表示格式，

12、包括柱状（bar）图、面积（area）图、折线（line）图、饼（pie）图以及树状（tree）图。测试用例报告又分为3种子类型：测试用例分布（Test Case Distribution）报告测试用例结果分布（Test Case Results）报告测试用例趋向（Test Case Trend）报告 测试用例分布报告包括了测试计划覆盖率报告和测试开发覆盖率报告，这两个测试覆盖率报告跟踪测试计划过程、测试开发以及测试执行的工作。测试计划覆盖率（Test Planning Coverage）显示测试计划中的测试输入的百分率和计划的测试用例的数量。测试开发覆盖率（Test Input Develo

13、pment Coverage）显示输入测试用例的数量、实现（手工或已有自动化测试脚本）的测试用例以及测试用例实现的百分比。测试用例结果分布报告测试用例结果分布报告 测试结果分布报告在一个项目的执行阶段使用。这些报告提供有关执行一个测试脚本、测试用例或者测试套件的关键信息。通过结果信息，可以评估一个指定的build 的质量以及这个build的测试过程。测试用例结果分布报告包括测试执行覆盖率（Test Plan Execution Coverage）报告，测试执行覆盖率报告显示计划的测试用例数、已执行的测试用例数和百分比、通过的测试用例数以及失败的测试用例数。测试用例趋向报告测试用例趋向报告 测试

14、用例趋向报告提供的信息包括测试的数量，已经计划的、开发的、执行的测试用例的数量，或者是在一段时期内符合测试标准的测试用例的数量，伴随通过builds、迭代或者日期的间隔描述和指定。下面的测试用例趋向报告展现了遍及所有迭代的计划的和实施的测试用例的数目。过滤测试输入的来源数据过滤测试输入的来源数据 有两种方法可以在测试用例分布报告或者测试用例结果分布报告中过滤测试输入的来源数据：在执行一个报告之前过滤可以过滤掉不必要的数据信息，以便缩小显示在测试用例报告中的数据数量。在执行了一个报告之后过滤执行一个报告之后，如果依然存在不必要的信息和数据，那么可以过滤掉这些不必要的数据信息。2 列表报告列表报告

15、 列表报告显示了保存在一个Rational项目中的不同测试资产。TestManager提供了针对builds、测试机、测试机列表、配置、迭代、sessions、测试套件、测试日志、测试计划、测试脚本以及用户的列表报告。设计布局定义每个报告的外观和包含在一个列表报告中的说明信息。每个列表报告可以使用一种或多种设计布局的组合。可以定制设计布局或者使用Crystal Reports创建新的设计布局（要定制已存在的设计布局或创建一个新的设计布局，必须安装Crystal Reports专业版，具体的有关使用Crystal Reports来创建或定制已存在的设计布局的信息，请参阅Crystal Repor

16、ts帮助）。3 性能测试报告性能测试报告 性能测试报告帮助分析在指定条件下一个服务器的性能。例如，可以决定一个虚拟测试者多长时间执行一个命令，以及不同的测试套件执行的响应时间的变化。性能测试报告包括：性能（Performance）报告 比较性能（Compare Performance）报告 响应时间（Response vs.Time）报告 命令状态（Command Status）报告 命令使用（Command Usage）报告4 选择要使用的报告选择要使用的报告目的目的使用的报告使用的报告利用指定的属性分类测试用例（例如，可以查看在每个迭代中测试用例得数目或在一个指定的测试用例组已创建的测试用

17、例的数目）测试用例分布报告确定符合测试准则的测试用例的数目测试用例结果分布确定某些builds、迭代或日期中计划的、已实施的或已执行的测试用例的百分比；查看某些builds、迭代或日期中已测试的、未测试的、符合测试准则或不符合的测试准则输入的测试用例的百分比测试用例趋向报告显示项目中的buildsBuild 列表显示项目中的测试机测试机列表显示项目中的测试机列表测试机表的列表显示项目中的配置配置列表显示项目中的迭代迭代列表显示项目中的会话会话列表显示项目中的测试套件测试套件列表显示项目中的测试日志 测试日志列表测试日志列表显示项目中的测试计划测试计划列表显示项目中的测试脚本测试脚本列表显示项目

18、中的用户用户列表显示响应时间和估计一个测试套件中针对每条命令的平均差和标准差以及百分位性能报告比较由多个性能报告估量的响应时间比较性能报告显示单独的响应时间以及一个响应是否已经通过或者失败响应时间报告获得命令通过或者失败的摘要命令状态报告查看累计响应时间和摘要统计，以及针对所有测试脚本的仿真命令和将一个测试套件作为整体执行的吞吐量信息命令使用报告5 创建报告创建报告 要创建一个报告，选择“Reports”-“New”，选择想要创建的报告类型。创建测试用例分布报告创建测试用例分布报告 创建测试用例分布报告时，可以选择结果的展现格式，例如，柱状图、折线图、饼图或者树状图，如下图所示。创建一个测试用

19、例结果分布报告创建一个测试用例结果分布报告 创建一个测试用例结果分布报告时，选择报告中希望显示的测试用例结果类型，例如，Passed、Failed、Warning等创建一个测试用例趋向报告创建一个测试用例趋向报告 创建一个测试用例趋向报告时，选择有关测试用例和测试输入的数据信息，例如，选择趋向报告是针对builds、迭代或者日期 创建一个列表报告创建一个列表报告 创建列表报告时，需要确定如何通过一个Crystal Reports设计布局来显示需要的信息，如下图所示。可以创建或者定制现有的Crystal Reports设计布局。创建性能测试报告创建性能测试报告 创建性能测试报告时，可以说明执行报

20、告的日志数据和如何操作这些日志数据以便能得到需要的信息。6 打开报告打开报告 创建和保存一个报告之后，可以打开它，如果需要，还可以修改报告。可以通过以下两种方法打开或者修改一个报告：选择“Reports”“Open”，从列表中选择一个报告，并点击“OK”按钮。在测试资产工作区的“Analysis”标签中，选择要打开的报告类型，然后选择要打开或者修改的报告。7 打印、导出报告打印、导出报告 执行一个测试用例报告之后，可以打印、保存或者将它复制到剪贴板中。执行一个列表报告之后，可以打印该报告，或者将它导出到指定的文件格式中，并将其保存在测试机上。TestManager 支持的导出的文件格式有电子表

21、格、文字处理格式、HTML、ODBC以及普通的数据交换格式，这就使得信息的发布更加容易。6.5 集成集成Rational ClearQuest跟踪缺陷和变更请求跟踪缺陷和变更请求 变更请求是指在软件开发生命周期内产生的所有需要改动项目相关内容的请求，如：缺陷、功能增强、需求变更等，它是推动项目向前发展的源动力，同时也是项目重要的过程资产。6.5.1 从从TestManager的测试日志中提交缺陷的测试日志中提交缺陷 利用TestManager可以直接从测试日志向ClearQuest 提交缺陷，TestManager会将测试日志中缺陷信息自动地填充到ClearQuest 缺陷表（TestStud

22、io 缺陷表）的一些区域。可以通过以下两种方式从TestManager中提交或者修改一个缺陷：在测试日志的Detail面板中，展开失败的测试用例，找到失败的验证点，点击右键，在菜单中选择“Submit Defect”，如下图所示。选择“Edit”*“Submit Defect”。6.5.2 Rational ClearQuest配置配置 Rational ClearQuest（以下简称CQ）是国内目前比较常用的一款缺陷管理工具，它的功能强大，灵活，可实现流程自定义、查询自定义、功能域自定义、用户权限分级管理等功能，并可以集成Crystal Report 实现更加灵活的报表自定义功能。当我们使用

23、CQ进行缺陷的跟踪和管理时，所有的信息都是被存放在后台的数据库中的，而我们通过CQ提供的操作界面来对数据库中的数据进行操作。CQ可以支持Oracle、MS Access、MS SQL Server、IBM DB2、Sybase SQLAnywhere 等常见的DBMS.1.新增新增Master 数据库数据库 Master 数据库是CQ 的主数据库，用来存放各种预先定义的流程模板、功能域模板等数据。在新建数据库时一定要使用SQL Server 的用户，而不是windows 用户登录。但是不要使用SQL Server 默认的SA 用户，因为使用该用户会对将来进行数据迁移造成影响，可以在SQL Se

24、rver 中新增一个用户，并使用这个新建用户重新连接到SQL SERVER 来进行这项操作。新增数据库后，我们还需要为CQ 添加一个新的数据库登录用户 在登录用户属性的“数据库访问”页面中，选定刚刚新建的数据库，并赋予public 和db_owner 的角色权限 2.新建新建Schema Repository 打开ClearQuest Maintenance Tool 工具，选择“Schema Repository”菜单下的“Create”项，新建一个Schema，然后在“Vendor”下拉列表中选择“SQL SERVER”项。并填写物理数据库名、数据库服务器名、管理用户和读写用户名，然后点击

25、“下一步”按钮。配置完数据库后点击下一步，如下图所示。然后取消掉“Create sample database”项，点击“完成”按钮。3.修改修改CQ 管理员密码管理员密码 打开“ClearQuest Designer”，使用默认管理用户登录（用户名为admin，密码为空），不必理会弹出的提示信息（等会我们会处理它），在弹出的Schema 选择列表中点击“取消”按钮。然后选择ClearQuest Designer 工具栏中的“User Administrator”按钮，然后在用户列表中选择“admin”用户，并修改admin 用户的密码（比如我们在这里改为“tester”），在填写“Passw

26、ord”和“Confirm Password”项后点击“OK”按钮退出当前界面。接着点击“User Administrator”界面的“OK”按钮退出时，系统会提示是否要保存刚刚修改的信息，点击“是”退出“User Administrator”界面，并退出ClearQuest Designer 工具。4.配置配置code page installutil setdbcodepagetoplatformcodepage-dbset CQSchema admin tester 其中“installutil setdbcodepagetoplatformcodepage-dbset”是命令和参数，“

27、CQSchema”是我们在ClearQuest Maintenance Tool 中建立的Schema 的名字，而“admin”和“tester”分别是CQ Schema 的管理员用户名和密码。5.添加添加Production Database 和和Test Database Production Database 和Test Database 是使用CQ 是必须建立的另外两个数据库，Production Database 和Test Database 同Master 数据库分别保存了同CQ 有关的不同的信息。对于Master 数据库，它保存了CQ 预设的一些方案（Schema），包括预设的处

28、理流程、用户界面、数据库字段等信息；而在Production Database 和Test Database 中保存的是某个具体的Schema 进行个性化配置后的信息 建立CQ 同这两个数据库的关联 然后继续“下一步”。我们需要把Producation Database 同Master 中存储的多个Schema 中的某一个进行关联，并进行调整。6.用户管理用户管理 7.定制缺陷管理流程定制缺陷管理流程 虽然我们选择的Schema 中也提供了预设的缺陷管理流程，但是在实际工作中，这个流程常常不能完全符合我们的工作要求，所以我们会使用CQ Designer 来重新定制或调整已有的流程。在Submi

29、tted 之后，可以转到退回测试部状态，或者在Assigned 之后，也可以转到退回测试部状态。保存一下这些变化，我们还需要添加一个新的操作来完成这些状态之间的关联。那我们继续进入Action 的维护界面 8.使用使用Test Database 对变动进行调试对变动进行调试 我们完成了缺陷管理流程的调整或变更了Action 的权限之后，如何来验证这些变化的有效性呢？首先，我们要设置一个用来试验的数据库，选择Database 菜单下的Set Test Database 菜单项，在弹出的Test Database 窗口中，选择一个Test Database，然后选择登录该数据库所使用的用户，在用户

30、选择后，密码会自动填入。选择OK 完成设置之后，点击CQ Designer 工具栏中的Validate 按钮 然后点击工具栏中的Test Work 按钮，提交一个缺陷实际操作一下，看看是不是和你预想的一样。9.内容定制内容定制 CQ 的提供的内容定制包括两方面内容，一是对数据库结构的调整，二是对用户界面的调整。首先，我们进入CQ Designer 的“Fields”项，如下图所示，在界面的右侧所列出的就是当前数据库中已经预设的一些字段。我们现在需要新增一个叫DefectSource（缺陷来源）的字段。然后，我们需要在DefectSource 字段中添加需要提供给用户选择的列表项。点击Defec

31、tSourse 字段最右侧的“Choice List”项的箭头按钮，选择“Constant List”项 对于用户界面的调整，需要对“Forms”项中的Defect_Base_Submit 和Defect_Base 进行操作。如果我们想进一步设置DefectSource 字段为必填项，在提交缺陷的时候必须确定这个缺陷的来源，那么就需要通过“Behaviors”进行设置了。我们双击左侧WorkSpace 中的中的“Behaviors”项后，在屏幕的右侧会出现一个矩阵，矩阵的上方是系统中现有的所有状态，而左侧则是系统中现有的所有字段，之间的内容是某个字段在不同的状态所应当遵守的规则。例如，对于我们

32、新增的DefectSource 字段，从提交缺陷开始，就必须要选择某项内容，在缺陷处理的整个过程中，这一项是不允许修改并且不允许为空的。所以，DefectSource 一个需要强制填写的项目，我们可以通过进行设置来添加这个规则。完成了上面的工作，保存并Validate 后，我们就可以使用前面所说的Test Work 功能来进行调试了。调试，如果确认变更没有问题，则可以将Test Database 中的数据同步到Producation Database 中，如下图所示。首先选择工具栏中的“Upgrade Database”工具，然后会弹出一个提示信息，告诉你这个操作是不可逆的，一定要想好。我们确

33、定之后就可以看到数据库列表了。6.5.3 Rational ClearQuest使用使用1 操作界面操作界面 ClearQuest 的操作界面分为三个部分：菜单栏与工具栏、导航窗体、主窗体。菜单栏与工具栏位于窗体的上部，在工具栏中，包含了很多命令，如：创建新的查询、图表、保存查询、执行报表等等。见下图：导航窗体位于窗体的左侧，通过双击导航窗体中的文件，打开相应的图表、报表和查询。具有管理公共文件夹权限的用户，右键单击文件，还可进行编辑等操作。2.BUG 的处理流程的处理流程1）.测试员或程序员发现BUG，点击工具栏的“New Defect”，填写BUG 信息，此时BUG 的状态系统设置为“Su

34、bmitted”，即为“已提交”状态。完成后点击“OK”按钮。2）.一个BUG 被发现并提交后，测试员或程序员需要将它指派（Assign）给相关的程序员查看。点击“Actions”中的“Assign”。3）.BUG 被指派后，程序员通过OutLook 收到邮件通知查看BUG。根据邮件信息，程序员有多种方法可以找到他负责的BUG，这里介绍两种方法：通过负责人查询和通过ID 查询。双击导航栏中“BUG 查询”文件夹中的“Owner Query”，在弹出的窗体中选择自己的用户名，点击“确定”ID 查询方法即双击导航栏中“BUG 查询”文件夹中的“ID Query”，在弹出窗体的“Criteria”中

35、输入BUG 的ID，选择“Operator”中的“Equal”,点击“确定”4）.经过一段时间的修改，测试员提出的BUG 被程序员已经处理。这时候，程序员需要修改BUG 的状态。点击“Actions”中的“Resolve”，填写解决方案，选择验证BUG 的测试员，点击“Apply”。5）.测试员负责结束BUG 的生命周期，点击“Resolution”选择Resolution。点击“Actions”中的“Validate”，填写相应信息，点击“Apply”。在一般情况下，BUG 的生命周期就此结束。6）.当测试员提交BUG 后，发现该BUG 与以往发现的BUG 重复，点击“Actions”中的“

36、Duplicate”，见下图，填入与之相重复的BUG 的ID 号，见下图，点击“Find”验证，若输入的ID 号不存在，会给予提示。最后“OK”确认。7).一个BUG 的终结状态有两种，“Duplicate”是其中一个。若要改变这一终结状态，点击“Actions”中的“Unduplicate”，见下图，即可回到“Submitted”状态。8).对于已经提交的BUG（状态为Assigned），程序员可能因为某种原因认为暂时无法解决，这种情况下，可点击“Actions”中的“Postpone”，将BUG搁置挂起。9).被挂起的BUG 有两种解决途径，其中一种就是由程序员本人再次打开该BUG，点击“

37、Actions”中的“Open”,“Apply”后，BUG 的状态转为“Opened”。10）.如果被挂起的BUG 始终无法解决，程序员修改负责人为测试员，由测试员来进行关闭。点击“Actions”中的“Close”即可。11）.程序员解决好BUG 后，等待测试员做最后的确认。如果测试员认为解决不合格，点击“Actions”中的“Reject”，将负责人该为程序员，此时BUG回到“Opened”状态。12）.对于已经关闭的BUG，如有特殊原因，可由测试员重新打开。点击“Actions”中的“Re_open”，将负责人该为程序员，点击“Apply”，BUG 的状态改为“Opened”。3.BUG

38、 的查询和统计的查询和统计 3.1.创建查询表创建查询表1.右击“Personal Queries”，选择“New Query”。在弹出的“Choose Record Type”窗体中选择“Defect”，点击OK。见下图：2.右击新建的查询表，选择“Edit”进行编辑。点击“下一步”后，选择要显示的字段，点击“下一步”。见下图：3.选择与查询条件有关的字段，点击“下一步”。4.若没有设置查询条件，即在“Select fields to use as query filters”窗体中没有选择字段，直接点击“Run”即可。若选择了一个字段来设置查询条件，（见下图），在设置查询条件时，可以直接对

39、字段进行赋值，也可以选择“Dynamic Filter”，在执行查询的时候再输入值。若选择了一个以上的字段，见下图，先确认各个字段的操作关系，再对每个字段设置查询条件。3.2.创建图表创建图表 ClearQuest 设置的图表形式有三种：Distribution Chart、Trend Chart、Aging Chart 这里以创建Distribution Chart 为例。1.右击“Personal Queries”，选择“New Chart”。在弹出的“Choose Record Type”窗体中选择“Defect”，点击OK。2.右击新建的图表，选择“Edit”进行编辑。在弹出的“Spe

40、cify Chart”窗体中选择图表的类型为Distribution Chart，点击“下一步”。3.在弹出的“Parameters”窗体中，选择水平轴表示的字段，即点击“Horizontal Axis”中“Field”的下拉框，假设选择“Submitter”，“Sort”选择升序“Ascending”，点击“下一步”。见下图：4.在弹出的“Labels”窗体中，填入图表的名称“Defects by Submitter”，点击“下一步”，见下图：5.在弹出的“Display Type”窗体中选择图表显示的类型，假设选择线形图“Line”，点击“下一步”，见下图：6.在弹出的“Style”窗体中，为图表选择样式，点击“完成”，见下图：7.按上述步骤，得到的图表见下图，点击图中的圆点，可以得到注释。例如该图表最上面的圆点表示yanling 提交的BUG 有21 个。