這是《落葉》文集里第?162?片落葉，希望你能喜歡，不為別的，只為這份堅持。
【背景】
同學 A 問：作為測試小組的組長，項目下來之后，我們怎么評估測試所需要的時間呢？評估點包括哪一些？是否有一個行業標準可供參考？
同學 B 問：前兩天去面試，面試官問，當你拿到一個產品需求后，怎么去把它拆分成你想要的測試點。
我之所以把這兩個問題放到一起回答，是因為我認為第一個問題的解答涵蓋了第二個問題的解答。
【你問】
如何做好項目的測試工作量評估？
【我答】
估算方法常用的有幾種：
1. 功能點估算，這種是在項目管理里中相對估算較準的，但耗時較長，一般也需要經過相應的培訓和練習；
2. 經驗法，也叫類比估算法，常用于同類型項目，或復雜度也相差不大的項目，參考歷史項目數據估算；
3. 三點估算，給出最可能、最樂觀和最悲觀的三個值，用加權平均公式可以算出一個相對合理的估算值；
我們常用的方法應該是幾者的結合：
粗評：
剛拿到項目或任務時，會用經驗法和三點估算法得出一個粗略的評估。
這個根據你自己實際的項目環境而定是否需要，我做粗評的目的，是用于跟技術總監討論項目計劃，根據既定的發布時間反推最晚的提測時間或者是結合開發的評估估計最早能發布的日期；。
細評：
細評就是基于確定的需求范圍或任務范圍，已經研讀過一遍需求文檔或任務范圍說明書，且沒有什么大的疑問或不確定范圍了。
我們常用 WBS 法，自上而下地將需求或任務分解開來，基本步驟如下：
樹狀結構的第一層：把需求功能點分解出來，也許子功能點較多，這里也可以分解成兩層，第一層是大模塊或分類，第二層是子模塊或功能點；
第二層：針對每個功能點，從不同維度去分解場景，常見維度有：UI，交互，業務邏輯，數據檢查，異常容錯等，還有一些維度，比如有些跟服務端有頻繁數據請求的頁面或增刪改的功能點還需要考慮性能維度，安全維度；
第三層：針對每個功能點基于不同的測試維度，分解成具體的測試點。這一層的所有測試點你就可以看作一個一個的工作包了，能夠分配給具體的工程師去估算并做用例設計了；
到這一步，其實就已經回答了 B 同學的問題了，接下來我們再看基于這個樹狀結構圖怎么得出測試時間的估算。
有兩種方法：
第一種：估算出第三層所有測試點的測試時間，相當于自下而上就得出了總的測試點人日估算；
第二種：我們可以將第三層的每個測試點看作大小相當的工作包，那么每個所需的測試時間應該相差也不會太大。我們估算出一個工作包大概需要0.2個人日，那總的測試點人日估算 = 0.2 * 測試點個數；
到此為止，同學 B 的問題也回答完畢了。
但是，在實際的項目中，測試工作量其實還要加上下列幾項內容：
1. 需求討論；
2. 項目相關會議；
3. Bug的驗證和回歸測試；
4. 其它臨時任務；
你可以給上述每一項都做個人日估算，加到最后的總人日里，也可以不細分上面那些項，而是在總的估算基礎上多算20%加入最后的人日里，相當于預留了20%的buffer。
工作量估算建議最好拆分成設計階段和執行階段兩部分，這樣會便于制訂測試計劃，根據不同階段的起始和結束時間來計算所需人力資源數量。
比如你設計階段有5天，你評估量為10人日，而你執行階段有10天，但評估測試量是100人日。
如果你算總賬，那你總人日是110，時間是15天，你就需要7～8名測試人員，但實際上，你在設計階段只需要3個人，而執行階段你卻需要10個人。
同時，分階段評估，也便于你在每個階段做進度跟蹤。
《測試路上你問我答》里的?Q&A 27，如果是你要的，甚好！如果不是，你問，我答！
作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵
