之前看到有小伙伴說：軟件測試（測試工程師）沒啥技術含量，也沒有難度。

其實，真正牛逼的測試工程師，是需要掌握很多技能的，要熟悉產品的各項功能、應用場景，根據產品整理測試用例、記錄結果等等。。。

這里簡單的給大家介紹下關于測試的一些基本知識

1、黑盒測試、白盒測試、灰盒測試

1.1 黑盒測試

黑盒測試 又叫 功能測試、數據驅動測試 或 基于需求規格說明書的功能測試。該類測試注重于測試軟件的功能性需求。

采用這種測試方法，測試工程師把測試對象看作一個黑盒子，完全不考慮程序內部的邏輯結構和內部特性，只依據程序的《需求規格說明書》，檢查程序的功能是否符合它的功能說明。

測試工程師無需了解程序代碼的內部構造，完全模擬軟件產品的最終用戶使用該軟件，檢查軟件產品是否達到了用戶的需求。黑盒測試方法能更好、更真實地從用戶角度來考察被測系統的功能性需求實現情況。

在軟件測試的各個階段，如 單元測試、集成測試、系統測試及驗收測試 等階段中，黑盒測試都發揮著重要作用，尤其在系統測試和確認測試中，其作用是其他測試方法無法取代的。

1.2 白盒測試

白盒測試 又稱 結構測試、透明盒測試、邏輯驅動測試 或 基于代碼的測試。白盒測試是一種測試用例設計方法，盒子指的是被測試的軟件，白盒指的是盒子是可視的，即清楚盒子內部的東西以及里面是如何運作的。

"白盒"法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。"白盒"法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，得出測試數據。貫穿程序的獨立路徑數是天文數字。

白盒測試的測試方法有 代碼檢查法、靜態結構分析法、靜態質量度量法、邏輯覆蓋法、基本路徑測試法、域測試、符號測試、路徑覆蓋和程序變異。

白盒測試法的覆蓋標準有 邏輯覆蓋、循環覆蓋 和 基本路徑測試。

其中 邏輯覆蓋 包括 語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋 和 修改條件判斷覆蓋 。六種覆蓋標準發現錯誤的能力呈 由弱到強 的變化：

語句覆蓋：每條語句至少執行一次。

判定覆蓋：每個判定的每個分支至少執行一次。

條件覆蓋：每個判定的每個條件應取到各種可能的值。

判定/條件覆蓋：同時滿足判定覆蓋、條件覆蓋。

條件組合覆蓋：每個判定中各條件的每一種組合至少出現一次。

修改條件判斷覆蓋：每一個判斷的所有可能結果都出現過、每一個判斷中所有條件的所有可能結果都出現過、每一個進入點及結束點都執行過、判斷中每一個條件都可以獨立的影響判斷的結果。

1.3 灰盒測試

灰盒測試，是介于白盒測試與黑盒測試之間的一種測試，灰盒測試多用于集成測試階段，不僅關注輸出、輸入的正確性，同時也關注程序內部的情況。

灰盒測試不像白盒那樣詳細、完整，但又比黑盒測試更關注程序的內部邏輯，常常是通過一些表征性的現象、事件、標志來判斷內部的運行狀態。

2、自頂向下集成和自底向上集成各自的優缺點

集成測試的方法有兩種：非增量式測試 和 增量式測試。

非增量式是每個模塊測試完了再連接。

增量式則是測一個模塊，就連接一個模塊。而采用增量式測試時又有兩種選擇：自頂向下結合、自底向上結合。

2.1 自頂向下集成

自頂向下的集成測試就是 按照系統層次結構圖，以主程序模塊為中心，自上而下按照深度優先或者廣度優先策略，對各個模塊一邊組裝一邊進行測試。

優點：

較早地驗證了主要控制和判斷點

按深度優先可以首先實現和驗證一個完整的軟件功能

功能較早證實，帶來信心；只需一個驅動，減少驅動器開發的費用

支持故障隔離。

缺點：

柱的開發量大

底層驗證被推遲

底層組件測試不充分

適應于產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為。

2.2 自底向上集成

自底向上集成是 從系統層次結構圖的底層模塊開始進行組裝和集成測試的方式。對于某一個層次的特定模塊，因為它的子模塊（包括子模塊的所有下屬模塊）已經組裝并測試完成，所以不再需要樁模塊。在測試過程中，如果想要從子模塊得到信息可以通過直接運行子模塊得到。也就是說，在集成測試的過程中只需要開發相應的驅動模塊就可以了。

優點：

對底層組件行為較早驗證

工作起初可以并行集成，比自頂向下效率高

減少了樁的工作量；支持故障隔離。

缺點：

驅動的開發工作量大

對高層的驗證被推遲，設計上的錯誤不能被及時發現

適應于底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。

3、按照開發階段劃分，軟件測試可以分為哪幾個流程？

軟件測試類型按開發階段分為：

單元測試又稱為模塊測試，是針對軟件設計的最小單位——程序模塊進行正確性檢查的測試工作，單元測試需要從程序內部結構出發設計測試用例，多個模塊可以平行地獨立進行單元測試。

集成測試又稱為 組裝測試 或 聯合測試，在單元測試的基礎上需要將所有模塊按照概要設計說明書和詳細設計說明書的要求進行組裝。

確認測試的目標是驗證軟件的功能和性能以及其他特性是否與用戶的要求一致。確認測試一般包括有效性測試和軟件配置復查。一般由第三方測試機構進行。

