【文档说明】软件测试结果分析与评估测试评估过程的输入与活动课件.ppt，共(72)页，19.429 MB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-50487.html

以下为本文档部分文字说明：

软件测试结果分析与评估•测试评估过程的输入与活动•软件测试的评估方法•测试日志•测试报告•集成RationalClearQuest跟踪缺陷和变更请求•测试评估活动的目的是统计和分析测试结果，确定是否达到软件发布的标准。具体内容包括以下几方面：确定实际测试执行的有效性。测试执行是否完全？执行失

败是否因为不符合前置条件？分析测试输出以确定结果。在执行测试过程中，查看测试结果报告中的数据来检验该执行是否是可接受的。查看统计后的结果以检查对测试计划、测试输入、配置等的覆盖程度。6.1测试评估过程的输入与活动6.2软件测试的评估方法6.2.1覆盖评测•

最常用的覆盖度量是基于需求的测试覆盖和基于代码的测试覆盖。测试覆盖是对需求（基于需求的）或代码的设计/实施标准（基于代码的）全面的评测，如测试用例的核实（基于需求的）或所有代码行的执行（基于代码的）。覆盖策略陈述测试的一般目的，指导测试用例的设计。1．基于需求的测试覆盖•基于需求的测试覆盖

在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识，如已计划的（p）、已实施的（i）、已执行的（x）和成功的（s）测试覆盖。•测试覆盖通过以下公式计算：测试覆盖=T(p,i,x,s)/RfT•在制定测试计划活动中，将计算测试覆盖以决定已计划的测试覆盖，其计算方法如下：

测试覆盖（已计划的）=Tp/RfT•在实施测试活动中，由于测试过程正在实施中（按照测试脚本），在计算测试覆盖时使用以下公式：测试覆盖（已实施的）=Ti/RfT•在执行测试活动中，使用两个测试覆盖评测，一个确定通过执行测试获得的测试覆盖，另一个确定成功的测试覆盖（

即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）。这些覆盖评测通过以下公式计算：测试覆盖（已执行的）=Tx/RfT2．基于代码的测试覆盖•基于代码的测试覆盖用于评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在

控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已作定义。•基于代码的测试覆

盖通过以下公式计算：测试覆盖=Ie/TIic•如将该比率转换为百分数，则可以通过以下的方式来描述基于代码的测试覆盖：x%的测试用例（上述公式中的I）已经覆盖，成功率为y%6.2.2质量评测•测试覆盖的度量评价了测试的完备

性，而对测试过程中发现缺陷的评估提供了软件质量指标。•缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标。•对于缺陷分析，常用的主要缺陷参数有4个：状态：缺陷的当前状态（打开的、正在修复或关闭的等）。优先级：必

须处理和解决缺陷的相对重要性。严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。6.2.3性能评测•评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作

可靠性和限制。这些评测主要在评估测试活动中进行评估，但是也可以在执行测试活动中使用性能评测评估测试进度和状态。•主要的性能评测包括：动态监测——在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。响应时间/吞吐量——测试对象针对特定主角和/或用例的响应时间或吞

吐量的评测。百分位报告——数据已收集值的百分位评测/计算。比较报告——代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。追踪报告——主角（测试脚本）和测试对象之间的消息/会话详细信息。6.3

测试日志•回顾测试评估过程的输入与活动的介绍，我们可以看到测试日志是测试评估过程的一项重要的输入制品。使用TestLog窗口可以：打开测试日志查看测试结果。过滤测试日志的数据以查看满足过滤条件的信息。对测试

用例进行分类，复查和更新所有未评估的测试用例。提交日志中失败的事件所对应的缺陷。测试日志自动填写build、配置以及RationalClearQuest缺陷表中的测试脚本信息。利用测试脚本开发工具打开基于脚本的日志事件的测试脚本。预览和打印TestLog窗口的活动测试日志数据

。结合其他测试脚本生成工具，使用比较器（Comparator）分析结果。1．TestLog窗口介绍2．在TestManager中打开测试日志•选择“File”*“OpenTestLog”。•在测试资产工作区的“Results”标签中展

开Build树，选择一个日志，双击即可打开该日志。3．查看测试日志结果在执行一个测试用例、测试脚本或套件之后，可以在TestLog窗口中快速评估测试结果。•查看测试用例结果1）．按照不同的标准对测试用例进行分类2)．根据不同的标准显示测试用例3)

