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

其實，真正牛逼的測試工程師，是需要掌握很多技能的，要熟悉產(chǎn)品的各項功能、應(yīng)用場景，根據(jù)產(chǎn)品整理測試用例、記錄結(jié)果等等。。。

這里簡單的給大家介紹下關(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á)到了用戶的需求。黑盒測試方法能更好、更真實地從用戶角度來考察被測系統(tǒng)的功能性需求實現(xiàn)情況。

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

1.2 白盒測試

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

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

白盒測試的測試方法有 代碼檢查法、靜態(tài)結(jié)構(gòu)分析法、靜態(tài)質(zhì)量度量法、邏輯覆蓋法、基本路徑測試法、域測試、符號測試、路徑覆蓋和程序變異。

白盒測試法的覆蓋標(biāo)準(zhǔn)有 邏輯覆蓋、循環(huán)覆蓋 和 基本路徑測試。

其中 邏輯覆蓋 包括 語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋 和 修改條件判斷覆蓋 。六種覆蓋標(biāo)準(zhǔn)發(fā)現(xiàn)錯誤的能力呈 由弱到強 的變化：

語句覆蓋：每條語句至少執(zhí)行一次。

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

條件覆蓋：每個判定的每個條件應(yīng)取到各種可能的值。

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

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

修改條件判斷覆蓋：每一個判斷的所有可能結(jié)果都出現(xiàn)過、每一個判斷中所有條件的所有可能結(jié)果都出現(xiàn)過、每一個進(jìn)入點及結(jié)束點都執(zhí)行過、判斷中每一個條件都可以獨立的影響判斷的結(jié)果。

1.3 灰盒測試

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

灰盒測試不像白盒那樣詳細(xì)、完整，但又比黑盒測試更關(guān)注程序的內(nèi)部邏輯，常常是通過一些表征性的現(xiàn)象、事件、標(biāo)志來判斷內(nèi)部的運行狀態(tài)。

2、自頂向下集成和自底向上集成各自的優(yōu)缺點

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

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

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

2.1 自頂向下集成

自頂向下的集成測試就是 按照系統(tǒng)層次結(jié)構(gòu)圖，以主程序模塊為中心，自上而下按照深度優(yōu)先或者廣度優(yōu)先策略，對各個模塊一邊組裝一邊進(jìn)行測試。

優(yōu)點：

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

按深度優(yōu)先可以首先實現(xiàn)和驗證一個完整的軟件功能

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

支持故障隔離。

缺點：

柱的開發(fā)量大

底層驗證被推遲

底層組件測試不充分

適應(yīng)于產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定；高層接口變化較小；底層接口未定義或經(jīng)常可能被修改；產(chǎn)口控制組件具有較大的技術(shù)風(fēng)險，需要盡早被驗證；希望盡早能看到產(chǎn)品的系統(tǒng)功能行為。

2.2 自底向上集成

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

優(yōu)點：

對底層組件行為較早驗證

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

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

缺點：

驅(qū)動的開發(fā)工作量大

對高層的驗證被推遲，設(shè)計上的錯誤不能被及時發(fā)現(xiàn)

適應(yīng)于底層接口比較穩(wěn)定；高層接口變化比較頻繁；底層組件較早被完成。

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

軟件測試類型按開發(fā)階段分為：

單元測試又稱為模塊測試，是針對軟件設(shè)計的最小單位——程序模塊進(jìn)行正確性檢查的測試工作，單元測試需要從程序內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例，多個模塊可以平行地獨立進(jìn)行單元測試。

集成測試又稱為 組裝測試 或 聯(lián)合測試，在單元測試的基礎(chǔ)上需要將所有模塊按照概要設(shè)計說明書和詳細(xì)設(shè)計說明書的要求進(jìn)行組裝。

確認(rèn)測試的目標(biāo)是驗證軟件的功能和性能以及其他特性是否與用戶的要求一致。確認(rèn)測試一般包括有效性測試和軟件配置復(fù)查。一般由第三方測試機構(gòu)進(jìn)行。

系統(tǒng)測試：軟件作為計算機系統(tǒng)的一部分，與硬件、網(wǎng)絡(luò)、外設(shè)、支撐軟件、數(shù)據(jù)以及人員結(jié)合在一起，在實際或模擬環(huán)境下，對計算機系統(tǒng)進(jìn)行測試，目的在于與系統(tǒng)需求比較，發(fā)現(xiàn)問題。

驗收測試：以用戶為主的測試，軟件開發(fā)人員和質(zhì)量保證人員參加，由用戶設(shè)計測試用例。不是對系統(tǒng)進(jìn)行全覆蓋測試，而是對核心業(yè)務(wù)流程進(jìn)行測試。

4、什么是測試用例，為什么要設(shè)計測試用例？

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

1、指導(dǎo)測試的實施

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

根據(jù)測試用例的測試等級，集成測試應(yīng)測試那些用例，系統(tǒng)測試和回歸測試又該測試那些用例，在設(shè)計測試用例時都已作明確規(guī)定，實施測試時測試人員不能隨意作變動。

2、規(guī)劃測試數(shù)據(jù)的準(zhǔn)備

在我們的實踐中測試數(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)

完成測試實施后需要對測試結(jié)果進(jìn)行評估，并且編制測試報告。

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

5、分析缺陷的標(biāo)準(zhǔn)

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

5、軟件測試的常見模型

軟件測試和軟件開發(fā)一樣，都遵循軟件工程原理，遵循管理學(xué)原理。

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

5.1 V 模型

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

優(yōu)勢：

清楚地描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系。

局限性：

把測試作為編碼之后的最后一個活動，需求分析等前期產(chǎ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ā)流程完全獨立出來，使測試流程形成一個完全獨立的流程，將測試準(zhǔn)備活動與測試執(zhí)行活動清晰地體現(xiàn)出來。其他流程可以是任何的開發(fā)流程，測試這邊只要測試條件成熟（滿足測試就緒點），測試執(zhí)行活動就可進(jìn)行（與其他流程并發(fā)地進(jìn)行）。

優(yōu)勢：

是一個獨立的流程，貫穿產(chǎn)品整個生命周期，與其他流程并發(fā)地進(jìn)行。

充分的體現(xiàn)了測試過程。

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

軟件測試要盡早準(zhǔn)備，盡早執(zhí)行，具有很強的靈活性。

軟件測試可以根據(jù)被測物的不同而分層次進(jìn)行。

不同的測試活動可以是按照某個次序先后進(jìn)行的，但也可能是反復(fù)的，只要某個測試達(dá)到準(zhǔn)備就緒點,測試執(zhí)行活動就可以開展。

局限性：

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

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

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

5.4 X 模型

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

優(yōu)勢：

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

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

X 模型還定位了探索性測試，這是給有經(jīng)驗的測試人員在測試計劃之外發(fā)現(xiàn)更多的軟件缺陷。

局限性：

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

審核編輯：郭婷