從測試用例列表批量生成 CQTM Test Case 的三種解決方案

本文介紹了三種從 Test Case 列表批量生成 IBM Rational ClearQuest TestManager（CQTM）Test Case 的解決方案，通過本文所提供的解決方案，可以節省測試人員在CQTM中手動創建 Test Case 的大量重復性工作，提高生產力。

IBM Rational CQTM（ClearQuest TestManager）可以與 RMT（Rational Manual Tester）或 RFT （Rational Functional Tester）集成。通常，測試人員需要先在 RMT 或 RFT 中編寫腳本，然后在 CQTM 中，將此腳本關聯到一個 TMTestCase 或 TMConfiguredTestCase。在很多情況下（例如測試用例數量眾多，或是迭代次數較多），這樣的工作會很耗時，并且往往有大量重復性勞動。本文介紹了三種從 Test Case 列表批量生成 CQTM Test Case 的解決方案，其核心思想是通過使用 CQ（ClearQuest）所提供的 API 來實現自動化的批量生成 TMTestCase 并將相應的腳本與之關聯起來。通過本文所提供的解決方案 , 可以節省測試人員在 CQTM 中手動創建 Test Case 的大量重復性工作，提高生產力。經過測試，在局域網內的 CQTM 中創建 Test Case，每個用例大約花費的時間在 3-5 秒之間，相對于以前由測試人員手動添加并編輯測試計劃、測試用例，效率提高在 90% 以上。

我們已成功實現了 RMT 和 CQTM 的這種整合，因此本文主要討論根據 RMT 的腳本列表如何批量生成，但文中所描述的方案同樣適用于 RFT。本文中，我們結合我們的思路提供了部分示例代碼，讀者可以根據具體的應用需求來實現和定制自己的代碼。

注 : 文中有關 IBM Rational ClearQuest TestManager 的示例代碼為非官方代碼，IBM 不對其提供支持。使用示例代碼需自行承擔風險。作者強烈建議在使用前先在虛擬項目中對代碼進行測試。

1. 通常的使用場景

圖 1 展示了結合使用 CQTM 和 RMT 的通常場景。測試主管（Test Lead）在 CQTM 中創建 Asset Registry，Test Plan，Configuration 和 Iteration。測試人員（Testers）在 RMT/RFT 中編寫腳本，然后在 CQTM 中創建 Test Case，并將相應的腳本與之關聯。測試人員根據 Test Case， Configuration 和 Iteration 生成 Configured Test Case。在測試執行過程中，測試人員為每個 Configured Test Case 創建 Test Log。

圖 1. 通常的使用場景
 

現在我們深入分析一下測試人員如何創建 RMT 腳本和 CQTM Test Case，即圖 1 中紅框所包含的部分。

首先，測試人員在 RMT 中編寫一些腳本并將它們放在某個共享目錄下，例如，\\SharedMachine\SampleProject。為了更好的組織這些腳本，測試人員在此目錄下創建了一個名為“FVT”的子目錄，以標識這些腳本是用于 FVT 的；然后在“FVT”目錄下再創建一個子目錄“Function1_Scripts”用于存放關于組件“Function1”的腳本。對于每個 RMT 腳本，使用一些描述性的命名以表示其功能，例如“TestCase3.rmt”。如圖 2 所示。

圖 2. 創建 RMT 腳本
 

接下來，在 CQTM 中，測試人員需要先定義 Asset Registry 和 File Location，才能開始添加 Test Case 并與 RMT 腳本相關聯。圖 3 展示了在這個場景中所定義的 File Location。

圖 3. 創建 File Location
 

當 Asset Registry 和 File Locations 都準備好之后，測試主管創建一個名為“FVT”的 Test Plan, 并在其下創建一個名為“Function1”的子計劃。然后測試人員就可以開始在“Function1”下創建 TMTestCase。測試人員需要把每個 TMTestCase 與一個 RMT 腳本相關聯，為了保持一致性，TMTestCase 的標題與 RMT 腳本的名字一樣。如圖 4 所示。

圖 4. 創建 CQTM Test Case
 




回頁首

2. 上述場景中的問題

通過觀察圖 2 和圖 4，可以發現其樹結構和命名規則都是極其類似的。因此在 CQTM 中所做的工作其實是一種重復性勞動。我們為何不能尋求一種自動完成這些工作的方法呢？

基于以上考慮，我們通過編程的方法，根據 CQTM 提供的 API 與之進行交互，開發了一個工具來實現自動化，以消除這些重復工作。

假定將 ClearQuest 安裝在 C:\Program Files\Rational\ClearQuest 目錄，則可以在 C:\Program Files\Raitonal\ClearQuest\doc\books 目錄下找到 cq_api.pdf 文件。在這個文件中，所有的 API 都采用 Basic 語言和 Perl 語言進行了描述，但這些 API 也提供對 Java 語言的支持?；旧?，使用 ClearQuest 客戶端所能進行的所有操作，都能通過這些 API 來編程實現。這為 CQ 用戶實現工作的自動化提供了充分的可能。

在以下章節中，我們針對上述場景中 CQTM 用戶所面臨的問題，提出了三種解決方案。3.1 節是一個普通方案，可以節省測試人員在 CQTM 中創建 Test Case 和 Configured Test Case 所需的工作。3.2 節是一個高級方案，將測試準備和測試用例（test case）的生成更徹底的結合在一起。3.3 節是一個更為綜合的方案，它提供了一個包含所有相關信息的模板以用于測試準備和審查，并且除批量生成 CQTM 測試用例以外，還會批量生成相應的 RMT 腳本。

在實際使用中，我們在不同的項目的測試中已經實踐了這三種解決方案。對于普通方案，我們開發了一款名為 RMT2CQ 的工具。對于高級方案，我們往 RMT2CQ 工具中增加了一些特性。對于綜合方案，我們設計了一個模板，并開發了另一款名為 GenRMT 的工具與 RMT2CQ 結合起來使用。

在本文中，我們以 RMT2CQ 的一些示例代碼來闡述我們的思路。讀者可以根據自己的項目情況來定制代碼。對于第三種方案中所涉及的模板和 GenRMT 工具，將會有其他的文章進行更詳細的描述。

注：示例中所使用的是 CQTM 7.0.0.0 和 Common Schema CQTMCS_V1。

使用 API 建立查詢的技巧：通過 API 在 CQTM 中創建新的實體（entity）之前，必須進行查詢（query）以防止重復。在建立查詢時，可以使用 session.BuildSQLQuery() 或 session.BuildQuery()。

如果使用 BuildSQLQuery()，當前會話（session）的登錄用戶應當具有“SQL Editor”特權，這是由于用戶需要傳入正確的 SQL 語句。如果用戶對于 SQL 語句的語法不太確定，可以通過 CQ 的 Eclipse 客戶端得到提示。用戶可以在客戶端中創建類似的查詢，并右鍵單擊該查詢，選擇“SQL”，然后選擇“View SQL”，如圖 5 所示。該查詢相應的 SQL 語句將會顯示出來，如圖 6 所示。在我們的工具以及本文的示例代碼中，我們使用的是這個 API。

圖 5. 查看 SQL
 

圖 6. 顯示 SQL
 

如果使用 Buildquery()，其代碼非常類似于用戶從客戶端創建查詢的過程?？梢允褂?BuildField() 來指定要顯示的域，并使用 BuildFilterOperator() 和 BuildFilter() 來指定查詢標準。

原文轉自：http://www.anti-gravitydesign.com