我們來打個比方，經常會有人這麼問，我想買台電腦，有什麼推薦嗎？這個時候，我們就能馬上給出一個推薦嗎？我們是否還應該問問這些問題：
1）主要用途是什麼？
2）桌上型電腦還是筆記本？
3）預算多少？
4）對品牌有什麼要求？
……
在這些問題都有答案之後，我們才能幫着去推薦。也就是說，通過這些問題，我們才能真正了解對方的需求。同樣的，我們做測試工作，産品需求也不等于是測試需求。沒有測試需求分析，會導緻我們的資訊不完整、不準确，無法對所測産品有一個清晰全面的認識。是以，我們要先進行測試需求分析，在這個基礎上，再進行後面的測試設計，測試計劃等工作。
當然，工作中難免會遇到并不“完美”的需求文檔，比如牽一發而動全身不清楚的互動邏輯，子條目頻繁的變更，交流缺失導緻的歧義，都會讓測試在項目推進中手足無措。呐這篇文章就是想和你一起讨論，當我們閱讀需求文檔時，我們都需要了解啥。
在閱讀需求文檔之前，我們要對項目或者功能本身有一個宏觀的認識，目前項目追求的是什麼，是與時俱進快速疊代的更新速度，還是穩中求勝的代碼品質，還是耳目一新的智能化設計，明确這些有助于我們在測試中有明确的重心。站在宏觀的角度看需求文檔，主要是明确需求的合理性和優先級，是針對需求整體作用進行的評審，如果整體的方向錯誤，那麼細節上也沒有再讨論的意義了。
在合理性的意義上，通讀需求文檔，從客觀的角度出發，應有一整套合理、公正、客觀、完善的需求文檔的評價體系去保證需求品質。更多的時候我們也要換位思考，站在使用者的角度，去評價需求文檔解決的痛點是什麼，是否符合使用者需求；解決的這個需求會不會隻考慮到小範圍的使用者，進而影響到大衆關注的邏輯，更應站在開發的角度去評估，在效率、效果上是否可行，在技術上實作是不是會有阻礙。如果這個需求的涉及到的資源緊張，那麼這個需求和其他需求的優先級又該怎麼取舍，都是應該在需求評審時，首先應該考慮到的。
站在完整性的角度看需求文檔，實際上是将目前的負責的項目子產品化（或者抽象化），根據功能的需求确定功能的影響範圍，再細化，同時對比需求文檔，這樣對目标的操作有個明确的預期結果。
1）結構化項目流程
以核心為例，無論是功能類的需求、品質類的需求還是解決使用者回報的需求，都可以把這些需求抽象成為操作（增、删、改）、查詢兩個大模式。要麼是純查詢類需求（即刻俊譯），要麼就是兩者結合操作類+查詢類（靈犀）。在這裡有些看起來是純操作類的需求（删詞），但是實際上要通過查詢的方式才能生效在這裡就不單獨作為一個模式贅述。
2）确認影響子產品
比如一個純查詢類的功能需求，我們通過以上的圖就可以知道，整個過程影響我們的因素有：
1、使用者輸入
例如：
1） 類型（中文、漢字、英文、數字、不支援編碼、表情、符号）
2） 長度（最短、最長）
3） 異常輸入
2、查詢條件
1）完全比對查詢、部分比對查詢（簡拼、暴力）
2）需求中定義的查詢規則（比對規則、優先級邏輯）
3、 查詢内容
這裡的查詢内容指的是被查詢内容的特性，存在/不存在，同步/異步，正常/異常，或某些需求文檔中指明的情況
4、效果展示
例如 :
1）展示位置
2）排序優先級
3）展示個數
4）标記情況等
3）考量綜合因素
這裡的外界影響因素，指的是其他外界因素，有可能改變這四個過程中的某些因素，比如開啟繁體下會改變使用者輸入，比如當使用者關閉使用者詞會使使用者詞查詢内容失效，再比如某些固排的詞會影響效果展示。
還有一些效果性的需求，比如提高查詢效率，我們知道這個功能隻需要改動查詢條件就可以，但是在需求文檔中也應明确是否有使用者輸入和查詢内容的限制。當然這些綜合考量離不開測試人員項目知識的掌握程度、在這裡建議（類比相似功能、總結記錄（bug、特殊）以及用例評審去提升綜合因素的覆寫度）。
将以上因素排列組合和歸納，再對比需求文檔，我們就可以知道某種特定的輸入下，有哪些預期結果，那這些預期結果到底好不好，這就涉及到需求細節的合理性、明确性以及優先級。
合理性的驗證也需要從使用者行為和開發行為兩個角度去進行分析，細節是否合理到位。比如之前出現過的需求中，上屏标點後，再輸入上屏不會自動補空格。我們找了一篇英文文章去輸入體驗，發現每次上屏标點後，都需要手動輸入一個空格，再輸入其他詞條，這樣的體驗肯定不是使用者想要的，是以會針對這種現象提出需求建議，再比如某些效果需求的時候，罰分與其他功能沖突，都是我們期待在需求分析階段發現的。
明确性是需求閱讀中的痛點，因為閱讀的時候人都是主觀的，是以很難有這個明确性的意識。經常出現問題的地方是歧義和沒有限制。在這裡我對歧義的建議是多次閱讀，特别是那些覺得非常拗口的地方，往往都是問題頻發的根源。限制的問題往往依賴個人經驗，比如鍵盤類型的限制以及異常校驗的限制等。
優先級某些需求項與已有功能有“沖突”，針對這些需求項，是否明确了優先級，并評估優先級的合理性。
需要注意的是，合理性、明确性以及優先級的相關的影響因素是在完善性的考量中确定的，是以結構化項目流程，明确影響因素範圍尤其重要。
最後一個是在閱讀需求文檔後會被頻繁讨論的事情，值得大家深入思考。
一般來說常見的有兩種問題：
1）測試和開發的成本比較高，難以比對目前的産品進度。
2）當目前的已有測試手段不能有效保證功能的品質。
針對這兩種問題，我的建議是嘗試變更測試方案，提出對被測試需求的多種測試政策，并在每種方案後标注測試成本和風險，并将方案與合作方讨論，選擇大家都可以接受的方案進行調整。
以上就是我的一些閱讀需求文檔的經驗，可能每一個測試同學對應的項目不同，抽象出來的流程不同，思考和解決的方式也不同，歡迎在下面分享經驗，與大家讨論，如何進行需求分析。
程式員二黑