最近工作接觸測試相關(guān)的內(nèi)容比較多，這里簡單的給大家介紹下關(guān)于軟件測試的一些基本知識
1、黑盒測試、白盒測試、灰盒測試
1.1 黑盒測試
黑盒測試 又叫 功能測試、數(shù)據(jù)驅(qū)動測試 或 基于需求規(guī)格說明書的功能測試。該類測試注重于測試軟件的功能性需求。
采用這種測試方法，測試工程師把測試對象看作一個黑盒子，完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的《需求規(guī)格說明書》，檢查程序的功能是否符合它的功能說明。
測試工程師無需了解程序代碼的內(nèi)部構(gòu)造，完全模擬軟件產(chǎn)品的最終用戶使用該軟件，檢查軟件產(chǎn)品是否達到了用戶的需求。黑盒測試方法能更好、更真實地從用戶角度來考察被測系統(tǒng)的功能性需求實現(xiàn)情況。
在軟件測試的各個階段，如 單元測試、集成測試、系統(tǒng)測試及驗收測試 等階段中，黑盒測試都發(fā)揮著重要作用，尤其在系統(tǒng)測試和確認測試中，其作用是其他測試方法無法取代的。
1.2 白盒測試
白盒測試 又稱 結(jié)構(gòu)測試、透明盒測試、邏輯驅(qū)動測試 或 基于代碼的測試。白盒測試是一種測試用例設計方法，盒子指的是被測試的軟件，白盒指的是盒子是可視的，即清楚盒子內(nèi)部的東西以及里面是如何運作的。
"白盒"法全面了解程序內(nèi)部邏輯結(jié)構(gòu)、對所有邏輯路徑進行測試。"白盒"法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內(nèi)部結(jié)構(gòu)，從檢查程序的邏輯著手，得出測試數(shù)據(jù)。貫穿程序的獨立路徑數(shù)是天文數(shù)字。
白盒測試的測試方法有 代碼檢查法、靜態(tài)結(jié)構(gòu)分析法、靜態(tài)質(zhì)量度量法、邏輯覆蓋法、基本路徑測試法、域測試、符號測試、路徑覆蓋和程序變異。
白盒測試法的覆蓋標準有 邏輯覆蓋、循環(huán)覆蓋 和 基本路徑測試。
其中 邏輯覆蓋 包括 語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋 和 修改條件判斷覆蓋 。六種覆蓋標準發(fā)現(xiàn)錯誤的能力呈 由弱到強 的變化：
語句覆蓋：每條語句至少執(zhí)行一次。
判定覆蓋：每個判定的每個分支至少執(zhí)行一次。
條件覆蓋：每個判定的每個條件應取到各種可能的值。
判定/條件覆蓋：同時滿足判定覆蓋、條件覆蓋。
條件組合覆蓋：每個判定中各條件的每一種組合至少出現(xiàn)一次。
修改條件判斷覆蓋：每一個判斷的所有可能結(jié)果都出現(xiàn)過、每一個判斷中所有條件的所有可能結(jié)果都出現(xiàn)過、每一個進入點及結(jié)束點都執(zhí)行過、判斷中每一個條件都可以獨立的影響判斷的結(jié)果。
1.3 灰盒測試
灰盒測試，是介于白盒測試與黑盒測試之間的一種測試，灰盒測試多用于集成測試階段，不僅關(guān)注輸出、輸入的正確性，同時也關(guān)注程序內(nèi)部的情況。
灰盒測試不像白盒那樣詳細、完整，但又比黑盒測試更關(guān)注程序的內(nèi)部邏輯，常常是通過一些表征性的現(xiàn)象、事件、標志來判斷內(nèi)部的運行狀態(tài)。
2、自頂向下集成和自底向上集成各自的優(yōu)缺點
集成測試的方法有兩種：非增量式測試 和 增量式測試。
非增量式是每個模塊測試完了再連接。
增量式則是測一個模塊，就連接一個模塊。而采用增量式測試時又有兩種選擇：自頂向下結(jié)合、自底向上結(jié)合。
2.1 自頂向下集成
自頂向下的集成測試就是 按照系統(tǒng)層次結(jié)構(gòu)圖，以主程序模塊為中心，自上而下按照深度優(yōu)先或者廣度優(yōu)先策略，對各個模塊一邊組裝一邊進行測試。
優(yōu)點：
1、較早地驗證了主要控制和判斷點
2、按深度優(yōu)先可以首先實現(xiàn)和驗證一個完整的軟件功能
3、功能較早證實，帶來信心;只需一個驅(qū)動，減少驅(qū)動器開發(fā)的費用
4、支持故障隔離。
缺點：
1、柱的開發(fā)量大
2、底層驗證被推遲
3、底層組件測試不充分
適應于產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定;高層接口變化較小;底層接口未定義或經(jīng)?？赡鼙恍薷?產(chǎn)口控制組件具有較大的技術(shù)風險，需要盡早被驗證;希望盡早能看到產(chǎn)品的系統(tǒng)功能行為。
2.2 自底向上集成
自底向上集成是 從系統(tǒng)層次結(jié)構(gòu)圖的底層模塊開始進行組裝和集成測試的方式。對于某一個層次的特定模塊，因為它的子模塊(包括子模塊的所有下屬模塊)已經(jīng)組裝并測試完成，所以不再需要樁模塊。在測試過程中，如果想要從子模塊得到信息可以通過直接運行子模塊得到。也就是說，在集成測試的過程中只需要開發(fā)相應的驅(qū)動模塊就可以了。
優(yōu)點：
1、對底層組件行為較早驗證
2、工作起初可以并行集成，比自頂向下效率高
3、減少了樁的工作量;支持故障隔離。
缺點：
1、驅(qū)動的開發(fā)工作量大
2、對高層的驗證被推遲，設計上的錯誤不能被及時發(fā)現(xiàn)
3、適應于底層接口比較穩(wěn)定;高層接口變化比較頻繁;底層組件較早被完成。
3、按照開發(fā)階段劃分，軟件測試可以分為哪幾個流程?
軟件測試類型按開發(fā)階段分為：
單元測試 又稱為模塊測試，是針對軟件設計的最小單位——程序模塊進行正確性檢查的測試工作，單元測試需要從程序內(nèi)部結(jié)構(gòu)出發(fā)設計測試用例，多個模塊可以平行地獨立進行單元測試。
集成測試 又稱為 組裝測試 或 聯(lián)合測試，在單元測試的基礎(chǔ)上需要將所有模塊按照概要設計說明書和詳細設計說明書的要求進行組裝。
確認測試 的目標是驗證軟件的功能和性能以及其他特性是否與用戶的要求一致。確認測試一般包括有效性測試和軟件配置復查。一般由第三方測試機構(gòu)進行。
系統(tǒng)測試：軟件作為計算機系統(tǒng)的一部分，與硬件、網(wǎng)絡、外設、支撐軟件、數(shù)據(jù)以及人員結(jié)合在一起，在實際或模擬環(huán)境下，對計算機系統(tǒng)進行測試，目的在于與系統(tǒng)需求比較，發(fā)現(xiàn)問題。
驗收測試：以用戶為主的測試，軟件開發(fā)人員和質(zhì)量保證人員參加，由用戶設計測試用例。不是對系統(tǒng)進行全覆蓋測試，而是對核心業(yè)務流程進行測試。
4、什么是測試用例，為什么要設計測試用例?
測試用例(Test Case)是為某個特殊目標而編制的 一組測試輸入、執(zhí)行條件以及預期結(jié)果，以便測試某個程序路徑或核實是否滿足某個特定需求。
1、指導測試的實施
測試用例主要適用于集成測試、系統(tǒng)測試和回歸測試。在實施測試時測試用例作為測試的標準，測試人員一定要按照測試用例嚴格按用例項目和測試步驟逐一實施測試。并對測試情況記錄在測試用例管理軟件中，以便自動生成測試結(jié)果文檔。
根據(jù)測試用例的測試等級，集成測試應測試那些用例，系統(tǒng)測試和回歸測試又該測試那些用例，在設計測試用例時都已作明確規(guī)定，實施測試時測試人員不能隨意作變動。
2、規(guī)劃測試數(shù)據(jù)的準備
在我們的實踐中測試數(shù)據(jù)是與測試用例分離的。按照測試用例配套準備一組或若干組測試原始數(shù)據(jù)，以及標準測試結(jié)果。
尤其象測試報表之類數(shù)據(jù)集的正確性，按照測試用例規(guī)劃準備測試數(shù)據(jù)是十分必須的。
除正常數(shù)據(jù)之外，還必須根據(jù)測試用例設計大量邊緣數(shù)據(jù)和錯誤數(shù)據(jù)。
3、編寫測試腳本的"設計規(guī)格說明書"
為提高測試效率，軟件測試已大力發(fā)展自動測試。自動測試的中心任務是編寫測試腳本。
如果說軟件工程中軟件編程必須有設計規(guī)格說明書，那么測試腳本的設計規(guī)格說明書就是測試用例。
4、評估測試結(jié)果的度量基準
完成測試實施后需要對測試結(jié)果進行評估，并且編制測試報告。
判斷軟件測試是否完成、衡量測試質(zhì)量需要一些量化的結(jié)果。例：測試覆蓋率是多少、測試合格率是多少、重要測試合格率是多少，等等。以前統(tǒng)計基準是軟件模塊或功能點，顯得過于粗糙。采用測試用例作度量基準更加準確、有效。
5、分析缺陷的標準
通過收集缺陷，對比測試用例和缺陷數(shù)據(jù)庫，分析確證是漏測還是缺陷復現(xiàn)。漏測反映了測試用例的不完善，應立即補充相應測試用例，最終達到逐步完善軟件質(zhì)量。而已有相應測試用例，則反映實施測試或變更處理存在問題。
5、軟件測試的常見模型
軟件測試和軟件開發(fā)一樣，都遵循軟件工程原理，遵循管理學原理。
測試專家通過實踐總結(jié)出了很多很好的測試模型。這些模型將測試活動進行了抽象，明確了測試與開發(fā)之間的關(guān)系，是測試管理的重要參考依據(jù)。
5.1 V 模型
與瀑布模型有公共的特性，V模型中的過程從左到右，描述了開發(fā)的過程到最后測試全經(jīng)過。
優(yōu)勢：
清楚地描述了這些測試階段和開發(fā)過程期間各階段的對應關(guān)系。
局限性：
把測試作為編碼之后的最后一個活動，需求分析等前期產(chǎn)生的錯誤直到后期的驗收測試才能發(fā)現(xiàn)。
5.2 W 模型
優(yōu)勢：
測試與開發(fā)是同步進行的，明確地標注了生產(chǎn)周期中開發(fā)與測試之間的對應關(guān)系，從而更好、更快、更全地發(fā)現(xiàn)問題。
局限性：
W 模型和 V 模型都把軟件的開發(fā)視為需求、設計、編碼等一系列串行的活動，無法支持迭代、自發(fā)性以及變更調(diào)整。
5.3 H 模型
H 模型將測試活動從開發(fā)流程完全獨立出來，使測試流程形成一個完全獨立的流程，將測試準備活動與測試執(zhí)行活動清晰地體現(xiàn)出來。其他流程可以是任何的開發(fā)流程，測試這邊只要測試條件成熟(滿足測試就緒點)，測試執(zhí)行活動就可進行(與其他流程并發(fā)地進行)。
優(yōu)勢：
是一個獨立的流程，貫穿產(chǎn)品整個生命周期，與其他流程并發(fā)地進行。
充分的體現(xiàn)了測試過程。
軟件測試不僅僅指測試的執(zhí)行，還包括很多其他的活動(計劃、需求分析、用例設計、環(huán)境搭建、提交缺陷、評估總結(jié)等)。
軟件測試要盡早準備，盡早執(zhí)行，具有很強的靈活性。
軟件測試可以根據(jù)被測物的不同而分層次進行。
不同的測試活動可以是按照某個次序先后進行的，但也可能是反復的，只要某個測試達到準備就緒點,測試執(zhí)行活動就可以開展。
局限性：
管理性要求高：由于模型很靈活，必須要定義清晰的規(guī)則和管理制度，否則測試過程將非常難以管理和控制。
技能要求高：H 模型要求能夠很好的定義每個迭代的規(guī)模，不能太大也不能太小。
測試就緒點分析困難：測試很多時候，你并不知道測試準備到什么時候是合適的，就緒點在哪里，就緒點的標準是什么，這就對后續(xù)的測試執(zhí)行的啟動帶來很大的困難。
5.4 X 模型
X 模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此后將進行頻繁的交接，通過集成最終成為可執(zhí)行的程序，然后再對這些可執(zhí)行程序進行測試。
優(yōu)勢：
很好地處理測試與開發(fā)的交接過程(交接的過程是一個時間段，而不是一個點)。
己通過集成測試的成品可以進行封裝并提交給用戶，也可以作為更大規(guī)模和范圍內(nèi)集成的一部分。多根并行的曲線表示變更可以在各個部分發(fā)生。
X 模型還定位了探索性測試，這是給有經(jīng)驗的測試人員在測試計劃之外發(fā)現(xiàn)更多的軟件缺陷。
局限性：
探索性測試可能對測試造成人力、物力和財力的浪費，對測試員的熟練程度要求比較高。
