一、準確理解需求。
我認為測試首先要準確的了解系統是干什么的，要達到一個什么樣的效果。設計階段中就已經確定了什么事情系統是能夠完成的，什么事情是系統不能夠做的。測試不但是各個功能單獨的測試，最好能夠從整體上了解整個系統的結構，流程等等。理解需求，包括兩方面，一個從我們程序的角度，即我們的詳細設計文檔所描述的具體的什么表，什么字段等來了解。了解什么功能的實現跟那些表，那些字段有關，做了某些操作后，這些表的字段應該發生了什么樣的變化。這些都是建立在對系統的深刻理解的基礎上面的。另一方面，從客戶哪個角度去理解需求，因為客戶不會管我們實現這些功能具體是怎樣實現的。但是他們對業務的理解會比較深，有些情況（情景）是要在實際操作的時候，才可能考慮得到。對需求的準確理解是驗證程序的正確性的最重要的要求。如果測試的過程中不清楚系統應該實現的怎樣的功能,必須通過各種途徑了解清楚。
二、測試重點要分明。
測試整個系統的過程中，對一些關鍵的重要功能測試，必須重視它，反復進行測試。根據可能出現的種種情況進行測試。因為這些關鍵的部分有問題會引起其他相關的一連串的錯誤。
三、測試案例的準備和保留。
對于系統整個流程的各個功能，每個功能的各種應用的情形，準備好相應的情形的數據,(做好備份),以備修改好后可以重現或檢查。理想狀態下應有完整的記錄說明，什么樣的數據是做什么測試用的.
有些經常要用到的測試，最好能夠另外編寫很簡單的測試驅動程序�？梢詫懶⿲ｉT用于校對數據的準確性的小程序。案例的準備數據和應有正確結果對于回歸測試特別有意義。
四、溝通技巧
溝通的時機主要是一個測試前，一個在測試后。測試前務必了解清楚系統的功能點。測試員必須不恥下問，程序員回答測試員問題的時候也不應該感到厭煩.第一點中已經有過這方面的說明。測試員在問程序員問題之前，最好自己首先閱讀相關的設計文檔和數據庫結構.心中有底之后，再帶著疑問去咨詢，會取得比較好的效果。對需求有了準確的理解后，做好數據準備后開始測試，測試完成后,記錄測試結果。發現問題的時候要重復多次，最好能夠重現錯誤。有些錯誤確實不能每次都重現的話，盡量回憶清楚發生的情景是怎樣的，好描述或演示給程序員看。有的時候，可能確實不是程序的錯誤，而是操作不當引起的。這種情況應該區分好，有的時候應該堅持自己的理解，當雙方對同一個問題的理解出現分歧的時候，必須找系統分析員或項目經理確認一下誰的理解是正確的。溝通的時候，測試員要很耐心的聆聽對方的意見。有的時候以郵件的方式溝通比較好，不要所有的溝通都以口頭完成.當雙方都比較煩躁的時候，可以暫時把問題放在一邊，不要爭吵。等大家平靜下來的時候再繼續討論問題。
五、測試的順序
測試有單元測試，集成測試和壓力測試等，還有白盒測試，黑盒測試等分類.我覺得測試一般來說先進行功能性測試，然后再進行壓力測試.可以借助一些工具來輔助測試。測試的數據不能太少，有時數據太少就不能暴露出某些問題。集成測試的時候,重點測試各個接口,這時對整個系統的全局的了解,整個流程怎么走必須心中有數。通過測試驅動開發，從而提高軟件的質量。
六、測試的分工合作。
測試的時候是很需要老老實實的執行程序的，千萬不能想當然。測試需要分工合作,測試計劃和案例跟著需求變動，特別是后期需求發生了變化，時間又緊迫的情況下，測試的文檔就很容易跟不上。到后期編碼任務基本完成后交付給客戶之前需要進行詳盡的完整的測試。以前我們會進行交叉測試，但效果不是很理想。測試后集中修改，必須進行回歸測試。特別是項目后期的集成測試的時候，最好能夠大家有計劃的安排好測試的內容，準備好一些數據可以從頭走到尾，盡量覆蓋比較多的案例情況。盡可能不讓重要的Bug逃逸。
七、如何面對客戶
前面第四點描述的是我們內部的溝通。當我們有機會面對客戶的時候，也要注意跟客戶的溝通技巧。用心聆聽客戶的聲音。不能先入為主的認為我們的程序就是完全正確的，客戶什么都不懂，或者客戶是在提無理的要求。我們認真的聽取客戶的意見，把需求收集起來，去蕪存精。然后我們再根據實際的情況決定是否修改程序。如果有的時候確實不能修改程序的時候，也要耐心跟客戶解釋清楚。
以上就是在做測試的過程中的一點點心得，歡迎大家能夠多點交流各自的心得體會。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