．显示一个测试用例的事件细节•查看一组测试套件的测试日志测试套件的测试日志记录了一组套件执行的所有信息。该日志包含了build、日志文件夹、日志名称信息、套件验证的信息、测试脚本以及任何与该测试套件有关的警告和错误。

要想查看一个测试套件的日志，可以右键点击TestLog窗口中一组测试套件的开始事件，然后选择“ViewSuiteLog”。在一个打开的测试套间日志中，选择“File”->“Print”可以打印该测试套件的日志。•查看事件细节每个事件的详

细信息可以从TestLog窗口的“Details”标签中获得。在Details标签中，可以：收缩或展开事件列表。找出一个特殊的结果、事件类型、协议、失败原因、验证点或命令，或者寻找一个特定事件属性的

名称和值。4．查看一个测试脚本可以在相应的创建测试脚本的工具中查看与日志事件关联的测试脚本。要查看一个测试脚本，首先打开一个测试日志，选择“Details”标签，右键点击一个测试脚本的开始或者结束事件，在菜单中选择“OpenScript”。5．测试日志的其他操作•在TestAssetWorksp

ace（测试资产工作区）中选择“Results”标签，右键点击一个测试日志，在弹出的菜单中可以选择重命名一个测试日志、查看一个测试日志的属性（名称、描述、build、和日志文件夹）。•可以创建一个日志过滤器来减少在TestLog活动窗口中显示的数据量。例如

，可以创建一个过滤器只显示验证点或测试机启动。•选择“File”－>“Print”可以打印在活动测试日志中显示的信息，以分析测试结果。如果要在打印出的报告中获得更多的细节，点击“EventType”栏中的（＋）号，展开详细的信息。如果要减少细节数量，点击EventType栏中的

（－）号，收缩信息。6.4测试报告TestManager提供了灵活的报告工具以方便用户创建各种类型的和格式的报告。同时TestManager还提供了许多预定义的报告，用户可以便利地使用这些定制好的报告分析性能和测试用例的结果。T

estManager提供了3种类型的测试报告：•测试用例报告（TestCaseReports）——跟踪计划实施的过程以及测试用例的执行。•列表报告（ListingReports）——显示了保存在一个Rat

ional项目中的测试资产。•性能测试报告（PerformanceTestingReports）——分析在指定条件下的某个服务器的性能。1．测试用例报告•测试用例报告跟踪测试计划的实施过程以及测试用例的执行。报告有多种表示格式，包括柱状（bar）图、面积（area）图、折线（line）图

、饼（pie）图以及树状（tree）图。•测试用例报告又分为3种子类型：测试用例分布（TestCaseDistribution）报告测试用例结果分布（TestCaseResults）报告测试用例趋向（TestCaseTr

end）报告•测试用例分布报告包括了测试计划覆盖率报告和测试开发覆盖率报告，这两个测试覆盖率报告跟踪测试计划过程、测试开发以及测试执行的工作。测试计划覆盖率（TestPlanningCoverage）——显示测试计划中的测试输入的百分率和计划的测试用例的数量。测试开发

覆盖率（TestInputDevelopmentCoverage）——显示输入测试用例的数量、实现（手工或已有自动化测试脚本）的测试用例以及测试用例实现的百分比。测试用例结果分布报告•测试结果分布报告在一个项目的执行阶段使用。

这些报告提供有关执行一个测试脚本、测试用例或者测试套件的关键信息。通过结果信息，可以评估一个指定的build的质量以及这个build的测试过程。•测试用例结果分布报告包括测试执行覆盖率（TestPlanExecutionCoverage）报告，测试执行覆盖率报告

显示计划的测试用例数、已执行的测试用例数和百分比、通过的测试用例数以及失败的测试用例数。测试用例趋向报告•测试用例趋向报告提供的信息包括测试的数量，已经计划的、开发的、执行的测试用例的数量，或者是在一段时期内符合测试标准的测试用例的数量，伴随通过builds、迭代或者日期的间隔描

