測試用例評審是QA日常工作流程中的關(guān)鍵一環(huán)，是QA同學完善測試用例、交流測試經(jīng)驗的好機會。
負責組內(nèi)測試用例建設以來，作者對于評審流程做了一些優(yōu)化工作。本文作者將整個優(yōu)化過程中的心得體會做了一個總結(jié)，希望能給大家?guī)韼椭?/p>

01 原始流程
1. 原始流程
首先介紹一下我們組原本的用例評審流程：
1、通知用例評審會議，大家到會議室集合。

2、用例負責人現(xiàn)場講解用例，同時記錄大家提出的問題。

3、會后用例負責人根據(jù)自己記錄的問題修改用例。

2. 存在的問題
按照這個流程執(zhí)行下來，用例評審的效果并不理想，整理了一下存在的問題：

1、評審開始前，用例缺乏預審。如果遇到質(zhì)量不太理想的用例直接在會議上展示，評審效率會變的很低，甚至出現(xiàn)過一輪評審結(jié)束后的結(jié)論是“建議回爐重造”。

2、有時評審來的很突然，參加評審的同學可能沒有時間充分了解待評審模塊，評審時無法充分發(fā)現(xiàn)問題，導致評審效果不理想。

3、評審現(xiàn)場，用例負責人講解自己用例的同時還需要處理其他同學提出的問題。這時候如果花時間做詳細記錄或者修改用例，那么將會影響會議效率；如果只是草草做一筆記錄，會后很可能就忘記當時想記錄內(nèi)容的具體含義，甚至還可能根本找不到那些做了標記的待修改用例。

4、評審現(xiàn)場，可能會有一些同學總是保持沉默，參與評審的積極性不高。

5、評審會后，評審問題會根據(jù)一個測試自主任務單跟進，但是單子的描述往往不會涵蓋會議提出的所有問題（因為上面提到用例負責人記錄問題存在的弊端）。有時可能連單子都忘記開了，整個評審不是閉環(huán)流程。

02 流程改進
可以看到我們原始的流程存在諸如“評審前準備不充分”，“評審效率不高”，“評審參與不積極”，“評審后問題跟進不閉環(huán)”等問題。針對這些問題，逐一分析了背后原因，對評審流程的各個環(huán)節(jié)做了優(yōu)化，具體改進措施以及改進原因如下：

1. 會議前
1.1 安排評審總負責人：
評審需要有一個總負責人，主要負責：選取評審內(nèi)容，會前預定會議室、邀請與會人員，會議中把握會議節(jié)奏，注意每個環(huán)節(jié)都走到，會議后跟進問題處理情況。

我們組內(nèi)一般是我來擔任這個角色，也可以安排其他有經(jīng)驗的QA同學輪流擔任。

1.2 合理規(guī)劃用例體量：
每次評審用例的體量不易過大，過大的模塊建議拆分多次進行評審。當然也可以安排幾個體量小的模塊在一次會議中評審。

根據(jù)經(jīng)驗，每次會議控制在一小時內(nèi)最好，如果超過一個半小時大家就會很疲憊，專注力明顯下降，后面的用例得到的有價值建議數(shù)量減少。與其這樣不如將模塊拆分，或者至少安排一下中場休息。

1.3 增加用例預評審流程：
會議前安排一個QA同學對待評審的用例做預審工作，發(fā)現(xiàn)用例中明顯的規(guī)則、邏輯、格式問題，避免將這類問題帶到會議上，提升評審效率。

預審過程中，兩人之間可能會出現(xiàn)一些爭議，對于這些爭議不必深究，可以記錄下來放到評審會議中討論。

建議安排用例負責人的導師來做這個工作，也可以安排相關(guān)模塊的負責人來做這個工作。

1.4 通過集中測試讓其他QA同學事先熟悉待評審模塊：
恰好我是組內(nèi)集中測試負責人，想到可以把用例評審與集中測試相結(jié)合。在計劃發(fā)起某個模塊的用例評審時，如果之前沒有針對這個模塊組織過集中測試，那么可以先安排一次集中測試，讓組內(nèi)的QA同學事先熟悉一下這個模塊。這么做可以避免出現(xiàn)部分同學在用例評審會議上才第一次接觸這個模塊，導致大家因為不熟悉模塊而無話可說。

2. 會議中
2.1 安排記錄員：
安排用例負責人之外的另一個QA同學作為會議記錄員，專門負責記錄大家提出的問題。

記錄員可以安排負責預審的QA同學、導師、徒弟或者往常提問不積極的同學來做。

這樣做的好處：

1、用例負責人就可以專心講解用例，不再會因為需要記錄問題而耽誤評審流程。

2、問題可以被詳細記錄下來，會后過很久也可以被很好的理解。

