一、什么是測試需求
測試需求的概念比較簡單。例如，比方說一個計算平方根的程序，如果輸入一個大于或等于零的數，程序可以給出一個結果；如果輸入一個小于零的數，程序將指出輸入錯誤。讀過《軟件測試的藝術》一書的工程師都會立即聯想到邊界值。對數值零進行測試；對零非常接近的負數進行測試，這就是兩個具體的測試需求。
在一個更加復雜的程序中，你可以將打算測試的項目做成一個列表。但是，這些測試需求都不會確定具體的測試數據。例如，一個銀行交易程序，一個測試需求是試圖支付客戶的金額為負數，另一個測試需求是交易中的客戶并不存在，等等。你有一系列這樣的測試需求，它們并沒有指出具體的數值或數據，如客戶的姓名。
測試的下一步是選擇滿足這些測試需求的輸入值/測試數據。一個簡單的測試用例可能會同時滿足好幾個測試需求。一個用例能同時滿足好幾個測試需求，當然是最理想的情況，但是這樣做的代價較高。另外一種方法是為每一個測試需求設計一個單獨的測試用例，就可以不必考慮那些復雜的測試用例，但是這些相對簡單的測試用例發現缺陷的能力就會有所下降。
這里有一個測試需求的實例：對一個哈希表的插入操作進行測試，有以下這些測試需求：
1）插入一個新的條目
2）插入失�。瓧l目已經存在
3）插入失�。硪褲M
4）哈希表在插入前為空
這些就是測試需求，而非測試用例，因為它們沒有對被插入元素進行描述。另外你也不能馬上就著手書寫用例，就好象軟件需求完成后不能立即進行編碼一樣。還需要對測試需求進行評審，確保正確和沒有需求遺漏。
二、為什么要做測試需求分析
如果要成功的做一個測試項目，首先必須了解測試規模、復雜程度與可能存在的風險，這些都需要通過詳細的測試需求來了解。所謂知己知彼，百戰不殆。測試需求不明確，只會造成獲取的信息不正確，無法對所測軟件有一個清晰全面的認識，測試計劃就毫無根據可言�；钤谧约菏澜缋锏娜耸强杀�，只憑感覺不做詳細了解就下定論的項目是失敗的。
測試需求越詳細精準，表明對所測軟件的了解越深，對所要進行的任務內容就越清晰，就更有把握保證測試的質量與進度。
如果把測試活動比作軟件生命周期，測試需求就相當于軟件的需求規格，測試策略相當于軟件的架構設計，測試用例相當于軟件的詳細設計，測試執行相當于軟件的編碼過程。只是在測試過程中，我們把”軟件”兩個字全部替換成了”測試”。這樣，我們就明白了整個測試活動的依據來源于測試需求。
三、需求測試注意事項有哪些
一個良好的需求應當具有一下特點：
完整性：每一項需求都必須將所要實現的功能描述清楚，以使開發人員獲得設計和實現這些功能所需的所有必要信息。
正確性：每一項需求都必須準確地陳述其要開發的功能。
一致性：一致性是指與其它軟件需求或高層（系統，業務）需求不相矛盾。
可行性：每一項需求都必須是在已知系統和環境的權能和限制范圍內可以實施的。
無二義性：對所有需求說明的讀者都只能有一個明確統一的解釋，由于自然語言極易導致二義性，所以盡量把每項需求用簡潔明了的用戶性的語言表達出來。
健壯性：需求的說明中是否對可能出現的異常進行了分析，并且對這些異常進行了容錯處理。
必要性：“必要性”可以理解為每項需求都是用來授權你編寫文檔的“根源”。要使每項需求都能回溯至某項客戶的輸入，如Use Case或別的來源。
可測試性：每項需求都能通過設計測試用例或其它的驗證方法來進行測試。
可修改性：每項需求只應在系統需求分析中出現一次。這樣更改時易于保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規格說明書更容易修改。
可跟蹤性：應能在每項軟件需求與它的根源和設計元素、源代碼、測試用例之間建立起鏈接鏈，這種可跟蹤性要求每項需求以一種結構化的，粒度好（f i n e - g r a i n e d ）的方式編寫并單獨標明，而不是大段大段的敘述。
四、測試需求需要考慮幾個層面的因素
第一層：測試階段。系統測試階段，需求分析更注重于技術層面，即軟件是否實現了具備的功能。如果某一種流程或者某一角色能夠執行一項功能，那么我們相信具備相同特征的業務或角色都能夠執行該功能。為了避免測試執行的冗余，可不再重復測試。而在驗收測試階段，更注重于不同角色在同一功能上能否走通要求的業務流程。因此需要根據不同的業務需要而測試相同的功能，以確保系統上線后不會有意外發生。但是否有必要進行這種大量的重復性質的測試，不過也是見仁見智的做法，要看測試管理者對測試策略與風險的平衡能力了。
目前，大多數的測試都會在系統測試中完成，驗收測試只是對于系統測試的回歸。此種情況也是合理的，關鍵看測試周期與資源是否允許，以及各測試階段的任務劃分。
第二層：待測軟件的特性。不同的軟件業務背景不同，所要求的特性也不相同，測試的側重點自然也不相同。除了需要確保要求實現的功能正確，銀行/財務軟件更強調數據的精確性，網站強調服務器所能承受的壓力，ERP強調業務流程，驅動程序強調軟硬件的兼容性。在做測試分析時需要根據軟件的特性來選取測試類型，并將其列入測試需求當中。
第三層：測試的焦點。測試的焦點是指根據所測的功能點進行分析、分解，從而得出 的著重于某一方面的測試，如界面、業務流、模塊化、數據、輸入域等。目前關于各個焦點的測試也有不少的指南，那些已經是很好的測試需求參考了，在此僅列出業務流的測試分析方法。
任何一套軟件都會有一定的業務流，也就是用戶用該軟件來實現自己實際業務的一個流程。簡單的來說，在做測試需求分析時需要列出以下類別：
1） 常用的或規定的業務流程
2） 各業務流程分支的遍歷
3） 明確規定不可使用的業務流程
4） 沒有明確規定但是應該不可以執行的業務流程
5） 其他異�；虿环弦幎ǖ牟僮�
然后根據軟件需求理出業務的常規邏輯，按照以上類別提出的思路，一項一項列出各種可能的測試場景，同時借助于軟件的需求以及其他信息，來確定該場景應該導致的結果，便形成了軟件業務流的基本測試需求。
在做完以上步驟之后，將業務流中涉及的各種結果以及中間流程分支回顧一遍，確定是否還有其他場景可能導致這些結果，以及各中間流程之間的交互可能產生的新的流程，從而進一步補充與完善測試需求。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
