軟體評測師考試學習計劃

1、測驗是以評價一個程式或者系統屬性為目標的任何一種活動，測驗是對軟體質量的度量；

2、測驗是為了度量和提高被測軟體的質量，對測驗軟體進行工程設計、實施和維護的整個生命周期程序；

3、軟體測驗的根本目的：是為了提高軟體質量，降低軟體專案的風險；

4、軟體的質量風險表現在兩個方面：一種是內部風險，一種是外部風險；

5、內部風險：是在即將銷售的時候發現有重大的錯誤，從而延遲發布日期，失去市場機會；

6、外部風險：是用戶發現了不能容忍的錯誤，引起索賠、法律糾紛，以及用于客戶支持的費用甚至失去客戶的風險；

1、軟體測驗經典定義：在規定條件下對程式進行操作，以發現錯誤，對軟體質量進行評估；

2、軟體是由檔案、資料、程式組成的，軟體測驗應該是對軟體形成程序的檔案、資料以及程式進行測驗，而不僅僅是對程式進行測驗；

3、軟體質量保證和軟體測驗是軟體質量工程的兩個不同層面的作業；

4、質量保證（QA）：質量保證的重要作業通過預防、檢查與改進來保證軟體質量；

5、軟體測驗：測驗雖然也與開發程序緊密相關，但關心的不是程序的活動，而是對程序的產物以及開發出的軟體進行剖析；

6、測驗人員通過執行軟體，對程序中的產物——開發檔案和源代碼進行走查，運行軟體，以找出問題，報告質量，測驗人員必須假設軟體存在潛在的問題，測驗中所做的操作都是為了找出更多的問題，而不僅僅是為了驗證每一件事是正確的，對測驗中發現的問題的分析、追蹤與回歸測驗也是軟體測驗中的重要作業，因此軟體測驗是保證軟體質量的一個重要環節；

7、軟體測驗目的：測驗是程式的執行程序，目的在于發現錯誤；一個好的測驗用例在于能發現至今未發現的錯誤；

一個成功的測驗是發現了至今未發現的錯誤的測驗；

8、測驗的目的：以最少的人力、物力和時間找出軟體中潛在的各種錯誤和缺陷，通過修正各種錯誤和缺陷提高軟體質量，回避軟體發布后由于潛在的軟體缺陷和錯誤造成的隱患所帶來的商業風險；

9、軟體測驗原則：所有的軟體測驗都應追溯到用戶需求；

應當把“盡早地和不斷地進行軟體測驗”作為軟體測驗者的座右銘；

完全測驗是不可能的，測驗需要終止；

10、在有限的時間和資源條件下，軟體趨于完美，是不可能的，主要原因有三個：

軟體入量太大；輸入結果太多；路徑組合太多；

11、測驗無法顯示軟體潛在的缺陷；

12、充分注意測驗中的群集現象；

13、根據軟體定義，軟體包括程式、資料和檔案，所以軟體測驗并不僅僅是程式測驗；

14、軟體測驗應貫穿于整個軟體生命周期中；

15、在整個軟體生命周期中，各階段有不同的測驗物件，形成了不同開發階段的不同型別的測驗；

16、需求分析、概要設計、詳細設計以及程式編碼等各階段所得到的檔案，包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程式，都應成為軟體測驗的物件；

17、在軟體編碼結束后，對撰寫的每一個程式模塊進行測驗，稱為“單元測驗”；

18、在模塊集成后，對集成在一起的模塊組件進行測驗，稱為“集成測驗”；

19、在集成測驗后，需要檢測與證實軟體是否滿足軟體需求說明書中規定的要求，稱為“確認測驗”；

20、將整個程式模塊集成為軟體系統，安裝在運行環境下，對硬體、網路、作業系統及支撐平臺構成的整體系統進行測驗，稱為“系統測驗”，

21、驗證是保證軟體正確性實作特定功能的一系列活動和程序，目的是保證軟體生命周期中的每一個階段的成果滿足上一個階段所設定的目標；

22、確認是保證軟體滿足用戶需求的一系列的活動和程序，目的是在軟體開發完成后保證軟體與用戶需求相符合；

23、按照開發階段劃分軟體測驗可分為：單元測驗、集成測驗、系統測驗、確認測驗和驗收測驗，

24、單元測驗又稱模塊測驗，是針對軟體設計的最小單位—程式模塊進行正確性檢驗的測驗作業；其目的在于檢查每個程式單元能否正確實作詳細設計說明中的模塊功能、性能、介面和設計約束等要求，發現各模塊內部可能存在的各種錯誤，單元測驗需要從程式的內部結構出發設計測驗用例，多個模塊可以平行地獨立進行單元測驗；

25、集成測驗也叫組裝測驗，通常在單元測驗的基礎上，將所有的程式模塊進行有序的、遞增的測驗，集成測驗是檢驗程式單元或部件的介面關系，逐步集成為符合概要設計要求的程式部件或整個系統；

