軟體測試計劃

詳細的測試計劃可以幫助測試項目組之外的人了解為什麼和怎樣驗證產品。它非常有用但是測試項目組之外的人卻很少去讀它。軟體測試計劃作為軟體項目計劃的子計劃，在項目啟動初期是必須規劃的。在越來越多公司的軟體開發中，軟體質量日益受到重視，測試過程也從一個相對獨立的步驟越來越緊密嵌套在軟體整個生命周期中，這樣，如何規劃整個項目周期的測試工作；如何將測試工作上升到測試管理的高度都依賴於測試計劃的制定。測試計劃因此也成為測試工作的賴於展開的基礎。《ANSI/IEEE軟體測試文檔標準829-1983》將測試計劃定義為：“一個敘述了預定的測試活動的範圍、途徑、資源及進度安排的文檔。它確認了測試項、被測特徵、測試任務、人員安排，以及任何偶發事件的風險。”軟體測試計劃是指導測試過程的綱領性文件，包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。藉助軟體測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。

當今任何商業軟體都包含了豐富的功能，因此，軟體測試的內容千頭萬緒，如何在紛亂的測試內容之間提煉測試的目標，是制定軟體測試計劃時首先需要明確的問題。測試目標必須是明確的，可以 量化和度量的，而不是模稜兩可的宏觀描述。另外，測試目標應該相對集中，避免羅列出一系列目標，從而輕重不分或平均用力。根據對用戶需求文檔和設計規格文檔的分析，確定被測軟體的質量要求和測試需要達到的目標。編寫軟體測試計劃得重要目的就是使測試過程能夠發現更多的軟體缺陷，因此軟體測試計劃的價值取決於它對幫助管理測試項目，並且找出軟體潛在的缺陷。因此，軟體測試計劃中的測試範圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具並且具有較高的實用性，便於使用，生成的測試結果直觀、準確。

一個好的測試計劃可以起到如下作用：

1、使測試工作和整個開發工作融合起來；

2、資源和變更事先作為一個可控制的風險。

軟體項目的測試計劃是描述測試目的、範圍、方法和軟體測試的重點等的文檔。對於驗證軟體產品的可接受程度編寫測試計劃文檔是一種有用的方式。詳細地測試計劃可以幫助測試項目組之外的人了解為什麼和怎樣驗證產品。它非常有用但是測試項目組之外的人卻很少去讀它。

依據特定的項目，在一個測試計劃中可能包括下面項目：

1、標題；

2、軟體標識，包括版本/發布版本號；

3、目錄；

4、文檔的目的和閱讀人群；

5、測試的對象；

6、軟體產品概述；

7、相關文檔列表，例如需求規格、設計文檔和其它測試計劃等；

8、有關的標準和法規；

9、可追溯的需求；

10、有關的命名約定和標識約定；

11、軟體項目的相關的所有部門和成員/聯繫信息/職責；

12、測試項目組和人員/聯繫信息/職責；

13、假設和依賴；

14、項目風險分析；

15、測試優先順序和重點；

16、範圍和測試限制；

17、測試描述－根據測試類型、特徵、功能、過程、系統、模塊等分類；

18、輸入等價類分類描述、邊界值分析、錯誤分類；

19、測試環境－軟、硬體、操作系統、其它需要的軟體、數據配置、與其它系統的介面；

20、測試環境有效性分析－測試環境的不同和產品系統對測試有效性的影響；

21、測試環境建立和配置問題；

22、軟體移植性考慮；

23、軟體配置管理過程；

24、測試數據建立需求；

25、系統日誌描述/錯誤日誌/其它的能力和工具，例如屏幕捕獲工具、這對於描述bug和報告bug

是很有用的；

26、討論任何測試人員用來發現bug或跟蹤bug的硬體、軟體工具；

27、測試自動化－採用的理由和描述；

28、採用的測試工具、包括版本、補丁等；

29、測試腳本/測試代碼維護過程和版本控制；

30、跟蹤和解決－工具和步驟

31、用於項目的測試度量標準；

32、報告需求和測試交付產品；

33、軟體入口和出口標準；

34、初期確定的測試周期和標準；

35、測試暫停和重啟標準；

36、人員分配；

37、人員崗前培訓；

38、測試地點/場所；

39、測試項目組之外可用的資源和他們的作用、職責、交付、聯繫人和協調等問題；

40、與所有權相關的級別、分類、安全和許可問題；

41、公開的一些問題。

編寫軟體測試計劃要避免一種不良傾向是測試計劃的“大而全”，無所不包，篇幅冗長，長篇大論，重點不突出，既浪費寫作時間，也浪費測試人員的閱讀時間。“大而全”的一個常見表現就是測試計劃文檔包含詳細的測試技術指標、測試步驟和測試用例。最好的方法是把詳細的測試技術指標包含到獨立創建的測試詳細規格文檔，把用於指導測試小組執行測試過程的測試用例放到獨立創建的測試用例文檔或測試用例管理資料庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從宏觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。測試資源的變更是源自測試組內部的風險而非開發組風險，當測試資源不足或者衝突，測試部門不可能安排如此多的人手和足夠時間參與測試時，在測試計劃中的控制方法與測試時間不足相類似。沒有測 試經理願意承擔資源不足的測試工作，只能說公司本身是否具備以質量為主的體系或者項目經理對產品質量的重視程度如何決定了對測試資源投入的大小，最終產品質量取決因素不僅僅在於測試經理。為了排除這種風險，除了像時間不足、測試計劃變更時那樣縮減測試規模等等方法以外，測試經理必須在人力資源和測試環境一欄標出明確需要保證的資源，否則，必須將這個問題作為風險記錄。

