- 相關推薦
測試用例的功效
隨著軟件行業(yè)的快速發(fā)展，大家對軟件的質量也越來越看重，關注。軟件測試做為能盡可能發(fā)現(xiàn)軟件中的BUG，減少軟件成本，也在不斷的高速發(fā)展，受人們關注，重視的程度也越來越大。從最初的程序員自己測試到后面獨立的測試部門，測試職位的設立。以及軟件測試的一整套方案，流程等。
一，測試用例的重要性
什么是測試用例？測試用例有什么作用？
測試用例：是為某個特殊目標而編制的一組測試輸入、執(zhí)行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。
測試用例的作用：
1，通過一個用例來證明被測軟件的某功能符合需求說明書中規(guī)定的要求，可以通過設計正反兩方面的測試用例來驗證
2，可以保證一個軟件被測試的有效性，使測試人員知道那些功能以被測，那些功能還需要測試，從而避免漏測，重復測，提高測試效率
3，指導測試的工作，保證測試是有計劃的實施，而不是隨意性的測試
4，為公司留下財富，為后期軟件維護提高幫助，為公司新人進來提供指導，在測試的時候可以盡量把人為因素的影響減少到最小。保障軟件測試質量的穩(wěn)定
5，可以做為評估測試結果的，為編寫測試報告提供依據(jù)。
6，分析缺陷的標準，通過收集缺陷，對比測試用例和缺陷數(shù)據(jù)庫，分析確證是漏測還是缺陷復現(xiàn)。漏測反映了測試用例的不完善，應立即補充相應測試用例，最終達到逐步完善軟件質量。而已有相應測試用例，則反映實施測試或變更處理存在問題。
二，測試用例的設計：
測試用例設計這部分主要是根據(jù)我自身的經(jīng)驗來寫，可能很多不足的地方，請大家指出。（這里寫的測試用例都以黑盒測試為準，不設計到白盒測試）
1，設計測試用例的模板：
我想，每個公司都應該有一套適合自己公司的測試用例模板。還是那句話，最好的并不是最適合自己的，適合自己的才是最好的。測試用例模板可以分為兩部分：
1）介紹部分：可以有這些：公司名稱，保密等級，編寫人員，日期，審核人，版本號，測試對象的介紹，測試的范圍和目的，測試環(huán)境，定義術語，參考文檔，用例執(zhí)行情況，測試用例設計思路等
2）測試用例部分：模塊名稱，測試類型，用例ID，用例目的，重要程度，測試過程分為（前提條件，測試步驟，期望結果，測試結果，測試結論）測試日期，備注。
現(xiàn)在打部分公司用來編寫測試用例的軟件應該都是EXECL和WORD（那個叫微軟NB撒），感覺上，在進行模塊測試和系統(tǒng)測試設計用例的時，用EXECL來編寫比較好，方便統(tǒng)計，查找測試通過的，沒通過的用例，EXECL統(tǒng)計功能很強大。但是對于驗收測試用例和性能測試用例，使用WORD會好點，因為驗收測試用例和性能測試用例，一般都是一個用例一頁，方便打印，而進行驗收測試的時候，必須要把驗收測試用例打印出給客戶，而且驗收測試用例一般都沒系統(tǒng)測試那邊多，一般是一個功能就是一個用例。(下面有2種測試用例的模板)
2，測試用例設計的一些思路：
按照書上說的可以分為幾大類：
1）等價類劃分
2）邊界值分析
3）錯誤推測
4）因果圖
我認為測試用例的設計應該從深度和廣度方面去想，即要考慮到被測模塊所有功能，還要考慮他們的組合，以及和其它模塊的組合。不單單要考慮正常情況下功能，還要考慮異常情況下軟件的反應，不要僅只考慮一種測試環(huán)境下的情況，還要考慮多種環(huán)境下的情況，因為用戶的環(huán)境是千變萬化，不是能全部模擬出來的，只能盡可能的模擬，下面是我以前測試的一個模塊：
禁用USB外接設備：
主要功能是：除了USB鍵盤和鼠標外，其它一切外接USB設備都不能使用。 （不知道大家能想到一些什么情況來設計測試用例），下面是我設計的一些思路：
1）正常情況下運行該功能后，看USB鍵盤和鼠標能否使用
2）正常情況下運行該功能后，USB鍵盤和鼠標拔插后能否使用
3）正常情況下運行該功能后，USB鍵盤和鼠標拔掉，接上外接USB設備，能否正常使用
4）正常情況下運行該功能后，USB鍵盤和鼠標拔掉，接上外接USB設備，插上 USB鍵盤和鼠標，USB鍵盤和鼠標能否使用，外接USB設備能否使用
5）正常情況下運行該功能后，接上外接USB設備（USB鍵盤和鼠標一直存在），外接設備能否使用
6）重復拔出外接USB設備，看USB設備能否使用，USB鍵盤和鼠標是否會影響
7）先插外接USB設備（能正常運行），再運行該功能，USB設備是否立即不能被使用
8）外接USB設備正在拷貝文件，運行該功能后，是什么反應
異常情況下該功能的反應，如運行該功能后，電腦重啟，電腦死機等會導致什么后果，是否是我們期望的。
《測試用例的功效》全文內容當前網(wǎng)頁未完全顯示，剩余內容請訪問下一頁查看。
多個USB接口情況下，該功能是否正常
對于不同USB設備是否該功能都有效果：如USB的U盤，移動硬盤，MP3，USB打印機等。
該功能運行后，是否能還原。還原功能是否正常。
。。。。等，上面這些，大家也應該想的到，下面這些大家是否會考慮：
1）大家都知道禁止某設備運行后，在設備管理器會顯示？號或者紅叉，大家會不會設計手動從設備管理器去啟動被禁止的外接USB設備的用例？
2）有的USB設備需要驅動才能運行，如USB接口打印機，是否會設計驅動卸載，重新安裝后的用例？
3）現(xiàn)在也有那種USB轉換器，比如把PS/2接口轉換為USB接口，那外接USB能否使用？把USB接口轉換為PS/2接口，PS/2接口的設備能否使用？
4）不同操作系統(tǒng)下，該功能是否有效，如LINUX，UNIX，WINDOWSXP，2000，2003等。
上面這些可能可能很難想到的地方，所有設計測試用例也并不是一件容易的事，需要發(fā)散性的思維，需要大量的經(jīng)驗。現(xiàn)在看到很多人有點本末倒置了，都去追求工具自動化，其實當你設計出一個完美的用例后，測試出的效果絕對是巨大的，要不怎么會說一個好的測試用例是發(fā)現(xiàn)從為發(fā)現(xiàn)的錯誤呢？基本功還是需要.
上面的那些情況只 是一部分，還可以設計出很多來，大家可以一起討論下。 三，測試用例的一些技巧：
在軟件測試中，有很多被測試的軟件都是C/S結構的，而軟件的界面估計是從頭到尾都在改變中，這都測試用例的編寫，維護是一件耗時，耗力的事。下面是我個人的一些經(jīng)驗： 1，界面測試用例和功能方面測試用例分開寫，比如在一份EXECL測試用例中，界面的就單單寫界面的，如寫字體，排版，快捷鍵等，功能就只寫邏輯方面，實現(xiàn)方面，這樣當界面修改后，修改也快點。
2，比如說在編寫一個彈出提示框用例時，以前我寫用例的時，把預期結果寫成提示的消息，如：“登陸用戶名錯誤”，而當這個提示消息變?yōu)椤坝脩裘e誤”時，有要去修改用例，很煩的。后面我就寫“彈出一個提示消息框”，這樣就解決了
3，寫用例時，盡量分清層次結構，比如用戶登陸模塊，寫的時先寫正常情況下登陸，再寫異常情況下登陸，不要一下寫正常情況下，有寫異常情況，然后再寫正常情況下，讓人感覺很混亂。
4，寫測試用例之前，最好在紙上畫一個框架出來，按照什么順序來寫，比如是按照操作系統(tǒng)的分類先，還是按照正常，異常情況先來寫，下面模板中的一級分類，二級分類就是這個效果
測試用例的作用2017-05-10 15:15 | #2樓
4年前我剛入職測試的時候也是對測試用例的實際價值和具體應用有過相當一段時間的不解，不過當時沒人能給我一個真正合理并具有說服性的理由，只知道很重要，就這樣一直做下來，直到4年后現(xiàn)在的我，當帶別人的時候我也會說測試用例很重要，是一個測試人員的核心能力，測試的好壞一半取決于你對測試用例的編寫能力，另一半來自于你對業(yè)務的發(fā)散性思維，來自于測試人員測試時的狀態(tài)。
不要說時間緊迫，需求變化較快，如果你提前在心里就為自己找好了不去做的理由，那么對這項工作你會永遠都保持著抵觸的情緒，進而越發(fā)的覺得測試用例沒用。我具體說幾點希望能讓你對測試用例有所改觀：
1、先說說你所說的編寫用例和臨時的靈感之間的區(qū)別，這也是現(xiàn)在很多測試人員的困惑，因為工作中所有的感覺都在告訴我們，臨時的發(fā)揮往往發(fā)現(xiàn)更多更隱蔽的bug，而測試用例中往往也都是開發(fā)人員已經(jīng)注意過的地方，能出現(xiàn)讓你感覺很有成就感的bug實屬不易，但我前面說了，這僅僅限于我們的感覺，舉個大學時的例子來解答你這個困惑，我記得我大學的時候我的高數(shù)老師在講課的同時不忘提醒我們該以怎樣的態(tài)度對待目前的知識，我想大多數(shù)同學都會有我這樣的想法，看看書本上的東西，這么簡單還用學么，臨時看看就會了，況且學了能有什么用呢？有一天老師在講一個簡單的公理時突然說了一句話，他說這個公理是很簡單，是最基礎的，但我提醒大家最基礎不是不重要，相反它是最重要的，如果沒有這個基礎公理后續(xù)課程中所有的理論都不存在。這句話我一直記在心里，基礎的是最重要的，這也是我一直很痛心的地方，因為平時我看著都會的東西，一個學期過去，我居然什么都不會了，我很鄙視同學平時不斷的做著我看著都會的題目，可到最后我都答不上來了，可同學卻很輕松的交卷了。
不知道你對我所說的能否理解，編寫測試用例我們都很不耐煩，覺得自己到時候也知道這些，寫了又有什么用呢？可真正到了測試的時候你憑什么說你都知道呢，這不過是一廂情愿的想想罷了，就像我面對剛開始簡單的公理，我反復做這個公理的題有什么用呢，多簡單啊，可對簡單的都無法理解吃透，又如何在簡單的基礎上進行發(fā)散性思考？一個系統(tǒng)連基本的保障都沒有，僅靠臨時的靈感去挖掘我們不太容易發(fā)現(xiàn)的問題，我想你自己心里對系統(tǒng)都沒底吧。簡單的說，編寫是基礎，臨時的靈感是深度挖掘。
2、如果說上面的理由不足以說服你，那么再看看這一點如何。不靠譜的靈感——如論是哪個測試人員，都會承認，測試與我們本身的狀態(tài)有相當緊密的關系，如寫文章一樣，狀態(tài)好時文思如泉涌，狀態(tài)不好時提筆忘字，甚至生厭，畢竟我們大多仍然還執(zhí)行著手工測試，工作的單調和枯燥不會讓你像一直打了興奮劑一樣，此時你如何保障你的測試是有效的？
3、盲點。不知道你是否聽過這個詞，由于每個人的邏輯思維迥異，看待事物必然不同，針對一個測試點每個人編寫的測試用例也會有不同，我不相信一個人可以把一個系統(tǒng)想得方方面面滴水不漏，bug總是源源不斷超出你的想象，這些你想不到的即是你的盲點，當你把編寫好的測試用例上交評審時，你會發(fā)現(xiàn)別人總是會提出這樣那樣的問題，你會發(fā)現(xiàn)你原有的邏輯竟然暗藏n多漏洞，更可怕的是隨著工作的進行，當你對系統(tǒng)進行多次的回歸，你會發(fā)現(xiàn)你可測的越來越少，為何？不是你的錯，每個人在持續(xù)的重復同樣的活動時，都會漸漸失去原有狀態(tài)，漸漸麻木，那么我們的盲點也會偷偷的加大，如果沒有提前的測試用例保證，你可以保證你在系統(tǒng)交付前的測試與你第一遍測試的內容完全一致么？如果不完全一致，那些落下的測試點，你測試過嗎，測試幾次呢？現(xiàn)在是正確的嗎？
4、管理成本。這個應該說和部門對項目的長期管理有關，面對現(xiàn)今it業(yè)人員流動大的特性，每個部門對項目的管理成本在加大，老員工離職留下一堆問題，新員工入職業(yè)務不熟，無法馬上接手，之前的系統(tǒng)如何，由誰去給他講解？對于測試，我想如果我是管理者，我會直接給他一些模塊的測試用例，按著這些用例去測試，從這些用例中去理解系統(tǒng)，即增加了一點人手，也極大提高他學習的速度，4年的經(jīng)歷告訴我一個新入職的測試人員僅僅是看需求說明來學習，效率異常低下，并且一旦實際接手測試任務，之前所學習的基本還得對著系統(tǒng)重來一遍，記得，企業(yè)招聘員工，要盡可能要你來創(chuàng)造更多的效益，當然這個效益創(chuàng)造的越早越好，而不是真的讓你來學習。
或者整體來說，測試用例是測試對系統(tǒng)的一個基本的質量保障，是一個項目可持續(xù)化管理的有效手段之一，當然，不是說寫了測試用例就萬事大吉，軟件就毫無問題，還是我老師那句話，這是最基礎的，也是最重要的，你的那些靈感會使你的測試大放異彩，但絕不要被這色彩蒙住你的眼睛，導致你看不清基石而摔下來。
最后回到我開始說的，"不要說時間緊迫，需求變化快"，這個問題我不想多說，因為這個問題只要我們想解決，總會有辦法，關鍵是看你以什么樣的態(tài)度對待，想克服就不是什么大問題，不想克服，那就無解。
以上只是簡單說了下測試用例實際的好處與作用，當然不止這些，既然有這些好處，至于你執(zhí)行多少全在自己，現(xiàn)在很多企業(yè)都想采用敏捷開發(fā)的方式，對測試也發(fā)起了新的挑戰(zhàn)，也有人用測試點或者需求列表的形式來代替，無論什么形式都無所謂，選擇一條最適合當前部門狀況的方式，但你所說的靈感是絕不靠譜的事情，兩者無法比較。
自己也曾經(jīng)疑惑過用例和作用，并想方設法提高用例對于異常場景的覆蓋。其實這類靈光一現(xiàn)的異常場景有用例設計初期是無法做到太多的覆蓋，只能根據(jù)以往的測試經(jīng)驗來寫。在測試過程中如果有新的場景想到，一定要及時補充到用例中，而不是測試過一次就忘了~~還是那句老話：測試用例是需要維護的，不是死的！
【測試用例的功效】相關文章：
測測能申請哪個檔次學校04-17
課例研修心得02-11
收入證明樣例05-06
2016行測文學常識05-07
行測的常識怎么復習09-27
行測常識怎么復習09-27
購房收入證明3例01-13
安全例檢應急制度04-16
物理課例反思05-21
地測科工作總結01-09