复用RQM标准报告对测试过程进行综合管理和跟踪汇报

技术狂人

复用 IBM Rational Quality Manager 标准报告对测试过程进行综合管理和跟踪汇报
3 p* \; U* @% Y4 l8 rIBM Rational Quality Manager 是一个支持多方协作的商业需求驱动的软件质量管理平台。Rational Quality Manager 功能覆盖面十分广阔，囊括了从测试计划，测试元素构造，测试资源管理，测试用例设计到测试执行和测试报告整个软件开发生命周期。
3 l. Z) S5 x  v. T4 _; wRational Quality Manager 为用户提供了很多 out-of-the-box 的标准报告，可以让用户无须从零开始创建报告而是方便地复用已有的报告。这些报告从多个角度涵盖测试的方方面面的需求。通过实时跟踪并分析这些报告，不仅能够使用户全方位地查看测试进度和状态，还能让其及时发现测试进度中的瓶颈和不足以尽快做出调整。可以说，如果能够很好的利用 Rational Quality Manager 的报告，测试过程中的一切尽在掌控之中。

! N1 z+ d/ W! }' a本文主要介绍了应用 Rational Quality Manager 复用标准报告创建随需应变的测试报告的方法。

---

+ b& O6 L+ q/ r1 G; j5 n( bRational Quality Manager 标准报告简介
& K1 M: X, ^$ p" YRational Quality Manager 提供了几组 out-of-the-box 的标准报告可供用户在整个测试生命周期中的任何时候跟踪测试进度和检验测试结果。
通过查看分析这些报告，您可以
% E3 G& e" H- k) E. v' O

• 跟踪和评估测试的执行情况；
• 通过对测试元素如测试计划，测试用例，测试环境，配置等进行匹配，检验测试完整性和覆盖率；
• 比较某些测试元素的期望值和真实值，并据此做出调整。
  5 L2 y( i( @4 ~# o+ I

Rational Quality Manager 报告基本组成和复用方法
7 p+ C  y0 W) V1 IRational Quality Manager 中每张报告都有以下两大部分组成：

• 报告参数
• 报告结果集
  1 U/ A5 a* a' d2 A

每个报告都都有一个参数区段，里面列出了这张报告所需要的所有参数。参数区段如图 1 所示。
. N* ]# \: V7 i8 S& y/ O9 D) p% S' P
6 b9 H% l7 m, `+ }" |- X图 1. RQM 报告参数区段
" d1 \5 m" }% q. b6 c! A

* X" W# v* o* e8 Q! O; w/ _9 H在图 1 中，我们可以看到这里列出了 2 个参数：Machine 和 test milestone。这两种参数的可选值是在测试计划阶段预先定义的。对于这些参数值，您可以

• 不进行选择，RQM 将把满足这个参数所有值的结果查询出来；
• 选中一到多个参数值的复选框，RQM 将把和您所选参数值相匹配的结果查询出来；
• 如果您要选择其中绝大部分的值时，您还可以先点击 Select All 按钮，然后去掉不需要的选项；
• 您也可以点击 Deselect All 按钮去掉所有的选中情况。
  

当前后两个参数有关联关系时——如测试计划和测试里程碑——RQM 也可以根据您的选择动态显示参数值列表。例如当您选择某一测试计划后，测试里程碑的参数列表会自动刷新为和所选测试计划相对应的值，而不再选中测试计划里的测试里程碑值将会被过滤掉。
. z# B+ ]& [+ A, g) K& M; S1 c此外，在您选择每一参数值后，当前参数列表右上角的已选个数（0 of 3 selected）就会自动更新。当您完成报告的所有参数值的选择后，您通过页面右上角的 save 和 save as 两个按钮选择保存或者另存这个报告。
通过以上的步骤，您已经完成复用 Rational Quality Manager 标准报告创建您所需要报告的步骤了。下面要做的就是查看报告结果集。点击报告参数区段右上角的 Run 按钮，参数区段会收缩为仅显示您所选的参数值，如图 2 所示，而在参数区段下方就会显示基于已选参数生成的报告结果集。

图 2. 运行报告后 RQM 报告参数区段
, ?0 F% R9 \* R+ ]0 O0 ~' d/ n8 k
$ @8 e" `- y: g! }: _" o
Rational Quality Manager 报告结果集有以下两种形式：
8 Y; {# M4 I0 N+ O& V' x8 W

• 列表
• 图表，包括条形图，饼图，折线图，区域图等。
  0 P& w" w* u; e$ Y* |# b

由于很多报告都是交互型的，某些情况下一张报告不足以显示所有的信息，RQM 提供了一种很便捷的方式可以使您能在报告中向下钻取（drill down）从而获得更加详细的信息。
通常，您在得到一张报告后，可以通过直接点击链接，条形图或者饼图来打开包含更多详细信息的报告。在 RQM 报告中，所有鼠标移至能够变成手型的对象都是可以钻取详细信息的。


9 f( w: o9 Y  k$ F6 q$ x+ xRational Quality Manager 报告分类
Rational Quality Manager 中的报告分为以下九类：

• 缺陷类：缺陷报告主要是根据缺陷所处的状态实时的显示缺陷的数量。如展示某测试计划的某个测试里程碑中处于打开状态的缺陷的个数。
• 执行类：执行类的报告主要基于测试用例个数或者权重报告测试记录的执行状况。这些报告对象包含了测试计划，测试用例所有者，测试调度，类别，缺陷和测试环境等。执行类报告还包括 S-curve 图，它可以直观地比较实际测试进度和期望进度。
• 实验室管理类：此类报告主要报告实验室资源的使用情况。例如，您可以查看实验室资源的预定信息，实验室资源申请的平均响应时间，每种实验室资源的利用和闲置率，这些都有助于实验室管理员更好地调配和利用实验室资源。
• 我的报告：这个报告夹主要用于存贮您复用的报告。我的报告中的所有内容都是只对您个人可见。只有将它们放在共享报告夹中，它们才对团队的其他成员可见。
• 需求类：需求类报告主要用来检验基于需求的测试覆盖率。另外也可以查看基于不同需求的测试执行状况。
• 积分卡：积分卡报告可以为您展示测试用例状态、测试执行数和结果点数以及缺陷数的概述。
• 综述类：此类报告主要报告基于不同测试人员的测试执行状况。如每个测试人员所执行的测试用例数，权重总数，未完成的任务列表等，这些信息对于测试人员是非常有价值的。
• 系统类：系统类报告主要显示手工测试的进度和情况。
• 测试用例类：测试用例类报告可以根据您的不同需要从不同角度展示测试用例的详细信息。您可以根据用例，团队，配置项等条件过滤出您想要的报告。测试用例审查报告还可以让您并行地查看用例，需求任务项和合用力相关的其他任务。.
  - ]+ o/ K/ M+ n3 b0 Q- v" k" K

- F$ h# i" V$ K8 t+ O. d5 n
Rational Quality Manager 报告特性
) D3 h6 T7 u* b1 i0 @Rational Quality Manager 中的报告具有以下几种特性：
数据来源多种多样：RQM 可以收集跨任务和跨流程的不同数据，包括存贮在不同数据源，不同位置，各种格式的数据。这个特性就决定了 Rational Quality Manager 报告具有强大的数据收集能力和高覆盖度。您仅需要通过一种应用——Rational Quality Manager 报告就可以分析和访问到分散在各个不同数据源，各种类型的项目数据了。
保证更加有效地多方协作：Rational Quality Manager 的标准报告强化了以往测试管理中比较薄弱的环节——资源的管理和配置。您可以通过查看报告结果和对报告的分析来确保最佳的资源配置，使人员，硬件和虚拟资源能有效的调配执行。
多角度的视图：Rational Quality Manager 标准报告提供了基于不同角色和关联关系的报告。这些报告都是通过对软件工程和测试过程的研究，基于能够最准确地最全面地反映软件测试过程的各个视角精心提炼出来的。
易于复用：Rational Quality Manager 标准报告简单清晰，易于复用。它能够使用户从测试的角度，随需应变的报告测试情况。
% e7 L2 Y7 e1 {# V6 u6 ]

---

* w" w% ^3 y: P; i" s/ W9 b
2 x4 L- D/ n% X1 p
$ r; M$ v7 C) H; t) W- g9 ^0 a测试计划和设计阶段使用 RQM 报告进行需求和用例管理
IBM Rational Quality Manager 提供了很多标准报告支持对测试计划，需求和测试用例的跟踪，并通过交互式的报告直观地反映出测试计划和需求、需求和测试用例的覆盖率。下面就向您着重介绍 Rational Quality Manager 中几种在测试计划和设计阶段中用于需求和测试用例管理以及需求覆盖率检验的报告。

