（3）第三類情況純屬個人行為：迫于進度壓力，開發人員來不及修改問題，會故意把一些問題標記為修改，這樣可以在下次測試后進行修改。解決這種問題方法是統計缺陷的修改次數，分析出那些反復修改的缺陷歸屬于那些開發人員，然后和績效考核結合起來。（測試人員也可以這樣做，把一些未驗證的缺陷標記為“重新打開”，讓開發人員來幫忙“驗證”，我們仍然可以統計這種問題的次數，后根據時間進行分析。）

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

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

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

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

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

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

　　進行了上面正確的版本控制后，我們可以通過配置管理庫進行產品發布管理。對外部發布產品時，直接從配置管理庫中提取可以了。詳細的內容，讀者可以參考配置管理方面的書籍。

　　11、性能測試什么時候開展為合適？

　　大多數情況下，性能測試在系統測試的后階段進行階段進行。這主要是由于性能測試是一種綜合性的測試，只有在功能測試通過后，談系統測試才會有較大意義。但下列兩類情況比較特殊，性能測試一般進行的較早，幾乎伴隨著單元測試同步進行：

　　第一類是系統軟件，例如開發操作系統或者數據庫，等系統開發完成后再進行性能的作用是進行一個綜合評估。如果在后發現性能問題，很有可能推翻整個系統。

　　第二類是對性能要求較高的應用軟件。例如銀行、電信的系統，對系統的性能要遠遠高于一般的辦公自動化系統。這類系統軟件后測試時發現性能問題，往往是系統架構或者一些關鍵算法、重要功能模塊的原因，這個時候會帶來較大的改動，甚至可能報廢整個系統。

　　對于上面兩類軟件，性能測試應該貫穿著整個軟件開發過程，大致要經過下面幾個測試過程：

　　（1）單元性能測試階段。上面這兩類軟件的性能測試后從單元測試階段應該介入，具體做法是安排性能測試工程師對一些重要算法進行測試，保證這些算法能夠滿足性能要求。這樣做的好處是把問題盡早解決，可以大大提高整體性能。

　　（2）組成/集成性能測試階段。這個階段的性能測試是前面的深入，相當于把系統測試階段的組合業務性能測試提前進行，可以把一些性能問題在集成測試階段發現并解決。

　　（3）系統測試階段的性能測試。這個階段的性能測試是一個全面的性能測試，有了前面的基礎，這個時候發現的問題很更加容易解決。