1.軟件測(cè)試簡(jiǎn)介

軟件測(cè)試技術(shù)是軟件開發(fā)過程中的一個(gè)重要組成部分，是貫穿整個(gè)軟件開發(fā)生命周期、對(duì)軟件產(chǎn)品（包括階段性產(chǎn)品）進(jìn)行驗(yàn)證和確認(rèn)的活動(dòng)過程，其目的是盡快盡早地發(fā)現(xiàn)在軟件產(chǎn)品中所存在的各種問題——與用戶需求、預(yù)先定義的不一致性。檢查軟件產(chǎn)品的 Bug。寫成測(cè)試報(bào)告，交于開發(fā)人員修改。軟件測(cè)試人員的基本目標(biāo)是發(fā)現(xiàn)軟件中的錯(cuò)誤。

軟件測(cè)試技術(shù)就相當(dāng)于是軟件測(cè)試人員的武器。作為軟件測(cè)試人員，我們必須要清除的了解可以通過哪些手段去保障產(chǎn)品的質(zhì)量。只有知道了這些，才能更好的完成測(cè)試的工作。

2.軟件測(cè)試分類

軟件測(cè)試的分類可以按照不同的維度去劃分，一般來說，我們可以按照下面的這些維度去劃分。

按開發(fā)階段分類

• 單元測(cè)試

• 集成測(cè)試

• 冒煙測(cè)試

• 系統(tǒng)測(cè)試

• 驗(yàn)收測(cè)試

按測(cè)試實(shí)施組織分類

• α 測(cè)試：非正式驗(yàn)收測(cè)試

• β 測(cè)試：內(nèi)測(cè)后的公測(cè)

按測(cè)試執(zhí)行方式分類

• 靜態(tài)測(cè)試：不啟動(dòng)被測(cè)對(duì)象的測(cè)試，比如代碼走讀，代碼評(píng)審，文檔評(píng)審，需求評(píng)審等

• 動(dòng)態(tài)測(cè)試：?jiǎn)?dòng)被測(cè)試對(duì)象的測(cè)試，比如白盒測(cè)試，黑盒測(cè)試等

按是否查看代碼分類

• 黑盒測(cè)試：指的是把被測(cè)的軟件看作是一個(gè)黑盒子，我們不去關(guān)心盒子里面的結(jié)構(gòu)是什么樣子的，只關(guān)心軟件的輸入數(shù)據(jù)和輸出結(jié)果。

• 白盒測(cè)試：指的是把盒子蓋子打開，去研究里面的源代碼和程序結(jié)果。

按是否手工執(zhí)行分類

• 手工測(cè)試：由人去一個(gè)一個(gè)的去執(zhí)行測(cè)試用例，通過鍵盤鼠標(biāo)等輸入一些參數(shù)，查看返回結(jié)果是否符合預(yù)期結(jié)果。通常用于黑盒測(cè)試方法或系統(tǒng)測(cè)試階段。

• 自動(dòng)化測(cè)試：把以人為驅(qū)動(dòng)的測(cè)試行為轉(zhuǎn)化為機(jī)器執(zhí)行的一種過程。

按測(cè)試對(duì)象分類

• 性能測(cè)試：檢查系統(tǒng)是否滿足需求規(guī)格說明書中規(guī)定的性能

• 安全測(cè)試：各種的攻擊手段，例如 SQL 注入、XSS 等。

• 兼容性測(cè)試：軟件和硬件之間是否能夠發(fā)揮很好的效率工作，會(huì)不會(huì)影響導(dǎo)致系統(tǒng)的奔潰

• 文檔測(cè)試

• 易用性測(cè)試：用戶體驗(yàn)測(cè)試

• 業(yè)務(wù)測(cè)試：測(cè)試人員將系統(tǒng)的各個(gè)模塊串接起來運(yùn)行、模擬真是用戶實(shí)際的工作流程，滿足永續(xù)需求定義的功能進(jìn)行測(cè)試的過程。

