一

我在面試時，經常會出一道簡易計算器需求的程式設計題，完了之後再讓寫一下這個需求的用例，題目看起來很簡單，但是幾乎可以把我想了解到的基礎測試理論全部都涵蓋了。

今天我還拿這個例子來實操下在《測試人員參與需求評審的價值是什麼？》中提到的需求評審關注點。

比如我現在是產品的角色，我給的需求描述是這樣的：

現在有一個 PC 客戶端的命令列工具，這個工具可以接收三個命令列引數，其中，前兩個是數字，最後一個是運算子，運算子只支援加減乘除四種，工具的功能就是把前兩個數字使用運算子做下運算，然後輸出運算結果。

下面是模擬針對這個需求的需求評審。

二

先是需求合理性的討論。

測試：「命令列的計算器，幹嘛用的，為啥不用系統自帶的計算器？」 產品：「恩，目前是演示環節，先不用考慮使用者，請忽略這個問題。」 測試：「為啥是命令列工具？命令列的可控性太差，建議改成 GUI 實現。」 產品：「本次針對的是特定的 Geek 群體，習慣於命令列操作，而且市面上已經有很多 GUI 的實現工具了。」 測試：「前面兩個是數字，最後是運算子，不太符合操作習慣，建議把運算子放中間。」 產品：「恩，這個我們回去考慮下。」 測試：「確定只需要支援加減乘除麼？是不是功能太弱了？」 產品：「這是第一版迭代，後面會根據使用者需求再酌情擴充套件，所以這地方開發記得別寫死了。」

只是做了下簡單的需求合理性討論，就變更了一次需求—引數位置的問題，同時讓開發在功能實現時提前考慮了可擴充套件性，這些問題如果是在測試階段提出來，大部分的可能是先不動了，不然又得改程式碼，如果真的改，開發和測試的工作量都會相應增加，如果不改就會增加下次迭代時候的工作量，總之，早提出需求合理性討論，有百利而無一害。

三

接著是需求全面性的討論。

測試：「最大支援的運算數是多少？」 產品：「浮點型的最大值就行。」（懂技術的產品都是好產品。） 測試：「工具是每次執行後只做一次運算，還是一次運算結束可以繼續接收新的引數輸入？」 產品：「第一版不做太複雜，每次都需要重新執行，只接收直接執行時候的引數傳入。」 測試：「三個引數之間用什麼分隔？」 產品：「空格或逗號，兩個都支援。」 測試：「這個得有個說明吧，不然使用者會傻傻分不清。」 產品：「對，如果引數格式錯誤輸出一個使用說明的提示。」 測試：「如果缺少引數提示什麼錯誤資訊呢？」 產品：「提示說，你輸入的引數個數不正確，請按照 [運算數 運算子 運算數] 的格式輸入。」 測試：「如果引數型別錯誤提示什麼錯誤資訊呢？」 產品：「提示說，你輸入的引數型別不支援，請重新輸入。」 測試：「這個提示不明確吧？引數型別不支援，那具體支援哪些型別呢？使用者還是會懵逼呀。」 產品：「那改一下，你輸入的引數型別不正確，運算數只支援浮點型，運算子中只支援±*/，分隔符支援空格和的逗號。」 測試：「如果除數為零，提示什麼錯誤資訊呢？」 產品：「提示說，你輸入的除數為零，請重新輸入。」

除了一個主分支的問題，其他的都屬於旁支，旁支是對主分支的補充和完善，也是大家最容易忽視的地方，也是使用者環境最容易出現問題的地方。

四

怎麼樣？這麼簡單一個 if 語句就可以搞定的需求，竟然可以提出 12 個有效問題，如果這些是在測試過程中提出，考慮下每個問題從提出到產品確認，然後開發修復，然後測試驗證，這過程的損耗有多大，而如果是在需求評審階段提出的話，開發就可以完全按照既定的需求，提前考慮各種場景的處理，極大的減少了需求變化造成的溝通和返工成本。

然後再羅嗦一句，面試過程中會發現很多人自己寫的程式碼，會被自己之後寫的測試用例測的漏洞百出，就比如除數為零的考慮吧，如果我們從測試的角度寫用例，很多人都能考慮到，但是寫程式碼呢，99% 的人都沒處理，當然不排除一部分人是面試時候的簡單實現，但是仍然能說明開發思維和測試思維的差異性，所以我想說的是：

1.作為測試，我們對開發的要求，自己儘量也以身作則，這樣才能從開發的角度上更好的和開發溝通； 2.作為開發，20% 的程式碼做實現，80% 的程式碼處理異常，是很正常的事，所以請不要等 bug 上來了才去處理異常； 3.作為產品，要考慮到所有可能出現的和使用者互動的地方，對於細節的處理，一直都是作為產品功底的體現，這也是為什麼彩蛋稱之為彩蛋，儘可能不要讓它變成臭蛋。

五

好了，這次是從一個簡單的需求著手，說說關於需求評審的兩個關注點，可以想象一下，如果是比較大的需求，測試要提出的問題會很多，那麼就需要考慮一些策略的問題了，比如分批次進行評審，每一次評審確定下合理的顆粒度，方便大家聚焦，但是不管怎麼說，測試參與需求評審的作用是很大的。

別看上面的例子簡單，可能也還有我沒考慮到的點呢，如果你有補充的內容，歡迎給我留言。

本文首發於公眾號「sylan215」，十年測試老兵的原創乾貨，關注我，漲姿勢！