首先對這類缺陷進行分析：
(1)有些問題在開發環境下沒有重現，而開發人員迫于進度壓力，往往會把它標記為已經修改。這種條件下測試人員應該和開發人員進行直接溝通;
(2)有些問題測試人員沒有描述清楚，開發人員認為問題不存在也可能把問題標記為已經修改(正確的作法是標記問題為商討或者不可再現狀態)。測試人員應該清晰的描述問題，減少這類問題的發生，尤其要描述清楚運行的環境以及缺陷的重現步驟;
(3)第三類情況純屬個人行為：迫于進度壓力，開發人員來不及修改問題，會故意把一些問題標記為修改，這樣就可以在下次測試后進行修改。解決這種問題的方法就是統計缺陷的修改次數，分析出哪些反復修改的缺陷歸屬于哪些開發人員，然后告知項目經理;(由可能和績效考核結合起來。)測試人員遇到這種情況，需要重新打開哪些未被修改而狀態為修改標記的缺陷。
決這種問題的根本方法就是加強項目管理，提高項目執行能力，一旦資源較充裕時，測試人員和開發人員就會更加投入的一起解決缺陷，共同來提高軟件質量。這就需要在制定項目計劃時盡量要合理。
5、 產品測試完成后產品由誰來發布?
很多時候產品經過最后一次測試后由開發人員來發布，或由質量管理部來發布，這樣做都是不合適的。
開發人員發布產品常常會導致缺陷解決不徹底。一種較常見的現象是最后一次回歸測試后，開發人員修改完成最后幾個缺陷直接從開發環境發布產品，這種條件下實際是缺陷一次測試，因為修改缺陷通常會引入新的缺陷，甚至是嚴重的缺陷。
測試人員發布產品也不符合流程的，測試人員的職責是報告軟件質量情況。而且測試人員發布產品容易帶來版本管理混亂。
正確的做法是產品經過最后一次測試后，把產品和缺陷修改情況存入產品基線庫，形成一個可以發布的版本。這樣發布產品的一個前提是每次產品提交測試前都要有一個預備發布版本，測試或者回歸測試后如果有問題需要修改解決，開發人員對該預備版本進行修改。如此反復多次后，直到最后一次測試，所有缺陷都得到修改或者審核，同時開發人員此次測試后沒有對產品經過任何修改，我們就可以把這個最后一個預備發布版本存入基線庫。
進行了上面正確的版本控制后，我們可以通過配置管理庫進行產品發布管理。對外部發布產品時，直接從配置管理庫中提取就可以了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
