1、 測試人員需要何時(shí)參加需求分析？
原則上，測試人員對需求了解得越深入對測試工作越有利，所以最好一開(kāi)始就應該參加需求分析工作。這樣可以帶來(lái)如下好處：
測試人員全程參與需求分析，對需求了解很深刻，減少了很多與開(kāi)發(fā)人員的交互，節省了時(shí)間。測試人員參與前期開(kāi)發(fā)討論，直接掌握了不清晰的需求點(diǎn)；
早期確定測試用例的編寫(xiě)思路，為項目（產(chǎn)品）測試打好了基礎；
可以獲取一些測試數據，為測試用例設計提供幫助；
可以發(fā)現需求不合理的地方，降低了測試成本。
測試人員主要的工作之一就是確認系統是否正確實(shí)現了需求。測試人要不參與前期的工作，就只能依賴(lài)最后形成的需求文檔，甚至由開(kāi)發(fā)人員來(lái)講解需求，而這些需求可能發(fā)生了“問(wèn)題”，因為這個(gè)需求是已經(jīng)經(jīng)過(guò)分析的需求，很多的內容可能與用戶(hù)的真正要求發(fā)生了偏差。同時(shí)如果只看最后形成的需求文檔，對需求也會(huì )有理解上的偏差。因此作為測試人員要盡可能的獲取到“第一線(xiàn)”的需求資料，才能真正地了解用戶(hù)的業(yè)務(wù)，從而更好的對系統進(jìn)行測試。
當然，如果測試人員不能參與需求環(huán)節，一定要通過(guò)其他途徑保證需求的正確性，例如和開(kāi)發(fā)人員進(jìn)行集中討論需求疑問(wèn)的項目會(huì )議，并且一定要加強測試案例評審，甚至于是測試需求的評審。
2、 系統測試階段低級缺陷較多怎么辦？
在系統測試階段，如果仍有很多低級缺陷，說(shuō)明測試對象是不合格的，沒(méi)有達到測試標準。如果系統階段發(fā)現的簡(jiǎn)單缺陷（也就是不應該有的缺陷）較多，最好停止測試，反饋給開(kāi)發(fā)人員進(jìn)行測試，發(fā)現問(wèn)題立刻修改，因為這種由測試人員進(jìn)行測試的成本較高，反復交互還會(huì )耽誤項目進(jìn)度。
建議建立預測試制度：系統測試前對核心模塊進(jìn)行抽查測試，如果問(wèn)題較多（例如核心功能存在20個(gè)以上的缺陷），就可以停止本次測試，反饋給開(kāi)發(fā)組進(jìn)行測試，直到抽測后問(wèn)題較少才可以啟動(dòng)系統測試。
3、 缺陷流落到客戶(hù)那里有什么后果？
如果軟件缺陷被遺落到客戶(hù)那里，結果就是代價(jià)高昂的電話(huà)或現場(chǎng)支持費用，還可能需要修復、重新測試和發(fā)布新的產(chǎn)品，更糟糕的情況是產(chǎn)品要被召回甚至被客戶(hù)起訴。這種成本付出非常高，幾乎是在內部修改缺陷的幾倍，甚至十幾倍。
質(zhì)量之父PhilipCrosby把質(zhì)量的費用分為整合費用和非整合費用兩類(lèi)，整合費用是指與一次性計劃和執行測試相關(guān)的全部費用，用于保證軟件按照預期方式進(jìn)行。如果發(fā)現缺陷，經(jīng)過(guò)一系列的缺陷處理流程而解決缺陷，這種費用就是非整合費用。PhilipCrosby在自己的作品中詳細論述了內部的整合費用和內部的非整合費用之和遠遠小于外部也就是客戶(hù)引起的非整合費用。
軟件測試是保證軟件質(zhì)量的有效手段，但不是唯一手段。高質(zhì)量的軟件不是測試出來(lái)的，而是設計出來(lái)。這就需要全員一起參與，提高全員的質(zhì)量意識，共同提高軟件的質(zhì)量。
總之，軟件缺陷一定要盡可能的在內部解決，這對節約成本、提高產(chǎn)品知名度都大有意義的。
4、 狀態(tài)為已經(jīng)修改的缺陷沒(méi)有修改怎么辦？
首先對這類(lèi)缺陷進(jìn)行分析：
（1）有些問(wèn)題在開(kāi)發(fā)環(huán)境下沒(méi)有重現，而開(kāi)發(fā)人員迫于進(jìn)度壓力，往往會(huì )把它標記為已經(jīng)修改。這種條件下測試人員應該和開(kāi)發(fā)人員進(jìn)行直接溝通；
（2）有些問(wèn)題測試人員沒(méi)有描述清楚，開(kāi)發(fā)人員認為問(wèn)題不存在也可能把問(wèn)題標記為已經(jīng)修改（正確的作法是標記問(wèn)題為商討或者不可再現狀態(tài)）。測試人員應該清晰的描述問(wèn)題，減少這類(lèi)問(wèn)題的發(fā)生，尤其要描述清楚運行的環(huán)境以及缺陷的重現步驟；
（3）第三類(lèi)情況純屬個(gè)人行為：迫于進(jìn)度壓力，開(kāi)發(fā)人員來(lái)不及修改問(wèn)題，會(huì )故意把一些問(wèn)題標記為修改，這樣就可以在下次測試后進(jìn)行修改。解決這種問(wèn)題的方法就是統計缺陷的修改次數，分析出哪些反復修改的缺陷歸屬于哪些開(kāi)發(fā)人員，然后告知項目經(jīng)理；（由可能和績(jì)效考核結合起來(lái)。）測試人員遇到這種情況，需要重新打開(kāi)哪些未被修改而狀態(tài)為修改標記的缺陷。
決這種問(wèn)題的根本方法就是加強項目管理，提高項目執行能力，一旦資源較充裕時(shí)，測試人員和開(kāi)發(fā)人員就會(huì )更加投入的一起解決缺陷，共同來(lái)提高軟件質(zhì)量。這就需要在制定項目計劃時(shí)盡量要合理。
5、 產(chǎn)品測試完成后產(chǎn)品由誰(shuí)來(lái)發(fā)布？
很多時(shí)候產(chǎn)品經(jīng)過(guò)最后一次測試后由開(kāi)發(fā)人員來(lái)發(fā)布，或由質(zhì)量管理部來(lái)發(fā)布，這樣做都是不合適的。
開(kāi)發(fā)人員發(fā)布產(chǎn)品常常會(huì )導致缺陷解決不徹底。一種較常見(jiàn)的現象是最后一次回歸測試后，開(kāi)發(fā)人員修改完成最后幾個(gè)缺陷直接從開(kāi)發(fā)環(huán)境發(fā)布產(chǎn)品，這種條件下實(shí)際是缺陷一次測試，因為修改缺陷通常會(huì )引入新的缺陷，甚至是嚴重的缺陷。
測試人員發(fā)布產(chǎn)品也不符合流程的，測試人員的職責是報告軟件質(zhì)量情況。而且測試人員發(fā)布產(chǎn)品容易帶來(lái)版本管理混亂。
正確的做法是產(chǎn)品經(jīng)過(guò)最后一次測試后，把產(chǎn)品和缺陷修改情況存入產(chǎn)品基線(xiàn)庫，形成一個(gè)可以發(fā)布的版本。這樣發(fā)布產(chǎn)品的一個(gè)前提是每次產(chǎn)品提交測試前都要有一個(gè)預備發(fā)布版本，測試或者回歸測試后如果有問(wèn)題需要修改解決，開(kāi)發(fā)人員對該預備版本進(jìn)行修改。如此反復多次后，直到最后一次測試，所有缺陷都得到修改或者審核，同時(shí)開(kāi)發(fā)人員此次測試后沒(méi)有對產(chǎn)品經(jīng)過(guò)任何修改，我們就可以把這個(gè)最后一個(gè)預備發(fā)布版本存入基線(xiàn)庫。
進(jìn)行了上面正確的版本控制后，我們可以通過(guò)配置管理庫進(jìn)行產(chǎn)品發(fā)布管理。對外部發(fā)布產(chǎn)品時(shí)，直接從配置管理庫中提取就可以了。
6、 用戶(hù)試用階段產(chǎn)生的新需求或修改意見(jiàn)由誰(shuí)來(lái)處理？
在試用階段用戶(hù)會(huì )提出一些新的需求或修改意見(jiàn)，這些意見(jiàn)的反饋渠道應該是怎么樣的呢？是反饋給測試人員、質(zhì)量保證人員、項目經(jīng)理還是項目的負責人？實(shí)際情況證實(shí)，這些新的需求或修改意見(jiàn)，反饋給項目經(jīng)理或項目的負責人是最好的渠道，這樣項目經(jīng)理或項目負責人能夠直接得到項目的修改意見(jiàn)或新增需求，而不是其他人員的轉述。還因為項目經(jīng)理或項目負責人是項目的設計者、開(kāi)發(fā)者，他們對軟件系統最熟悉，對于用戶(hù)提出來(lái)的新的需求或修改意見(jiàn)可以根據系統的實(shí)際情況，應允合理的需求和合理的修改意見(jiàn)。屏蔽一些不合理的需求或修改意見(jiàn)，或給用戶(hù)一個(gè)合理的不能修改的解釋。
如果先給測試人員或是質(zhì)量保證人員，效果不會(huì )很好；首先測試人員得到新的需求或修改意見(jiàn)后，不能馬上確認是否修改，不清楚修改這些功能的工作量和是否有技術(shù)上的難點(diǎn)等疑問(wèn)。其次在測試人員得到需要后，仍需要轉述給項目經(jīng)理或項目負責人，這樣在一定程度上浪費了一些時(shí)間。主要表現在，如果測試人員沒(méi)有完全理解新的需求或修改意見(jiàn)，這樣在轉述的時(shí)候就會(huì )有偏差，還得需要項目經(jīng)理或項目負責人在對需求或修改意見(jiàn)進(jìn)行再次確認，這樣就產(chǎn)生了不必要的工作量。
聯(lián)系客服
