2010軟考軟件測評師：編寫測試用例的一點小結(jié)

　　編寫測試用例的一點小結(jié) 軟件測試

　　首先我們寫用例的依據(jù)有幾種，其中之一就是需求設(shè)計及相關(guān)文檔，有人說UC有很多問題，UC不可靠，我個人覺得這種說法是不對的，雖然UC有問題，但是我們還要依靠UC，總不能說今天中午的午飯不好吃，我們自此不再吃午飯吧。同樣的道理，UC有問題，我們要想辦法解決這些問題，而不是因噎廢食。

　　同樣，一個好的UC不僅僅節(jié)約測試的時間，也節(jié)約開發(fā)人員的時間，一個書寫簡單的UC雖然編寫的時候節(jié)約時間，但是在以后的過程中需要不停的修改，測試也需要為一些小的問題不停的找開發(fā)人員確認(rèn)，你煩我煩大家都很煩。一個好的UC讓大家都一勞永逸。

　　其次用例的編寫還依賴于與開發(fā)組交流對需求的理解。這點就要求開發(fā)和測試之間建立良好的溝通，即使CHECK發(fā)現(xiàn)的各種問題。有問題及時解決，及早避免南轅北轍離題千里的尷尬境地。

　　最后我們寫用例的依據(jù)還來自原型界面，以此次用例PK為例，我們不可能為了進行PK讓開發(fā)那邊再重新編寫用例，而且我們對于發(fā)布寶貝的過程都是很熟悉的，再重新寫UC顯然是不切實際的。

　　現(xiàn)在，我們有了編寫用例的依據(jù)，那么先就需要做好用例設(shè)計，在我們公司用的是流程圖，讓UC上的文字更加直觀。但是不僅僅是將這些主流程文字搬上去就可以了，我開始畫設(shè)計圖的時候每次注釋的時候直接貼上一大塊文字，后來發(fā)現(xiàn)，其實這個只是把UC上的文字挪個窩而已。

　　對于一些輸入項，比如說是必填項完全可以用判斷符號來判斷是否填寫，總比旁邊的注釋框中的必須輸入四個字直觀得多。另外，畫設(shè)計圖的時候是詳細(xì)了解流程的時候，如果設(shè)計圖畫的流程不正確，即使你糾纏于細(xì)節(jié)，每個邊界值設(shè)定都非常正確。只能說當(dāng)你發(fā)現(xiàn)你錯誤的時候，會很很很抓狂滴~~~

　　最后到了寫設(shè)計用例的時間了，有人說，寫設(shè)計用例是很痛苦的個過程，確實有點，很長一段時間總是糾結(jié)在長度類型，邊界值，和特殊符號中……但是，我不知道是不是支持這種方法，我開始寫用例的時候是老老實實的一個個的寫的，然后就發(fā)現(xiàn)有些用例是有共通之處的，比如說對于名稱的校驗，無非是長度，類型，在各種名稱的校驗中都是換湯不換藥的，所有建立一個模板總匯，直接COPY就好了，當(dāng)然記得COPY后要修改下。

　　我發(fā)現(xiàn)用模板編寫的效果除了效率變高外，還可以保證格式上的一致。格式一致的好處就不多說了，至少看起了也好看不是。

　　但是我擔(dān)心的一個問題是過于依賴于模板，導(dǎo)致有些細(xì)節(jié)的地方?jīng)]有挖掘出來，畢竟一個個編寫用例的同時，我們也許會偶爾靈感一現(xiàn)。于是我們就有另一個方法，先搭建整體的框架，先整體考慮出那些框框條條的內(nèi)容，最后的過程就是填空啦。

　　其實說來簡單，在編寫用例的過程中總會遇到很多的問題，比如說需求變更，但是也許唯一不變的就是變化，如果變更了這么辦?擁抱變化，跟著變更唄，但是，這里有個問題是：測試組最無奈的事情是——開發(fā)人員變更了需求，但是測試這里卻不知道。如果再給我一個機會，我一定要在項目開始之前就和測試組約定好!

　　　　　　　2010年11月計算機軟件水平考試備考寶典匯總