26、確認測驗：是通過檢驗和提供客觀證據，證實軟體是否滿足特定預期用途的需求，確認測驗是檢測與證實軟體是否滿足軟體需求說明書中規定的要求；

27、系統測驗：系統測驗是為驗證和確認系統是否達到其原始目標，而對集成的硬體和軟體系統進行的測驗，系統測驗是在真實或模擬系統運行的環境下，檢查完整的程式系統能否和系統（包括硬體、外設、網路和系統軟體、支持平臺等）正確配置、連接、并滿足用戶需求；

28、驗收測驗：按照專案任務書或合同、供需雙方約定的驗收依據檔案進行的對整個系統與評審，決定是否接識訓拒收系統；

29、按照測驗實施組織劃分，軟體測驗可分為開發方測驗、用戶測驗（β測驗）、第三方測驗；

30、開發方測驗：通常也叫“驗證測驗”或“α”測驗；開發方通過檢測和提供客觀證據，證實軟體的實作是否滿足規定的需求，驗證測驗是在軟體開發環境下，由開發者檢測與證實軟體的實作是否滿足軟體設計說明或軟體需求說明的要求；

31、用戶測驗：在用戶的應用環境下，用戶通過運行和使用軟體，檢測與核實軟體實作是否符合位元組集預期的要求，通常情況用戶測驗不是指用戶的驗收測驗，而是用戶的使用性測驗，由用戶找出軟體的應用程序中發現的軟體的缺陷與問題，并對使用質量進行評價；

32、第三方測驗：介于軟體開發方和用戶方之間的測驗組織的測驗，一般情況下是在模擬用戶真實應用環境下，進行軟體確認測驗，

33、按照測驗技識訓分：白盒測驗、黑盒測驗、灰盒測驗，也可劃分為靜態測驗和動態測驗，

34、靜態測驗：是指不運行程式，通過人工對程式和檔案進行分析與檢查：靜態測驗技術又稱靜態分析技術，靜態測驗實際上是對軟體的需求說明書、設計說明書、程式源代碼等進行非運行的檢查，靜態測驗包括：走查、符號執行、需求確認等；

35、動態測驗：是指通過人工或使用工具運行程式進行檢查、分析程式的執行狀態和程式的外部表現；

36、白盒測驗：通過對程式內部結構的分析、檢測來尋找問題，了解程式結構和處理程序，檢查是否所有的結構及路徑都是正確的，檢查軟體內部動作是否按照設計說明的規定正常進行；

37、黑盒測驗：通過軟體的外部表現來發現其缺陷和錯誤，黑盒測驗把測驗物件看成一個黑盒子，完全不考慮程式內部結構和處理程序，黑盒測驗是在程式界面處進行測驗，它只是檢查程式是否按照需求規格說明的規定正常實作；

38、灰盒測驗：關注輸出對于輸入的正確性；

39、軟體測驗程序模型：V模型、W模型、H模型、X模型；

40、V模型：它反應了測驗活動與分析和設計的關系，從左到右，描述了基本的開發程序和測驗行為，非常明確地標明了測驗程序中存在的不同級別，并且清楚地描述了這些測驗階段和開發程序期間各階段的對應關系，如圖所示，圖中的箭頭代表了時間方向，左邊下降的是開發程序各階段，與此相對應的是右邊上升的部分，即各測驗程序的各個階段，

41、V模型指出，單元和集成測驗是驗證的程式設計，開發人員和測驗組應檢測程式的執行是否滿足軟體設計的要求；系統測驗應當驗證系統設計，檢測系統功能、性能的質量特性是否達到系統設計的指標；由于測驗人員和用戶進行軟體的確認測驗和驗收測驗，追溯軟體需求說明書進行測驗，以確定軟體的實作是否滿足用戶需求或合同的要求；

42、V模型存在一定的局限性，它僅僅把測驗程序作為在需求分析、概要設計、詳細設計及編碼之后的一個階段，容易使人理解為測驗是軟體開發的最后一個階段，主要是針對程式進行測驗尋找錯誤，而需求分析階段隱藏的問題一直到后期的驗收測驗才被發現；

43、W模型建立：V模型的局限性在于沒有明確地說明早期的測驗，不能體現“盡早地和不斷地進行軟體測驗”的原則，在V模型中增加軟體各開發階段應同步進行的測驗，被演化為一種W模型，因為實際上開發是“V”，測驗也是與此相并行的“V”，基于“盡早地和不斷地進行軟體測驗”的原則；

44、W模型應用：W模型可以說是V模型自然而然的發展，它強調：測驗伴隨著整個軟體開發周期，而且測驗的物件不僅僅是程式，需求、功能和設計同樣要測驗，這樣，只要相應的開發活動完成，我們就可以開始執行測驗，可以說，測驗與開發是同步進行的，從而有利于盡早地發現問題，以需求為例，需求分析一完成，我們就可以對需求進行測驗，而不是等到最后才進行針對需求的驗收測驗；