• 界面測(cè)試：也稱為 UI 測(cè)試。測(cè)試用戶界面的功能模塊的布局是否合理，整體風(fēng)格是否一致、各個(gè)控件的放置位置是否符合客戶的使用習(xí)慣，還要測(cè)試操作界面操作便捷性、導(dǎo)航簡(jiǎn)單易懂性、頁面元素的可用性，頁面元素的可用性、界面中文字是否正確，命名是否統(tǒng)一，頁面是否美觀、文字、圖片組合是否完美。

• 安裝測(cè)試：測(cè)試程序的安裝、卸載

其他分類

• 回歸測(cè)試：修改了舊代碼后，重新時(shí)行測(cè)試以確認(rèn)修改后沒有引入新的錯(cuò)誤或?qū)е缕渌a產(chǎn)生錯(cuò)誤。

• 隨機(jī)測(cè)試：指測(cè)試中的所有輸入數(shù)據(jù)都是隨機(jī)生成的，其目的是模擬用戶的真實(shí)操作，并發(fā)現(xiàn)一些邊緣性的錯(cuò)誤。

• 探索性測(cè)試：試可以說是一種測(cè)試思維技術(shù)。它沒有很多實(shí)際的測(cè)試方法、技術(shù)和工具，但是卻是所有測(cè)試人員都應(yīng)該掌握的一種測(cè)試思維方式。探索性強(qiáng)調(diào)測(cè)試人員的主觀能動(dòng)性，拋棄繁雜的測(cè)試計(jì)劃和測(cè)試用例設(shè)計(jì)過程，強(qiáng)調(diào)在碰到問題時(shí)及時(shí)改變測(cè)試策略。

3.黑盒測(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ù)程序的需求文檔，檢查程序的功能是否符合它的功能說明。測(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è)試方法無法取代的。

方法

從理論上講，黑盒測(cè)試只有采用窮舉輸入測(cè)試，把所有可能的輸入都作為測(cè)試情況考慮，才能查出程序中所有的錯(cuò)誤。實(shí)際上測(cè)試情況有無窮多個(gè)，人們不僅要測(cè)試所有合法的輸入，而且還要對(duì)那些不合法但可能的輸入進(jìn)行測(cè)試。這樣看來，完全測(cè)試是不可能的，所以我們要進(jìn)行有針對(duì)性的測(cè)試，通過制定測(cè)試案例指導(dǎo)測(cè)試的實(shí)施，保證軟件測(cè)試有組織、按步驟，以及有計(jì)劃地進(jìn)行。

黑盒測(cè)試行為必須能夠加以量化，才能真正保證軟件質(zhì)量，而測(cè)試用例就是將測(cè)試行為具體量化的方法之一。常用的黑盒測(cè)試方法有劃分等價(jià)類、邊界值分析、錯(cuò)誤推測(cè)法、因果圖與判定表、正交試驗(yàn)設(shè)計(jì)、決策樹等。

流程

測(cè)試計(jì)劃：適當(dāng)選擇測(cè)試內(nèi)容，合理安排測(cè)試人員、測(cè)試時(shí)間及測(cè)試資源等。

測(cè)試設(shè)計(jì)：將測(cè)試計(jì)劃階段制訂的測(cè)試需求分解、細(xì)化為若干個(gè)可執(zhí)行的測(cè)試過程，并為每個(gè)測(cè)試過程選擇適當(dāng)?shù)臏y(cè)試用例（測(cè)試用例選擇的好壞將直接影響到測(cè)試結(jié)果的有效性）。

測(cè)試開發(fā)：建立可重復(fù)使用的自動(dòng)測(cè)試過程。

測(cè)試執(zhí)行：執(zhí)行測(cè)試開發(fā)階段建立的自動(dòng)測(cè)試過程，并對(duì)所發(fā)現(xiàn)的缺陷進(jìn)行跟蹤管理。

測(cè)試評(píng)估：結(jié)合量化的測(cè)試覆蓋域及缺陷跟蹤報(bào)告，對(duì)于應(yīng)用軟件的質(zhì)量和開發(fā)團(tuán)隊(duì)的工作進(jìn)度及工作效率進(jìn)行綜合評(píng)價(jià)。