3、評審記錄員是一個很好的機會，可以觀察學習其他同學的評審技巧。

2.2 邀請策劃/程序同學參加用例評審：
根據(jù)實際情況，我們會選擇邀請策劃/程序同學來參加用例評審，這么做的好處有：

1、原本需要會后確認的設計問題或者代碼邏輯問題可以在會上就得到確認，提升效率。

2、策劃/程序同學往往會從不同于QA的角度給出評審建議。

3、可以讓策劃/程序同學更好的了解QA日常都是從哪些角度進行測試，他們在日后工作中也會更加注意這些方面，減少設計/開發(fā)階段的問題。（雖然效果不一定會立竿見影，但是確實有幫助。）

4、可以消除職能間的隔閡，有一些策劃/程序同學在參加用例評審后，會發(fā)現(xiàn)我們的QA同學其實非常專業(yè)，會增加對產(chǎn)品測試質(zhì)量的信心。

決定邀請哪些策劃和程序同學后，要事先通知評審時間和地點。評審結(jié)束后，我們還會對他們貢獻建議表示感謝（不用很正式，輕松愉快一些就好）。這都有助于下次的再邀請他們來參加評審。

2.3 提升用例講解效率：
評審效率低不僅耽誤時間，而且過長的評審時間會讓大家專注力下降，影響評審效果。對比多次用例評審，我發(fā)現(xiàn)體量與完成度差不多的兩份用例分別由不同的QA同學講解，會議效率并不相同。用例負責人獎需要掌握一些講解技巧來提升評審效率，詳見3.1。

此外，評審負責人需要注意每次講解的情況，遇到問題可以會后與用例負責人單獨溝通，便于下次講解過程更加高效。如果是首次講解用例的新人，評審負責人也需要在會前將基本技巧傳授給新人。

2.4 提升用例評審中發(fā)言的積極性：
我這邊總結(jié)一般大家發(fā)言積極性不高的原因主要有：“不好意思提出自己的看法”、“缺乏評審技巧”、“對于待評審模塊不熟悉”、“專注力下降”這四點。下面逐一介紹一下這些問題的解決建議：

1、 不好意思提出自己的看法——這個情況多出現(xiàn)于新人，如果發(fā)現(xiàn)這種情況，會后我會去找他或者安排導師與他單獨溝通，提升新人的自信心。新人的可塑性很強，越早發(fā)現(xiàn)這個問題，越容易解決。

2、 缺乏評審技巧——這個情況也是多出現(xiàn)于新人。除了會后指導外，還會安排他作為下一次評審會議的記錄員，記錄員可以更好的觀察學習其他同學的評審技巧。3.2中整理了一些基本的評審技巧。

3、 對于待評審模塊不熟悉——

a) 像上面說的，盡量在評審前組織一次集中測試，讓大家熟悉模塊。

b) 評審開始，用例負責人先介紹一下自己設計用例的思路以及用例的大體框架。

c) 負責人可以事先準備一些視頻，用于主要玩法的介紹。

d) 需要提升QA同學的用例評審技巧。實際評審過程中發(fā)現(xiàn)，有經(jīng)驗的QA同學，對于陌生模塊也能很快熟悉，并積極參與到討論中。

4、 專注力下降——

a) 與會人員自己需要排除干擾，專心聽講。

b) 負責人控制討論范圍，避免無關(guān)的發(fā)散。

c) 合理安排會議內(nèi)容，對體量大的模塊進行拆分。

d) 提升講解效率，適當通過發(fā)起討論或播放視頻等其他手段引起大家注意。

e) 對于無法拆分，會議時間較長的評審，安排中場休息。

評審負責人可以觀察每次評審中每人的提問次數(shù)，針對發(fā)言較少的同學分析原因，單獨溝通。但是需要注意避免讓這種方法“強迫”大家提問，無效的評審建議反倒會影響評審效果。目前我們組發(fā)言積極性提高了很多，已經(jīng)不再用這個方法了。

2.5 問題記錄回顧：
評審結(jié)束前，還有一個重要環(huán)節(jié)，記錄員需要逐一展示一下自己記錄的問題，與大家進行確認。避免出現(xiàn)記漏記錯的情況。

2.6 優(yōu)化用例管理平臺：
設計了用例評審工具需求，并在雷火MTL同學的支持下，用例管理平臺已經(jīng)支持用例評審功能，可以很方便的記錄并跟進評審問題，統(tǒng)計評審數(shù)據(jù)等。

3. 會議后
3.1 跟進評審問題解決：
借助用例管理平臺，可以很方便的對每個問題進行跟進，讓流程形成閉環(huán)。

修改用例——用例負責人，借助用例管理平臺，針對記錄的問題逐條修改。

