通過在開發的整個周期內同步化團隊的工作，並使一些費力的工作自動化，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 服務測試任務。通過這種方式，您可以將它們與測試項目的其余部分完全的集成起來。
下一步
現在考慮一下您的測試計劃過程，以及您用於支持它的工具。如果您使用並不止一個，您可以考慮將一些測試工具移動到諸如 IBM Rational Quality Manager 之類的工具之中。同樣，考慮一下在您的團隊中是怎樣共享信息的。您是否在使用 SharePoint 文件夾的復雜集合，或者 e-mail？這也是您想要將此移動到更加自然分配信息的工具中的信號。使用 Rational Quality Manager 來開發一系列的計劃，根據數據進行工作，並查看您是否可以考慮更早的進行報告。
接下來邏輯化的一步，便是使用您在執行項目時在測試計劃中獲取的信息。文章“使用 IBM Rational Quality Manager 實現測試分析和報表”是本文的後續文章。它對測試分析以及報告使用 Rational Quality Manager 方面進行了深入探討。
