一、顯式需求與隱式需求
可以說，用戶需求是軟件測試的第一綱領，測試活動都應該圍繞軟件需求展開。我們可以將用戶需求分為顯式需求和隱式需求。顯式需求就是白紙黑字寫在需求文檔上的，這往往是用戶要求直接實現的功能特性；隱式需求是需求文檔沒有直接提及但是在軟件開發、測試等角度需要考慮的。顯式需求是硬性要求，是無論如何都要實現的部分，而隱式需求則要視實際情況而定，比如界面友好性、字段檢查等，在需求中不一定提及，但是如果客戶對質量要求很高的話那在測試的時候需要考慮更多的隱式需求，反之則在保證顯式需求的前提下適度的考慮隱式部分。
如下面這個簡單的需求片斷：
“點擊[申請]按鈕，在彈出的對話框中用戶能夠輸入電子郵件和用戶名並提交申請
(無配圖)”
字段 數據類型 數據長度
姓名 字符 30
電子郵件 字符 50
由此我們可以分析出顯式需求如下：
1，添加一個按鈕，Label 為“申請”
2，點擊[申請]按鈕打開一個對話框(對話框大小、位置、標題、是否模態化等因素並未說明)。
3，對話框中有兩個字段“電子郵件”和“姓名”(擺放位置、字體大小、顏色等未說明)。
4，兩個字段的類型都是字符型，且指明了長度（電子郵件格式、姓名可否包含空格、是否要驗證必填、輸入超長時如何提示等未說明）。
5，對話框中至少有一個按鈕“提交”(關閉對話框的方式未提及)。 與之對應的隱式需求包括但不限於如下：
1，對話框的大小、位置要合理（與系統其它部分風格統一），標題參照其它部分或者合理處理。
2，“電子郵件”和“姓名”字段在對話框中位置合理，字體大小顏色等與整個系統風格統一。
3，電子郵件要驗證格式，數據超長時凍結文本框（依據系統類似的處理），未輸入時提交彈出提示等。
4，需要有合理的關閉對話框方式(如添加“取消”按鈕、給對話框右上角添加關閉 功能)。
上面只是一個很簡單的例子, 所要表達的意思是，需求往往是並不十分明確的，因為有些時候就連用戶自己都不知道他想要怎樣，但是站在軟件測試者的角度來看，我們並不一定要將所有明確或不明確的需求都實現，但是我們需要清楚眼下的情況，甚至幫助用戶完善需求。
在實際軟件測試周期中，在需求階段通常的做法有：
1，對於很明顯很直接的用戶需求，可以直接轉化為測試需求；
2，對於用戶需求不明朗的部分，但是又必須弄明白的部分，進行確認；
3，對於用戶需求不明朗，但是又無關緊要的部分，可以酌情適當處理（依質量要求轉化為不同程度的測試需求）；
4，對於用戶明確提出的需求，需求之間存在邏輯或者業務上的沖突時，盡快確認。
當然，實際當中都得視情況而定，有些用戶需求確實寫得很完善，那可以直接用來
轉化為測試需求並體現在測試用例中，也有些需求寫得很粗糙，但是出於成本等因素考
慮，他們的質量要求或許並不高，那也可以放寬限度不去深究不明朗的部分。軟件測試並不是保證所有被測軟件都完美無暇，而是給用戶需要的。
二、理解需求忌管中窺豹
用戶需求的提出往往是為了實現某一完整的業務流程或功能，在分析理解用戶需求時也像寫作一樣，要先有一個框架在心里，要先把握用戶的大概意圖、明確整個需求文檔(或其它形式需求)的整體意思，在此前提下再去深入的細讀每個需求點才會更有利於理解用戶的真正需求。
這樣做還有一點好處就是在后續的測試設計環節中能減少冗余、優化測試過程。比如如果我們事先就通過大概了解整個需求而得知有幾個頁面的布局和功能點有很多類似的地方，那我們就可以直接同時考慮這幾個相似頁面的情況設計公用的測試用例，同時在流程測試上也能相應的設計合適的測試流程。
實際場景中就有些測試人員在拿到需求后，二話不說就逐行往下細讀並開始設計測試用例，這樣往往就造成對需求理解不到位、不全面，特別是在一些英文需求中，如果不了解大環境就開始設計測試用例，可能就會造成對需求的理解有較大偏差。
三、多站在用戶的角度思考
其實任何產品都一樣，做得再美好、再精致、質量再高，如果不是用戶需要的那都白搭。當然這里可能涉及到一些產品需求方面的東西，這里主要是說對用戶已經提出了的需求的把握，既然都有需求了為什么還會不明白用戶想要什么呢？這里就有點像是“傳話筒”游戲，第一個傳話的人就是用戶的明確需求，然后經過產品需求人員的理解、落實在需求文檔上、測試人員對需求文檔的理解，這一輪過后往往是會造成一些偏差的，那作為最終把握質量關的測試人員如果能站在用戶的角度多思考，就能一定程序上抵消一些需求傳遞過程中的偏差，這就有利於設計更加合理的測試用例，並且盡早的發現需求中矛盾的地方，同時對於軟件提供者來說會變得不那么被動。
軟件測試過程中基本上都要以測試用例做為參考和判斷依據，而清楚的理解需求是設計、完善測試用例的前提。當然，需求分析本身就已經可以認為是介入測試了，實際上往往很大一部分缺陷都是在需求階段暴露出來的，相反，如果因為在分析需求時就已經出現了理解偏差而最終導致所做非所需的質量問題，那就是很不應該的。