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