前言
大家好，我是IT小學生蔡坨坨。
前些日與朋友聊天，談及需求評審，作為測試人員，我們應該在需求評審會議上做些什麼？
記得第一次參加需求評審，傻傻的過去坐著，然後聽別人巴拉巴拉說半天，自己一頭霧水、一臉懵逼，會後又花大量的時間看需求，等到提測的時候可能需求都沒怎麼搞明白……
那麼問題來了。怎樣能夠讓需求評審更高效呢？作為測試人員又如何在其中發揮價值呢？
首先參與評審的可能是產品、開發、測試，時間一般控制在1個小時左右，如果過長，如兩三個小時可能就不是很高效，如果過短，對於稍微大一點的需求一些詳細的點就可能沒有考慮到。
需求評審
會議前：
進行需求評審之前，產品經理一般會給到需求相關資料，像我們公司會由產品經理建一個jira單，單子上附有客戶背景、客戶需求、產品方案、PRD、原型圖等。我們需要提前閱讀相關文件，深刻理解需求，對於有疑問的點提前標註出來，然後在開會的過程中積極地去參與這個會議，丟擲疑問點。除了關注功能要求，還需要關注資料型別、介面定義、效能要求、安全性等，這個根據具體業務進行評估，像我們公司是做電子合同業務的，就會考慮檔案縮圖頻繁請求、加蓋印章過多等是否會導致效能問題。同時還需要考慮一些隱性需求。
會議中：
- 需求澄清的時候不要在會議上面玩手機或者幹其他事情，因為如果需求理解不深刻，後面測試相關的工作就很難開展。如：不能正確編寫測試用例，找不準測試點，業務相關知識串不起來等。
- 需求中產品設計不合理、很難理解、邏輯有問題、以及可能影響原功能的地方，對於這些點我們要丟擲疑問進行澄清，從而推動產品進行修改，最終達成一致。
- 需求中沒有被量化的點，例如：某個功能涉及的欄位型別、長度和規則，如：標題欄位型別為普通文字，長度為100個字元、手機號欄位應該符合規範，首位為1，11位數字。為什麼需要量化？因為只有量化之後，才有利於測試後續用例的編寫，測試才有可能用等價類、邊界值進行用例設計，開發才能進行一些資料庫欄位的設計（如varchar（11）、int、bigint）。
- 思考需求中的測試點，影響我們做測試的地方讓產品經理給出說明，比如這種異常情況怎麼處理？有多少種狀態？狀態之間如何轉化？總之就是影響我們測試的地方都要讓產品經理給出說明，這樣給我們後面寫測試設計和測試用例掃清障礙。
會議後：
- 評審結束之後，需要把一些待確認的地方整理併發出來。
- 經過評審會議的討論，可能會有需求點發生了變更，這時就需要讓產品將最新的PRD整理完整重新發出來，再對修改的地方進行確認。
成果
經過以上需求評審，你會得到什麼？
- 符合軟體測試的原則，“測試應該儘早進行，最好在需求階段就開始介入，因為最嚴重的錯誤不外乎是系統不能滿足使用者的需求”，從而在產品初期幫助整個團隊避免很多的錯誤。
- 充分理解被測需求，深刻熟悉被測業務，為後續測試工作的開展、測試用例的編寫掃清障礙。