是否還有異常沒有想到？試試用例測試評審

來自專欄 Kevin改變世界的點滴

近期負責的後台系統中某個模塊進入開發落地流程，但從事後台的過程中除了大量的表單與業務邏輯梳理，我們往往少了面向C端用戶的「用戶體驗為王」的核心追求。

面向C端用戶，哪怕是一個下拉刷新的異常產品人員都需要考慮如何展示該文案或toast如何設計。

在業務的優先順序要求上，後台產品人為了滿足業務需求而存在可能降低體驗上的細節問題，測試人員也是相同的以核心業務流程模塊為重點測試，針對於文案的校對與體驗的bug上可能就不會那麼細緻了。

提升自己的異常輸出能力，寫測試用例

用例評審按照功能以頁面中的事件操作的用例集合來評審，同時產品人員參加是為了矯正與檢察該用例與需求的一致性。

上圖中以搜索描述測試人員的用例，輸入的內容、輸出結果、輸出條件將可能出現的用例一一列舉。很多時候我相信當多個人參與需求的用例分析之後，產品人員是可以檢查一些我們沒有梳理的異常。比如用戶信息填寫到底是用輸入框、還是下拉框等這樣的小場景和case，是產品人員極易疏漏的。

用例評審的順序，按照業務或模塊順序

用例評審的順序以測試人員發起並邀約相關開發、產品同學進行。以後台產品為例，可以以模塊順序將每個模塊的頁面用例進行評審。產品人員只需要確認每個頁面的需求是否落地或缺失。

當然用例評審也可以按業務的順序，比如登陸註冊流程。可以以註冊功能用例、再到登陸功能用例，總之讓整個用例評審高校有序、便於理解是其核心。

用例評審同樣是需求深入的一個過程，因此針對於產品人員「砍我可以，別砍需求」的這段話往往會在這裡出現最多。很多用例產品人員是可能沒有想到的異常，所以提升自己的異常梳理能力建議產品同學多多參與用例評審。

異常的梳理，是一個產品人功力深厚的關鍵。

好，今天的感悟與分享就在這裡，每周

推薦閱讀：