談談測試中的常見問題及解決意見

1、 測試人員需要何時參加需求分析？

原則上，測試人員對需求了解得越深入對測試工作越有利，所以最好一開始就應該參加需求分析工作。這樣可以帶來如下好處：

測試人員全程參與需求分析，對需求了解很深刻，減少了很多與開發人員的交互，節省了時間。測試人員參與前期開發討論，直接掌握了不清晰的需求點；

早期確定測試用例的編寫思路，為項目（產品）測試打好了基礎；

可以獲取一些測試數據，為測試用例設計提供幫助；

可以發現需求不合理的地方，降低了測試成本。

測試人員主要的工作之一就是確認系統是否正確實現了需求。測試人要不參與前期的工作，就只能依賴最后形成的需求文檔，甚至由開發人員來講解需求，而這些需求可能發生了“問題”，因為這個需求是已經經過分析的需求，很多的內容可能與用戶的真正要求發生了偏差。同時如果只看最后形成的需求文檔，對需求也會有理解上的偏差。因此作為測試人員要盡可能的獲取到“第一線”的需求資料，才能真正地了解用戶的業務，從而更好的對系統進行測試。

當然，如果測試人員不能參與需求環節，一定要通過其他途徑保證需求的正確性，例如和開發人員進行集中討論需求疑問的項目會議，并且一定要加強測試案例評審，甚至于是測試需求的評審。

2、 系統測試階段低級缺陷較多怎么辦？

在系統測試階段，如果仍有很多低級缺陷，說明測試對象是不合格的，沒有達到測試標準。如果系統階段發現的簡單缺陷（也就是不應該有的缺陷）較多，最好停止測試，反饋給開發人員進行測試，發現問題立刻修改，因為這種由測試人員進行測試的成本較高，反復交互還會耽誤項目進度。

建議建立預測試制度：系統測試前對核心模塊進行抽查測試，如果問題較多（例如核心功能存在20個以上的缺陷），就可以停止本次測試，反饋給開發組進行測試，直到抽測后問題較少才可以啟動系統測試。

3、 缺陷流落到客戶那里有什么后果？

如果軟件缺陷被遺落到客戶那里，結果就是代價高昂的電話或現場支持費用，還可能需要修復、重新測試和發布新的產品，更糟糕的情況是產品要被召回甚至被客戶起訴。這種成本付出非常高，幾乎是在內部修改缺陷的幾倍，甚至十幾倍。

質量之父PhilipCrosby把質量的費用分為整合費用和非整合費用兩類，整合費用是指與一次性計劃和執行測試相關的全部費用，用于保證軟件按照預期方式進行。如果發現缺陷，經過一系列的缺陷處理流程而解決缺陷，這種費用就是非整合費用。PhilipCrosby在自己的作品中詳細論述了內部的整合費用和內部的非整合費用之和遠遠小于外部也就是客戶引起的非整合費用。

軟件測試是保證軟件質量的有效手段，但不是唯一手段。高質量的軟件不是測試出來的，而是設計出來。這就需要全員一起參與，提高全員的質量意識，共同提高軟件的質量。

總之，軟件缺陷一定要盡可能的在內部解決，這對節約成本、提高產品知名度都大有意義的。

4、 狀態為已經修改的缺陷沒有修改怎么辦？

首先對這類缺陷進行分析：

（1）有些問題在開發環境下沒有重現，而開發人員迫于進度壓力，往往會把它標記為已經修改。這種條件下測試人員應該和開發人員進行直接溝通；

（2）有些問題測試人員沒有描述清楚，開發人員認為問題不存在也可能把問題標記為已經修改（正確的作法是標記問題為商討或者不可再現狀態）。測試人員應該清晰的描述問題，減少這類問題的發生，尤其要描述清楚運行的環境以及缺陷的重現步驟；

（3）第三類情況純屬個人行為：迫于進度壓力，開發人員來不及修改問題，會故意把一些問題標記為修改，這樣就可以在下次測試后進行修改。解決這種問題的方法就是統計缺陷的修改次數，分析出哪些反復修改的缺陷歸屬于哪些開發人員，然后告知項目經理；（由可能和績效考核結合起來。）測試人員遇到這種情況，需要重新打開哪些未被修改而狀態為修改標記的缺陷。

決這種問題的根本方法就是加強項目管理，提高項目執行能力，一旦資源較充裕時，測試人員和開發人員就會更加投入的一起解決缺陷，共同來提高軟件質量。這就需要在制定項目計劃時盡量要合理。

5、 產品測試完成后產品由誰來發布？

很多時候產品經過最后一次測試后由開發人員來發布，或由質量管理部來發布，這樣做都是不合適的。

開發人員發布產品常常會導致缺陷解決不徹底。一種較常見的現象是最后一次回歸測試后，開發人員修改完成最后幾個缺陷直接從開發環境發布產品，這種條件下實際是缺陷一次測試，因為修改缺陷通常會引入新的缺陷，甚至是嚴重的缺陷。

測試人員發布產品也不符合流程的，測試人員的職責是報告軟件質量情況。而且測試人員發布產品容易帶來版本管理混亂。

正確的做法是產品經過最后一次測試后，把產品和缺陷修改情況存入產品基線庫，形成一個可以發布的版本。這樣發布產品的一個前提是每次產品提交測試前都要有一個預備發布版本，測試或者回歸測試后如果有問題需要修改解決，開發人員對該預備版本進行修改。如此反復多次后，直到最后一次測試，所有缺陷都得到修改或者審核，同時開發人員此次測試后沒有對產品經過任何修改，我們就可以把這個最后一個預備發布版本存入基線庫。

進行了上面正確的版本控制后，我們可以通過配置管理庫進行產品發布管理。對外部發布產品時，直接從配置管理庫中提取就可以了。

6、 用戶試用階段產生的新需求或修改意見由誰來處理？

在試用階段用戶會提出一些新的需求或修改意見，這些意見的反饋渠道應該是怎么樣的呢？是反饋給測試人員、質量保證人員、項目經理還是項目的負責人？實際情況證實，這些新的需求或修改意見，反饋給項目經理或項目的負責人是最好的渠道，這樣項目經理或項目負責人能夠直接得到項目的修改意見或新增需求，而不是其他人員的轉述。還因為項目經理或項目負責人是項目的設計者、開發者，他們對軟件系統最熟悉，對于用戶提出來的新的需求或修改意見可以根據系統的實際情況，應允合理的需求和合理的修改意見。屏蔽一些不合理的需求或修改意見，或給用戶一個合理的不能修改的解釋。

如果先給測試人員或是質量保證人員，效果不會很好；首先測試人員得到新的需求或修改意見后，不能馬上確認是否修改，不清楚修改這些功能的工作量和是否有技術上的難點等疑問。其次在測試人員得到需要后，仍需要轉述給項目經理或項目負責人，這樣在一定程度上浪費了一些時間。主要表現在，如果測試人員沒有完全理解新的需求或修改意見，這樣在轉述的時候就會有偏差，還得需要項目經理或項目負責人在對需求或修改意見進行再次確認，這樣就產生了不必要的工作量。

原文轉自：http://www.anti-gravitydesign.com