述和指定。•下面的测试用例趋向报告展现了遍及所有迭代的计划的和实施的测试用例的数目。过滤测试输入的来源数据•有两种方法可以在测试用例分布报告或者测试用例结果分布报告中过滤测试输入的来源数据：在执行一个报告之前过滤——可以过滤掉不必要的数据信息，以便缩

小显示在测试用例报告中的数据数量。在执行了一个报告之后过滤——执行一个报告之后，如果依然存在不必要的信息和数据，那么可以过滤掉这些不必要的数据信息。2．列表报告•列表报告显示了保存在一个Rational项目中的不同测试资产。TestManager提供了针对buil

ds、测试机、测试机列表、配置、迭代、sessions、测试套件、测试日志、测试计划、测试脚本以及用户的列表报告。•设计布局定义每个报告的外观和包含在一个列表报告中的说明信息。每个列表报告可以使用一种或多

种设计布局的组合。可以定制设计布局或者使用CrystalReports创建新的设计布局（要定制已存在的设计布局或创建一个新的设计布局，必须安装CrystalReports专业版，具体的有关使用CrystalReports来创建或定制已存在的设计布局的信息，请参阅CrystalReports帮助）

。3．性能测试报告•性能测试报告帮助分析在指定条件下一个服务器的性能。例如，可以决定一个虚拟测试者多长时间执行一个命令，以及不同的测试套件执行的响应时间的变化。•性能测试报告包括：•性能（Performance）报告

•比较性能（ComparePerformance）报告•响应时间（Responsevs.Time）报告•命令状态（CommandStatus）报告•命令使用（CommandUsage）报告4．选择要使用的报告目的使用的报告利用指定的

属性分类测试用例（例如，可以查看在每个迭代中测试用例得数目或在一个指定的测试用例组已创建的测试用例的数目）测试用例分布报告确定符合测试准则的测试用例的数目测试用例结果分布确定某些builds、迭代或日期中计划的、已实施的或已执行的测试用例的

百分比；查看某些builds、迭代或日期中已测试的、未测试的、符合测试准则或不符合的测试准则输入的测试用例的百分比测试用例趋向报告显示项目中的buildsBuild列表显示项目中的测试机测试机列表显示项目中的测试机列表测试机表的列表显示项目中的

配置配置列表显示项目中的迭代迭代列表显示项目中的会话会话列表显示项目中的测试套件测试套件列表显示项目中的测试日志测试日志列表测试日志列表显示项目中的测试计划测试计划列表显示项目中的测试脚本测试脚本列表显示项目中的用户用户列表显示响应时间和估计一个测试套件中针对每条命令的平均

差和标准差以及百分位性能报告比较由多个性能报告估量的响应时间比较性能报告显示单独的响应时间以及一个响应是否已经通过或者失败响应时间报告获得命令通过或者失败的摘要命令状态报告查看累计响应时间和摘要统计，以及针对所有测试脚本的仿真命令和将一个测试套件作为整体

执行的吞吐量信息命令使用报告5．创建报告要创建一个报告，选择“Reports”->“New”，选择想要创建的报告类型。•创建测试用例分布报告创建测试用例分布报告时，可以选择结果的展现格式，例如，柱状图、折线图、饼图

或者树状图，如下图所示。•创建一个测试用例结果分布报告创建一个测试用例结果分布报告时，选择报告中希望显示的测试用例结果类型，例如，Passed、Failed、Warning等•创建一个测试用例趋向报告创建一个测试用例趋向报告时，选择有关测试用例和测试输入的数据信息，例如，选择趋向报

告是针对builds、迭代或者日期•创建一个列表报告创建列表报告时，需要确定如何通过一个CrystalReports设计布局来显示需要的信息，如下图所示。可以创建或者定制现有的CrystalReports设计布局。•创

建性能测试报告创建性能测试报告时，可以说明执行报告的日志数据和如何操作这些日志数据以便能得到需要的信息。6．打开报告•创建和保存一个报告之后，可以打开它，如果需要，还可以修改报告。可以通过以下两种方法打开或者修改一个报告：选择“Reports”－

>“Open”，从列表中选择一个报告，并点击“OK”按钮。在测试资产工作区的“Analysis”标签中，选择要打开的报告类型，然后选择要打开或者修改的报告。7．打印、导出报告•执行一个测试用例报告之后，可以打印、保存或者将它复制到剪贴板中。•执行一个列表报告之后，可以打印该报告，或者将

