使用 IBM Rational Quality Manager 進行測試規劃

轉自：developerworks

作者：

Michael Kelly,

通過在開發的整個週期內同步化團隊的工作，並使一些費力的工作自動化，IBM® Rational® Quality Manager 能夠幫助團隊實現更好的合作。使用這款工具，團隊可以通過提供及時可靠的評價，來更好的管理他們的專案。Rational Quality Manager 是在 Jazz 平臺的基礎之上構建的。本文檢查了測試計劃過程，並探究了 Rational Quality Manager 是怎樣支援這個過程的。

通過在開發的整個週期內同步化團隊的工作，並使一些費力的工作自動化，IBM® Rational® Quality Manager 能夠幫助團隊實現更好的合作。使用這款工具，團隊可以通過提供及時可靠的評價，來更好的管理他們的專案。使用這款工具，團隊可以通過提供及時可靠的評價，來更好的管理他們的專案。Rational Quality Manager 是在 Jazz 平臺的基礎之上構建的，Jazz 平臺是一種協作性的，基於角色的，業務驅動的環境，它能夠提供用於工作流程控制，追蹤以及評價報告的工具。這款軟體是一種協作性的，基於 Web 的質量管理方案，它能夠提供綜合性的測試計劃，雙方測試，並能與自動測試工具相整合。

測試計劃就是制定測試戰略並付之行動，通常是為一個特定的時期而制定的，例如一次重複期，衝刺期或者一個小型專案。本文檢查了測試計劃過程，並探究了 Rational Quality Manager 是怎樣支援這個過程的。您可以按您自己的想法給 Rational Quality Manager 一些測試文件。它提供了儘可能簡化這個過程的工具。在計劃的每個階段內，使用 Rational Quality Manager，而不是一個基本檔案或者專案計劃的目的，是在專案進行過程中，將它與您的報告和評價整合起來。

考慮測試計劃

當您考慮您的測試計劃時，您不應該從一個檔案開始。這是一個過程。您應該做的第一件事情，是理解具體公司和專案的背景。理解背景也就是說，理解您將要與之打交道的事物的價值、過程、操作、思想、政策以及個性。而不僅僅是商業目標以及專案需求。而是關於公司和團隊是怎樣工作的，以及為什麼要這樣做。

一旦您對背景有所瞭解，那麼就開始制定一項測試計劃吧。Karen N. Johnson 最近在 Portland，Oregon 舉行的 Pacific Northwest Software Quality Conference 會議上，發表了關於建立一個測試計劃的談話。在這次談話中，她進行了生動的描述：“測試戰略的有趣之處在於，如果您不去寫出它，那麼它就會自己寫出來。” Karen 繼續指出，如果您不去制定一項測試計劃，那麼它將會以人們會思考您將要進行的測試這種假設的形式而替換。隨後您可能會發現，只有通過寫下一些什麼東西，您才能夠節省大量的時間和精力。
這就是測試戰略的全部：它是一種您告訴團隊成員您想要測試什麼以及不想測試什麼，下一步您準備怎麼做的方式。它是一種傳達意圖的高水平交流方式。Karen 談話傳達的另一個資訊，是可以將測試戰略當做測試商品賬單或者工作總結。這是您告訴人們您計劃想要交付什麼的一種方式。對於測試戰略，您要回答以下這些問題：

• 我們正在測試什麼？
• 我們將要採用什麼方法？
• 為了更有效的計劃我還需要哪些資訊？

只有在您知道您開始計劃後想要交付什麼以後。測試計劃就是測試所要完成的特定任務。它是邏輯性的測試用例以及資源，並且包含了在測試時您需要注意的所有附件以及風險。在您計劃時，您要估計，發現您不能完成您想要做的一切事情，商議範圍，確定交付日期並且分配工作。

當您在計劃時，問一些如下的問題：

• 我們將會怎樣執行我們的測試？
• 我們將會在什麼地方執行它們？
• 我們將會在什麼時候開始執行它們？
• 我們將會怎樣管理工作中發現的問題？
• 以及等等諸如此類問題。

提出這些問題的目的，是概括並總結某個特定時期內的測試效果細節。一般更加有可能的情況是，如果您正在記錄一個測試計劃（它並不僅僅是為管理和處理的過程），那麼您就能夠使用它來幫助指導測試效果。這意味著您想要資訊竟可能的正確。

接下來就是您可以處理測試計劃的一些問題：

• 前期準備
• 人員配備
• 測試範圍
• 所有的測試需求（技術上或者其他方面的）
• 測試環境
• 進入標準
• 退出標準
• 職責分配
• 設施批准
• 任務計劃
• 日程安排
• 記錄與其他的團隊成員之間的協調和合作
• 可能會影響測試的風險和問題
• 測試專案的具體可傳遞性

