最近公司的產品一直忙於測試，看著每天的bug不斷的增加和修正，真是痛並快樂著，痛苦是因為bug不斷的出現，快樂是看著bug乙個乙個的被消滅，把這些天的測試開發過程總結一下。
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、測試經驗的總結
測試的過程很枯燥，而測試過程中發現的測試經驗是十分重要的，不斷的調整測試的策略、流程，多總結和借鑑別人的測試經驗，會更好的提高測試質量。