做這個工作也有一段時間，總結幾點經驗，大家分享一下：
1、測試要盡早
公司的產品已經修訂一段時間了，但是由于任務繁忙和人手不足，因此測試一直拖后，因此當進行集中測試的時候Bug集中爆發，因此感覺更加的繁忙，另外由于很多功能和修訂，都已經修改了很長的時間，因此程序員再次進入修改的時候，往往需要重新分析和理解，造成Bug的修復周期延長了很多。
建議當完成功能修訂后，要盡快進入測試狀態，以縮短Bug的存在時間，降低程序員修訂成本。
2、使用好的缺陷管理工具
之前公司只是使用一個BBS作為缺陷的跟蹤和管理工具，但是，效果很不理想，雖然缺陷管理的工具很多，但是都有自己的長處和短處，后來使用了TD，效果的確好的多。
3、缺陷描述要準確
很多測試人員反饋的缺陷，程序員讀起來十分的費勁，甚至比理解缺陷本身還要難懂，因此，如果發現缺陷后，在登記的時候，一定要盡量描述準確和清晰，以免造成錯誤的理解，反而更加干擾缺陷的修訂。如果缺陷的確很難描述，可以將缺陷的發生過程錄制下來，或者干脆手工給程序員演示一遍，效果就更好了。
4、缺陷描述不完整
很多缺陷都是有前世和今生的，因此把缺陷產生的出發條件描述的完整，對解決缺陷起著很重要的作用。
5、缺陷要分等級
缺陷都是要優先級別的，嚴重的當然要盡快解決，低級別的放一放。
6、開發和測試最好不同步
公司是早上8：30上班，一般是9：00左右才能給測試部一個新的測試版本，而如果Build出現意外，則新的版本發布就會推遲，因此開發和測試一定要有個時間差，開發部最好在早上第1時間給測試部一個最新的測試版本。一種是開發部早點來，一種是晚點走，最后我們的約定是下午4:30分開發部Build版本給測試部明天使用。
7、優先驗證Fixed狀態的缺陷
測試部每天最優先的任務就是驗證新版本中Fixed狀態的缺陷是否正確，這個很主要，因為開發部剛剛修正，如果沒有驗證通過，程序員可以立刻進行修訂，如果過了很長時間才通知沒有通過，那么可能程序員還得重新理解和分析代碼。
8、一個缺陷報告包含多個缺陷
有些時候測試人員在一個測試報告中，包含N(N>=1)個缺陷，結果程序員修訂了其中一個，另一個需要拒絕掉，結果缺陷的狀態就失去效果了，因此一個缺陷記錄只能包含一個缺陷，如果存在多個就是測試人員的責任了。
9、交叉測試的重要性
我們最初安排測試的時候，是某個測試人員只測試其中一部分，另外的測試人員測試另外一部分，過了幾天后發現，每個測試人員的Bug檢測數量都下降了，原來，測試人員對自己部分已經發現不出來缺陷了，后來采用了交叉測試的方式，就是測試人員交換測試工作，結果不同的人從不同的角度進行測試，結果一些缺陷又發現了，因此交叉測試很重要。
10、測試經驗的總結
測試的過程很枯燥，而測試過程中發現的測試經驗是十分重要的，不斷的調整測試的策略、流程，多總結和借鑒別人的測試經驗，會更好的提高測試質量。
以上是個人意見，供大家分享
文章來源于領測軟件測試網 http://www.k11sc111.com/