優(yōu)點(diǎn)

• 對(duì)較大的代碼單元來說，黑盒測(cè)試比白盒測(cè)試的效率高

• 測(cè)試人員不需要了解實(shí)現(xiàn)的細(xì)節(jié)，包括特定的編程語言

• 測(cè)試人員和編程人員是相互獨(dú)立的

• 從用戶的角度進(jìn)行測(cè)試，很容易被接受和理解

• 有助于暴露任何與規(guī)格不一致或者歧異的地方

• 測(cè)試用例可以在規(guī)格完成后馬上進(jìn)行

缺點(diǎn)

• 不能測(cè)試程序內(nèi)部特定部位

• 程序未執(zhí)行的代碼無法發(fā)現(xiàn)

• 沒有清晰的和簡(jiǎn)明的規(guī)格，測(cè)試用例很難被設(shè)計(jì)

• 不可能進(jìn)行完全的、毫無遺漏的輸入測(cè)試

4.白盒測(cè)試

白盒測(cè)試又稱結(jié)構(gòu)測(cè)試、透明盒測(cè)試、邏輯驅(qū)動(dòng)測(cè)試或基于代碼的測(cè)試。

白盒法全面了解程序內(nèi)部邏輯結(jié)構(gòu)、對(duì)所有邏輯路徑進(jìn)行測(cè)試。

白盒測(cè)試是通過檢查軟件內(nèi)部的邏輯結(jié)構(gòu)，對(duì)軟件中的邏輯路徑進(jìn)行覆蓋測(cè)試。在程序不同地方設(shè)立檢查點(diǎn)，檢查程序的狀態(tài)，以確定實(shí)際運(yùn)行狀態(tài)與預(yù)期狀態(tài)是否一致

白盒測(cè)試常用的方法有代碼檢查法、靜態(tài)結(jié)構(gòu)分析法、靜態(tài)質(zhì)量度量法、邏輯覆蓋法、基本路徑測(cè)試法。

優(yōu)點(diǎn)

• 迫使測(cè)試人員去了解軟件的實(shí)現(xiàn)

• 檢測(cè)代碼中的每條路徑和分支

• 揭示隱藏在代碼中的錯(cuò)誤

• 對(duì)代碼的測(cè)試進(jìn)行比較徹底

缺點(diǎn)

• 白盒測(cè)試投入較大，成本較高

• 白盒測(cè)試不驗(yàn)證規(guī)格的正確性

• 無法檢查代碼中遺漏的路徑和數(shù)據(jù)敏感性錯(cuò)誤

5.分層測(cè)試體系

其中 Unit 代表單元測(cè)試，API 代表接口測(cè)試，UI 代表頁面級(jí)的系統(tǒng)測(cè)試。分層的自動(dòng)化測(cè)試倡導(dǎo)產(chǎn)品的不同層次都需要自動(dòng)化測(cè)試，這個(gè)金字塔也正表示不同層次需要投入的精力和工作量。對(duì)于測(cè)試金字塔，越靠下越容易自動(dòng)化，越靠下成本越低，越靠下效率越高。

分層測(cè)試顧名思義就是分多個(gè)層次一個(gè)層次一個(gè)層次的測(cè)試，比如先測(cè)完中間接口層，再測(cè)最上層的界面（當(dāng)然了，也可以同時(shí)測(cè)試）。

分層測(cè)試的測(cè)試方法還是原來的測(cè)試方法，但對(duì)測(cè)試人員的代碼能力還有自動(dòng)化測(cè)試水平有較高要求，同時(shí)要求測(cè)試人員和開發(fā)團(tuán)隊(duì)真正的理解敏捷開發(fā)和敏捷測(cè)試，甚至要求開發(fā)團(tuán)隊(duì)達(dá)到開發(fā)即測(cè)試、測(cè)試即開發(fā)的能力。

單元測(cè)試

