2010軟考軟件測(cè)評(píng)師：編寫測(cè)試用例的一點(diǎn)小結(jié)

　　編寫測(cè)試用例的一點(diǎn)小結(jié) 軟件測(cè)試

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

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

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

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

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

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

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

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

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

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

　　　　　　　2010年11月計(jì)算機(jī)軟件水平考試備考寶典匯總