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

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

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

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

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

可以發(fā)現(xiàn)需求不合理的地方，降低了測試成本。

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

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

2、 系統(tǒng)測試階段低級缺陷較多怎么辦？

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

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

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

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

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

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

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

4、 狀態(tài)為已經(jīng)修改的缺陷沒有修改怎么辦？

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

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

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

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

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

5、 產(chǎn)品測試完成后產(chǎn)品由誰來發(fā)布？

很多時候產(chǎn)品經(jīng)過最后一次測試后由開發(fā)人員來發(fā)布，或由質(zhì)量管理部來發(fā)布，這樣做都是不合適的。

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

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

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

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

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

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

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