它导出到指定的文件格式中，并将其保存在测试机上。TestManager支持的导出的文件格式有电子表格、文字处理格式、HTML、ODBC以及普通的数据交换格式，这就使得信息的发布更加容易。6.5集成RationalClearQuest跟踪缺陷和变更请求变更请求是指在软件开发生命周期内产生的所有需要

改动项目相关内容的请求，如：缺陷、功能增强、需求变更等，它是推动项目向前发展的源动力，同时也是项目重要的过程资产。6.5.1从TestManager的测试日志中提交缺陷•利用TestManager可以直接从测试

日志向ClearQuest提交缺陷，TestManager会将测试日志中缺陷信息自动地填充到ClearQuest缺陷表（TestStudio缺陷表）的一些区域。•可以通过以下两种方式从TestManager中提交或者修改一个

缺陷：在测试日志的Detail面板中，展开失败的测试用例，找到失败的验证点，点击右键，在菜单中选择“SubmitDefect”，如下图所示。选择“Edit”*“SubmitDefect”。6.5.2RationalClearQuest配置•RationalClearQuest

（以下简称CQ）是国内目前比较常用的一款缺陷管理工具，它的功能强大，灵活，可实现流程自定义、查询自定义、功能域自定义、用户权限分级管理等功能，并可以集成CrystalReport实现更加灵活的报表自定义功能。•当

我们使用CQ进行缺陷的跟踪和管理时，所有的信息都是被存放在后台的数据库中的，而我们通过CQ提供的操作界面来对数据库中的数据进行操作。CQ可以支持Oracle、MSAccess、MSSQLServer、IBMDB2、SybaseSQLAnywhere等常见的

DBMS.1.新增Master数据库•Master数据库是CQ的主数据库，用来存放各种预先定义的流程模板、功能域模板等数据。•在新建数据库时一定要使用SQLServer的用户，而不是windows用户登录。但是不要使用SQLServer默认

的SA用户，因为使用该用户会对将来进行数据迁移造成影响，可以在SQLServer中新增一个用户，并使用这个新建用户重新连接到SQLSERVER来进行这项操作。新增数据库后，我们还需要为CQ添加一个新的数据库登录用户•在登录用户属性的“数据库访问”页面

中，选定刚刚新建的数据库，并赋予public和db_owner的角色权限2.新建SchemaRepository•打开ClearQuestMaintenanceTool工具，选择“SchemaRepo

sitory”菜单下的“Create”项，新建一个Schema，然后在“Vendor”下拉列表中选择“SQLSERVER”项。并填写物理数据库名、数据库服务器名、管理用户和读写用户名，然后点击“下一步”

按钮。•配置完数据库后点击下一步，如下图所示。然后取消掉“Createsampledatabase”项，点击“完成”按钮。3.修改CQ管理员密码•打开“ClearQuestDesigner”，使用默认管理用户登录（用户名为admin，密码为空），不必理会弹

出的提示信息（等会我们会处理它），在弹出的Schema选择列表中点击“取消”按钮。然后选择ClearQuestDesigner工具栏中的“UserAdministrator”按钮，然后在用户列表中选择“admin”用户，并修改admin用户的密码（比如我们在这里

改为“tester”），在填写“Password”和“ConfirmPassword”项后点击“OK”按钮退出当前界面。接着点击“UserAdministrator”界面的“OK”按钮退出时，系统会提示是否要保存刚刚修改的信息，点击“是”退

出“UserAdministrator”界面，并退出ClearQuestDesigner工具。4.配置codepage•installutilsetdbcodepagetoplatformcodepage-dbsetCQSchemaadmintester•其中“installu

tilsetdbcodepagetoplatformcodepage-dbset”是命令和参数，“CQSchema”是我们在ClearQuestMaintenanceTool中建立的Schema的名字，而“admin”和“

tester”分别是CQSchema的管理员用户名和密码。5.添加ProductionDatabase和TestDatabase•ProductionDatabase和TestDatabase是使用CQ是必须建立的另外两个数据库，•Productio

nDatabase和TestDatabase同Master数据库分别保存了同CQ有关的不同的信息。对于Master数据库，它保存了CQ预设的一些方案（Schema），包括预设的处理流程、用户界面、数据库字

