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