最近在寫一個模組的場景測試用例，從一個場景十幾個步驟，基本沒有按照使用者邏輯，且沒有主題到最後 一個場景簡單明瞭的幾個步驟並且主題明確通過外部評審，這個過程中，遇到了很多問題，不停糾正，不斷總結，最終終於寫成一個不錯的場景測試用例。

好的場景用例必須滿足以下幾點：

儘可能覆蓋更多的BVT；
每個場景的執行步驟簡單明瞭；
一定是使用者可能使用的場景(場景故事)，有一定的邏輯性；
不浪費資源，實現成程式碼執行速度較快；

場景測試用例的格式：

前置條件：有些步驟並不是本次場景測試的重點，所以並不關注這些步驟，所以，將需要的直接設定為前置條件,也就是執行這個測試用例，需要哪些。舉個例子，比如我們需要測試一個物件是否具有某個特性的時候，物件的建立就不是此測試用例的重點，所以前置條件就應該是有一個物件。
執行步驟：按照使用者的邏輯，一步一步完成
1.
2.
預測結果：切忌不要籠統的寫成 以上各個步驟均可以正常設定 ，要寫成：每一步設定成功之後，我們是怎樣進行檢驗這步設定的成功，也就是程式碼中要怎麼寫。
1.
2.
後置條件：資源的銷燬清理工作。舉個例子，這個測試用例中只關注物件的建立過程，所以執行步驟中最終就會創建出了一個物件，那麼就需要在後置條件中將建立的物件進行銷燬。

場景測試用例應該注意的點：

1.注意主題化，一定要明白自己的這個場景用例是要測試什麼功能，切忌將API中的測試點自己任意組合，想到哪裡寫到哪裡；
為了達到測試點的主題化，我們可以在寫測試用例之前先yy出一個使用者使用的場景故事，也就是保證這個場景在使用者使用的過程中可以出現到的。
2.注意上下文，場景用例本身就是模擬使用者使用，測試基本功能（BVT）連線起來是否有bug，一定要有使用者使用時的邏輯性；
3.注意只測試簡單的基本功能，比如密碼的合法性，記憶體，頻寬的越界這樣的問題場景中不需要出現，API中已經會有覆蓋；
關於密碼的合法性等測試點，就不需要出現在場景用例中了，也就是場景中只出現主流程（密碼錯誤這個屬於副流程）。
4.注意步驟要簡潔明瞭，沒有歧義，數字要說明單位；
因為寫出來的測試用例並非自己去手工測試或者自己去程式碼實現，所以，要做到讓別人一下子就可以看懂執行步驟的意思，沒有歧義。
5.並不是說所有的BVT測試點都測試兩個方面，因為有時，某個方面就不是BVT；
6.儘量不要使得不同的場景覆蓋同樣的測試點；