段等信息；而在ProductionDatabase和TestDatabase中保存的是某个具体的Schema进行个性化配置后的信息•建立CQ同这两个数据库的关联然后继续“下一步”。我们需要把ProducationDatabase同

Master中存储的多个Schema中的某一个进行关联，并进行调整。6.用户管理7.定制缺陷管理流程•虽然我们选择的Schema中也提供了预设的缺陷管理流程，但是在实际工作中，这个流程常常不能完全符合我们的工作要求，所以我们会使用CQDesigner来

重新定制或调整已有的流程。•在Submitted之后，可以转到退回测试部状态，或者在Assigned之后，也可以转到退回测试部状态。保存一下这些变化，我们还需要添加一个新的操作来完成这些状态之间的关联。那我们继续进入Action的维护界面8.使用TestData

base对变动进行调试•我们完成了缺陷管理流程的调整或变更了Action的权限之后，如何来验证这些变化的有效性呢？•首先，我们要设置一个用来试验的数据库，•选择Database菜单下的SetTestDatabase菜单项，在弹出的TestDatabase窗口中，选择一个TestDataba

se，然后选择登录该数据库所使用的用户，在用户选择后，密码会自动填入。选择OK完成设置之后，点击CQDesigner工具栏中的Validate按钮然后点击工具栏中的TestWork按钮，提交一个缺陷实际操作一下，看看是不是和你预

想的一样。9.内容定制•CQ的提供的内容定制包括两方面内容，一是对数据库结构的调整，二是对用户界面的调整。•首先，我们进入CQDesigner的“Fields”项，如下图所示，在界面的右侧所列出的就是当前数据库中

已经预设的一些字段。•我们现在需要新增一个叫DefectSource（缺陷来源）的字段。•然后，我们需要在DefectSource字段中添加需要提供给用户选择的列表项。点击DefectSourse字段最右侧的“ChoiceList”项的箭头按钮，选择“ConstantList”项•对于用

户界面的调整，需要对“Forms”项中的Defect_Base_Submit和Defect_Base进行操作。•如果我们想进一步设置DefectSource字段为必填项，在提交缺陷的时候必须确定这个缺

陷的来源，那么就需要通过“Behaviors”进行设置了。•我们双击左侧WorkSpace中的中的“Behaviors”项后，在屏幕的右侧会出现一个矩阵，矩阵的上方是系统中现有的所有状态，而左侧则是系统中现有的所有字段，之间的内容是某个字段在不同的状态所应当遵守

的规则。例如，对于我们新增的DefectSource字段，从提交缺陷开始，就必须要选择某项内容，在缺陷处理的整个过程中，这一项是不允许修改并且不允许为空的。所以，DefectSource一个需要强制填写的项目，我们可以通过进行设置来添加这个规则。•完成了上面的工作，保存并Validate后，我们就

可以使用前面所说的TestWork功能来进行调试了。•调试，如果确认变更没有问题，则可以将TestDatabase中的数据同步到ProducationDatabase中，如下图所示。•首先选择工具栏中的“Upgrade

Database”工具，然后会弹出一个提示信息，告诉你这个操作是不可逆的，一定要想好。我们确定之后就可以看到数据库列表了。6.5.3RationalClearQuest使用1．操作界面•ClearQuest的操作界面分为三个部分：菜单栏与工

具栏、导航窗体、主窗体。菜单栏与工具栏位于窗体的上部，在工具栏中，包含了很多命令，如：创建新的查询、图表、保存查询、执行报表等等。见下图：•导航窗体位于窗体的左侧，通过双击导航窗体中的文件，打开相应的图表、报表和查询

。具有管理公共文件夹权限的用户，右键单击文件，还可进行编辑等操作。2.BUG的处理流程1）.测试员或程序员发现BUG，点击工具栏的“NewDefect”，填写BUG信息，此时BUG的状态系统设置为“Submitted

”，即为“已提交”状态。完成后点击“OK”按钮。2）.一个BUG被发现并提交后，测试员或程序员需要将它指派（Assign）给相关的程序员查看。点击“Actions”中的“Assign”。3）.BUG被指派后，程序员通过OutLook收到邮件通知查看BUG。根据邮件信息，程序员有多种方法可以找到