通常在您計劃時，專案會在您完成計劃之前就已經開始執行了。這就迫使您同時進行計劃和執行。當您使用 Rational Quality Manager 這樣的工具時，您可以追蹤進展，並記得解決計劃過程中出現的一些問題 。

當您在進行計劃時，您應該擁有以下：

• 關於背景的資訊
• 關於需要解決難題（或者專案）的資訊
• 關於測試的打算
• 關於測試覆蓋面的打算
• 關於專案風險的打算
• 關於具體執行方案的打算
• 試著共享意圖的檔案或者產品，這在挑戰假設和理解方面十分有用。
• 可能需要移到程式前面的檔案或者產品（取決於背景）

回頁首

Rational Quality Manager 中的測試規劃

本段將會探討您可以怎樣使用 Rational Quality Manager，來支援您的計劃過程。Rational Quality Manager 擁有被稱為測試計劃的物件，為測試規劃提供了可定製的模板，並提供工具和可視性到您的程式中。下面有一系列您可以使用 Rational Quality Manager 的特性的方法。

在開發程式內進行規劃

您可以使用 Rational Quality Manager 中的一系列特性，將其整合到您的開發環境中。Rational Quality Manager 會使用角色的概念，工作流程以及產品包含中的工具。我們的目標不是讓您以一種“Rational 的方式”來做事，而是向您提供一些不用改造就可以直接使用的工具。通過這種方式，您可以學到它的一些功能，這樣您就會發現什麼是可能的，並得到業內其他人士正在做的事情的資訊。

從計劃的角度來看，這項任務很重要，因為它允許您去做很多事情。首先，您可以在工具中建立一個測試計劃概述。它可以包含檢查器，產品狀態，訊號以及等等。在圖 1 中，您可以看到一個具體的例子，是關於怎樣在包含的預設流程中這一切是怎樣執行的。測試計劃的狀態現在被設定成 Draft，而且您可以將測試計劃轉化為 Ready for Review 狀態。當您建立 Roles 時，您可以定義由誰來在 Ready for Review 狀態下檢查測試計劃。

圖 1. 在 Rational Quality Manager 中將一個測試計劃轉化為 Ready for Review 狀態

除了為檢查建立簡單的工作流程，您還可以通過建立工作項，來向其他人分配測試計劃的任務。如圖 2 所示。

圖 2. 在 Rational Quality Manger 中分配工作項

然後這些專案就會自動顯示在被分配任務人員的“要完成之事”的列表之中。每一個專案都會有其自己的狀態以及可能的准許程式，如圖 3 所示。對於該工作項，狀態是新的，而且您可以因為準許，檢查或者證實來提交它。

圖 3. 准許 Rational Quality Manager 中的工作項

在任務的另一端，如果您不需要准許或者檢查，那麼您就可以刪除它，或者直接簡單的不去使用它。您可以根據需要建立或者刪除角色，對映工作流程的各個方面的角色，更改工作流程。您可以控制程式，並使其能夠支援您的計劃程式。

除了角色，工作流程以及檢查，在測試計劃中還有進入和退出標準，它能使您的開發過程變得可見。許多團隊使用進入標準來指定什麼時候可以開始進行測試，使用退出標準來指定什麼時候工作算已經完成。這些標準可以為嚴格的審視把關，或者作為產品什麼時候為嚴格的測試做好了準備，或者什麼時候測試算完成的啟發式指示符。但是如果您使用它們的話，它們可能會十分的棘手，因為您可以在一箇中心的位置處追蹤它們，並使用自動生成的報告來報告它們。圖 4 中顯示的就是一個追蹤進入標準的範例。

圖 4. Rational Quality Manager 測試計劃的進入標準範例

注意就算是對標準項，您也可以建立工作項。在前一個例子中，您也許為需要建立的三種測試環境配置建立了工作項。那麼理論上您就可以更緊密的追蹤這些活動的狀態了。

不管測試計劃的各個部分，您可以為 Rational Quality Manager 的計劃追蹤個人專案（如果您願意這麼做的話）。使用這種工具的優勢，就像一個 Microsoft® Project 計劃那樣，將您和您的團隊維持在剩餘工作可以完成的工具處。它同樣還整合了您的專案追蹤和報告功能。

規劃覆蓋範圍

Rational Quality Manager 中追蹤和報告測試程式的一個關鍵工具，就是測試計劃。Rational Quality Manger 擁有一些需求特性，這些特效能夠幫助您去管理需求覆蓋範圍。在測試計劃中，有一個管理某個測試計劃所有需求的 Requirements 部分（如圖 5 所示）。如果您想要追蹤來自 Rational Quality Manager 的需求，那麼您完全有能力這樣做。如果您想要從其他工具中匯入它們，您也擁有這個能力。您還可以選擇，如果您只想建立並追蹤一些通用的測試需求的話，也是可能的。

