軟件測試中總結出的有關(guān)功能測試的經(jīng)驗之談
從事軟件測試這么長(cháng)時(shí)間了，以前一直只是聽(tīng)同事朋友們學(xué)起功能測試有多么的利害，自己卻一直沒(méi)有去學(xué)習過(guò)。后來(lái)在網(wǎng)上看了一些有關(guān)功能測試方面的教學(xué)課程，至今我也學(xué)習了這方面的知識，不學(xué)不知道，學(xué)后才知道功能測試的強大性。以下是我做的一部分有關(guān)功能測試的小小經(jīng)驗之談，望能幫到像我當時(shí)迷茫的測試行業(yè)的朋友們。
測試準備： 1、實(shí)際測試總比你預想的要花更多的時(shí)間，遇到更多的麻煩，所以要盡量爭取足夠的測試時(shí)間，不要不加思索的說(shuō)這個(gè)東西我一星期肯定可以測完。還要盡可能考慮到測試過(guò)程中的風(fēng)險，比如測試環(huán)境的問(wèn)題、部署失敗的問(wèn)題、開(kāi)發(fā)延期的問(wèn)題、人員變動(dòng)的問(wèn)題等等。
2、實(shí)際上從來(lái)都沒(méi)有過(guò)完善的需求，可惜的是教科書(shū)從來(lái)也沒(méi)講過(guò)如何應對不完善的需求。我曾不止一次的想如果讓做需求的和編程人員都來(lái)做兩個(gè)月的測試，他們的工作能力肯定會(huì )有質(zhì)的飛躍，可惜這只是我的夢(mèng)想。需求說(shuō)明書(shū)中總會(huì )遺漏很多細節，通常需求人員認為那些地方都是理所當然無(wú)需贅言的，但開(kāi)發(fā)人員卻會(huì )有不同的理解，所以測試人員要盡可能的在開(kāi)始編程之前找出需求中所有不明確、有遺漏的地方。如果能在討論需求的時(shí)候就提出問(wèn)題那比從已經(jīng)寫(xiě)好的需求說(shuō)明書(shū)中挑錯要好的多。問(wèn)題越早發(fā)現越容易解決。
3、測試人員最好能在開(kāi)發(fā)開(kāi)始之前，總結出一個(gè)列表，列表中列出需要開(kāi)發(fā)人員統一處理的一些細節，比如表單中表頭和表內容用什么字體字號;是左對齊還是居中;翻頁(yè)控件是放在表單左下角還是右下角還是居中;標點(diǎn)符號是用中文半角還是全角;選擇框和下拉菜單中的內容按什么排序;搜索結果是否需要排序;錯誤提示是彈出窗口還是顯示在原界面;錯誤提示語(yǔ)也應盡量統一風(fēng)格;查詢(xún)后是否要保存查詢(xún)條件;瀏覽器的前進(jìn)后退是否需要限制等等。項目經(jīng)理最好統一給開(kāi)發(fā)人員講一下這些規矩，這樣會(huì )在測試時(shí)省很多事。
測試用例：
1、測試用例要因人而異，如果自己已經(jīng)很熟練了，測試用例可以只是簡(jiǎn)單的提示，不需寫(xiě)出詳細的執行步驟和測試數據，以免因為無(wú)謂的文檔浪費太多時(shí)間。如果很可能別人還要復用你的測試用例而且有充足的時(shí)間，這時(shí)就可以把測試用例寫(xiě)詳細點(diǎn)。
2、至于測試數據需不需要在設計測試用例時(shí)就寫(xiě)出需要根據實(shí)際項目情況來(lái)定，我一般認為最好把測試用例都寫(xiě)完之后，再準備測試數據，一條數據可以覆蓋多個(gè)測試用例，這樣很可能四五條數據就可以覆蓋十幾個(gè)測試用例，這樣可以提高效率。教科書(shū)通常認為一條測試數據最好對應一個(gè)測試用例，這樣測試執行失敗時(shí)就容易定位問(wèn)題出在哪里。但實(shí)際情況是只有極少數的測試會(huì )執行失敗并因此發(fā)現bug，但如果因為這極少數的失敗的情況來(lái)降低整個(gè)測試執行的效率就顯得缺乏實(shí)踐性了，況且并不是說(shuō)一條測試數據覆蓋了多個(gè)用例時(shí)就不容易定位錯誤的根源。所以測試要根據實(shí)際情況靈活進(jìn)行。
3、如果要寫(xiě)詳細的測試用例，就一定要寫(xiě)的非常的清楚明了，最好讓一個(gè)不懂項目情況的人也能根據用例執行測試。而且測試用例和測試數據中的關(guān)鍵值一定要用顏色標出。最好還能寫(xiě)出每條用例的測試目的，這樣方便日后別人補充你的測試用例。
測試執行：
1、如果時(shí)間允許，測試一個(gè)頁(yè)面時(shí)，要把這個(gè)頁(yè)面的所有功能點(diǎn)的正常異常情況都測完之后再去測下一個(gè)頁(yè)面，這樣不容易遺漏。大多時(shí)候時(shí)間都不很充足，這時(shí)要先測主要流程和主要的功能點(diǎn)，這些完成之后再去測細節和異常情況，因為并不是有bug就不能上線(xiàn)的。
2、如果發(fā)現了很多界面性的小問(wèn)題，不要連續提出，最好先提一兩個(gè)功能性的問(wèn)題，再提一兩個(gè)界面性的問(wèn)題，這樣間隔著(zhù)提bug有利于開(kāi)發(fā)人員接收，免得他把你提的連續的四五個(gè)界面性的bug都拒絕了。另外，一個(gè)bug里最好不要既包括功能性問(wèn)題又包括界面性問(wèn)題，這樣有可能開(kāi)發(fā)人員只解決了功能性問(wèn)題就把bug 關(guān)了。
3、可以一條測試數據覆蓋多個(gè)測試用例，這樣可以提高效率，前提是程序的質(zhì)量還可以或者可以根據測試結果(結果數據和log)定位是哪個(gè)功能點(diǎn)的問(wèn)題。
4、如果時(shí)間充足的話(huà)，測試要在安靜的環(huán)境中不慌不忙地進(jìn)行，這樣容易聯(lián)想到更多的測試功能點(diǎn)，也可能因此發(fā)現更多的bug。如果測試太匆忙，通常測試人員只是想盡快地執行完所有測試用例。
5、如果測試還要進(jìn)行多個(gè)版本，則需要不斷完善測試用例，并總結為什么一開(kāi)始會(huì )遺漏這些測試點(diǎn)。
6、測試的目的是發(fā)現bug，不是執行完所有用例或者覆蓋盡可能多的路徑。所以如果全面的測試已無(wú)益于發(fā)現新的bug時(shí)，要讓測試人員充分發(fā)揮自己的主觀(guān)能動(dòng)性，隨機地對可疑的地方進(jìn)行測試。
7、發(fā)現bug時(shí)要確定自己操作和理解沒(méi)有問(wèn)題再向開(kāi)發(fā)人員提出，而且要注意表達方式。
8、平日最好能和開(kāi)發(fā)人員保持不錯的關(guān)系，這樣有利于測試的進(jìn)行。
9、不要迷信功能測試的自動(dòng)化，我認為只有在版本穩定后還需要進(jìn)行多個(gè)版本的測試時(shí)才需要測試自動(dòng)化，而且要求測試人員都可以熟練使用測試自動(dòng)化工具。自動(dòng)化測試的最大困難可能是需求和界面的頻繁變化。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