驗收修改——用例復審員，借助用例管理平臺，針對修改的問題，逐條驗收。未通過的話，可以打回修改用例階段。通過的話，就可以進行歸檔完成整個用例評審流程。

3.2 復盤本次評審流程：
評審負責人需要在每次評審結(jié)束后，對本次評審進行復盤：

分析存在的問題——針對本次流程存在的問題，與QA同學溝通或者思考流程改進方法。

評估所做改進的效果——如果本次流程中做了新的優(yōu)化嘗試，那么也需要在會后進行評估，分析方法是否可行，是否需要調(diào)整。

03 用例講解與用例評審技巧
上文提到了對于用例評審流程的優(yōu)化，幫助我們的用例評審工作可以更好的開展。但是歸根結(jié)底，對于用例的“講解”與“評審”才是最核心的部分，所以除了優(yōu)化流程，我們的QA同學也需要掌握一些基本的講解與評審技巧。

1. 用例講解技巧
用例評審中，用例負責人的職責并不只是詳盡的把自己的用例講完就夠了。講解效率低，除了會消耗更多的時間外，大家的專注度也會被逐步消耗，隨著會議的持續(xù)有價值的建議會越來越少，評審效果也會大打折扣。

對比多次用例評審，我發(fā)現(xiàn)體量與完成度差不多的兩份用例分別由不同的QA同學講解，會議效率并不相同。這里分享一些簡單好上手的講解技巧：

1、評審開始后，不要匆忙開始，直接就“現(xiàn)在開始給大家講解我的用例，首先是一個部分……”。在開始之前，可以先簡單介紹一下模塊基礎玩法，模塊設計目的，用例設計思路，以及用例框架這些基礎信息。簡單介紹就好，不用花費太多時間。這么做的好處和會議PPT最開始的目錄效果類似：一方面大家會對評審內(nèi)容有一個初步的概念；另一方面大家可以估計一下會議時長，做好心理準備。

2、不要誤解用例評審的目的：

用例評審不是為了介紹模塊，瑣碎的細節(jié)講解可以簡略帶過。

用例評審不是為了展示負責人對于自己模塊有多么熟悉，用例覆蓋有多么全面。對于自己很有把握的部分，可以簡略帶過。

3、用例評審主要是為了讓大家?guī)兔Πl(fā)現(xiàn)問題，提升用例覆蓋率。對于自己不太有把握的部分、涉及核心功能的部分、模塊間交叉的部分等，負責人可以多花些時間講解。還可以拋出問題，引發(fā)大家思考與討論，比如“這個玩法掉落的道具，可能涉及到數(shù)值培養(yǎng)與生產(chǎn)制造，相關(guān)模塊的同學可以看看有我的用例或者你們的用例沒有什么要補充的內(nèi)容？”。

4、就像開始說的，會議持續(xù)時間越久，大家專注度下降越多。所以重點部分無需作為壓軸節(jié)目放在最后，在不影響邏輯的前提下，可以不按照用例結(jié)構(gòu)順序講解，將重點部分放在前面講。

5、可以事先準備一些視頻用來輔助展示玩法內(nèi)容（用例管理平臺支持上傳多種格式的視頻文件）。視頻表現(xiàn)能力強，效果往往會勝過口頭表達或者圖片展示。而且視頻可以很好引起聽眾的注意力，恢復對會議的專注度。

控制視頻的時長與數(shù)量，針對重要流程準備一下就好了。

非必要情況，不是很推薦真機展示，事先準備不充分的話，可能會受到環(huán)境或者BUG的影響阻礙展示，導致評審中斷，需要重新恢復評審氛圍。

2. 用例評審技巧
用例評審不是用例負責人的獨角戲，各位參與者提出的評審建議的價值與數(shù)量，直接決定了評審會議的效果。各位參與者需要在會前先熟悉一下模塊內(nèi)容，在會上保持專注，積極參與討論，貢獻有價值的建議。下面主要介紹一些常用的評審角度，除了評審時可以用于提出有價值的建議，日常自己做測試設計時也可以用到：

2.1 針對用例覆蓋：

1、 根據(jù)我的經(jīng)驗，待評審用例覆蓋率最低的是模塊之間交叉的部分，這也是召集大家在一起評審用例最希望補充的內(nèi)容。所以各位評審同學針對待評審模塊，首先需要思考：

a) 與其他模塊，尤其是自己負責的模塊之間是否有可能發(fā)生交叉？如，抽卡與戰(zhàn)斗模塊，立刻裝備新抽到的卡用于戰(zhàn)斗。

b) 這些發(fā)生交叉的可能是否會引入風險？如，玩家戰(zhàn)斗時更換時裝。

