4.1軟體測試分類

4.1.1是否關心內部結構：

（1）白盒測試（白盒測試一般是靜態測試）

注重於內部結構，又稱為結構測試或邏輯驅動測試，是一種按照程式內部邏輯結構和編碼結構設計測試資料並完成測試的一種測試方法。

（2）黑盒測試（黑盒測試基本上都是動態測試）

注重於軟體的功能，把測試物件當作看不見內部的黑盒，在完全不考慮程式內部結構和處理過程的情況下，測試者僅依據程式功能的需求規範考慮，確定測試用例和推斷測試結果的正確性.

（3）灰盒測試：介於白盒和黑盒之間，它不像白盒那樣詳細、完整、但比黑盒更注重於內部邏輯

4.1.2.開發過程級別：

（1）單元測試：偏向於白盒測試，它測試的是每個單元模組的程式結構

（2）整合測試：整合是單元和單元拼在一起，不注重單元與單元之間的內部結構，而更注重於單元和單元拼在一起後的介面是否正確，一般用灰盒來測

（3）系統測試：測試的是軟體的一些功能，用黑盒來測

（1）驗收測試：又稱為使用者測試，關注使用者的需求

4.1.3.是否執行程式：

（1）靜態測試：靜態測試是指不執行被測程式本身，通過分析或檢查源程式的語法、結構、過程、介面等來檢查程式的正確性。其被測物件是各種與軟體相關的有必要進行測試的產物，是對需求規格說明書、軟體設計說明書、源程式做結構分析、流程圖分析、符號執行來找錯。靜態測試可以手工進行，充分發揮人的思維的優勢，並且不需要特別的條件，容易展開，但是靜態測試對測試人員的要求較高，至少測試人員需要具有程式設計經驗。

靜態測試包含的內容：

靜態測試主要包括各階段的評審、程式碼檢查、程式分析、軟體質量度量等，用於對被測程式進行特性分析。其中評審通常有人來執行；程式碼檢查程式分析、軟體質量度量等即可人工完成，也可用工具來完成，但工具的作用和效果相對更大更好一些。

（2）動態測試：通過執行被測程式來檢查執行結果與預期結果的差異；

4.1.4執行過程是否要人工干預：

（1）手動測試（規模、複用性小）

（2）自動測試（規模大的產品）

4.1.5測試實施組織：開發測試、使用者測試、第三方測試

4.2.功能測試與非功能測試

（1）功能測試就是對產品的各功能進行驗證，根據功能測試用例，逐項測試，檢查產品是否達到使用者要求的功能。功能性測試又叫作黑盒測試；

（2）非功能性測試包括：效能、安全性、可使用性、相容性、併發性；

4.3軟體測試分級

（1）元件測試：針對單個軟體單元的測試都可以稱為元件測試，是在程式級別進行的測試。目的：①保證各個模組的正確進行；

      ②保證整個流程在各個模組能按照正確的邏輯進行執行；

（2）整合測試：也叫組裝測試、聯合測試，是一種旨在暴露介面以及整合元件/系統間互動時存在缺陷的測試。在保證元件測試的前提下還要保證各個模組的相容性；

（3）配置項測試：測試的物件是計算機軟體配置項，配置項測試可根據軟體測評任務書、合同或其他等效檔案及軟體配置項的重要性、安全性關鍵等級對要求進行裁剪，但必須說明理由。

（4）系統測試：將已經過整合測試的軟體，作為計算機系統的一個部分，與系統中其他部分結合起來，在實際執行環境下對計算機系統進行的一系列嚴格有效地測試，以發現軟體潛在的問題，保證系統的正常執行。

（5）驗收測試：指確認一統是否符合設計規格或需求內容的測試。通常由使用系統的使用者來進行測試。

（6）維護測試：指軟體被市場接受後，再執行一段時間後，在需要做某些修正、改變或擴充套件的情況下進行的維護測試。

軟體缺陷管理

5.1.軟體缺陷概念：符合下面5個規則中的一個，就是軟體缺陷

（1）軟體未實現產品說明書要求的功能

（2）軟體出現了產品說明書指明不應該出現的錯誤

（3）軟體實現了產品說明書未提到的功能

（4）軟體未實現產品說明書雖未明確提及但應該實現的目標

（5）軟體難以理解、不易使用、執行緩慢或者—從測試員的角度看—終端使用者會認為不好

5.2.軟體錯誤、軟體失效、軟體故障；

①軟體錯誤：導致期望的執行結果和實際執行結果間出現差異的一些問題；

②軟體故障：指軟體執行過程中出現的一種不希望或不可接受的內部狀態；

③ 軟體失效：軟體無法滿足日益發展的需求；

5.3.缺陷產生的原因：需求分析、設計、編碼等階段產生缺陷（出現缺陷的最大原因在需求分析階段，其次是在設計階段）；

