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

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

測試執(zhí)行分以下幾個階段：冒煙測試、功能測試、容錯性測試、性能測試、UI測試。冒煙測試是主要功能測試，是線的測試。功能測試是細(xì)分的功能點的測試，是點的測試。容錯性測試、性能測試的測試點不一樣，要看不同的項目涉及的業(yè)務(wù)，以用戶的關(guān)注點來定。

UI測試主要針對三點：正確、規(guī)范、美觀協(xié)調(diào)。

經(jīng)驗：程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況。

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

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

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

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

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

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

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

21/212>

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。