軟件測試流程及規(guī)范一、軟件生命周期中測試工作流程二、各階段具體流程1.需求分析階段1.1步驟說明1、需求定義基本完成，SRS編寫完成。2、開評審會，由需求調(diào)研人員、開發(fā)組、設(shè)計組、測試組等人員對需求中不清楚、不完整、存在疑義的地方提出問題，相關(guān)人員解答并確認(rèn)。3、當(dāng)評審未通過，直接打回，重新修改SRS，問題解決后，重新提交評審。4、當(dāng)評審?fù)ㄟ^后，依據(jù)SRS，項目整體計劃，設(shè)計、編寫《測試計劃》和《測試設(shè)計》，具體模板見附件。5、開評審會，由開發(fā)組、設(shè)計組、測試組等人員對計劃和設(shè)計中不清楚、不完整、存在疑義的地方提出問題。6、當(dāng)審批未通過，直接打回，優(yōu)化測試計劃、測試設(shè)計，問題解決后，重新提交評審。7、審核通過后，進(jìn)入下一階段。1.2測試通過打回標(biāo)準(zhǔn)1.3、階段的輸出輸入：最新SRS、項目計劃輸出：測試計劃、測試設(shè)計2、單元及集成測試流程2.1步驟說明：1、理解需求和設(shè)計理解設(shè)計是很重要的，特別是要搞清楚被測試模塊在整個\o"軟件"軟件中所處的位置，這對測試的內(nèi)容將會有很大的影響。需要記住的一個原則就是：好的設(shè)計，各模塊只負(fù)責(zé)完成自己的事情，層次與分工是很明確的。在單元測試的時候，可以不用測試不屬于被測試模塊所負(fù)責(zé)的功能，以減少測試用例的冗余，集成測試的時候會有機(jī)會測試到的。所以，單元測試主要是關(guān)注本單元的內(nèi)部邏輯，而不用關(guān)注整個業(yè)務(wù)的邏輯，因為會有根據(jù)測試的結(jié)果分析、查找錯誤的原因，并找到解決的辦法。測試結(jié)束之后，根據(jù)測試過程的數(shù)據(jù)統(tǒng)計，給出被測試對象評價2.2測試通過打回標(biāo)準(zhǔn)1、通過標(biāo)準(zhǔn)2、打回標(biāo)準(zhǔn)2.3、階段的輸出輸入：最新SRS、項目計劃、詳細(xì)設(shè)計輸出：單元測試計劃、單元測試用例、單元測試總結(jié)分析。3、系統(tǒng)測試流程系統(tǒng)測試是將已經(jīng)確認(rèn)的軟件、計算機(jī)硬件、外設(shè)、網(wǎng)絡(luò)等其他元素結(jié)合在一起，進(jìn)行信息系統(tǒng)的各種組裝測試和確認(rèn)測試，系統(tǒng)測試是針對整個產(chǎn)品系統(tǒng)進(jìn)行的測試，目的是驗證系統(tǒng)是否滿足了需求規(guī)格的定義，找出與需求規(guī)格不符或與之矛盾的地方，從而提出更加完善的方案。系統(tǒng)測試發(fā)現(xiàn)問題之后要經(jīng)過調(diào)試找出錯誤原因和位置，然后進(jìn)行改正。是基于系統(tǒng)整體需求說明書的黑盒類測試，應(yīng)覆蓋系統(tǒng)所有聯(lián)合的部件。對象不僅僅包括需測試的軟件，還要包含軟件所依賴的硬件、外設(shè)甚至包括某些數(shù)據(jù)、某些支持軟件及其接口等。3.1步驟說明1、測試組收到測試任務(wù)通知書，告知較為確切的測試內(nèi)容、日期。2、根據(jù)最新SRS和各設(shè)計文檔，將已經(jīng)確認(rèn)的軟件、計算機(jī)硬件、外設(shè)、網(wǎng)絡(luò)等其他元素結(jié)合在一起，針對整個產(chǎn)品系統(tǒng)進(jìn)行的測試。3、編寫此階段系統(tǒng)測試方案，通過評審，優(yōu)化系統(tǒng)測試方案。4、然后編寫或補充系統(tǒng)測試用例，用例完成后，需要通過評審，優(yōu)化系統(tǒng)測試用例。5、執(zhí)行冒煙測試用例，測試版本僅少量嚴(yán)重程度低的bug未修改引起的不通過，反饋項目組，通知延長冒煙測試時間；測試版本符合冒煙測試打回標(biāo)準(zhǔn)，冒煙測試不通過，直接打回或掛起，結(jié)束測試。測試完成度滿足冒煙測試開始條件，重新發(fā)起測試申請。6、當(dāng)不通過時，退回或掛起。7、當(dāng)完成冒煙測試后，進(jìn)行系統(tǒng)測試，提交bug報告，審核bug，當(dāng)審核未通過時，補充測試用例，當(dāng)審核通過匯總bug，總結(jié)報告。8、當(dāng)開發(fā)人員完成缺陷的修改后，提交新的版本，測試人員繼續(xù)開始做回歸測試。當(dāng)測試版本僅少量bug未修改引起的不通過，反饋項目組，通知延長系統(tǒng)測試時間；測試版本符合系統(tǒng)測試打回標(biāo)準(zhǔn)，系統(tǒng)測試不通過，直接打回，結(jié)束測試。待測試完成度滿足系統(tǒng)測試開始條件，重新發(fā)起測試申請。9、當(dāng)缺陷的統(tǒng)計曲線出現(xiàn)的逐漸收斂，并且得到控制。10、分析缺陷的原因。11、提交測試報告。12、進(jìn)入下一階段。3.2測試通過打回標(biāo)準(zhǔn)1）通過標(biāo)準(zhǔn)2）打回標(biāo)準(zhǔn)3.3、階段的輸出輸入：最新SRS、項目計劃、詳細(xì)設(shè)計輸出：系統(tǒng)測試計劃、系統(tǒng)測試用例、測試總結(jié)分析。4、驗收測試軟件產(chǎn)品測試組對經(jīng)過內(nèi)部單元測試、集成測試和系統(tǒng)測試后的軟件所進(jìn)行的測試，測試用例采用業(yè)務(wù)流程測試用例。4.1步驟說明1、驗收測試進(jìn)入準(zhǔn)則1）軟件產(chǎn)品通過單元測試、集成測試和系統(tǒng)測試。2）項目組提交以下測試文檔：測試計劃、測試用例、測試日志、測試通知單、測試分析報告。3）待驗收的軟件安裝程序。2、測試錯誤類型參考軟件測試停止標(biāo)準(zhǔn).doc3、對用戶手冊和幫助的驗收規(guī)定1）用戶手冊和幫助的編制要使用非專門術(shù)語的語言，充分地描述該軟件系統(tǒng)所具有的功能及基本的使用方法。2）使用戶（或潛在用戶）通過用戶手冊能夠了解該軟件的用途，并且能夠確定在什么情況下，如何使用它。3）語句通順、簡潔，語義明確，錯別字小于0.1%。4）對相關(guān)名詞解釋應(yīng)易于被用戶理解。5）對相關(guān)界面的說明要符合操作流程并將每一項功能解釋完整、清楚。6）保證用戶手冊、幫助能夠正確指導(dǎo)用戶使用軟件。4、軟件驗收測試合格通過準(zhǔn)則1）軟件需求分析說明書中定義的所有功能已全部實現(xiàn)，性能指標(biāo)全部達(dá)到要求。2）所有測試項必須符合以下標(biāo)準(zhǔn)：(以下比例為錯誤占總測試模塊的比例)一級錯誤二級錯誤三級錯誤四級錯誤五級錯誤無無<2%<3%暫不做要求3）需求分析文檔、設(shè)計文檔和編碼實現(xiàn)一致。4）用戶手冊及幫助符合對用戶手冊及幫助的驗收規(guī)定(編寫人在責(zé)任認(rèn)定書上簽字時對于軟件產(chǎn)品的各項功能描述、名詞解釋、結(jié)構(gòu)、語句表達(dá)等方面均要保證其正確性并加以說明)。5）驗收測試文檔齊全（見驗收測試進(jìn)入準(zhǔn)則）。6）以上五條其中之一不滿足要求，視為不合格。三、缺陷管理3.1缺陷定義軟件缺陷（Defect），常常又被叫做Bug。所謂軟件缺陷，即為計算機(jī)軟件或程序中存在的某種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷。具體歸納為以下這些問題。1、軟件沒有達(dá)到需求規(guī)格說明書中表明的功能；2、軟件出現(xiàn)了需求規(guī)格說明書中不一致的表現(xiàn)；3、軟件功能超出需求規(guī)格說明書的范圍；4、軟件沒有達(dá)到用戶期望的目標(biāo)(雖然需求規(guī)格說明書中沒有要求)；5、測試員或用戶認(rèn)為軟件的易用性差。3.2缺陷的修復(fù)在實際項目中不是所有的缺陷都會修改，具體見以下情況：1、市場的壓力使得產(chǎn)品最終發(fā)行有時間限制；2、測試員錯誤理解或者不正確操作引出的缺陷；3、錯誤的修改影響的模塊較多，帶來的風(fēng)險較大；4、缺陷報告中提出的問題很難重現(xiàn)；5、修改性價比太低。3.3缺陷的分類標(biāo)準(zhǔn)一旦發(fā)現(xiàn)軟件缺陷，就要設(shè)法找到引起這個缺陷的原因，分析對產(chǎn)品質(zhì)量的影響，然后確定軟件缺陷的嚴(yán)重性和處理這個缺陷的優(yōu)先級。各種缺陷所造成的后果是不一樣的，有的僅僅是不方便，有的可能是災(zāi)難性的。一般問題越嚴(yán)重，其處理優(yōu)先級就越高，可以概括為以下五種級別：缺陷標(biāo)示缺陷嚴(yán)重等級描述5嚴(yán)重缺陷不能執(zhí)行正常工作功能或重要功能。使系統(tǒng)崩潰或資源嚴(yán)重不足。1、由于程序所引起的死機(jī),非法退出；2、死循環(huán)；3、數(shù)據(jù)庫發(fā)生死鎖；4、錯誤操作導(dǎo)致的程序中斷；5、嚴(yán)重的計算錯誤；6、與數(shù)據(jù)庫連接錯誤；7、數(shù)據(jù)通訊錯誤。4較嚴(yán)重缺陷嚴(yán)重地影響系統(tǒng)要求或基本功能的實現(xiàn)，且沒有辦法更正。1、功能不符；2、程序接口錯誤；3、數(shù)據(jù)流錯誤；4、輕微數(shù)據(jù)計算錯誤。3一般性缺陷嚴(yán)重地影響系統(tǒng)要求或基本功能的實現(xiàn)，但存在合理的更正辦法。1、界面錯誤（附詳細(xì)說明）；2、打印內(nèi)容、格式錯誤；3、簡單的輸入限制未放在前臺進(jìn)行控制；4、刪除操作未給出提示；5、數(shù)據(jù)輸入沒有邊界值限定或不合理。 2較小缺陷使操作者不方便或遇到麻煩，但它不影響執(zhí)行工作或功能實現(xiàn)。1、輔助說明描述不清楚；2、顯示格式不規(guī)范；3、系統(tǒng)處理未優(yōu)化；4、長時間操作未給用戶進(jìn)度提示；5、提示窗口文字未采用行業(yè)術(shù)語。1其它缺陷1、建議2、其它錯誤3.3缺陷的流程目前分公司的缺陷管理使用的是流程中缺陷存在以下6種狀態(tài)：提交bug狀態(tài)（New）：開發(fā)人員或測試人員發(fā)現(xiàn)bug，記錄在系統(tǒng)里。激活狀態(tài)（Open）：當(dāng)項目經(jīng)理或負(fù)責(zé)人覺得這個bug是問題，將bug置為此狀態(tài)。駁回狀態(tài)（Rejected）:當(dāng)項目經(jīng)理或負(fù)責(zé)人覺得這個bug不是問題，則可以駁回，將bug置為此狀態(tài)。已修正狀態(tài)（Fixed）：開發(fā)人員針對缺陷，修正軟件后已解決問題或通過單元測試。關(guān)閉狀態(tài)（Close）：測試人員經(jīng)過驗證后，確認(rèn)缺陷不存在之后的狀態(tài)。重新激活狀態(tài)（Reopen）：測試人員經(jīng)過驗證后，確認(rèn)此缺陷存在，之后將其置為此狀態(tài)。四、關(guān)于單元測試1、首先應(yīng)該明確單元的含義。單元在面向?qū)ο蟮某绦蛑兄傅氖且粋€類，在結(jié)構(gòu)化的方法中指的是一個函數(shù)。2、其次應(yīng)該明確單元測試的方法。單元測試的常用方法包括：(1)靜態(tài)檢查，即采用靜態(tài)代碼檢查的工具對程序進(jìn)行內(nèi)部邏輯的分析，以分析程序中可能的錯誤。(2)動態(tài)測試，通過編寫單元測試程序，設(shè)計單元測試用例，測試每個函數(shù)或每個類的邏輯正確性。3、如果一個類或一個函數(shù)對其他的類或環(huán)境依賴性很強(qiáng)，需要編寫大量的樁程序或驅(qū)動程序，那恰恰說明了這個類或這個函數(shù)的設(shè)計有問題，違背了“低耦合”的基本設(shè)計原則，這也正式敏捷方法中提倡的“測試驅(qū)動開發(fā)”的作用之一。4、質(zhì)量的投入產(chǎn)出也是一種平衡，需要在單元測試上投入到什么程度首先是公司的一個管理方針。如果每個單元都進(jìn)行單元測試則測試代碼的規(guī)模和產(chǎn)品代碼的規(guī)模能夠達(dá)到1：1，也就是說編寫測試代碼的工作量還是比較大的，但是也要看到單元測試的產(chǎn)出。在單元測試、集成測試、系統(tǒng)測試中，單元測試是投入產(chǎn)出比最大的測試種類，即單元測試在單位時間內(nèi)發(fā)現(xiàn)的缺陷個數(shù)大于集成與系統(tǒng)測試。原則上單元測試的投入最大，找到的缺陷最多，集成測試與系統(tǒng)測試依次遞減。5、在實踐中推廣單元測試時可以采用如下的方法：1)、加大靜態(tài)檢查的力度。通過靜態(tài)檢查的工具快速地識別程序中的錯誤、警告，公司可以規(guī)定對檢查出的哪些警告、錯誤必須進(jìn)行修改，注意如果修改所有的警告、錯誤可能工作量比較大。靜態(tài)檢查是一種投入產(chǎn)出比很高的單元測試方法。在JAVA下可以采用checkStyle,Sourcemonitor，PMD，F(xiàn)indBugs，Jslink等。2)、通過測試策略的選擇減少測試程序的工作量。單元測試一般有三種策略：策略一：自底向上的策略：先測底層的函數(shù)或類，再測上層的函數(shù)或類，此時只需要編寫驅(qū)動程序，不需要編寫樁程序。策略二：自頂向下的策略：先測上層的函數(shù)或類，再測試底層的函數(shù)類，此時只需要編寫樁程序，不需要或很少需要編寫驅(qū)動程序。策略三：混合策略：綜合上述的2種策略，需要綜合編寫樁程序與驅(qū)動程序。如果被測的單元需要調(diào)用很多其他的單元，則可以采用自底向上的策略減少驅(qū)動程序的編寫量。如果被測的單元需要很多外圍的環(huán)境準(zhǔn)備則可以采用自頂向下的策略。3)、在組織級可以規(guī)定執(zhí)行單元測試的時機(jī),比如：a)系統(tǒng)中最核心的、最關(guān)鍵的功能模塊；b)算法復(fù)雜的功能模塊；c)出錯最多的功能模塊；d)客戶最常使用的功能模塊；e)復(fù)用的底層代碼；根據(jù)Pareto定律，我們可以選擇少部分代碼執(zhí)行單元測試。6、單元測試的技術(shù)1)、JUnit的工具2)、生成測試用例時可以采用如下的方法：a）單元功能分析b）入口參數(shù)等價類分析c）入口參數(shù)邊界分析d）全程變量、共享數(shù)據(jù)的等價類與邊界分析e）調(diào)用函數(shù)返回值的等價類與邊界分析f）覆蓋率分析上述的方法要求的嚴(yán)格程度可以循序漸進(jìn),不能的嚴(yán)格程度需要投入的工作量不同。7、單元測試完成后，編寫軟件評定書。五、通用檢查點見附件：公共測試用例.xlsx六、常見缺陷分類見附件：缺陷分類.xlsx七、評審工作一、審批過程評審的通用過程由如下6個階段組成：1、計劃階段：選擇評審員并分配角色、為正式的評審類型（如審查）規(guī)定評審的入口和出口準(zhǔn)則，以及選擇需要評審的文檔或文檔章節(jié)等。2、預(yù)備會階段：分發(fā)文檔，向評審參與者解釋本次評審的目標(biāo)、過程和文檔，以及核對入口準(zhǔn)則（針對正式的評審類型）。3、個人準(zhǔn)備階段：在評審會議之前每位評審參與者準(zhǔn)備各自的評審工作，標(biāo)注評審對象中可能的缺陷、問題和建議等。4、評審會議階段：討論評審員提交的問題列表，并形成會議紀(jì)要（針對正式的評審類型）。會議參與者可以標(biāo)識缺陷并提出處理建議。5、返工階段：修復(fù)評審過程中發(fā)現(xiàn)的缺陷，通常由作者完成。6、跟蹤結(jié)果階段：檢查缺陷是否已經(jīng)解決，收集度量數(shù)據(jù)并評估出口準(zhǔn)則（針對正式的評審類型）。二、審批中涉及的主要角色經(jīng)理、主持人或組長、作者、評審員和記錄員，其他可能涉及包括決策者或者其他利益相關(guān)者，如用戶代表；另外一個可選的角色有時會出現(xiàn)在審查中，即宣讀員，在評審會議中宣讀產(chǎn)品的某些部分。三、審批遵循原則評審遵循原則1、盡早的開展評審。2、控制評審會議的時間。3、評審的是軟件產(chǎn)品而不是作者。4、每個評審員都必須有機(jī)會充分地表達(dá)各自的觀點，并且評審會議紀(jì)要必須完整地記錄每個評審員的意見和建議。5、發(fā)現(xiàn)缺陷，而不是修復(fù)缺陷。評審會議關(guān)注的是發(fā)現(xiàn)被評審對象中的缺陷，而盡量避免討論針對缺陷的可能解決方案和方法，提出解決方案及其對應(yīng)的討論不應(yīng)該是評審會議的關(guān)注點。6、評審過程中發(fā)現(xiàn)的缺陷和問題，應(yīng)該劃分為不同的嚴(yán)重程度級別。1）嚴(yán)重缺陷：評審對象不能滿足其目標(biāo)，在批準(zhǔn)評審對象之前必須修復(fù)相關(guān)缺陷。2）重要缺陷：影響評審對象的可用性，批準(zhǔn)評審對象之前應(yīng)該修復(fù)相關(guān)缺陷。3）一般缺陷：小的偏差，基本不影響使用。4）好的：沒有缺陷，返工時無須修改。7、評審團(tuán)隊最后應(yīng)該對評審對象給出如下評審意見。1）接受：文檔、軟件產(chǎn)品不需要修改或者只要微小的修改。2）有條件接受：文檔、軟件產(chǎn)品需要修改，但是不需要進(jìn)一步評審。3）不接受：文檔、軟件產(chǎn)品需要深入修改，并且需要重新評審或者其他檢查措施。四、審批類型評審可以是正式或非正式的。基于IEEEStd1028-2008軟件評審和審計標(biāo)準(zhǔn)，分為審查、技術(shù)評審、走查、非正式評審、管理評審和審計等評審類型。1、審查。目的：這是一種系統(tǒng)的同行檢查方法，檢查并發(fā)現(xiàn)軟件產(chǎn)品中的缺陷。主要關(guān)注軟件產(chǎn)品是否滿足規(guī)格說明及其是否體現(xiàn)了特定的質(zhì)量特性，以及是否滿足了規(guī)范、標(biāo)準(zhǔn)、指南、計劃、規(guī)格說明和規(guī)程等要求，并識別其中存在的差異。參與人員：審查一般由2至6個人參與，包括作者。角色主要有主持人、記錄員、宣讀員、作者和審查員。度量數(shù)據(jù)：檢查表結(jié)果輸出：確定補救措施或調(diào)查活動。注：審查會議上并不討論解決方案。收集相關(guān)數(shù)據(jù)并定期分析：數(shù)據(jù)包括被審查的軟件產(chǎn)品、審查召開的日期、審查參與的成員、審查員準(zhǔn)備的時間、審查會議的時間、審查對象規(guī)模和審查結(jié)果等。通過分析優(yōu)化審核本身的過程，并改進(jìn)生成軟件產(chǎn)品的過程。2、技術(shù)評審目的：為了評估軟件產(chǎn)品是否滿足預(yù)期的使用要求，識別軟件產(chǎn)品和規(guī)格說明與標(biāo)準(zhǔn)之間不一致的地方。方式：同行間小組討論活動，主要為了對測試對象所采用的技術(shù)實現(xiàn)方法達(dá)成共識。參與人員：包括決策者、評審主持人、記錄員和技術(shù)評審員，也可以包括項目的其他利益相關(guān)者，如客戶代表。輸入：相關(guān)的規(guī)范、標(biāo)準(zhǔn)、計劃和規(guī)格說明之外，評審檢查表與缺陷分類等也是重要的內(nèi)容。輸出：其中主要包括技術(shù)評審的對象、參與技術(shù)評審的成員名單、技術(shù)評審的目標(biāo)、技術(shù)評審的相關(guān)輸入、評審得到的軟件產(chǎn)品缺陷列表、管理問題列表、應(yīng)對活動列表（應(yīng)對活動的狀態(tài)、負(fù)責(zé)人、完成的目標(biāo)時間與完成的實際時間等）和評審團(tuán)隊得到的建議列表，并且判斷軟件產(chǎn)品是否滿足了規(guī)范和標(biāo)準(zhǔn)等的要求。3、走查目的：1）發(fā)現(xiàn)缺陷。2）改善軟件工作產(chǎn)品。3）討論軟件工作產(chǎn)品的替換方案。4）評估和標(biāo)準(zhǔn)及規(guī)格說明等的一致性。5）評估軟件產(chǎn)品的可用性。6）培訓(xùn)參與者。參與人員：包括走查主持人、記錄員、作者與走查員等。度量數(shù)據(jù)：檢查表收集相關(guān)數(shù)據(jù)并定期分析：數(shù)據(jù)包括被走查的軟件產(chǎn)品、走查開始的日期、走查參與的成員、走查員準(zhǔn)備的時間、走查會議的時間、走查對象規(guī)模和走查對象的走查結(jié)果等。通過分析優(yōu)化走查本身的過程，并改進(jìn)生成軟件產(chǎn)品的過程。4、非正式評審非正式評審是一種不基于正式（文檔化）過程的評審，它是評審的精簡版，在某種程度上遵循通用的評審過程。通常情況下，由作者發(fā)起非正式評審。評審計劃限定于選擇評審員和要求他們在指定時間點提交意見和建議。非正式評審?fù)ǔ２徽匍_會議和相互交換意見，只是作者和評審員之間的交互。非正式評審可以是一種由一個或多個同事完成的交叉閱讀，其結(jié)果不需要明確的文檔化，有時一個評審清單或修訂文檔就足夠了。結(jié)對編程、結(jié)對測試和代碼交換等都是非正式評審的方式，非正式評審非常普遍，并且由于工作量小而被廣泛接受。五、如何開展審批活動被評審的產(chǎn)品應(yīng)當(dāng)符合相應(yīng)條件（如審查需要滿足一定的評審入口準(zhǔn)則），同時不同的評審對象需要不同的評審員參與。如下表：文檔名稱作者評審員需求規(guī)格說明書系統(tǒng)人員項目經(jīng)理、架構(gòu)師、測試組人員……測試計劃測試組人員開發(fā)經(jīng)理、架構(gòu)師、測試組……測試設(shè)計規(guī)格說明書測試組人員開發(fā)經(jīng)理、架構(gòu)師、測試組……測試用例測試組人員開發(fā)經(jīng)理、測試組測試報告測試組人員項目經(jīng)理、開發(fā)經(jīng)理、測試組其中的評審員，如功能開發(fā)經(jīng)理，可以指定符合要求的開發(fā)人員代替其參與評審活動。評審對象的“作者”一欄中列出了該文檔的主要責(zé)任人，有的文檔可能需要多個項目人員共同完成，作者可能有多人。為了成功地將評審引入到項目和組織中，需要采取以下措施。1、獲得管理層支持：評審需要時間和資源，如評審員的時間計劃、工作量計劃、評審需要的基礎(chǔ)設(shè)施和設(shè)備等，這些都需要組織管理層的支持。2、管理人員培訓(xùn)：早期發(fā)現(xiàn)和修復(fù)缺陷可以節(jié)約時間和降低成本。管理人員必須意識到學(xué)習(xí)新的評審技術(shù)是一項投資，其收益不是立即可見的，隨著時間的推移會越來越明顯地顯現(xiàn)出來。管理人員需要在評審成本、利益和執(zhí)行方面進(jìn)行有效的平衡。3、正規(guī)的評審過程：組織內(nèi)定義并文檔化評審步驟，定義不同的評審類型和評審過程中不同的角色和職責(zé)，并對評審過程定義合適的監(jiān)控手段和形式。通過評審過程的監(jiān)控和改進(jìn)提供評審的度量數(shù)據(jù)（如評審的效率和發(fā)現(xiàn)缺陷的分布等）。4、開展評審技術(shù)和規(guī)程的培訓(xùn)：根據(jù)項目特點和評審類型開展評審技術(shù)和規(guī)程的培訓(xùn)，更好地讓評審參與人員了解評審的目的、評審的過程及評審的作用和意義，從而更加有效地開展評審，而不是作為過程的一部分流于形式.5、獲得評審員和評審對象作者的支持：評審要求評審對象的作者提供合適的評審資料，以滿足評審的入口準(zhǔn)則。并且需要評審員具備合適的專業(yè)技能和知識，擁有足夠的能力完成評審工作。6、評審最重要的文檔：由于軟件開發(fā)的時間和資源有限，因此需要將評審用于最重要的文檔（如需求、合同和計劃等）。正式而嚴(yán)格的評審包括6個階段，即計劃階段、預(yù)備會階段、個人準(zhǔn)備階段、評審會議階段、返工階段和跟蹤結(jié)果階段。1、計劃階段。作者將評審對象和相關(guān)的輸入材料匯總給評審主持人，主要內(nèi)容如下。評審對象：XXX系統(tǒng)需求規(guī)格說明……輸入材料：包括XXX需求規(guī)格說明……如果需要，在計劃階段確定評審的范圍和重點。例如，如果評審對象內(nèi)容過多，可以選擇重點或者風(fēng)險較高部分評審。評審計劃階段