測試需求分析

1.前言

　1.1 什麼是測試需求？

　　确切地講，所謂的測試需求就是在項目中要測試什麼。我們在測試活動中，首先需要明确測試需求（What），才能決定怎麼測（How），測試時間（When），需要多少人（Who），測試的環境是什麼（Where），測試中需要的技能、工具以及相應的背景知識，測試中可能遇到的風險等等，以上所有的内容結合起來就構成了測試計劃的基本要素。而測試需求是測試計劃的基礎與重點。

　　就像軟體的需求一樣，測試需求根據不同的公司環境，不同的專業水準，不同的要求，詳細程度也是不同的。但是，對于一個全新的項目或者産品，測試需求力求詳細明确，以避免測試遺漏與誤解。

　　1.2 為什麼要做測試需求？

　　如果要成功的做一個測試項目，首先必須了解測試規模、複雜程度與可能存在的風險，這些都需要通過詳細的測試需求來了解。所謂知己知彼，百戰不殆。測試需求不明确，隻會造成擷取的資訊不正确，無法對所測軟體有一個清晰全面的認識，測試計劃就毫無根據可言。活在自己世界裡的人是可悲的，隻憑感覺不做詳細了解就下定論的項目是失敗的。

　　測試需求越詳細精準，表明對所測軟體的了解越深，對所要進行的任務内容就越清晰，就更有把握保證測試的品質與進度。

　　如果把測試活動比作軟體生命周期，測試需求就相當于軟體的需求規格，測試政策相當于軟體的架構設計，測試用例相當于軟體的詳細設計，測試執行相當于軟體的編碼過程。隻是在測試過程中，我們把“軟體”兩個字全部替換成了“測試”。這樣，我們就明白了整個測試活動的依據來源于測試需求。

2.測試需求分析方法

  2.1 測試需求分析依據

　　通常是以被測産品的需求為原型進行分析轉變而來，測試需求主要通過以下途徑來進行收集：

　　與待測軟體相關的各種文檔資料。如軟體需求規格、Use case、界面設計、項目會議或與客戶溝通時有關于需求資訊的會議記錄、其他技術文檔等。

　　與客戶或系統分析員的溝通。

　　業務背景資料。如待測軟體業務領域的知識等。

　　正式與非正式的教育訓練。

　　其他。如果以舊系統為原型，以全新的架構方式來設計或完善軟體，那麼舊系統的原有功能跟特性就成為了最有效的測試需求收集途徑。

　　2.2 測試需求架構劃分

　　測試需求分析應首先進行測試需求架構劃分并先進行評審，通過後才進行後續的測試需求展開分析，從産品整體上考慮有哪些功能、測試類型需要進行分析，列出測試特性清單，也友善下一步展開具體分析。

　　首先，這裡需要對功能進行一下定義以達成共識，功能是指能獨立實作一個基本業務處理要求，為了降低測試需求設計的複雜性及依賴性，測試需求架構羅列的功能是指最小功能點，即不可再繼續分解。

　　(1)應用程式：

　　A.一般是最底層的菜單項為最小功能點，若最底層的菜單項不能展現一個獨立的業務流程時，可采用上一層

　　的菜單項為最小功能點。

　　B. 還有某些比較特殊沒有展現在菜單項的功能也需要作為最小功能點考慮，如POS應用程式中交易的沖正功能

　　等。

　　(2)驅動：一般是以一個API為最小功能點。

　　然後，再考慮産品實際使用者使用的場合及使用者特點考慮哪些測試類型，如故障及恢複、功能內建、性能要求、安裝測試、軟硬體相容性等，此處需要從産品層面考慮，而不是從功能點層面考慮。

2.3 測試需求分析過程

　　2.3.1 測試需求收集

　　測試需求的收集主要通過對測試依據進行分析整理，最後生成一個以測試的觀點出發的checklist（檢查表），用來作為測試該軟體的主要工作内容。檢查表的檢查要點包括需求的正确性、必要性、優先級、明确性、可測性、完整性、一緻性、可修改性：

　　在整個資訊收集過程中，務必確定軟體的功能與特性被正确了解。是以，測試需求分析人員必須具備優秀的溝通能力與表達能力。

  2.3.1.1 測試類型劃分

　　根據測試需求收集獲得的checklist(檢查表)，對每一條測試需求，從GB/T16260.1定義的軟體品質子特性角度出發，确定所對應的品質子特性。即，從适用性、準确性、互操作性、保密安全性、成熟性、容錯性、易恢複性、易了解性、易學性、以操作性、吸引性、時間特性、資源利用性、易分析性、易改變性、穩定性、易測試性、适應性、易安裝性、共存性、易替換性和依從性方面的定義出發，确定每一條測試需求所對應的品質子特性。進而對這些品質子特性進行測試類型劃分，如：功能測試、易用性測試（安裝測試、功能易用性測試、使用者界面測試、輔助系統測試）、相容性測試、可靠性測試、文檔測試、性能測試，強度測試等。

　　2.3.1.2 測試類型細化

　　對劃分的每個測試類型進行細化。軟體測試需求是開發測試用例的依據，測試需求分解得越詳細精準，表明對軟體的了解越深，對所有要進行的任務就越清晰，對測試用例的設計品質的幫助也越大，詳細的測試需求還是衡量測試覆寫度的重要名額，測試需求是計算測試覆寫的分母，沒有詳細的測試需求就無法有效的進行軟體測試覆寫計算。最好達到細化的結果是分支的最末端（測試項）針對的測試目的是單一的最小的功能點的測試，即每個測試項為一個測試功能點。

　　2.3.1.3 生成測試需求樹

　　已細化的測試需求中，由于在提取時，可能存在着重複或備援，需要進行删除和合并需求。删除測試需求中存在的重複的、備援的含有關系的測試項。如果有類似的測試項，則需要對其進行合并。最終生成測試需求樹。

　　2.3.2 測試風險分析

　　由于軟體的輸入、輸出、處理存在一定的限制和限制，另一方面由于測試樹中進行了必要的删除和合并，這導緻測試需求不可能是全面的覆寫，進而形成了一定的測試風險。測試需求中必須對不分析或不測試部分給出相應的風險分析說明。

　

3.總結

　　以上主要描述了測試需求相關理論和獲得測試需求樹的一般過程。為具體項目實施測試中提供了一套擷取測試需求樹的參考方案。實際的測試類型劃分和測試需求樹生成的形式或粒度，因項目而不同，需靈活應用。