Requirements Traceability
Requirement Traceability 是查看需求覆盖率功能中应用较频繁的报告。此报告能够根据您选择的参数， 显示与需求关联的测试计划或测试用例，以便用户查看覆盖状态。参数选择界面如图 3 所示。以显示与需求关联的测试计划或测试用例。您可以通过单击报告中的名称打开测试计划或测试用例。

图 3. Requirement Traceability 参数界面

5 g* }  ^: s0 H- Y6 g+ ]2 b8 [
$ f6 T1 @% c. A  s如果您选择 show test case，那么报告会显示与需求关联的测试用例列表，一个例子如图 4 所示；而选择 show test plan，那么报告会显示与需求关联测试计划列表。
, r/ y" j+ a! P2 p7 r  O. B! j# O5 m
7 e: Y( U) J8 u图 4. Requirement Traceability 报告实例


在图 4 中，报告左边是所有的需求列表，右边相对应地显示了与之关联的测试用例列表。如果该需求存在关联用例，RQM 会显示 cover 标识；反之，会显示 no cover。在这个报告中，您就可以迅速找出哪些需求还没有测试用例被覆盖到。另外，您也可以查看哪些需求对应的用例数是不是符合项目的要求。您还可以通过单击报告中的名称打开测试计划或测试用例，也就是前面提到的 drill down 功能。在图 4 中，点击右侧列表的测试用例，就可以直接查看测试用例的详细内容。总之，Requirement Traceability 报告的操作和定制十分简单，实用价值却很高。
Plan Requirements Coverage by Test Case
+ J6 k- T3 T5 x如果您需要获取需求已覆盖率和未覆盖的比例信息，Plan Requirements Coverage by Test Case 是您最好的帮手。此报告获取有关您的计划需求的测试覆盖率信息。报告结果会显示为一个分为两部分的饼图：已覆盖和未覆盖，如图 5 所示。
  @/ a5 w- d& _
图 5. Plan Requirements Coverage by Test Case 报告实例

& Y8 p9 S! D$ X. F2 j  z9 L, J
0 A2 u; e1 W, [9 U1 a在图 5 Plan Requirements Coverage by Test Case 报告实例中，饼图的两部分分别代表了您的计划中已覆盖和未覆盖的需求个数。单击饼图的任一部分可以获取有关需求的详细信息。

Plan Requirements Coverage Detail
Plan Requirements Coverage Detail 报告适合查看您的计划中已覆盖的需求以及关联用例的详细信息。它和 Requirement Traceability 报告的区别在于：前者仅列出您选定的计划中已覆盖的需求信息；后者会列出所有需求及其覆盖情况。一个 Plan Requirements Coverage Detail 报告的实例如图 6 所示。

; y5 _7 N9 d: k3 c图 6. 缺陷分布图参数界面 - 选择记录类型


在图 6 中共有四列，分别是您的测试计划，需求编号，需求和测试用例。同样地，单击测试计划和测试用例都可以链接到相关的内容页面。
. A# i$ [+ V( m% ^与之类似的是 Plan Requirements Not Coverage Detail 报告，顾名思义，此报告用于查看您的计划中未覆盖的需求。
! {$ k4 y6 D: y. g3 q. m

Test Case Review
, a1 Q" @* Y& {, ]: o3 l此报告主要用来查看各种测试用例的详细信息。测试用例的审查者可以通过这个报告便捷地进行测试用例的审阅。Test case Review 报告会显示三个图表，第一个显示测试用例详细信息，第二个显示需求工作项，最后一个按测试用例显示其他工作项。测试用例信息报告如图 7 所示，报告有三列分别显示测试计划，测试用例和测试用例状态。通过这张报告，不用角色可以关注不同状态的测试用例。
; B0 G. V) ^7 a' V& i
图 7. Test Case Review 报告的实例 - 测试用例报告


' o& `0 v* Z! `: ~3 A  Y$ V- k3 P需求工作项报告（如图 8）显示出和需求相关的工作项条目，以便您查看这些任务的负责人，任务状态。在 RQM 中，您可以随时随地创建一些任务项来记录您或者其他团队成员需要完成的工作。这些任务项可以和需求或测试用例等关联起来。
/ O1 M7 m& F5 `# [# D! k
. `- E$ m" c5 Y; A3 _% {0 v图 8. Test Case Review 报告的实例 - 需求工作项报告

# X% [: l% N1 u- _: f
+ A. O4 u  B+ H' [8 G通过按测试用例显示的其他工作项报告（如图 9），您可以查看自己的和测试用例相关任务的执行情况。

1 ~- F( P, u. W) {  s图 9. Test Case Review 报告的实例 - 其他工作项报告

1 z: y' g8 ]3 E. {7 y6 g
3 X5 q) }3 m+ j

---

使用 Rational Quality Manager 报告跟踪测试执行进度
RQM 对于测试执行过程中的进度跟踪方面也提供了很多标准报告供用户复用。在测试执行阶段，RQM 报告的报告对象主要是测试执行记录（Test Execution Record）。测试执行记录有权重（Weight），状态（Status），执行者（Owner），关联的缺陷（Defect）等属性。本章选取了几种常用的报告，这些报告涉及到了以上提到的几种属性。
  E" P; t# ]. _) n$ M, ?1 H: @/ a
- c4 Y. t3 ~+ t, z) p# t基于两种属性的测试执行记录报告
* C4 N: m* N$ b5 e( ?在测试过程中跟踪进度最常用的就是根据测试执行记录的状态如通过（Passed），失败（Failed），阻塞（Blocked），未得出结论（Inconclusive）等来显示测试的进度。RQM 有两种报告能使您花费最少的定制工作来满足需求。
Execution Status using TER Count
此报告能够显示您的测试计划中，不同执行状态下的测试执行记录数。此报告有以下几项参数：

• Test Plan
• Test Milestone
• Test Case
• Machine
• Owner
• TER State
• Test plan category type
• Test plan category name
  

虽然报告有很多参数供您选择，但通常您只需要选择您的测试计划（Test Plan）就能得到您的测试计划中所有测试执行情况的综述。当然，如果您想进一步缩小报告的范围，您可以再对您所关心的某个参数值如测试里程碑（Test Milestone），执行者（Owner），执行记录的状态（TER State）等进行选择。
/ a0 m3 s7 V6 w/ A
" S% C, D: z$ ]. c: [运行报告后，报告结果集如图 10 所示。图形中的每个条形图显示与测试计划关联的测试执行记录数及其执行状态。如果测试执行记录的状态各不相同，那么条形图将与这些状态类别堆叠在一起。将光标移动到类别上方，以查看该分组的测试执行记录数。
您还可通过单击条形图的特定类别部分，查看该特定类别测试执行记录的列表。

( F8 r3 D2 c& V9 A% y图 10. Execution Status using TER Count 报告实例
% _$ P- A) _$ y1 l* H% m, |3 [0 l
Execution Status using Weight
和 Execution Status using TER Count 报告类似的是 Execution Status using Weight 报告。两者区别仅在于使用后者按测试计划显示根据权重衡量的执行状态。基于测试用例个数的测试执行情况固然是很重要的，而基于权重的报告更能反映测试过程中执行记录的状态分布。
, w; F) C2 M+ N' q1 f
运行 Execution Status using Weight 报告后，报告结果集如图 11 所示。图的纵坐标是测试计划，横坐标是权重。图形中的每个条形图显示完成与测试计划关联的所有测试执行记录数所需要的权重或工时及其执行状态。如果测试执行记录的状态各不相同，那么条形图将与这些状态类别堆叠在一起。将光标移动到类别上方，以查看该分组的累积权重。

$ {: s; p: l8 v. ^) j5 N图 11. Execution Status using Weight 报告实例

TER Status Count
1 C" f4 S  I1 {- xTER Status Count 报告是 Execution Status using Weight 报告的列表形式，也是按测试计划显示不同执行状态的权重点数。报告的结果是根据测试计划显示尝试点、通过点、失败点、阻塞点和非决定点的概述（ 如图 12 所示）。单击链接可打开与点类别相关联的测试计划。
9 O3 f8 F; U+ G
图 12. TER Status Counts 报告实例
! c; t6 |% Q" g' M$ X+ d
+ q, v, q4 k( l# s* d* {9 u& g9 q7 A基于三种属性的测试执行记录报告
以上主要介绍的是基于两种属性的测试执行记录报告，RQM 也提供了基于更复杂迭代的测试执行报告。如 Execution Status by Owner using TER Count 报告。

Execution Status by Owner using TER Count
/ U) U* e; {1 z9 s使用此报告可以查看您的测试计划下，不同所有者处于不同执行状态的测试执行记录数。一个实例如图 13 所示，图形中的每个条形图显示与所有者关联的测试执行记录数及其执行状态。如果测试执行记录的状态各不相同，那么条形图将与这些状态类别堆叠在一起。将光标移动到类别上方，以查看该分组的测试执行记录数。
! W  J; v) R5 V4 ^2 @
) M. p% y$ w# j* x* }- g+ |- a图 13. Execution Status by Owner using TER Count 报告实例

