一、顯式需求與隱式需求
可以說，使用者需求是軟體測試的第一綱領，測試活動都應該圍繞軟體需求展開。我們可以將使用者需求分為顯式需求和隱式需求。顯式需求就是白紙黑字寫在需求文件上的，這往往是使用者要求直接實現的功能特性；隱式需求是需求文件沒有直接提及但是在軟體開發、測試等角度需要考慮的。顯式需求是硬性要求，是無論如何都要實現的部分，而隱式需求則要視實際情況而定，比如介面友好性、欄位檢查等，在需求中不一定提及，但是如果客戶對質量要求很高的話那在測試的時候需要考慮更多的隱式需求，反之則在保證顯式需求的前提下適度的考慮隱式部分。

如下面這個簡單的需求片斷：
“點選[申請]按鈕，在彈出的對話方塊中使用者能夠輸入電子郵件和使用者名稱並提交申請
(無配圖)”
欄位 資料型別 資料長度
姓名 字元 30
電子郵件 字元 50

由此我們可以分析出顯式需求如下：
1，新增一個按鈕，Label 為“申請”
2，點選[申請]按鈕開啟一個對話方塊(對話方塊大小、位置、標題、是否模態化等因素並未說明)。
3，對話方塊中有兩個欄位“電子郵件”和“姓名”(擺放位置、字型大小、顏色等未說明)。
4，兩個欄位的型別都是字元型，且指明瞭長度（電子郵件格式、姓名可否包含空格、是否要驗證必填、輸入超長時如何提示等未說明）。
5，對話方塊中至少有一個按鈕“提交”(關閉對話方塊的方式未提及)。 與之對應的隱式需求包括但不限於如下：
1，對話方塊的大小、位置要合理（與系統其它部分風格統一），標題參照其它部分或者合理處理。
2，“電子郵件”和“姓名”欄位在對話方塊中位置合理，字型大小顏色等與整個系統風格統一。
3，電子郵件要驗證格式，資料超長時凍結文字框（依據系統類似的處理），未輸入時提交彈出提示等。
4，需要有合理的關閉對話方塊方式(如新增“取消”按鈕、給對話方塊右上角新增關閉 功能)。

上面只是一個很簡單的例子, 所要表達的意思是，需求往往是並不十分明確的，因為有些時候就連使用者自己都不知道他想要怎樣，但是站在軟體測試者的角度來看，我們並不一定要將所有明確或不明確的需求都實現，但是我們需要清楚眼下的情況，甚至幫助使用者完善需求。

在實際軟體測試周期中，在需求階段通常的做法有：
1，對於很明顯很直接的使用者需求，可以直接轉化為測試需求；
2，對於使用者需求不明朗的部分，但是又必須弄明白的部分，進行確認；
3，對於使用者需求不明朗，但是又無關緊要的部分，可以酌情適當處理（依質量要求轉化為不同程度的測試需求）；
4，對於使用者明確提出的需求，需求之間存在邏輯或者業務上的衝突時，儘快確認。
當然，實際當中都得視情況而定，有些使用者需求確實寫得很完善，那可以直接用來
轉化為測試需求並體現在測試用例中，也有些需求寫得很粗糙，但是出於成本等因素考
慮，他們的質量要求或許並不高，那也可以放寬限度不去深究不明朗的部分。軟體測試並不是保證所有被測軟體都完美無暇，而是給使用者需要的。

二、理解需求忌管中窺豹
使用者需求的提出往往是為了實現某一完整的業務流程或功能，在分析理解使用者需求時也像寫作一樣，要先有一個框架在心裡，要先把握使用者的大概意圖、明確整個需求文件(或其它形式需求)的整體意思，在此前提下再去深入的細讀每個需求點才會更有利於理解使用者的真正需求。

  這樣做還有一點好處就是在後續的測試設計環節中能減少冗餘、優化測試過程。比如如果我們事先就通過大概瞭解整個需求而得知有幾個頁面的佈局和功能點有很多類似的地方，那我們就可以直接同時考慮這幾個相似頁面的情況設計公用的測試用例，同時在流程測試上也能相應的設計合適的測試流程。

  實際場景中就有些測試人員在拿到需求後，二話不說就逐行往下細讀並開始設計測試用例，這樣往往就造成對需求理解不到位、不全面，特別是在一些英文需求中，如果不瞭解大環境就開始設計測試用例，可能就會造成對需求的理解有較大偏差。

三、多站在使用者的角度思考
其實任何產品都一樣，做得再美好、再精緻、質量再高，如果不是使用者需要的那都白搭。當然這裡可能涉及到一些產品需求方面的東西，這裡主要是說對使用者已經提出了的需求的把握，既然都有需求了為什麼還會不明白使用者想要什麼呢？這裡就有點像是“傳話筒”遊戲，第一個傳話的人就是使用者的明確需求，然後經過產品需求人員的理解、落實在需求文件上、測試人員對需求文件的理解，這一輪過後往往是會造成一些偏差的，那作為最終把握質量關的測試人員如果能站在使用者的角度多思考，就能一定程式上抵消一些需求傳遞過程中的偏差，這就有利於設計更加合理的測試用例，並且儘早的發現需求中矛盾的地方，同時對於軟體提供者來說會變得不那麼被動。
軟體測試過程中基本上都要以測試用例做為參考和判斷依據，而清楚的理解需求是設計、完善測試用例的前提。當然，需求分析本身就已經可以認為是介入測試了，實際上往往很大一部分缺陷都是在需求階段暴露出來的，相反，如果因為在分析需求時就已經出現了理解偏差而最終導致所做非所需的質量問題，那就是很不應該的。