對(duì)軟件中的最小可測(cè)試單元進(jìn)行檢查和驗(yàn)證。具體的說就是開發(fā)者編寫的一小段代碼，用于檢驗(yàn)被測(cè)代碼的一個(gè)很小的、很明確的功能是否正確。通常而言，一個(gè)單元測(cè)試是用于判斷某個(gè)特定條件（或者場(chǎng)景）下某個(gè)特定函數(shù)的行為

缺點(diǎn)是入門門檻高，沒有好的實(shí)踐方法（覆蓋率和編寫標(biāo)準(zhǔn)），則可能無法推行。

優(yōu)點(diǎn)是能盡早執(zhí)行，降低測(cè)試成本，復(fù)用性好，可反復(fù)執(zhí)行

接口測(cè)試

接口測(cè)試是測(cè)試系統(tǒng)組件間接口的一種測(cè)試，主要用于檢測(cè)外部系統(tǒng)與系統(tǒng)之間以及內(nèi)部各個(gè)子系統(tǒng)之間的交互點(diǎn)。

測(cè)試的重點(diǎn)是要檢查接口參數(shù)傳遞的正確性，接口功能實(shí)現(xiàn)的正確性，輸出結(jié)果的正確性，以及對(duì)各種異常情況的容錯(cuò)處理的完整性和合理性。

接口測(cè)試可以更早介入，介入越早越能更早的發(fā)現(xiàn)問題，還可以縮短項(xiàng)目周期，能夠發(fā)現(xiàn)更底層的 Bug，減少開發(fā)成本。

因?yàn)椴煌耍ㄇ岸?，后端）的工作進(jìn)度不一樣，所以我們要針對(duì)最開始出來的接口，以及需要調(diào)用其他公司的（銀行，支付寶，微信，QQ 等）一些接口進(jìn)行接口測(cè)試及驗(yàn)證數(shù)據(jù)，從安全層面來說，只依賴前端進(jìn)行限制已經(jīng)完全不能滿足系統(tǒng)的安全要求（繞過前面實(shí)在太容易），需要后端同樣進(jìn)行控制，在這種情況下就需要從接口層面進(jìn)行驗(yàn)證。前后端傳輸、日志打印等信息是否加密傳輸也是需要驗(yàn)證的，特別是涉及到用戶的隱私信息，如身份證，銀行卡等。

UI 測(cè)試

UI 測(cè)試測(cè)的是應(yīng)用中的用戶界面是否如預(yù)期工作。比如，用戶的輸入需要觸發(fā)正確的動(dòng)作，數(shù)據(jù)需要能展示給用戶看，UI 的狀態(tài)需要發(fā)生正確變化等。

對(duì)于 UI 測(cè)試，可以采用靜態(tài)測(cè)試方法，也可以采用動(dòng)態(tài)測(cè)試方法。

對(duì)于用戶界面的布局，風(fēng)格，字體，圖片等與顯示相關(guān)的部分測(cè)試應(yīng)該采用靜態(tài)測(cè)試，比如點(diǎn)檢表測(cè)試，即將測(cè)試必須通過的項(xiàng)用點(diǎn)檢表一條一條列舉出，然后通過觀察確保每項(xiàng)是否通過。

對(duì)用戶界面中各個(gè)類別的控件應(yīng)該采用動(dòng)態(tài)測(cè)試，即編寫測(cè)試用例或者點(diǎn)檢表，對(duì)每個(gè)按鈕的響應(yīng)情況進(jìn)行測(cè)試，是否符合概要設(shè)計(jì)所規(guī)定的條件，還可以對(duì)用戶界面在不同環(huán)境下的顯示情況進(jìn)行測(cè)試。

UI 測(cè)試需要關(guān)注的內(nèi)容包括通過瀏覽測(cè)試對(duì)象可正確反映業(yè)務(wù)的功能和需求，這種瀏覽包括窗口與窗口之間、字段與字段之間的瀏覽。各種訪問方法 （Tab 鍵、鼠標(biāo)移動(dòng)和快捷鍵）是否支持。還有窗口的對(duì)象和特征，比如菜單、大小、位置、狀態(tài)和中心等都符合標(biāo)準(zhǔn)。