他负责的BUG，这里介绍两种方法：通过负责人查询和通过ID查询。双击导航栏中“BUG查询”文件夹中的“OwnerQuery”，在弹出的窗体中选择自己的用户名，点击“确定”•ID查询方法即双击导航栏中“BUG查询”文件夹中的“IDQuery”，在弹出窗体的“Criteria”

中输入BUG的ID，选择“Operator”中的“Equal”,点击“确定”4）.经过一段时间的修改，测试员提出的BUG被程序员已经处理。这时候，程序员需要修改BUG的状态。点击“Actions”中的“Resolve”，填写解决方案，选择验证BUG的测试员，点击“

Apply”。5）.测试员负责结束BUG的生命周期，点击“Resolution”选择Resolution。点击“Actions”中的“Validate”，填写相应信息，点击“Apply”。在一般情况下，BUG的生命周期就此结

束。6）.当测试员提交BUG后，发现该BUG与以往发现的BUG重复，点击“Actions”中的“Duplicate”，见下图，填入与之相重复的BUG的ID号，见下图，点击“Find”验证，若输入的ID号不存在，会给予提示。最后

“OK”确认。7).一个BUG的终结状态有两种，“Duplicate”是其中一个。若要改变这一终结状态，点击“Actions”中的“Unduplicate”，见下图，即可回到“Submitted”状态。8).对于已经提交的BUG（状态为Assigned）

，程序员可能因为某种原因认为暂时无法解决，这种情况下，可点击“Actions”中的“Postpone”，将BUG搁置挂起。9).被挂起的BUG有两种解决途径，其中一种就是由程序员本人再次打开该BUG，点击“Actions”中的“Open”,“Apply”后，BUG的状态转为“Opened”。1

0）.如果被挂起的BUG始终无法解决，程序员修改负责人为测试员，由测试员来进行关闭。点击“Actions”中的“Close”即可。11）.程序员解决好BUG后，等待测试员做最后的确认。如果测试员认为解决不合格，点击“Actions”中的“Reject”，将负责人该为程序员，此时BUG回到“O

pened”状态。12）.对于已经关闭的BUG，如有特殊原因，可由测试员重新打开。点击“Actions”中的“Re_open”，将负责人该为程序员，点击“Apply”，BUG的状态改为“Opened”。3.BUG的查询和统计3.1.创建查询

表1.右击“PersonalQueries”，选择“NewQuery”。在弹出的“ChooseRecordType”窗体中选择“Defect”，点击OK。见下图：•2.右击新建的查询表，选择“Edit”进行编辑。点击

“下一步”后，选择要显示的字段，点击“下一步”。见下图：3.选择与查询条件有关的字段，点击“下一步”。4.若没有设置查询条件，即在“Selectfieldstouseasqueryfilters”窗体中没有选择字段，直接点击“Run”即可。若选择了一个字段来设置查询条

件，（见下图），在设置查询条件时，可以直接对字段进行赋值，也可以选择“DynamicFilter”，在执行查询的时候再输入值。若选择了一个以上的字段，见下图，先确认各个字段的操作关系，再对每个字段设置查询条件。3.2.

创建图表•ClearQuest设置的图表形式有三种：DistributionChart、TrendChart、AgingChart•这里以创建DistributionChart为例。1.右击“PersonalQueries”，选择“NewChart”。在弹出的“ChooseRecordType”

窗体中选择“Defect”，点击OK。2.右击新建的图表，选择“Edit”进行编辑。在弹出的“SpecifyChart”窗体中选择图表的类型为DistributionChart，点击“下一步”。3.在弹出的“Paramete

rs”窗体中，选择水平轴表示的字段，即点击“HorizontalAxis”中“Field”的下拉框，假设选择“Submitter”，“Sort”选择升序“Ascending”，点击“下一步”。见下图：4.在弹出的“Labels”窗体中，填入图表的名称“Defects

bySubmitter”，点击“下一步”，见下图：5.在弹出的“DisplayType”窗体中选择图表显示的类型，假设选择线形图“Line”，点击“下一步”，见下图：6.在弹出的“Style”窗体中，为图表选择样式，点击“完

成”，见下图：7.按上述步骤，得到的图表见下图，点击图中的圆点，可以得到注释。例如该图表最上面的圆点表示yanling提交的BUG有21个。