前言

軟件評審，IEEE定義為‘一種對軟件元素所做的正式的、同行間的評審活動，其目的在于驗證軟件元素滿足其規格說明，并能符合標準的要求’。CMMI中要求按照已文檔化的規程在所選擇的項目里程碑處（階段成果物）進行正式評審，通過此活動評價軟件項目的完成情況和結果。只有前一階段的輸出物通過驗證評審無誤后，才能開展后續活動。階段評審活動可根據實際軟件生產活動的需求定期或臨時發起。階段評審通常從項目的人力資源、物力資源、資金狀況、風險、技術、規模、進度等因素評審項目的狀態并確定軟件生產活動是否可以進入下一階段。在一般的公司中，最重要的是軟件需求評審會議，根據需求規格說明書，開發需要了解和評估是否在技術上實現同時進行進一步的溝通具體細節，測試人員需要了解業務，以便盡早進入業務中，可以根據的工作經驗和開發了解開發的思路以及其他細節，在這個溝通中非常重要，可以發現開發沒有考慮的因素在里面。

除此之外還有一個是測試人員的用例評審，因為大一點的公司開發人員會拿測試人員的用例先進行自測，然后再交給測試人員進行測試，測試人員對用例評審主要加深業務的了解，同時可以知道測試用例的覆蓋度等。

一、評審前需要做哪些準備工作

1、需求評審結束后，就可以著手把需求拆分為功能點 。

工具：建議用XMind，需包含預期結果和測試結果，Android和iOS測試結果可用標簽區分標注。 優點：用畫思維導圖的方式，邏輯清楚，便于評審人員（產品和開發人員）快速查看，評審效率高。這里需要說明的是，很多測試者喜歡用Excel設計用例，我也不例外，但是根據一段時間的試驗，和開發產品溝通后，大家都覺得用XMind寫思維導圖的方式更好，看起來更便捷。所以具體用什么工具方法，大家可依個人愛好而定，不過目標是一樣的，讓用例評審高效快捷的開展，并產生價值。

2、把功能點再分解為具體的測試用例 。

這里需在思維導圖上補全預期結果和實際測試結果，便于測試結果跟進。

3、用例寫完后，自己先做好自檢，自檢中，針對有疑問的點羅列出來，可事先跟產品開發討論，確定結果后完善用例，仍有疑問的可先做標記，評審會上拋出一起討論。

4、和評審人員（開發和產品）確定好具體的評審時間并提前把測試用例發給參會人員查看。

二、用例評審參加人員

主要是產品、開發（客戶端和后端）、測試、項目負責人、運營。注：以上人員為必須參加人員，其他和項目質量、進度有關人員，根據實際情況可邀請參加。

三、用例評審時間

對于敏捷開發項目，建議控制在半小時以內。如果你認為需求復雜，功能點太多，半小時講不完，那么建議你對功能點劃分優先級，優先評審優先級高的用例，再針對疑問多的用例評審，最后對于功能簡單的用例可簡單帶過。時刻記住我們用例的評審目標，不能流于形式。

四、用例評審的形式

1、對照測試用例，從上而下，從左到右，逐條念。

這是目前很多公司的做法，如果你也這么做過，相信你并不一定喜歡這種方式，因為它費時，不分主次，參會人員的熱情與注意力逐漸降低，整個用例評審效率低，作為主持人也講的口干舌燥，事倍功半。

2、先對功能復雜，優先級高，疑問多的用例進行評審，再評審功能簡單，優先級低的功能點。

對于評審過程中，一時半會沒有結論的問題，可以記錄下來，作為會后討論跟進的重點。這種做法，有很多優點，評審剛開始的一段時間，大家注意力集中，參與激情高，這段時間討論有難度有疑問的問題，效率高。最重要的事最先做。另外，整個評審會主次分明，有高潮有緩點，可以更高效的達到我們評審的目的。

總結

以上是生活随笔為你收集整理的产品经理学习总结（3）——测试用例的需求评审的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。