軟件評審方法(軟件評審包括哪些內容)
1.軟件評審包括哪些內容
在軟件的生命周期內所實(shí)施的對軟件本身的評審。
評審本身根據不同的評審階段，分為需求評審，功能評審，質(zhì)量評審，成本評審，維護評審等。一般來(lái)說(shuō)，評審（Peer Review）包括下面幾種檢視（Inspection）團隊評審（Team Review/Technical Review）走讀（WalkThrough）成對編程（Pair Programming）同行檢查（Peer DeskCheck）特別檢查（Ad hoc Review）評審方法間的區別（1）評審方法間的區別（2）。
2.軟件測試的方法都有哪些
軟件測試的方法根據軟件工程的組織和實(shí)現方式，有很大差別，有些是比較技術(shù)化的方法，有些則是工程方法，主要分為：
黑盒測試方法群：等價(jià)類(lèi)劃分、邊界值、因果圖、基路徑法、專(zhuān)家測試法、smoking、場(chǎng)景測試等
白盒測試方法群：同行評審、需求審查、代碼審查、接口測試（調用測試和返回測試，需要結合等價(jià)類(lèi)和因果圖方法）等。
當在單元層面黑盒而在集成層面白盒時(shí)，基本上兩類(lèi)方法就會(huì )有結合了，就會(huì )出現習慣上說(shuō)的灰盒測試（說(shuō)實(shí)話(huà)，不做到純產(chǎn)品級開(kāi)發(fā)，基本上都是用的灰盒測試）。
3.軟件項目中如何開(kāi)展有效的需求評審
2 需求評審的關(guān)鍵 下文根據筆者多年參與軟件項目管理的切身體會(huì )及經(jīng)驗，從不同角度對需求評審方法進(jìn)行論述。
2·1 充分準備評審 好的軟件需求說(shuō)明書(shū)，是進(jìn)行有效需求評審的前提。首先，需求人員在與用戶(hù)確認需求的過(guò)程中，一定不要放過(guò)任何一個(gè)細節，仔細體會(huì )用戶(hù)的每一個(gè)要求。
對于用戶(hù)的要求，需求人員需要對其加以梳理：哪些是合理的需求，哪些是不合理的需求，還有一些可能是必要的但是用戶(hù)沒(méi)想到的需求。軟件需求說(shuō)明書(shū)不應該只是用戶(hù)意愿的表達，而應該是從軟件層面上對用戶(hù)需求的總結。
軟件需求說(shuō)明書(shū)對需求用例的描述一般分為基本流和擴展流，基本流是大家很容易想到的主要業(yè)務(wù)流程，而實(shí)際設計開(kāi)發(fā)及測試過(guò)程中，最耗費時(shí)間的是實(shí)現擴展流的過(guò)程。因此不能只注重基本流，好的軟件需求說(shuō)明書(shū)，擴展流一定遠遠多于基本流，擴展流寫(xiě)得越完善，說(shuō)明需求人員考慮得越周全。
而實(shí)質(zhì)上，如果擴展流寫(xiě)得不完善，后期的設計、開(kāi)發(fā)及測試人員往往在相應的細節處理上無(wú)所適從。2·2分層次評審 用戶(hù)的需求是可以分層次的，一般而言分成以下層次：①目標性需求，定義整個(gè)系統需要達到的目標；②功能性需求，定義了整個(gè)系統必須完成的任務(wù)；③操作性需求，定義了完成每個(gè)任務(wù)的具體的人機交互；目標性需求是企業(yè)的高層管理人員所關(guān)注的，功能性需求是企業(yè)的中層管理人員所關(guān)注的，操作性需求是企業(yè)的具體操作人員所關(guān)注的。
對不同層次的需求，其描述形式是有區別的，參與評審的人員也是不同的。如果讓具體的操作人員去評審目標性需求，可能會(huì )很容易地導致“撿了芝麻，丟了西瓜”的現象，如果讓高層的管理人員也去評審那些操作性需求，無(wú)疑是一種資源的浪費。
分層次評審，可以讓不同類(lèi)型的參與人分別評審他們關(guān)注的內容，從不同的角度找到需求的異常，提高評審效率。
4.軟件測試評審流程
1.什么是同行評審
同行評審是一種通過(guò)作者的同行（開(kāi)發(fā)、測試、QA等）來(lái)確認缺陷和需要變更區域的檢查方法。
一、計劃階段
1.項目負責人指定組織者；作者自檢工作產(chǎn)品；組織者規劃本次評審，制定Review Plan
2.檢查入口準則：是否符合文檔標準？是否已用工具檢查？代碼3.準備評審包：評審通知單；待Review產(chǎn)品；參考資料；評審表單（Review Form）；評審計劃（Review Plan）;
4.確定評審專(zhuān)家3—6人，選取原則： 評審對象所處生命周期上一階段、當前階段和后一階段的參與者（就是和評審對象相關(guān)的人）
5.組織者將評審包、評審通知單發(fā)給相關(guān)人員
二、介紹會(huì )議（*可選）
1.不了解流程以及產(chǎn)品技術(shù)難度較高，技術(shù)較新時(shí)，由專(zhuān)家提出，作者講解相關(guān)產(chǎn)品及流程
2.時(shí)間不超過(guò)1小時(shí)，30-60分為宜
三、準備階段（最重要、發(fā)現缺陷最多）
1.評審專(zhuān)家個(gè)人獨立完成工作產(chǎn)品的審視，提出缺陷，填寫(xiě)評審表單；反饋評審表單給組織者
2.準備時(shí)間大于會(huì )議時(shí)間，且應于會(huì )議前2天開(kāi)始
3.組織者：匯總并檢查評審表單；裁決是否需要增加評審投入（增加準備時(shí)間；增加評審專(zhuān)家人數；更換評審專(zhuān)家等）
四、Review會(huì )議（只提問(wèn)題，不關(guān)注解決）
1.組織者召開(kāi)評審會(huì )議（不能是作者）
2.講解員講解工作產(chǎn)品（不能是作者或組織者）
3.大家共同確認問(wèn)題（評審表單中記錄的問(wèn)題；會(huì )上發(fā)現的問(wèn)題），由組織者作裁決
4記錄員記錄所有的問(wèn)題，并發(fā)給組織者
5.組織者更新評審表單（問(wèn)題確認、問(wèn)題根源、預防/修正措施）
五、第三小時(shí)會(huì )議（*可選）
在Review會(huì )議上未解決或有爭議的問(wèn)題，由作者決定是否召開(kāi)
六、返工
作者修改工作產(chǎn)品，更新評審表單
七、跟蹤
1.組織評審專(zhuān)家確認各缺陷得到了修改，并且沒(méi)有引入新的缺陷；
2.協(xié)助組織者確認相關(guān)問(wèn)題得到了正確修改并且沒(méi)有引入新的缺陷；
3. 匯總所有需要的數據到評審表單發(fā)給相關(guān)評審專(zhuān)家
4.是否重新Re-review
5.軟件質(zhì)量保證的技術(shù)評審
⑴發(fā)現功能、邏輯或實(shí)現的錯誤
⑵證實(shí)經(jīng)過(guò)評審的軟件的確滿(mǎn)足需求
⑶保證軟件的表示符合預定義的標準
⑷得到一種一致的方式開(kāi)發(fā)的軟件
⑸使項目更易管理 3-5人參加，不超過(guò)2小時(shí)，由評審主席、評審者和生產(chǎn)者參加，必須做出下列決定中的一個(gè) ：
⑴工作產(chǎn)品可不可以不經(jīng)修改而被接受；
⑵由于嚴重錯誤而否決工作產(chǎn)品；
⑶暫時(shí)接受工作產(chǎn)品。 評審什么？由誰(shuí)評審？結論是什么？
評審總結報告是項目歷史記錄的一部分，標識產(chǎn)品中存在問(wèn)題的區域，作為行政條目檢查表以指導生產(chǎn)者進(jìn)行改正。 ⑴評審產(chǎn)品，而不是評審生產(chǎn)者。注意客氣地指出錯誤，氣氛輕松。
⑵不要離題，限制爭論。有異議的問(wèn)題不要爭論但要記錄在案。
⑶對各個(gè)問(wèn)題都發(fā)表見(jiàn)解。問(wèn)題解決應該放到評審會(huì )議之后進(jìn)行。
⑷為每個(gè)要評審的工作產(chǎn)品建立一個(gè)檢查表。應為分析、設計、編碼、測試文檔都建立檢查表。
⑸分配資源和時(shí)間。應該將評審作為軟件工程任務(wù)加以調度。
⑹評審以前所做的評審
6.軟件工程正式的技術(shù)評審知道原則有哪些
技術(shù)評審（Technical Review,TR）的目的是盡早地發(fā)現工作成果中的缺陷，并幫助開(kāi)發(fā)人員及時(shí)消除
缺陷，從而有效地提高產(chǎn)品的質(zhì)量。包括有正式技術(shù)評審和非正式技術(shù)評審。
正式技術(shù)評審的原則：
作者答復評審員的問(wèn)題，
并與評審員共同查找缺陷、商討缺陷解決方案。評審結束后，作者應當及時(shí)消除工作成果中的缺陷。
1.要有嚴格的評審計劃，并遵守日程安排。
2.
評審小組
☆ 評審主持人應當具備比較高的技術(shù)水平和比較豐富的評審經(jīng)驗，能夠控制評審會(huì )議的進(jìn)程。評審主持人可以是項目?jì)鹊募夹g(shù)骨干，也可以是項目外的技術(shù)專(zhuān)家。評審主持人本身是一名評審員，評審結論必須有評審主持人的簽字才能生效。
☆評審員主要來(lái)源于項目?jì)群晚椖客獾募夹g(shù)人員，必要時(shí)還應當要求客戶(hù)和質(zhì)量保證人員擔任評審員。
工作成果的作者不能擔任評審員。
評審員的人選以及分工都由評審主持人來(lái)確定。
評審員應當根據“檢查表”認真地查找工作成果中的缺陷，并和作者共同商討缺陷解決方案。
☆評審小組的總人數一般在3~7人之間。
記錄員：由評審主持人指定一位評審員來(lái)?yè)斡涗泦T。記錄員如實(shí)地將評審過(guò)程記錄在指定的文檔中。
7.軟件測試方法有哪些
1、按是否查看程序內部結構分為：
(1)黑盒測試（black-box testing）：只關(guān)心輸入和輸出的結果
(2)白盒測試（white-box testing）：去研究里面的源代碼和程序結構
2、按是否運行程序分為：
(1)靜態(tài)測試（static testing）：是指不實(shí)際運行被測軟件，而只是靜態(tài)地檢查程序代碼、界面或文檔可能存在的錯誤的過(guò)程。
靜態(tài)測試包括：
對于代碼測試，主要是測試代碼是否符合相應的標準和規范。
對于界面測試，主要測試軟件的實(shí)際界面與需求中的說(shuō)明是否相符。
對于文檔測試，主要測試用戶(hù)手冊和需求說(shuō)明是否真正符合用戶(hù)的實(shí)際需求。
(5)動(dòng)態(tài)測試（dynamic testing），是指實(shí)際運行被測程序，輸入相應的測試數據，檢查輸出結果和預期結果是否相符的過(guò)程
3、按階段劃分：
(1)單元測試（unit testing），是指對軟件中的最小可測試單元進(jìn)行檢查和驗證。
樁模塊（stud）是指模擬被測模塊所調用的模塊，驅動(dòng)模塊（driver）是指模擬被測模塊的上級模塊，驅動(dòng)模塊用來(lái)接收測試數據，啟動(dòng)被測模塊并輸出結果。
(2)集成測試（integration testing），是單元測試的下一階段，是指將通過(guò)測試的單元模塊組裝成系統或子系統，再進(jìn)行測試，重點(diǎn)測試不同模塊的接口部門(mén)。
集成測試就是用來(lái)檢查各個(gè)單元模塊結合到一起能否協(xié)同配合，正常運行。
(3)系統測試（system testing），指的是將整個(gè)軟件系統看做一個(gè)整體進(jìn)行測試，包括對功能、性能，以及軟件所運行的軟硬件環(huán)境進(jìn)行測試。
系統測試的主要依據是《系統需求規格說(shuō)明書(shū)》文檔。
(4)驗收測試（acceptance testing），指的是在系統測試的后期，以用戶(hù)測試為主，或有測試人員等質(zhì)量保障人員共同參與的測試，它也是軟件正式交給用戶(hù)使用的最后一道工序。
驗收測試又分為a測試和beta測試，其中a測試指的是由用戶(hù)、測試人員、開(kāi)發(fā)人員等共同參與的內部測試，而beta測試指的是內測后的公測，即完全交給最終用戶(hù)測試。
4、黑盒測試分為功能測試和性能測試：
1）功能測試（function testing），是黑盒測試的一方面，它檢查實(shí)際軟件的功能是否符合用戶(hù)的需求。
包括邏輯功能測試（logic function testing）
界面測試（UI testing）UI=User Interface
易用性測試（usability testing）：是指從軟件使用的合理性和方便性等角度對軟件系統進(jìn)行檢查，來(lái)發(fā)現軟件中不方便用戶(hù)使用的地方。
兼容性測試（compatibility testing）：包括硬件兼容性測試和軟件兼容性測試
2）性能測試（performance testing）
軟件的性能主要有時(shí)間性能和空間性能兩種
時(shí)間性能：主要指軟件的一個(gè)具體事務(wù)的響應時(shí)間（respond time）。
空間性能：主要指軟件運行時(shí)所消耗的系統資源。
軟件性能測試分為：
一般性能測試：指的是讓被測系統在正常的軟硬件環(huán)境下運行，不向其施加任何壓力的性能測試。
穩定性測試也叫可靠性測試（reliability testing）：是指連續運行被測系統檢查系統運行時(shí)的穩定程度。
負載測試（load testing）：是指讓被測系統在其能忍受的壓力的極限范圍之內連續運行，來(lái)測試系統的穩定性。
壓力測試（stress testing）：是指持續不斷的給被測系統增加壓力，直到將被測系統壓垮為止，用來(lái)測試系統所能承受的最大壓力。（Validate the system or software can allowed the biggest stress.）
8.軟件測試的方法有哪幾種
《全國計算機等級考試三級教程軟件測試》目錄 第1章 軟件測試的基本概念1.1 軟件質(zhì)量的概念1.1.1 軟件質(zhì)量的定義1.1.2 軟件質(zhì)量的屬性1.1.3 軟件質(zhì)量模型1.1.4 軟件質(zhì)量的度量1.1.5 影響軟件質(zhì)量的主要因素1.2 軟件測試的概念1.2.1 軟件測試的定義與目的1.2.2 軟件測試的原則1.3 軟件的缺陷與錯誤1.3.1 軟件缺陷的定義和類(lèi)型1.3.2 軟件缺陷的級別1.3.3 軟件缺陷產(chǎn)生的原因1.3.4 軟件缺陷的構成第1章 軟件測試的基本概念1.1 軟件質(zhì)量的概念1.1.1 軟件質(zhì)量的定義1.1.2 軟件質(zhì)量的屬性1.1.3 軟件質(zhì)量模型1.1.4 軟件質(zhì)量的度量1.1.5 影響軟件質(zhì)量的主要因素1.2 軟件測試的概念1.2.1 軟件測試的定義與目的1.2.2 軟件測試的原則1.3 軟件的缺陷與錯誤1.3.1 軟件缺陷的定義和類(lèi)型1.3.2 軟件缺陷的級別1.3.3 軟件缺陷產(chǎn)生的原因1.3.4 軟件缺陷的構成1.3.5 修復軟件缺陷的代價(jià)1.4 軟件測試的經(jīng)濟學(xué)與心理學(xué)1.4.1 軟件測試的心理學(xué)1.4.2 軟件測試的經(jīng)濟學(xué)1.5 軟件質(zhì)量保證1.5.1 軟件質(zhì)量保證概要1.5.2 軟件質(zhì)量保證活動(dòng)的實(shí)施1.5.3 軟件的驗證與確認1.5.4 驗證和確認任務(wù)分析 本章小結 第2章 軟件生存周期中測試的實(shí)施2.1 軟件開(kāi)發(fā)階段2.1.1 軟件生存周期2.1.2 軟件測試的生存周期模型2.1.3 軟件測試過(guò)程模型2.1.4 測試信息流2.2 需求獲取與分析階段的測試2.2.1 需求評審的實(shí)施2.2.2 需求規格說(shuō)明的評審2.2.3 Wiegers 用例與需求評審表2.2.4 基于原型的測試2.2.5 基于需求的測試覆蓋率評估2.3 設計階段的測試2.3.1 設計的測試因素2.3.2 設計評審的實(shí)施2.3.3 設計規格說(shuō)明的評審2.3.4 設計元素的覆蓋原則2.4 編程階段的測試2.4.1 白盒測試與黑盒測試2.4.2 源代碼的控制流覆蓋原則2.4.3 源代碼的數據流覆蓋原則2.4.4 源代碼的靜態(tài)分析與動(dòng)態(tài)測試2.5 運行和維護階段的測試2.6 回歸測試2.6.1 回歸測試的概念2.6.2 回歸測試的類(lèi)型2.6.3 回歸測試的時(shí)機2.6.4 回歸測試的實(shí)施 本章小結 第3章 代碼檢查、走查與評審3.1 桌上檢查3.1.1 桌上檢查的實(shí)施3.1.2 桌上檢查的檢查表3.2 代碼檢查3.2.1 特定的角色和職責3.2.2 代碼檢查的實(shí)施3.2.3 用于代碼檢查的檢查表3.3 走查3.3.1 特定的角色和職責3.3.2 走查的實(shí)施3.3.3 走查中的靜態(tài)分析技術(shù)3.4 同行評審3.4.1 同行評審的角色和職責3.4.2 同行評審的內容3.4.3 評審的方法和技術(shù)3.4.4 評審工作 本章小結 第4章 白盒測試4.1 覆蓋率的概念4.2 邏輯覆蓋4.2.1 語(yǔ)句覆蓋與塊覆蓋4.2.2 判定覆蓋（分支覆蓋）4.2.3 條件覆蓋4.2.4 條件/判定覆蓋4.2.5 條件組合覆蓋4.2.6 路徑覆蓋4.2.7 ESTCA覆蓋4.2.8 LCSAJ覆蓋4.3 路徑測試4.3.1 分支結構的路徑測試4.3.2 循環(huán)結構的路徑測試4.3.3 圈復雜度與基本路徑測試4.4 數據流測試4.4.1 定義∕使用測試的幾個(gè)定義4.4.2 定義∕使用測試舉例4.4.3 定義∕使用路徑測試覆蓋指標4.5 基于覆蓋的測試用例選擇4.5.1 覆蓋率的使用4.5.2 使用最少的測試用例來(lái)達到覆蓋4.6 程序插樁技術(shù)4.6.1 程序插樁4.6.2 用于測試覆蓋率的程序插樁4.6.3 用于斷言檢測的程序插樁4.6.4 用于數據流異常檢測的程序插樁 本章小結 第5章 黑盒測試5.1 等價(jià)類(lèi)測試5.1.1 等價(jià)類(lèi)的概念5.1.2 等價(jià)類(lèi)測試的原則5.1.3 等價(jià)類(lèi)方法測試用例設計舉例5.2 邊界值分析5.2.1 邊界值分析的概念5.2.2 選擇測試用例的原則5.2.3 邊界值方法測試用例設計舉例5.3 基于判定表的測試5.3.1 判定表的概念5.3.2 基于判定表的測試用例設計舉例5.4 基于因果圖的測試5.4.1 因果圖的適用范圍5.4.2 用因果圖生成測試用例5.4.3 因果圖法測試用例設計舉例5.5 基于狀態(tài)圖的測試5.5.1 狀態(tài)圖5.5.2 利用狀態(tài)轉換樹(shù)生成測試用例5.5.3 利用狀態(tài)轉換表生成測試用例5.6 基于功能圖的測試5.6.1 功能圖5.6.2 功能圖法設計測試用例舉例5.7 基于用例和場(chǎng)景的測試5.7.1 基本流和備選流5.7.2 利用用例和場(chǎng)景設計測試用例的實(shí)例5.8 基于有向圖的測試用例設計5.8.1 使用基于有向圖的測試的場(chǎng)合5.8.2 基于事務(wù)流建模設計測試用例5.8.3 基于控制流建模設計測試用例5.8.4 基于有向圖設計測試用例的過(guò)程5.9 基于正交實(shí)驗設計法的測試5.9.1 提取功能說(shuō)明，構造因子/ 狀態(tài)表5.9.2 加權篩選，生成因素分析表5.9.3 利用正交表構造測試數據集5.10 其他黑盒測試用例設計技術(shù) 本章小結 第6章 單元測試和集成測試6.1 單元測試的基本概念6.1.1 單元測試的定義6.1.2 單元測試與集成測試、系統測試的區別6.1.3 單元測試環(huán)境6.2 單元測試策略6.2.1 自頂向下的單元測試策略6.2.2 自底向上的單元測試策略6.2.3 孤立測試6.2.4 綜合測試6.3 單元測試分析6.3.1 模塊接口6.3.2 局部數據結構6.3.3 獨立路徑6.3.4 出錯處理6.3.5 邊界條件6.4 單元測試的測試用例設計原則6.4.1 單元測試的測試用例設計步驟6.4.2 單元測試中的白盒測試與黑盒測試6.5 集成測試的基本概念6.6 集成測試策略6.6.1 基于分解的集成策略6.6.2 基于功能的集成6.6.3 基于路徑的集成6.6.4 基于調用圖的集成6.7 集成測試分析6.7.1 體系結構分析6.7.2 模塊單元分析6.7.3 接口分析6.7.4 風(fēng)險分析6.7.5 可測試性分析6.7.6 集成測試策略分析6.7.7 常見(jiàn)的集成測試故障6.8 集成測試的測試用例設計原則6.8.1 集成測試的測試用例設計步驟6.8.2 場(chǎng)景測試 本章小結 第7章 系統測試7.1 系統測試概念7.2 系。
