功能測試的用例評審首先需要弄清楚功能測試的用例評審的目的：第一是為了減少測試人員執行階段做無效工作，如執行無效case，提交無效問題；第二是為了避免三方需求理解不一致；第三為了每個測試人員的質量標準與項目要求標準達成一致。

這樣才能測試出關鍵地方是否符合需求

第一、測試用例的好處：

1、 在開始實施測試之前設計好測試用例，可以避免盲目測試并提高測試效率；

2、 測試用例的使用令軟件測試的實施重點突出、目的明確；

3、 在軟件版本更新后只需修正少部分的測試用例便可展開測試工作，降低工作強度，縮短項目周期；

4、 功能模塊的通用化和復用化使軟件易于開發，而測試用例的通用化和復用化則會使軟件測試易于開展，并隨著測試用例的不斷精化其效率也不斷攀升；

5、測試用例構成了設計和制定測試過程的基礎。測試的“深度”與測試用例的數量成比例。由于每個測試用例反映不同的場景、條件或經由產品的事件流，因而，隨著測試用例數量的增加，對產品質量和測試流程的信心也會增強;

6、 測試工作量與測試用例的數量成比例。根據全面且細化的測試用例，可以更準確地估計測試周期各連續階段的時間安排；

7、測試設計和開發的類型以及所需的資源主要都受控于測試用例；

8、 測試用例通常根據它們所關聯關系的測試類型或測試需求來分類，而且將隨類型和需求進行相應地改變。最佳方案是為每個測試需求至少編制兩種測試用例：一種測試用例用于證明該需求已經滿足，稱作正向測試用例；另一種測試用例反映某個無法接受、反?；蛞馔獾臈l件或數據，用于論證只有在所需條件下才能夠滿足該需求，這種測試用例稱作反向測試用例；

第二、測試用例給誰看：

1、在計劃階段，項目管理人員就要根據測試用例(需要多少工作量，需要什么測試環境，需要什么測試人員等等)來制定測試計劃，合理安排工作任務;

2、在測試執行階段，測試人員要依據測試用例來指導測試工作，否則整個測試過程就是盲目的;

3、當測試人員發現問題時，開發有時也需要查看測試用例來判斷問題發生的背景；

4、 項目結束后，需要作為驗收成果交于客戶。

所以，測試用例在測試的整個過程當中起到了一個串聯的作用，是必不可少的。

? 1、測試思維不系統（沒有經過系統性培訓或專項訓練）--針對新人

? 2、個體思維局限（某些思維定勢導致測試點遺漏）--所有人

? 因此測試評審非常重要，目前我們的測試用例評審大部分是以項目維度在項目組內進行review，責任主體是開發，一般以郵件和會議的形式組織評審。這樣也能補充一些測試點，但是沒有一個完整的測試評審在線的流程約束，不是每個人都能進行前期的認真檢視并能提出有效的意見。另外僅依賴開發的review，很容易只從軟件設計實現的角度出發補充測試點，而不是從全局用戶角度出發來補充，可能還是會造成測試遺漏。

原因一：設計完成的測試用例要分配給每個人來設計具體數據，并實現自動測試。設計用例和實現用例、執行用例并非一人完成。設計用例的人并不知道用例在具體執行的時候是否有問題，或者哪些步驟不能實現自動測試。再者“測試是無窮盡的”，誰又能保證自己設計的用例能覆蓋完全？

　　原因二：測試人員總是抱怨測試出來Bug后與開發扯皮太多，主要的原因之一是測試人員和開發人員對于被測試功能的理解未達成一致。因此用例需要提交給開發人員check，并在測試開始之前對于測試目標的功能需求理解達成一致。用例一般比需求文檔更加具體，能更好的體現具體測試思路。如果在測試開始之前就提前和開發達成一致，那么在你發現爭議的bug的時候，就不用費勁解釋了，可以直接告訴他“用例評審的時候已經確認是這樣了?！?/p>

　　原因三：讓需求人員參與評審，她們能幫助你找出更多的問題。經常在測試的時候，有些細節是無法送需求文檔上得知的，需要頻繁來和需求人員溝通，問東問西，如果他們在忙，也許會產生這樣的心理“怎么連這個也不知道？”我們測試人員多委屈，吃苦不討好。所以在評審的時候讓需求人員明亮的眼睛多幫我們找出問題，解決疑問。

　　原因四：設計完成用例至少要讓Leader評審下，讓她理解你的思路，如果有問題也及早提出。不然當你測試的模塊出現問題的時候，Leader絕不會說都怪她當時沒review你的用例，責任還是在你身上。

　　原因五：現在有很多人是項目外包或人員外包，那么完成每一項工作的第一件事就是提交客戶評審，當然在提交給客戶前自己team先評審下最好，確保提交給客戶高質量的成功。

　　原因六：如果嚴格按照用例數量來計算工作量，真正測試A模塊需要200個用例，一周的時間，可是你卻由于某些誤差設計出100個case，那么評估出來3天的工作量，那么你就等著加班吐血吧。

第一是為了減少測試人員執行階段做無效工作，如執行無效case，提交無效問題；第二是為了避免三方需求理解不一致；第三為了每個測試人員的質量標準與項目要求標準達成一致。

每個測試工程師寫測試用例的時候或多或少都會遺漏一些測試點， 不是說他們能力不行，而是每個人的思維有局限性，通過測試、產品、開發一起評審，把沒有想到的測試點找出來??

俗話說:三個臭皮匠賽過諸葛亮,一個人的智慧有限,通過測試用例評審,就能夠匯聚集體的力量,別人可能會發現自己考慮不到的測試 點。 當局者迷,旁觀者清,