在正式的會議 上將軟體專案的成果(包括各階段的文件、 產生的**等)提交給使用者、 客戶或有關部門人員對軟體產品進行評審和批准。其目的是找出可能影響軟體產品質量、開發過程、維護工作的適用性和環境方面的設計缺陷,並採取補救措施,以及找出在效能、安全性和經濟方面的可能的改進。
在軟體開發與測試的各個階段進行相應的檢查,有利於軟體產品與過程的質量提高。
需求評審
《軟體需求》
《測試需求》
設計評審
《概要設計》
《詳細設計》
**評審
《**規範》
測試評審
《測試計畫》
《測試用例規範》
《缺陷報告規範》
評審入口準則
評審組長被任命。
評審在相關計畫中被定義。
被評審的產品準備就緒。
評審員經過評審規程的培訓。
評審員應經過被評審問題的技能的培訓。
協調員應當受過如何執行評審的正式培訓,或者應當參加幾次評審的經驗。
《專案計畫》已經制定。
同行評審
由軟體工作產品建立者的同行們檢查該工作產品,識別產品的缺陷,改進產品的不足。
準則：
評審產品,而不是評審設計者(不能使設計者有任何壓力)。
會場要有良好的氣氛。
限制爭論與反駁(評審會不是為了解決問題,而是為了發現問題)。
指明問題範圍，而不是解決提到的問題。
展示記錄(最好有黑板,將問題隨時寫在黑板上)。
組評審時會議人數應在5-9人為佳。
組評審**審員中應包括被評審產品作者的同行。( 例如對程式設計文件的評審,評審員中應包括其他程式設計人員)。
組評審**審員中應包括被評審產品的上下游相關人員。( 例如對程式設計文件的評審，評審員中應包括詳細設計人員和後續的編碼人員)。
堅持會前準備工作。
對全部評審人員進行必要的培訓。
管理評審
由軟體專案/產品管理者對專案過程中管理活動進行評估，識別過程缺陷，改進管理活動。
準則：
評審產品,而不是評審設計者(不能使設計者有任何壓力)。
指明問題範圍，而不是解決提到的問題。
評審人員接受過關於評審的必要的培訓。
評審人員在被評審產品領域具有豐富經驗。
單人評審
由單獨乙個評審員對簡單的工作產品進行評估,識別產品的缺陷,改進產品的不足。
準則：
評價專案總體情況和進展狀況。
評價小組內部的進度和人員狀況。
評價專案質量控制情況。
評價專案進展中遇到的問題並提出解決辦法。
評價專案當前存在的風險。
評價其他情況(視專案階段而定)。
制定評審計畫
評審準備
評審會議舉行
對評審結果採取行動
評審結果被跟蹤直到完成
提交和歸檔
參與人員不了解評審
評審沒有被安排專案計畫
評審會議變成問題解決方案討論會
評審人員事先對評審工件沒有足夠了解
評審人員關注與非實質性問題
忽略組織細節
會議時間過長
太多的歷史悲劇告訴我們風險無處不在,不學會控制它，就一定會 被它所控制。
風險分類
太多的歷史悲劇告訴我們風險無處不在,不學會控制它，就一定會被它所控制
軟體風險
這種風險分析主要是確定軟體中要測試什麼, 測試的優先順序，測試的深度。
規劃風險
這種風險主要是為了防範未計畫而影響專案進度的事件發生。比如測試人員突然離開導致人員不足、軟體的需求的突然變更。
風險分析過程
組建乙個「頭腦風暴」小組。
列出軟體中的所有功能列表。
確定某個功能失敗的可能性。
確定某個功能失敗所造成的影響。
量化。計算出風險優先順序。
評審並修改量化的數值。
將功能按優先順序排列。
決定「風險分割線」。
確定緩解風險的措施。
軟體測試風險分析
軟體測試風險分析的基本方針 制定軟體測試計畫並排列優先順序。風險分析是對軟體中潛在的問題進行識別 估計和評價的過程。軟體風險分析的目的是確定測試物件 測試優先順序以及測試深度。有時還包括確定可以忽略的測試物件。通過風險分析，測試人員識別軟體中高風險的部分並進行嚴格徹底的測試 確定潛在的隱患軟體構件，...
軟體測試風險分析
1 什麼是風險？2 什麼是軟體風險 3 識別軟體風險 4 商業風險 開發乙個沒有人真正需要的優秀產品或系統 市場風險 開發的產呂不再符合公司的整體商業策略 策略風險 建造了乙個銷售部門不知道如何去賣的產品 營銷風險 由於重點的轉移或人員的變動而失去了高階管理層的支援 管理風險 沒有得到預算或人力上的...
需求評審分析什麼 測試維度
軟體質量的六個標準 1 功能性 2 可靠性 3 易使用性 4 效率 5 可維修性 6 可移植性 測試人員，可以簡單的分為4個級別。第一層 功能性上保證。做好本職工作，考慮正常的業務主線以及各種異常流，盡量不出現問題。測試的最重要最基本的問題，就是保證產品質量，做到發布上線沒問題，那麼，在需求評審的時...