5.4.軟體缺陷管理目標：

  確保每個被發現的缺陷都能及時得到處理，是測試工作的一項重要內容。

（1）確保每個被發現的缺陷都能被解決。

（2）收集缺陷資料並根據缺陷趨勢曲線識別測試過程的階段。

（3）收集缺陷資料並進行資料分析，作為組織的過程財富。

5.5.缺陷的基本資訊：

（1）缺陷標題 （2）標識 （3）報告人 （4）報告日期 

（5）程式的名稱 （6）版本號 （7）配置 （8）缺陷型別 （9）嚴重性 （10）優先順序 

（11）關鍵詞 （12）缺陷描述 （13）重現步驟 （14）結果對比 （15）附件

5.6. 缺陷嚴重度和優先順序

5.6.1軟體缺陷的嚴重度：

Critical：不能執行正常功能或重要功能，或者危及人身安全；

Major：嚴重的影響系統要求或基本功能的實現，且無法更正（重新安裝或重新啟動該軟體不屬於更正辦法）；

Minor:嚴重影響系統要求或基本功能的實現，但存在合理的更正辦法。（重新安裝或重新啟動該軟體不屬於更正辦法）；

Cosmetic：造成操作者不便或遇到麻煩，但不影響執行工作或重要功能；

Other：其它錯誤

5.6.2軟體缺陷的優先順序：

High：指應該被立刻解決的缺陷。

Middle：指缺陷需要正常排隊等待修復或列入軟體釋出清單。

Low：指缺陷可以在方便的時候被糾正。

5.6.3關係：

缺陷的嚴重度和優先順序是含義不同但相互聯絡密切的兩個概念，從不同的側面描述了軟體缺陷對軟體質量、終端使用者、開發過程的影響程度和處理方式。

一般來說，嚴重度高的的缺陷具有較高的優先順序，嚴重度高說明缺陷對軟體造成的質量危害性大，需要優先處理，而嚴重性低的缺陷可能只是軟體不盡善盡美，可以稍後處理。

但是優先順序和嚴重度並不總是一一對應，但也存在低優先順序、高嚴重度的缺陷，或者高優先順序、低嚴重度的軟體缺陷。

5.7.缺陷管理的基本流程

（1）首先專案建立並初始化；

（2）測試人員發現錯誤，提交錯誤報告，此時缺陷狀態為New；

（3）專案經理收到測試人員提交的錯誤報告，對其進行確認，並分配給開發人員，此時缺陷狀態為Open；

（4）開發人員收到分配的錯誤，對其進行修正，並將缺陷狀態改為Fixed，再次將缺陷傳送給測試人員進行確認；

（5）測試人員對修復的錯誤進行驗證，錯誤消除，缺陷狀態改為Closed，否則錯誤狀態將重啟；

（6）如果錯誤暫時無法修改或者開發員認為無必要修改，錯誤將提交給評審委員會進行檢查是否有必要對其進行修改，如果沒有必要進行修改，則關閉專案缺陷；

（7）如果有必要進行修改則返回（4）；

測試人員：缺陷發現者

專案經理：專案的負責人

開發人員：執行開發任務的人員，主要完成設計、編碼工作

評審委員會：起仲裁作用

5.8.軟體缺陷報告：

缺陷報告是軟體測試過程中最重要的文件；是缺陷被修正的唯一方法，記錄了缺陷發生的環境，如各種資源的配置情況；

缺陷的再現步驟以及缺陷性質的說明記錄著缺陷的處理過程和狀態；

缺陷的處理程序從一定角度反映了測試的程序和被測軟體的質量狀況以及改善過程

5.9.缺陷報告的基本資訊：

5.10.缺陷報告的5C準則：

（1）準確：每個組成部分的描述準確不會引起誤解。

（2）簡潔：只包含必不可少的資訊，不包括任何多餘的內容。

（3）清晰：每個組成部分的描述清晰，易於理解。

（4）完整：包含復現該缺陷的完整步驟和其他本質資訊。

（5）一致：按照一致的格式書寫全部缺陷報告。

5.11. 5W1H原則

（1）Why——為什麼幹這件事？（目的）；
（2）What——怎麼回事？（物件）；
（3）Where——在什麼地方執行？（地點）；
（4）When——什麼時間執行？什麼時間完成？（時間）；
（5）Who——由誰執行？（人員）；
（6）How——怎樣執行？採取哪些有效措施？（方法）。
以上六個問題的英文第一個字母為5個W和1個H，所以簡稱5W1H工作法。運用這種方法分析問題時，先將這六個問題列出，得到回答後，再考慮列出一些小問題，又得到回答後，便可進行取消、合併、重排和簡化工作，對問題進行綜合分析研究，從而產生更新的創造性設想或決策。