圖 5. Rational Quality Manager 中測試計劃的 Requirements

許多專案擁有大量的功能性需求覆蓋範圍（如果應用讓您做 X，那麼您就不該做 Y，等等），但是他們只對輔助功能性需求擁有需求。這並不意味著您不去測試它們：您需要這樣做。但是，追蹤測試的狀態和覆蓋範圍通常會十分困難。如果您建立自己的需求，那麼您可以為效能，安全性，實用性以及其他易忽略的方面新增需求。然後您可以將測試用例與這些需求聯絡起來，以追蹤覆蓋範圍以及測試計劃層次的狀態。

在 Rational Quality Manager 中，您可以在測試計劃中的 Quality Objectives 部分中清晰的定義您的質量目標，如圖 6 所示。該段以表格的格式，列出了您的質量目標。您可以自由的去編輯 Quality，Objectives Description，Current Value，以及 Comment 區域（沒有顯示出來），允許您去指定您想要實現的所有目標。

圖 6. 測試計劃中質量目標的範例

一些可能的目標包含了以下領域的方法：

• 程式碼複雜性
• 單元測試成功
• 程式碼覆蓋範圍
• 需求覆蓋範圍
• 測試用例完成情況（完成百分率，通過百分率，等等）。
• 負載，效能或者評價性
• 開放的話題或者缺陷的嚴重情況，範圍或者狀態
• 缺陷出現率或者測試速度
• 測試用例或者需求優先順序或者嚴重性
• 標準適應性（section 508，W3C，以及等等）
• 文獻或者證據支援

您所選擇的質量標準，很大程度上取決於您想對專案所要做的，以及您在哪種開發背景下工作。不管您選擇了什麼，Quality Objectives 部分都會向您提供一個很棒的快照，顯示在一種質量視角下專案在什麼地方。

Rational Quality Manager 中一個重要的特性，便是測試計劃中的 Test Environments 計劃部分。當您首次開啟該部分時，它會催促您去定義需要涉及到的平臺需求。如下面的圖 7 所示，您所需要做的，就是定義您需要涉及到的平臺構件的型別，以及您需要測試的版本或者屬性。您只需建立需要測試的一個簡單列表。

圖 7. 定義測試計劃中的平臺覆蓋範圍

從這裡開始，您可以繼續去定義基於不同範圍模型的覆蓋面。如果您切換至 Test Environment 項時（如圖 8 所示），您可以看到一副不同的景象，它最終會包含您將會碰到的每一個環境。

圖 8. 生成之前的 Test Environments

在您儲存測試計劃之後，如果您點選 Generate New Test Environments 圖示的話，您將會啟動一個嚮導，該向導將會帶您去生成一個初始的覆蓋範圍列表 。該向導的第一步，如圖 9 所示，將會定義您想要處理的元素，以及您想要使用的生成方法。

圖 9. 生成環境的第一步

這裡提供了一系列的覆蓋範圍方法，包括單向的，雙向的以及三向的交流，還有所有的排列。您在這裡所做的選擇，決定了您將會碰到什麼樣的環境。很少有 團隊擁有測試所有排列的資源，所以問題是您和您的團隊願意接受什麼層次的風險。如果需要的話，您可以在未來改善您的生成過程：更改環境元素的高階屬性，並新增明確包含（explicit inclusions）、排除（exclusions）以及加權（weightings）。

在您選擇您所喜歡的涵蓋方法之後，您可以點選 Next，您就得到了一次機會，在接受它們之前檢查生成的環境。這種方式允許您，如果需要的話您可以做出更改。圖 10 使用瀏覽器分類的雙向的覆蓋來顯示生成的環境 。

圖 10. 生成環境的第 2 步（瀏覽器分組的，雙向的）

當您接受環境時，它們會新增到測試計劃中的 Test Environments 列表中（如圖 11 所示）。從這裡開始，如果您不需要的話您就可以刪除它們中的任何一個，或者如果需要新增一個新的配置時手動新增記錄。如果需要的話，您還可以編輯任意一個特定的環境。

圖 11. 載入測試計劃中的 Test Environments

規劃執行

計劃過程中一個比較棘手的方面便是規劃執行。您需要考慮以下的一些事情（有一些是您將會遇到的，有一些您不會遇到）：

• 測試人員的數量
• 應用每一個時期需要的層次，環境和配置，或者質量標準
• 您必須支援的測試初始資源的大小和範圍
• 您認為必須執行測試的一段時間
• 您覺得您將會遇到多少問題或者需要解決多少問題的估計
• 您將會揭示並需要執行多少新型測試的估計
• 您估計您不需要執行多少次測試的估計

