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