編寫測試用例的一點小結 軟件測試
方法/步驟
首先我們寫用例的依據有幾種，其中之一就是需求設計及相關文檔，有人說UC有很多問題，UC不可靠，我個人覺得這種說法是不對的，雖然UC有問題，但是我們還要依靠UC，總不能說今天中午的午飯不好吃，我們自此不再吃午飯吧。同樣的道理，UC有問題，我們要想辦法解決這些問題，而不是因噎廢食。
同樣，一個好的UC不僅僅節約測試的時間，也節約開發人員的時間，一個書寫簡單的UC雖然編寫的時候節約時間，但是在以後的過程中需要不停的修改，測試也需要為一些小的問題不停的找開發人員確認，你煩我煩大家都很煩。一個好的UC讓大家都一勞永逸。
其次用例的編寫還依賴於與開發組交流對需求的理解。這點就要求開發和測試之間建立良好的溝通，即使CHECK發現的各種問題。有問題及時解決，及早避免南轅北轍離題千里的尷尬境地。
最後我們寫用例的依據還來自原型界面，以此次用例PK為例，我們不可能為了進行PK讓開發那邊再重新編寫用例，而且我們對於發佈寶貝的過程都是很熟悉的，再重新寫UC顯然是不切實際的。
現在，我們有了編寫用例的依據，那麼先就需要做好用例設計，在我們公司用的是流程圖，讓UC上的文字更加直觀。但是不僅僅是將這些主流程文字搬上去就可以了，我開始畫設計圖的時候每次註釋的時候直接貼上一大塊文字，後來發現，其實這個只是把UC上的文字挪個窩而已。
對於一些輸入項，比如說是必填項完全可以用判斷符號來判斷是否填寫，總比旁邊的註釋框中的必須輸入四個字直觀得多。另外，畫設計圖的時候是詳細瞭解流程的時候，如果設計圖畫的流程不正確，即使你糾纏於細節，每個邊界值設定都非常正確。只能說當你發現你錯誤的時候，會很很很抓狂滴~~~
最後到了寫設計用例的時間了，有人說，寫設計用例是很痛苦的個過程，確實有點，很長一段時間總是糾結在長度類型，邊界值，和特殊符號中……但是，我不知道是不是支持這種方法，我開始寫用例的時候是老老實實的一個個的寫的，然後就發現有些用例是有共通之處的，比如說對於名稱的校驗，無非是長度，類型，在各種名稱的校驗中都是換湯不換藥的，所有建立一個模板總彙，直接COPY就好了，當然記得COPY後要修改下。
我發現用模板編寫的效果除了效率變高外，還可以保證格式上的一致。格式一致的好處就不多說了，至少看起了也好看不是。
但是我擔心的一個問題是過於依賴於模板，導致有些細節的地方沒有挖掘出來，畢竟一個個編寫用例的同時，我們也許會偶爾靈感一現。於是我們就有另一個方法，先搭建整體的框架，先整體考慮出那些框框條條的內容，最後的過程就是填空啦。
其實說來簡單，在編寫用例的過程中總會遇到很多的問題，比如說需求變更，但是也許唯一不變的就是變化，如果變更了這麼辦?擁抱變化，跟著變更唄，但是，這裡有個問題是：測試組最無奈的事情是——開發人員變更了需求，但是測試這裡卻不知道。如果再給我一個機會，我一定要在項目開始之前就和測試組約定好!