為了讓事情變得更加困難，作為一個測試管理員，您並不需要完全憑空想去計劃。您必須考慮對其他團隊和管理員的依賴性。對於過去的專案，計劃涉及到了一系列檔案（計劃檔案，專案計劃，估計傳單以及等等）還要舉行會議並進行檢查。對於現在的專案，計劃一般會更快，並涉及到了更少的人，但是它仍然需要考慮您知道些什麼，以及您不知道什麼。

使 Rational Quality Manager 測試計劃更加顯眼的是 Test Schedules，Test Estimation，以及 Test Team 部分。這三項以一種幫助您描述執行的畫面的方式，集合了其他所有的 部分（Entry and Exit Criteria，Test and Quality Objectives，Requirements，以及 Test Cases）。

在 Rational Quality Manager 的管理介面內，您可以建立並管理不同的測試團隊。您可以使用一對多分配模式來完成它，這意味著同一個人可以工作在多個團隊（現實中很常見）。一旦您開始了建立，如果您選擇了一個計劃內的測試團隊，那麼您可以檢視是哪個團隊成員分配給了該專案（同樣見於圖 12）。這些團隊成員通常能夠去做任務分配，測試用例分配以及計劃內的其他操作。

圖 12. 測試計劃內的 Test Team 分配

作為計劃過程的一部分，您可以建立關於測試計劃大小的高層次估計。您也可以提供執行每一個私人測試用例所需的具體時間或者精力的估計。這些估計幫助您去評估您的進展，它們會向一些報告提供輸入 。

在測試專案的早期階段，您可以提供高層次的完成測試計劃活動所需時間的估計，以及執行所有測試所需的時間和精力的估計。這些測試通常都是基於您對專案需求的理解。圖 13 顯示了在測試計劃中定義高層次估計的範例。在早期這種拉下式計劃可以十分有用。

圖 13. 測試計劃內高水平的測試估計

在隨後的計劃中，您可以通過向每一個測試用例新增一個加權值，來提供一份詳細的關於測試執行效果的估計。在 Rational Quality Manager 中，測試擴充套件記錄繼承了相關測試用例的加權值。例如，一個分配有 10 加權值的測試用例，其執行的時間可能是加權值為 5 測試用例的兩倍。一般來說，所謂的加權值就是您的測試團隊使用某個測試單元的數值。

有一些測試團隊想以點來衡量權重，而另外一些人則以小時、分鐘或者其他的一些測量手段來衡量。這些具體的範圍資訊可用作一些執行狀態報告的輸入。通過向每一個測試用例分配不同的權重，您可以執行精確的報告，同時考慮執行中的測試用例的絕對數量，以及執行每一個測試用例所需的時間。

在高水平的估計之後，您可以在測試計劃的 Test Schedule 部分中，定義一個高水平的日程表（如圖 14 所示）。對於每一個重大事件或者重複中，您可以建立高水平的日程表，該日程表列出了諸如版本、程式碼凍結、UI 凍結、beta 入口、beta 出口，以及其他的日期之類的資訊。

圖 14. 測試計劃中的日程安排規劃

規劃自動化

從測試計劃的角度出發，該角度時候考慮 Rational Quality Manager 可以怎樣幫助您去計劃使用自動化。您可以為效能和安全性測試之類的事情設定質量目標，併為您的自動化測試覆蓋面定義環境。您還可以為您準備使用哪些工具，以及在什麼地方使用它們做一些前置計劃。

在您的測試計劃中，所有的測試元素都會與 Rational Quality Manager 聯絡起來，您有機會去計劃並管理您的自動化效果。首先，您可以向您的需求新增通用標籤。這給您一些自動化使用方面的前置計劃。例如，如果您正在檢查一項需求，那麼您可以將其貼上以下的標籤：

• 關鍵字 regression 用於您想要建立一個自動化迴歸測試用例的需求
• 關鍵字 performance 用於您需要開發效能測試的需求，或者需要聯絡基於需求一些方面的效能測試
• 關鍵字 configuration 用於可能驅動自動化測試多環境的需求
• 關鍵字 SOA 用於您想要在 Web 服務介面層次上測試的需求
• 關鍵字 security 用於可能會使用 IBM® Rational® AppScan®（或者其他一些工具）來測試的需求

在計劃那些自動化效果時，提供一些您可以報告的簡單標籤。

在此之後，您可以嘗試進行特定自動化的指令碼和測試。您還可以選擇，為一些不同種類的您可能對專案進行自動化的類別分配測試用例。除了標籤和追蹤性，考慮一下向您的日程表和估計新增不同的自動化，效能，安全性測試以及 Web 服務測試任務。通過這種方式，您可以將它們與測試專案的其餘部分完全的整合起來。

 

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780914/viewspace-608539/，如需轉載，請註明出處，否則將追究法律責任。