.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.缺陷報告的基本信息：
| 編號 |
|
編號 |
|
| 1 |
缺陷標題 |
8 |
缺陷的類型 |
| 2 |
缺陷ＩＤ |
9 |
嚴重性 |
| 3 |
報告人 |
10 |
優先級 |
| 4 |
報告日期 |
11 |
關鍵詞 |
| 5 |
程序的名稱 |
12 |
缺陷描述 |
| 6 |
版本號 |
13 |
重現步驟 |
| 7 |
配置 |
14 |
結果對比 |
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工作法。運用這種方法分析問題時，先將這六個問題列出，得到回答后，再考慮列出一些小問題，又得到回答后，便可進行取消、合並、重排和簡化工作，對問題進行綜合分析研究，從而產生更新的創造性設想或決策。