測試案例是貫穿了整個測試流程和項目研發(fā)流程的，因此用例顯得至關(guān)重要。如何提高用例的質(zhì)量，用例評審是必不可缺的一環(huán)。

很多測試同學都知道應(yīng)該做測試案例評審，并且也樂意做需求評審，但是很少有測試同學總結(jié)過如何做案例評審。那么案例評審應(yīng)該從哪些方面著手呢？

?

在開始之前，再回顧一下測試案例的幾個要素。

測試案例的四要素分別是：測試環(huán)境、測試目的、測試步驟、測試結(jié)果。這四要素缺一不可。另外還有案例分級、案例類型。

不同的公司的案例模版會稍有差別，有的公司甚至還會將案例跟自動化覆蓋程度結(jié)合，每一條案例對應(yīng)的自動化覆蓋情況，以及自動化類型是基于代碼層的，還是接口層的，以及UI層的等等。這樣更容易評估公司的自動化覆蓋率。

因此評審的內(nèi)容也基本上和測試案例的幾大要素息息相關(guān)，但是案例評審的第一步應(yīng)該是設(shè)計框架的評審。

?

設(shè)計框架

案例的整體框架，也就是案例的結(jié)構(gòu)和模塊劃分。一般我們都是以xmind來提前定結(jié)構(gòu)，這樣評審時更容易直觀的看到結(jié)構(gòu)樹和層級關(guān)系。

設(shè)計框架可以從哪幾個維度看？

1、模塊劃分合理性：大類、子類，并行關(guān)系、歸屬關(guān)系要區(qū)分，不能在同一層級展現(xiàn)。
2、子屬關(guān)系正確性：比如正常來說一個登錄的方式，從歸屬關(guān)系上看大致是這樣：賬戶體系》登錄》指紋登錄，如果將指紋登錄歸到注冊層級下面，那自然是不合理到。

3、需求覆蓋完整性：顯性需求應(yīng)該100%包含，隱形需求也應(yīng)該能夠挖掘出來，開發(fā)原理涉及到的每個環(huán)節(jié)也需要考慮容易出錯的點。總之，不能只局限于表面ui曾看到的東西。簡單來說，就是代碼層、接口層和UI層，均要覆蓋。

（關(guān)于如果針對開發(fā)原理，來完善案例設(shè)計可以參考這一篇文章，舉的例子很典型：https://blog.csdn.net/alice_tl/article/details/79601697）

4、類型覆蓋全面性：前端、后端、UI、功能、性能、兼容、接口等。

?

測試目的

1、測試目的的唯一性

一條案例應(yīng)該都唯一一個測試目的，比如不能在測試字符類型是否合法的同時，再測試字符長度是否符合標準。原因很簡單，因為如果有多條測試目的，那么一條通過，一條不通過時，你是打Pass合適，還是打Fail合適呢？并且容易干擾測試結(jié)論，以及不方便評估回歸測試工作量。

2、測試目的的明確性

比如希望測試一個播放次數(shù)的功能，為零次是則不顯示播放次數(shù)，每一次播放后播放的次數(shù)會有增加，未播放完就結(jié)束時，次數(shù)仍然不變。則可以寫成：

播放_播放次數(shù)_為零
播放_播放次數(shù)_播放完成
播放_播放次數(shù)_播放未完成
播放_播放次數(shù)_刷新頁面
可以一目了然的看到我想測試的點是什么。

3、測試目的的簡潔性

比如繼續(xù)拿上個例子來講，有的小伙伴會將測試目的寫成：

測試播放功能_看播放次數(shù)為零時次數(shù)的顯示_不顯示播放次數(shù)
測試播放功能_看播放完成時播放的次數(shù)是否有增加_播放次數(shù)增加
測試播放功能_看播放未完成時播放的次數(shù)是否有增加_播放次數(shù)不增加
測試播放功能_看頁面刷新時播放的次數(shù)是否有增加_播放次數(shù)不增加
對比之下，孰好孰壞，顯而易見。

小編一直不建議在測試目的中體現(xiàn)測試結(jié)果，因為這樣就和預期結(jié)果的內(nèi)容重復了，并且結(jié)果的描述通常文字較多，會導致測試目的非常長。不過不同項目的實施情況不一樣，見仁見智了。

?

案例詳情

1、測試環(huán)境：是充分必要的環(huán)境條件。

2、操作步驟：步驟需要具備連貫性、可執(zhí)行性。

3、案例分級：P0-P4，需要滿足要求15%，35%，40%，10%，每一分級的案例占比偏差不能大于5%。

4、預期結(jié)果：保證明確性、準確性，以及和需求一致性。

5、操作步驟：一般應(yīng)該是3步左右，絕對不能超出5步。操作步驟超出3步時就應(yīng)當要思考案例是否有多個測試目的和多個對應(yīng)的預期結(jié)果，已經(jīng)不符合案例設(shè)計規(guī)范。

6、案例順序：應(yīng)該將優(yōu)先級高重要模塊的案例放到前面，異常和分級低的案例放到后面。優(yōu)先級越高的案例，執(zhí)行的順序應(yīng)該越優(yōu)先。這樣一方面可以快速暴露問題，二是減少后期測試的壓力。優(yōu)先級通常是核心功能>次要功能，正向案例>逆向案例，常規(guī)場景>異常場景。

?

對于詳細內(nèi)容的審核，很多初學小伙伴容易混淆測試環(huán)境和操作步驟，這一點我是如何理解的呢？

假設(shè)用戶上傳一個照片到相冊中，需要測試上傳的功能本身，還需要考慮對不同網(wǎng)絡(luò)的兼容，還需要測試到不同網(wǎng)絡(luò)的性能。

那么除了針對網(wǎng)絡(luò)兼容測試的case，網(wǎng)絡(luò)的類型和設(shè)定是作為操作步驟以外，其他的非專門測試網(wǎng)絡(luò)的case中應(yīng)該將網(wǎng)絡(luò)連通性作為測試環(huán)境而非作為操作步驟。試想如果每一條案例里都將網(wǎng)絡(luò)連通性作為第一個測試步驟，冗余量是得有多大，并且稍微有常識的用戶都知道，我要上傳成功，我的前提是網(wǎng)絡(luò)連通。

評審流程：

設(shè)計框架評審：一般來說要求測試全組參與、項目組全部參與，一方面能夠快速看到設(shè)計者的測試思路，另一方面避免出現(xiàn)大的設(shè)計遺漏。

測試目的、案例詳情評審：一般來說要求項目組全部參與，確認細節(jié)規(guī)則和測試結(jié)果的準確性。

?

總結(jié)

以上是生活随笔為你收集整理的测试案例的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。