注意對一些元數據增刪改后的測試，尤其注意如有其他地方引用了這些屬性，則禁止相關操作，這是系統的關聯性注意與數據庫的關聯查詢在測試初期，要分清主次，輕重緩急，先對主流功能進行測試。

不要在已經驗證為錯誤的功能上延伸測試，錯誤的錯誤還是錯誤注意界面中一些默認值的設置，增添系統的人性化設計如果需要進行下一個版本的測試，需要群發郵件。

測試執行分以下幾個階段：冒煙測試、功能測試、容錯性測試、性能測試、UI測試。冒煙測試是主要功能測試，是線的測試。功能測試是細分的功能點的測試，是點的測試。容錯性測試、性能測試的測試點不一樣，要看不同的項目涉及的業務，以用戶的關注點來定。

UI測試主要針對三點：正確、規范、美觀協調。

經驗：程序中所有可能有的錯誤和容易發生錯誤的特殊情況。

測試人員最好能在開發開始之前，總結出一個列表，列表中列出需要開發人員統一處理的一些細節，比如表單中表頭和表內容用什么字體字號；是左對齊還是居中；翻頁控件是放在表單左下角還是右下角還是居中；標點符號是用中文半角還是全角；選擇框和下拉菜單中的內容按什么排序；搜索結果是否需要排序；錯誤提示是彈出窗口還是顯示在原界面；錯誤提示語也應盡量統一風格；查詢后是否要保存查詢條件；瀏覽器的前進后退是否需要限制等等。項目經理最好統一給開發人員講一下這些規矩，這樣會在測試時省很多事。

盡可能考慮到測試過程中的風險，比如測試環境的問題、部署失敗的問題、開發延期的問題、人員變動的問題等。

1、測試用例要因人而異，如果自己已經很熟練了，測試用例可以只是簡單的提示，不需寫出詳細的執行步驟和測試數據，以免因為無謂的文檔浪費太多時間。如果很可能別人還要復用你的測試用例而且有充足的時間，這時就可以把測試用例寫詳細點。

1)如果時間允許，測試一個頁面時，要把這個頁面的所有功能點的正常異常情況都測完之后再去測下一個頁面，這樣不容易遺漏。大多時候時間都不很充足，這時要先測主要流程和主要的功能點，這些完成之后再去測細節和異常情況，因為并不是有bug就不能上線的。

2)至于測試數據需不需要在設計測試用例時就寫出需要根據實際項目情況來定，我一般認為最好把測試用例都寫完之后，再準備測試數據，一條數據可以覆蓋多個測試用例，這樣很可能四五條數據就可以覆蓋十幾個測試用例，這樣可以提高效率。教科書通常認為一條測試數據最好對應一個測試用例，這樣測試執行失敗時就容易定位問題出在哪里。但實際情況是只有極少數的測試會執行失敗并因此發現bug，但如果因為這極少數的失敗的情況來降低整個測試執行的效率就顯得缺乏實踐性了，況且并不是說一條測試數據覆蓋了多個用例時就不容易定位錯誤的根源。所以測試要根據實際情況靈活進行。

3)如果要寫詳細的測試用例，就一定要寫的非常的清楚明了，最好讓一個不懂項目情況的人也能根據用例執行測試。而且測試用例和測試數據中的關鍵值一定要用顏色標出。最好還能寫出每條用例的測試目的，這樣方便日后別人補充你的測試用例。

2、如果發現了很多界面性的小問題，不要連續提出，最好先提一兩個功能性的問題，再提一兩個界面性的問題，這樣間隔著提bug有利于開發人員接收，免得他把你提的連續的四五個界面性的bug都拒絕了。另外，一個bug 里最好不要既包括功能性問題又包括界面性問題，這樣有可能開發人員只解決了功能性問題就把bug 關了。

21/212>

總結

以上是生活随笔為你收集整理的软件测试工作的感想怎么写,软件测试工作中的一些感悟的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。