測試案例是貫穿了整個測試流程和專案研發流程的，用例也同時起著指導測試、保證質量度作用，因此用例至關重要。對於如何提高用例設計的質量，評審是必不可缺的一環。
很多測試同學都知道應該做測試案例評審，並且也樂意做需求評審，但是很少有測試同學總結過如何做案例評審。那麼最基本的案例評審應該從哪些方面著手呢？
在開始之前，再回顧一下測試案例的幾個要素。
測試案例的幾個要素分別是：測試環境、測試資料、測試目的、測試步驟、測試結果。這些要素缺一不可。另外還有案例分級、案例型別（ui、功能、相容等）、案例執行的階段（比如准入階段、整合階段等）。
不同的公司的案例模版會稍有差別，有的公司還會將案例跟自動化覆蓋程度結合，每一條案例對應的自動化覆蓋情況，以及自動化型別是基於**層的，還是介面層的，以及ui層的等等。這樣更容易評估公司的自動化覆蓋率。
評審的內容也基本上和測試案例的幾大要素相關，但是不管是什麼樣的案例模板，案例評審的第一步都應該是設計框架的評審。
設計框架
案例的整體設計框架，也就是案例的結構和模組劃分。一般我們都是以xmind來提前定結構，這樣評審時更容易直觀的看到結構樹和層級關係。如果乙個案例管理平台缺少視覺化的結構樹，那麼基本上可讀性是非常差合效率極低的。
設計框架可以從哪幾個維度看？
1、模組劃分合理性：即能包含所要測試的全部物件，又能夠不重複。
2、邏輯鏈路流暢性：乙個業務流程是順暢的，沒有阻斷的。
3、子屬關係正確性：主類、子類，並行關係、從屬關係要區分，不能在同一層級展現。
4、需求覆蓋完整性：顯性需求應該100%包含，**需求也應該能夠挖掘出來。開發實現涉及到的每個環節也需要考慮容易出錯的點。總之，不能只侷限於表面互動看到的東西。簡單來說，就是db層、**層、介面層和ui層，前後端均要覆蓋。
5、型別覆蓋全面性：前端、後端、ui、功能、效能、相容、埋點、介面、資料庫等。
拿乙個簡單的例子來講：通常的登入功能，包含賬戶密碼、手勢、人臉三種方式。
模組劃分：主類是登入，三種登入方式應該是互相並行的，並且歸屬於登入模組。
邏輯鏈路：對於任意一種登入方式，一定要包含輸入、校驗、結果整個完整的業務流程。
子屬關係：如果將手勢登入歸到註冊層級下面，明顯是不合理的。
測試目的
1、唯一性
一條案例應該有唯一乙個測試目的。
比如不能在測試字元型別是否合法的同時，再測試字元長度是否符合標準。原因很簡單，因為如果有多條測試目的，那麼一條通過，一條不通過時，你是打pass合適，還是打fail合適呢？如果打了fail，又怎麼根據案例數來評估回歸測試工作量呢。
2、明確性
3、簡潔性
比如繼續拿上個例子來講，有的小夥伴會將測試目的寫成：
案例詳情
1、測試環境：是充分必要的環境條件。
2、操作步驟：步驟需要具備連貫性、可執行性。
3、案例分級：p0-p4，一般來說，p0、p1、p2、p3案例的佔比分別為15%，35%，40%，10%，每一分級的案例佔比偏差不能大於5%。
新專案而言，p0為流程案例，p1為基本功能案例，p2深入邏輯規則測試的案例，p3為極限值、異常特殊場景案例。
4、預期結果：保證明確性、準確性，以及和需求一致性。
5、操作步驟：一般應該是3步左右，絕對不能超出5步。操作步驟超出3步時，就應當要思考案例是否有多個測試目的和多個對應的預期結果，已經不符合案例設計規範。
6、案例順序：應該將優先順序高重要模組的案例放到前面，異常和分級低的案例放到後面。優先順序越高的案例，執行的順序應該越優先。這樣一方面可以快速暴露問題，二是減少後期測試的壓力。優先順序通常是核心功能》次要功能，正向案例》逆向案例，常規場景》異常場景。
另外要注意語言的簡潔：簡潔的語言即能讓評審的聽眾快速讀懂案例，也能夠提高執行案例的效率。
對於詳細內容的審核，很多初學小夥伴容易混淆測試環境和操作步驟，這一點我是如何理解的呢？
假設使用者上傳乙個**到相簿中，需要測試上傳的功能本身，還需要考慮對不同網路的相容，還需要測試到不同網路的效能。
那麼除了針對網路相容測試的case，網路的型別和設定是作為操作步驟以外，其他的非專門測試網路的case中應該將網路連通性作為測試環境而非作為操作步驟。試想如果每一條案例裡都將網路連通性作為第乙個測試步驟，冗餘量是得有多大，並且稍微有常識的使用者都知道，我要上傳成功，我的前提是網路連通。
【示例】
下方是專案中之前進行案例設計時做到乙個小練習。
較好較差
較差一版腦圖存在的問題：
評審流程
結合到評審流程和參與的人來看。
設計框架評審：一般來說要求測試全組參與、專案組全部參與，一方面能夠快速看到設計者的測試思路，另一方面避免出現大的設計遺漏。
xss初試 簡單測試
跨站指令碼攻擊 cross site scripting 為不和層疊樣式表 cascading style sheets,css 的縮寫混淆，故將跨站指令碼攻擊縮寫為xss。惡意攻擊者往web頁面裡插入惡意script 當使用者瀏覽該頁之時，嵌入其中web裡面的script 會被執行，從而達到惡意攻...
靜態測試之評審
評審包括管理評審 審查 技術評查 走查和非正式評審等不同評審技術。評審的通用過程由以下6個階段組成。1 計畫階段 選擇評審員並分配角色 為正式的評審型別規定評審的入口和出口準則，以及選擇需要評審的文件和文件章節等 2 預備會階段 分發文件，向評審參與者解釋本次評審的目標 過程和文件，以及核對入口準則...
測試基礎 同行評審
同行評審 1.是由開發軟體產品作者以外的其他人檢查工作產品，以發現缺陷並尋找改進的機會 評審方法是評審參與者通常採用一行一行仔細閱讀被評審物件的形式發現被測物件中的缺陷 評審的時間點一般設在工作產品到達了乙個完成的里程碑並即將進入下乙個開發階段時 2.同行評審一般包括審查 小組評審 走查 桌面評審 ...