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