9 o( K  Q/ X5 f* _) H9 a9 q# h1 m

列表型测试执行记录报告
9 l$ J& {. p+ q5 e  T还有一些列表型的测试执行记录报告对于您在测试用例粒度上查看执行情况是很有帮助的。

. [6 u# P2 n+ C6 d4 G0 UExecution and defects by owner
4 k! Z6 @& _, L8 z' z9 P) f. z此报告用来显示每个所有者每一条测试执行记录状态及其关联的缺陷。您可以通过单击标识编号，从这些结果打开测试执行记录或缺陷。( 如图 14 所示）

图 14. Execution and defects by owner 报告实例

- ~% b7 Y+ s" D- @9 I( t
# j3 I0 T+ Q# J& p2 v' U& K5 yTER Listing
8 g( m2 G8 j" B此报告是测试执行记录的列表。它列出了每一条执行记录的名称，关联的测试用例，测试环境，测试计划，测试里程碑，执行者，执行状态等信息。( 如图 15 所示）您可以从这些结果链接到与测试执行记录关联的测试用例、配置和结果历史信息。对于测试人员来说，这张报告不但可以使他们总览自己的已执行情况，以帮助开展下一步工作；还可以检验每条记录属性的有效性。

& h8 A  k2 f& ~# R图 15. Listing 报告实例
% [8 P9 e% t  ~9 Y9 O6 h: G: \( @2 C
9 X0 ?0 N' u  T6 i) Y& C) z! ~& m3 F

---

# ~; s& Z* t% S( b+ n' P* i
使用 Rational Quality Manager 报告度量测试
3 W6 `  h9 W! M6 w5 g" @  P0 b# Y除了以上两章提到的报告，还有一些报告能使您通过对它的分析来度量测试过程，从而进一步帮助项目和测试过程做出科学的决策和改进。
; K* b+ a  R$ w% z
/ M  M& [7 A# f! cPlan Requirements Execution using TER Count
此报告用来按需求显示根据测试执行记录数衡量的执行状态（如图 16 所示）。图形中的每个条形图显示与需求关联的测试执行记录数及其执行状态。如果测试执行记录的状态各不相同，那么条形图将与这些状态类别堆叠在一起。将光标移动到类别上方，以查看该分组的测试执行记录数。您还可通过单击条形图的特定类别部分，查看该特定类别测试执行记录的列表。
1 i4 V; h& H! ~2 E) p9 R$ S* d
2 ]3 M$ d  Y( ?3 m. I% [/ @# T图 16. Plan Requirements Execution using TER Count 报告实例
" v& f$ l% }: o$ Z% z; x% p
' w, J4 `) ]& e- k9 i
; B; O  C, s9 U通过查看图 16 的分析，您可以总结出如下的一些现象：
现象 1：哪些需求的测试执行记录最多（最少）
$ }+ u" {0 I1 W* ~  ?5 J* i现象 2：哪些需求的测试执行通过率最低（最高）
……
3 F' z) H4 P1 B- ]) L$ P* q1 T当然，图表本身只能提供一些现象和事实，并不能告诉我们问题是什么。具体问题的分析还需要借助很多要素和信息。
% e  k) a: `  e$ ~举例如从现象 2( 哪些需求的测试执行通过率最低 / 最高）本身来看，出现这种情况的相关因素有很多：

• 从需求本身的角度考虑，与需求本身逻辑复杂程度相关。复杂度越高，开发难度越大，缺陷数可能就会比较多；
• 从开发角度考虑，与开发质量，开发人员对需求的熟悉程度相关；
• 从测试角度考虑，与测试覆盖率，测试人员经验等相关；
• 从项目管理角度考虑，与开发测试周期长短，资源多少，环境等因素相关。
  

要想得出结论，还需要结合项目的其他诸多信息，才能看到现象的根源。
Scorecard
Scorecard 主要用来获取测试用例状态、测试执行数和结果点数以及缺陷数的概述，它也是一个测试里程碑周期里中期和末期很常用到的。一个实例如图 17 所示，Scorecard 会展示出四张列表：测试用例状态列表，测试执行数，测试结果点数总结，缺陷数列表。

图 17. Listing 报告实例

$ S$ E9 m& u1 h$ \# K% \$ `3 f
& c; ~6 Z& R4 o. r) y测试用例状态列表显示了所选测试计划中的所有测试用例的个数和权重，以及处于各个状态（Draft，Under review，Approved，Completed）的用例数。
测试执行数显示了所选测试计划中所有测试执行记录（TER）的个数，以及处于各个状态（Passed，Blocked，Partially Blocked，Failed，Not Started，Inconclusive，Incomplete，PermFailed，Deferred，Error，In Progress，Paused）的记录数。
测试结果点数总结显示了测试执行记录的已执行结果的总权重和处于各个状态的权重。
4 n% J% |' I- B, f$ Y; q) K* N缺陷数列表列出了缺陷总数和处于各个状态（New，Triaged，In Progress，Resolved，Verified，Closed，Reopened，Unconfirmed）的缺陷个数。

Execution by Test Schedule
此报告也是一张综述报告，它是按测试安排列出测试执行记录的处于不同状态的权重。测试安排按顺序依次是：测试里程碑，测试者，测试环境（如图 18 所示）。报告结果集将显示测试执行详细信息的概述，比如权重、点状态和执行尝试。您可以通过单击链接，打开测试环境详情、测试用例和测试执行记录。
8 ~7 D/ }5 j% `; A
& s2 ?0 K5 B9 K& V图 18. Listing 报告实例
8 y0 V& d" O5 G) w# c7 U, |

---

# t( M: G' P8 G) Z, b结束语
本文主要介绍了复用 Rational Quality Manager 标准报告创建随需应变的测试报告的方法，以及如何通过查看这些报告对测试过程进行综合管理和跟踪汇报。本文在第二、三、四章按报告应用的不同阶段——测试计划和设计阶段，测试执行进度跟踪阶段和测试过程度量阶段——介绍了 Rational Quality Manager 常用的一些标准报告。希望本文对您在使用 Rational Quality Manager 报告管理测试项目时有所帮助。
, ?# I" T/ n) }! u) B+ ]

技术狂人

原文地址：http://www.ibm.com/developerwork ... streport/index.html