c) 如果無法與自己負責模塊發(fā)生關(guān)聯(lián)是否也是問題？如，生產(chǎn)制造需要使用材料A，需要確保采集玩法可以獲得材料A。

2、 遇到數(shù)值/數(shù)量相關(guān)內(nèi)容，需要關(guān)注各類邊界情況。如，拾取物品超過堆疊數(shù)量，發(fā)送空消息，刷新時間跨月跨年，獎勵領取次數(shù)達到上限等。

3、 窮舉玩法觸發(fā)條件的各種可能，確保這些觸發(fā)條件可用，且無邏輯問題。如，活動副本可以通過活動宣傳頁面進入，可以通過常規(guī)副本面板進入，可以與NPC交互進入等。

4、 嘗試重復相同操作。如，連續(xù)點擊UI，副本續(xù)杯功能等。

5、 檢查數(shù)值是否合理。如，技能傷害，獎勵投放等。

6、 嘗試在主流程中加入新的操作。如，工會戰(zhàn)期間被踢出公會等。

7、 記得考慮手機操作。如，鎖屏、多指操作、分辨率等情況。

8、 考慮刪號、斷線重連、重啟服務器、更換設備頂號等情況。

2.2 針對用例規(guī)則

1、 除了考慮用例覆蓋是否有不足，還要考慮用例是否冗余，是否可以被執(zhí)行。如，“零點前操作”，“零點整操作”與“零點后操作”這三條用例中，“零點整操作”本身就不具備可執(zhí)行性，通常來說只能讓操作無限接近零點。

2、 注意用例是否方便執(zhí)行。如，“抽卡抽到某張ssr”，雖然這條用例是可以執(zhí)行的，但是執(zhí)行時比較考驗QA同學的歐氣，建議可以附上調(diào)整概率的操作，讓用例更容易執(zhí)行。

3、 用例結(jié)構(gòu)是否合理，是否符合邏輯，可以提升用例執(zhí)行效率。

4、 用例中描述用詞與游戲內(nèi)正式包裝保持一致。

5、 注意用例格式，用例分級是否合適。

04 總結(jié)
最后，從人員分工的維度，再對整個用例評審流程做一下回顧：

用例負責同學：寫好用例后發(fā)起用例評審申請；修改預審階段發(fā)現(xiàn)的問題；掌握用例講解技巧，提高會議效率；會后及時處理評審問題，完善用例。

用例評審同學：會前熟悉待評審模塊；會上保持專注，積極參加討論；掌握評審技巧，貢獻有價值的建議。

用例預審同學：會前預審用例，發(fā)現(xiàn)用例設計中明顯的規(guī)則、邏輯、格式問題；記錄下預審中存在爭議的部分，評審會議上進行討論。

會議記錄同學：負責記錄現(xiàn)場提出的評審建議；會議結(jié)束前回顧記錄的問題。

用例復審同學：會后用例負責人修改完用例后，負責確保問題完全解決。

用例評審負責人：如果組內(nèi)預約不積極，可以主動出擊，尋找適合安排評審的模塊；評估用例體量，考慮是否拆分兩次評審；安排會議時間，通知與會人員；根據(jù)實際情況提前安排集中測試；會議中把控會議節(jié)奏，防止討論過分發(fā)散，適當插入中場休息；會后分析評審效果，進行改進。

下面是流程圖：

用例評審流程圖

以上是我對組內(nèi)用例評審流程優(yōu)化過程的總結(jié)，希望能給大家?guī)韼椭．斎挥美u審也不一定需要局限于會議形式，以文檔或者結(jié)對互審等其他形式也是可以的，如果各位朋友有什么想法也歡迎一起討論，謝謝。

總結(jié)：

感謝每一個認真閱讀我文章的人?。?！

作為一位過來人也是希望大家少走一些彎路，如果你不想再體驗一次學習時找不到資料，沒人解答問題，堅持幾天便放棄的感受的話，在這里我給大家分享一些自動化測試的學習資源，希望能給你前進的路上帶來幫助。

軟件測試面試文檔

我們學習必然是為了找到高薪的工作，下面這些面試題是來自阿里、騰訊、字節(jié)等一線互聯(lián)網(wǎng)大廠最新的面試資料，并且有字節(jié)大佬給出了權(quán)威的解答，刷完這一套面試資料相信大家都能找到滿意的工作。

???視頻文檔獲取方式：
這份文檔和視頻資料，對于想從事【軟件測試】的朋友來說應該是最全面最完整的備戰(zhàn)倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！以上均可以分享，點下方小卡片即可自行領取。???文章來源地址http://www.zghlxwxcb.cn/news/detail-791574.html

到了這里，關(guān)于測試用例評審流程優(yōu)化的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！