6、什么是測試策略？

　　測試策略描述測試工程的總體方法和目標。描述目前在進行哪一階段的測試（單元測試、集成測試、系統(tǒng)測試）以及每個階段內(nèi)在進行的測試種類（功能測試、性能測試、覆蓋測試等）。

　　測試策略的制定主要包含三個方面的內(nèi)容：

　。1）確定測試過程要使用的測試技術和工具；

　　（2）制定測試啟動、停止、完成標準；

　　（3）進行風險分析和應對方案。例如測試與外部接口或者模擬物理損壞、安全性威脅。測試計劃關鍵的一步是將軟件分解成單元，按照需求編寫測試計劃。

　　7、代碼會審是如何進行的？

　　在研發(fā)小組將所開發(fā)的程序經(jīng)驗證后，提交測試組后，測試實施工作基本開始了。這個時候，測試人員要仔細閱讀有關資料，包括規(guī)格說明、設計文檔、使用說明書及在設計過程中形成的測試大綱、測試內(nèi)容及測試的通過準則，全面熟悉系統(tǒng)，編寫測試計劃，設計測試用例，作好測試前的準備工作。為了保證測試的質(zhì)量，我們一般測試過程分成幾個階段，即：代碼審查、單元測試、集成測試和驗收測試。

　　代碼會審是由一組人通過閱讀、討論和爭議對程序進行靜態(tài)分析的過程。會審小組由組長，2～3名程序設計和測試人員及程序員組成。會審小組在充分閱讀待審程序文本、控制流程圖及有關要求、規(guī)范等文件基礎上，召開代碼會審會，程序員逐句講解程序的邏輯，并展開熱烈的討論甚至爭議，以揭示錯誤的關鍵所在。實踐表明，程序員在講解過程中能發(fā)現(xiàn)許多自己原來沒有發(fā)現(xiàn)的錯誤，而討論和爭議則進一步促使了問題的暴露。例如，對某個局部性小問題修改方法的討論，可能發(fā)現(xiàn)與之有牽連的甚至能涉及到模塊的功說明、模塊間接口和系統(tǒng)總結(jié)構(gòu)的大問題，導致對需求定義的重定義、重設計驗證，大大改善了軟件的質(zhì)量。

　　代碼會審盡管需要一定的成本，但是在大型軟件中，是必不可少的。

　　8、回歸測試中未解決的缺陷如何處理？

　　軟件的后期測試是一個反復回歸的工作，有些問題可能修改多次才能解決，尤其是那些在開發(fā)環(huán)境下不存在的問題，這些問題很容易被程序員忽視，拖到后才解決。因此大部分回歸測試是和開發(fā)人員反復配合解決那些上次測試中沒有解決的缺陷。

　　這里重點討論的是后一次回歸測試后，仍然發(fā)現(xiàn)有些缺陷沒有解決時測試經(jīng)理應該如何做。在管理不規(guī)范的組織中，由于進度或者其它方面的壓力，開發(fā)工作已經(jīng)停止，通常會將這些問題置之不理。正確的做法時把這些沒有解決的問題形成一個未解決缺陷報告，然后召開項目會議進行討論，對不同的問題采取不同的處理方式：

　　（1）嚴重性的問題：有些問題較難解決，往往會被拖到后，如果這類缺陷導致軟件功能發(fā)生障礙，則必須解決，這也是質(zhì)量控制的職責所在；

　　（2）功能性的問題：可以考慮升級時解決；

　。3）一般性問題：不影響使用，可以不解決或者升級解決。

　　這類項目會議通常需要技術總監(jiān)或者更高級別的人來參加。后，需要對終討論沒有解決的缺陷列表進行簽字并存檔，形成一個基線。特別要注意的某些缺陷是否修改不能由程序員或者測試人員來決定，這樣有可能帶來嚴重的后果??導致缺陷失控，終形成沒有人對質(zhì)量負責的局面。

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

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

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

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