“5W”規則指的是“What（做什麼）”、“Why（為什麼做）”、“When（何時做）”、“Where（在哪裡）”、“How（如何做）”。利用“5W”規則創建軟體測試計劃，可以幫助測試團隊理解測試的目的（Why），明確測試的範圍和內容（What），確定測試的開始和結束日期（When），指出測試的方法和工具（How），給出測試文檔和軟體的存放位置（Where）。為了使“5W”規則更具體化，需要準確理解被測軟體的功能特徵、應用行業的知識和軟體測試技術，在需要測試的內容裡面突出關鍵部分，可以列出關鍵及風險內容、屬性、場景或者測試技術。對測試過程的階段劃分、文檔管理、缺陷管理、進度管理給出切實

可行的方法。

就通常軟體項目而言，基本上採用“瀑布型”開發方式，這種開發方式下，各個項目主要活動比較清晰，易於操作。整個項目生命周期為“需求－設計－編碼－測試－發布－實施－維護”。然而，在制定測試計劃時候，有些測試經理對測試的階段劃分還不是十分明晰，經常性遇到的問題是把測試單純理解成系統測試，或者把把各類型測試設計（測試用例的編寫和測試數據準備）全部放入生命周期的“測試階段”，這樣造成的問題是浪費了開發階段可以并行的項目日程，另一方面造成測試不足。

相應階段可以同步進行相應的測試計劃編製，而測試設計也可以結合在開發過程中實現并行，測試的實施即執行測試的活動即可連貫在開發之後。值得注意的是：單元測試和集成測試往往由開發人員承擔，因此這部分的階段劃分可能會安排在開發計劃而不是測試計劃中。

測試計劃寫作完成後，如果沒有經過評審，直接發送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟體需求變更引起測試範圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。測試計劃包含多方面的內容，編寫人員可能受自身測試經驗和對軟體需求的理解所限，而且軟體開發是一個漸進的過程，所以最初創建的測試計劃可能是不完善的、需要更新的。需要採取相應的評審機制對測試計劃的完整性、正確性、可行性進行評估。例如，在創建完測試計劃后，提交到由項目經理、開發經理、測試經理、市場經理等組成的評審委員會審閱，根據審閱意見和建議進行修正和更新。測試計劃改變了已往根據任務進行測試的方式，因此，為使測試計劃得到貫徹和落實，測試組人員必須及時跟蹤軟體開發的過程，對產品提交測試做準備，測試計劃的目的，本身就是強調按規劃的測試戰略進行測試，淘汰以往以任務為主的臨時性。在這種情況下，測試計劃中強調對變更的控制顯得尤為重要。

變更來源於以下幾個方面：

1、項目計劃的變更；

2、需求的變更；

3、測試產品版本的變更；

測試階段的風險主要是對上述變更所造成的不確定性，有效的應對這些變更就能降低風險發生的幾率。要想計劃本身不成為空談和空白無用的紙質文檔，對不確定因素的預見和事先防範必須做到心中有數。對於項目計劃的變更，除了測試人員及時跟進項目以外，項目經理必須認識到測試組也是項目成員，因此必須把這些變更信息及時通知到項目組，使得整個項目得到順延。項目計劃變更一般涉及都是日程變更，令人遺憾的是，往往為了進度的原因，交付期限是既定的，項目經理不得不減少測試的時間，這樣，執行測試的時間就被壓縮了。在這種情況下，測試經理常常固執的認為進度縮減的唯一的方法就是向上級通報並主觀認為產品質量一定會下降，這種做法和想法不一定是正確的。

規避風險的辦法可能有：

一、項目組的需求和實施人員參與系統測試；二、抽調不同模塊開發者進行交叉系統測試或借用其他項目開發人員；

三、組織客戶方進行確認測試或發布β版本。

儘管上面儘可能的描述了測試計劃如何制定才能“完美”，但是還存在的問題是對測試計劃的管理和監控。一份計劃投入再多的時間去做也不能保證按照這份計劃進行實施。好的測試計劃是成功的一半，另一半是對測試計劃的執行。對小項目而言，一份更易於操作的測試計劃更為實用，對中型乃至大型項目來看，測試經理的測試管理能力就顯得格外重要，要確保計劃不折不扣的執行下去，測試經理的人際諧調能力，項目測試的操作經驗、公司的質量現狀都能夠對項目測試產生足夠的影響。另外，計劃也是“動態的”。不必要把所有的因素都可能囊括進去，也不必要針對這種變化額外製定“計劃的計劃”，測試計劃制定不能在項目開始后束之高閣，而是緊追項目的變化，實時進行思考和貫徹，根據現實修改，然後成功實施，這才能實現測試計劃的最終目標——保證項目最終產品的質量。