需求評審之實戰演練
我在面試時，經常會出一道簡易計算器需求的編程題，完了之後再讓寫一下這個需求的用例，題目看起來很簡單，但是幾乎可以把我想了解到的基礎測試理論全部都涵蓋了。
今天我還拿這個例子來實操下在《測試人員參與需求評審的價值是什麽？》中提到的需求評審關註點。
比如我現在是產品的角色，我給的需求描述是這樣的：
現在有一個 PC 客戶端的命令行工具，這個工具可以接收三個命令行參數，其中，前兩個是數字，最後一個是運算符，運算符只支持加減乘除四種，工具的功能就是把前兩個數字使用運算符做下運算，然後輸出運算結果。
下面是模擬針對這個需求的需求評審。
二
先是需求合理性的討論。
測試：「命令行的計算器，幹嘛用的，為啥不用系統自帶的計算器？」
測試：「為啥是命令行工具？命令行的可控性太差，建議改成 GUI 實現。」
產品：「本次針對的是特定的 Geek 群體，習慣於命令行操作，而且市面上已經有很多 GUI 的實現工具了。」
測試：「前面兩個是數字，最後是運算符，不太符合操作習慣，建議把運算符放中間。」
產品：「恩，這個我們回去考慮下。」
測試：「確定只需要支持加減乘除麽？是不是功能太弱了？」
產品：「這是第一版叠代，後面會根據用戶需求再酌情擴展，所以這地方開發記得別寫死了。」
只是做了下簡單的需求合理性討論，就變更了一次需求---參數位置的問題，同時讓開發在功能實現時提前考慮了可擴展性，這些問題如果是在測試階段提出來，大部分的可能是先不動了，不然又得改代碼，如果真的改，開發和測試的工作量都會相應增加，如果不改就會增加下次叠代時候的工作量，總之，早提出需求合理性討論，有百利而無一害。
三
接著是需求全面性的討論。
測試：「最大支持的運算數是多少？」
產品：「浮點型的最大值就行。」（懂技術的產品都是好產品。）
測試：「工具是每次運行後只做一次運算，還是一次運算結束可以繼續接收新的參數輸入？」
產品：「第一版不做太復雜，每次都需要重新執行，只接收直接執行時候的參數傳入。」
測試：「三個參數之間用什麽分隔？」
產品：「空格或逗號，兩個都支持。」
測試：「這個得有個說明吧，不然用戶會傻傻分不清。」
產品：「對，如果參數格式錯誤輸出一個使用說明的提示。」
測試：「如果缺少參數提示什麽錯誤信息呢？」
產品：「提示說，你輸入的參數個數不正確，請按照 [運算數 運算符 運算數] 的格式輸入。」
測試：「如果參數類型錯誤提示什麽錯誤信息呢？」
測試：「這個提示不明確吧？參數類型不支持，那具體支持哪些類型呢？用戶還是會懵逼呀。」
產品：「那改一下，你輸入的參數類型不正確，運算數只支持浮點型，運算符中只支持+-*/，分隔符支持空格和的逗號。」
測試：「如果除數為零，提示什麽錯誤信息呢？」
產品：「提示說，你輸入的除數為零，請重新輸入。」
除了一個主分支的問題，其他的都屬於旁支，旁支是對主分支的補充和完善，也是大家最容易忽視的地方，也是用戶環境最容易出現問題的地方。
四
怎麽樣？這麽簡單一個 if 語句就可以搞定的需求，竟然可以提出 12 個有效問題，如果這些是在測試過程中提出，考慮下每個問題從提出到產品確認，然後開發修復，然後測試驗證，這過程的損耗有多大，而如果是在需求評審階段提出的話，開發就可以完全按照既定的需求，提前考慮各種場景的處理，極大的減少了需求變化造成的溝通和返工成本。
然後再羅嗦一句，面試過程中會發現很多人自己寫的代碼，會被自己之後寫的測試用例測的漏洞百出，就比如除數為零的考慮吧，如果我們從測試的角度寫用例，很多人都能考慮到，但是寫代碼呢，99% 的人都沒處理，當然不排除一部分人是面試時候的簡單實現，但是仍然能說明開發思維和測試思維的差異性，所以我想說的是：
1.作為測試，我們對開發的要求，自己盡量也以身作則，這樣才能從開發的角度上更好的和開發溝通；
2.作為開發，20% 的代碼做實現，80% 的代碼處理異常，是很正常的事，所以請不要等 bug 上來了才去處理異常；
3.作為產品，要考慮到所有可能出現的和用戶交互的地方，對於細節的處理，一直都是作為產品功底的體現，這也是為什麽彩蛋稱之為彩蛋，盡可能不要讓它變成臭蛋。
五
好了，這次是從一個簡單的需求著手，說說關於需求評審的兩個關註點，可以想象一下，如果是比較大的需求，測試要提出的問題會很多，那麽就需要考慮一些策略的問題了，比如分批次進行評審，每一次評審確定下合理的顆粒度，方便大家聚焦，但是不管怎麽說，測試參與需求評審的作用是很大的。
別看上面的例子簡單，可能也還有我沒考慮到的點呢，如果你有補充的內容，歡迎給我留言。
本文首發於公眾號「sylan215」，十年測試老兵的原創幹貨，關註我，漲姿勢！
需求評審之實戰演練