系統測試：軟件作為計算機系統的一部分，與硬件、網絡、外設、支撐軟件、數據以及人員結合在一起，在實際或模擬環境下，對計算機系統進行測試，目的在于與系統需求比較，發現問題。

驗收測試：以用戶為主的測試，軟件開發人員和質量保證人員參加，由用戶設計測試用例。不是對系統進行全覆蓋測試，而是對核心業務流程進行測試。

4、什么是測試用例，為什么要設計測試用例？

測試用例（Test Case）是為某個特殊目標而編制的 一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。

1、指導測試的實施

測試用例主要適用于集成測試、系統測試和回歸測試。在實施測試時測試用例作為測試的標準，測試人員一定要按照測試用例嚴格按用例項目和測試步驟逐一實施測試。并對測試情況記錄在測試用例管理軟件中，以便自動生成測試結果文檔。

根據測試用例的測試等級，集成測試應測試那些用例，系統測試和回歸測試又該測試那些用例，在設計測試用例時都已作明確規定，實施測試時測試人員不能隨意作變動。

2、規劃測試數據的準備

在我們的實踐中測試數據是與測試用例分離的。按照測試用例配套準備一組或若干組測試原始數據，以及標準測試結果。

尤其象測試報表之類數據集的正確性，按照測試用例規劃準備測試數據是十分必須的。

除正常數據之外，還必須根據測試用例設計大量邊緣數據和錯誤數據。

3、編寫測試腳本的"設計規格說明書"

為提高測試效率，軟件測試已大力發展自動測試。自動測試的中心任務是編寫測試腳本。

如果說軟件工程中軟件編程必須有設計規格說明書，那么測試腳本的設計規格說明書就是測試用例。

4、評估測試結果的度量基準

完成測試實施后需要對測試結果進行評估，并且編制測試報告。

判斷軟件測試是否完成、衡量測試質量需要一些量化的結果。例：測試覆蓋率是多少、測試合格率是多少、重要測試合格率是多少，等等。以前統計基準是軟件模塊或功能點，顯得過于粗糙。采用測試用例作度量基準更加準確、有效。

5、分析缺陷的標準

通過收集缺陷，對比測試用例和缺陷數據庫，分析確證是漏測還是缺陷復現。漏測反映了測試用例的不完善，應立即補充相應測試用例，最終達到逐步完善軟件質量。而已有相應測試用例，則反映實施測試或變更處理存在問題。

5、軟件測試的常見模型

軟件測試和軟件開發一樣，都遵循軟件工程原理，遵循管理學原理。

測試專家通過實踐總結出了很多很好的測試模型。這些模型將測試活動進行了抽象，明確了測試與開發之間的關系，是測試管理的重要參考依據。

5.1 V 模型

與瀑布模型有公共的特性，V模型中的過程從左到右，描述了開發的過程到最后測試全經過。

優勢：

清楚地描述了這些測試階段和開發過程期間各階段的對應關系。

局限性：

把測試作為編碼之后的最后一個活動，需求分析等前期產生的錯誤直到后期的驗收測試才能發現。

5.2 W 模型

優勢：

測試與開發是同步進行的，明確地標注了生產周期中開發與測試之間的對應關系，從而更好、更快、更全地發現問題。

局限性：

W 模型和 V 模型都把軟件的開發視為需求、設計、編碼等一系列串行的活動，無法支持迭代、自發性以及變更調整。

5.3 H 模型

H 模型將測試活動從開發流程完全獨立出來，使測試流程形成一個完全獨立的流程，將測試準備活動與測試執行活動清晰地體現出來。其他流程可以是任何的開發流程，測試這邊只要測試條件成熟（滿足測試就緒點），測試執行活動就可進行（與其他流程并發地進行）。

優勢：

是一個獨立的流程，貫穿產品整個生命周期，與其他流程并發地進行。

充分的體現了測試過程。

軟件測試不僅僅指測試的執行，還包括很多其他的活動（計劃、需求分析、用例設計、環境搭建、提交缺陷、評估總結等）。

軟件測試要盡早準備，盡早執行，具有很強的靈活性。

軟件測試可以根據被測物的不同而分層次進行。

不同的測試活動可以是按照某個次序先后進行的，但也可能是反復的，只要某個測試達到準備就緒點,測試執行活動就可以開展。

局限性：

管理性要求高：由于模型很靈活，必須要定義清晰的規則和管理制度，否則測試過程將非常難以管理和控制。

技能要求高：H 模型要求能夠很好的定義每個迭代的規模，不能太大也不能太小。

測試就緒點分析困難：測試很多時候，你并不知道測試準備到什么時候是合適的，就緒點在哪里，就緒點的標準是什么，這就對后續的測試執行的啟動帶來很大的困難。

5.4 X 模型

X 模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此后將進行頻繁的交接，通過集成最終成為可執行的程序，然后再對這些可執行程序進行測試。

優勢：

很好地處理測試與開發的交接過程（交接的過程是一個時間段，而不是一個點）。

己通過集成測試的成品可以進行封裝并提交給用戶，也可以作為更大規模和范圍內集成的一部分。多根并行的曲線表示變更可以在各個部分發生。

X 模型還定位了探索性測試，這是給有經驗的測試人員在測試計劃之外發現更多的軟件缺陷。

局限性：

探索性測試可能對測試造成人力、物力和財力的浪費，對測試員的熟練程度要求比較高。

審核編輯：郭婷