前言

本文章為軟件測試基礎(chǔ)-概念篇課程的筆記記錄。

1-1 軟件測試概要

什么是軟件測試？

早期定義：
軟件測試是對程序能夠按預(yù)期運行建立起一種信心。 —— Bill Hetzel,1973

經(jīng)典定義：
測試是為發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。 —— Myers,1979

IEEE定義：
使用人工或自動的手段來運行或測量軟件系統(tǒng)的過程，以檢驗軟件系統(tǒng)是否滿足規(guī)定的需求，并找出與預(yù)期結(jié)果之間的差異

軟件測試的測試對象

測試對象是貫穿整個測試過程的：

• 軟件需求
• 軟件概要設(shè)計
• 軟件詳細(xì)設(shè)計
• 軟件運行環(huán)境
• 可運行程序

五大要素和兩個目標(biāo)

• 要素
  質(zhì)量、人員、資源、流程、技術(shù)
• 目標(biāo)
  測試覆蓋率、測試效率

軟件測試所遵循的原則

• 測試顯示缺陷的存在，但不能證明系統(tǒng)不存在缺陷；
• 窮盡測試是不可能的，應(yīng)設(shè)定及時終止的條件；
• 測試應(yīng)該盡早進(jìn)行；
• 缺陷具備群集特性；
• 測試的殺蟲劑悖論；
• 測試的二八原則(80%的時間花在20%的重點功能上)；
• 測試活動依賴于測試背景

1-2 軟件測試階段

按測試階段來分類：單元測試、集成測試、系統(tǒng)測試、驗收測試

單元測試

什么是單元測試

對軟件中的最小可測試單元進(jìn)行檢查和驗證。

單元測試的原則

• 盡可能保證各個測試用例是互相獨立的；
• 一般由代碼的開發(fā)人員來實施，用以檢驗所開發(fā)的代碼功能符合自己的設(shè)計要求

單元測試的益處

• 能盡早發(fā)現(xiàn)缺陷
• 有利于重構(gòu)
• 簡化集成
• 文檔
• 用于設(shè)計

單元測試的限制

• 不可能覆蓋所有的執(zhí)行路徑，所以不可能保證捕捉到所有路徑的錯誤
• 每一行代碼，一般需要3~5行測試代碼才能完成單元測試，所以存在投入和產(chǎn)出的一個平衡

單元測試框架

Xunit，如：Junit、nunit、PHPUnit、CppUnit

集成測試

定義

是在單元測試的基礎(chǔ)上，測試在將所有的軟件單元按照概要設(shè)計規(guī)格說明的要求組裝成模塊、子系統(tǒng)或系統(tǒng)的過程中各部分工作是否達(dá)到或?qū)崿F(xiàn)相應(yīng)技術(shù)指標(biāo)及要求的活動。

集成測試的主要實施方案

• Big Bang（全部組裝好，再進(jìn)行集成測試）
• 自頂向下（從主程序開始，控制層逐層測試）
• 自底向上（從程序模塊的最底層開始向上組裝；最常用）
• 核心系統(tǒng)集成
• 高頻集成（持續(xù)集成）

集成測試 VS 單元測試

• 測試的對象不同
• 測試的依據(jù)不同：詳細(xì)設(shè)計 VS 概要設(shè)計
• 測試的方法不同：接口測試 VS 程序內(nèi)部

系統(tǒng)測試

定義

是將經(jīng)過集成測試的軟件，作為計算機(jī)系統(tǒng)的一個部分，與系統(tǒng)中其它部分結(jié)合起來，在實際運行環(huán)境下對計算機(jī)系統(tǒng)進(jìn)行的一系列嚴(yán)格有效地測試，以發(fā)現(xiàn)軟件潛在的問題，保證系統(tǒng)的正常運行。

關(guān)注點

• 關(guān)注系統(tǒng)本身的使用
• 關(guān)注系統(tǒng)與其他相關(guān)系統(tǒng)間的聯(lián)通
• 關(guān)注系統(tǒng)在不同使用壓力下的表現(xiàn)
• 關(guān)注系統(tǒng)在真實使用環(huán)境下的使用

系統(tǒng)測試 VS 集成測試

• 測試對象不同
  • 集成測試：由通過了單元測試各個模塊所集成起來的構(gòu)件
  • 系統(tǒng)測試：除了軟件之外，還包括計算機(jī)硬件及相關(guān)的外圍設(shè)備、數(shù)據(jù)采集和傳輸機(jī)構(gòu)、支持軟件、系統(tǒng)操作人員等整個系統(tǒng)
• 測試時間不同
  • 集成測試：介于單元測試和系統(tǒng)測試之間
  • 系統(tǒng)測試：在集成測試之后
• 測試內(nèi)容不同
  • 集成測試：各個單元模塊之間的接口
  • 系統(tǒng)測試：整個系統(tǒng)的功能和性能
• 測試角度不同
  • 集成測試：偏于技術(shù)角度的驗證
  • 系統(tǒng)測試：偏于業(yè)務(wù)角度的驗證

驗收測試

定義

也稱交付測試。針對用戶需求、業(yè)務(wù)流程的正式測試，確定系統(tǒng)是否滿足驗收標(biāo)準(zhǔn)，由用戶、客戶或其他授權(quán)機(jī)構(gòu)決定是否接受系統(tǒng)。

細(xì)分

• 用戶驗收測試
• 運行驗收測試
• 合同和規(guī)范驗收測試
• Alpha測試（開發(fā)者提供的場景，用戶運行）
• Beta測試（用戶提供的場景下測試）

2-2 軟件測試手段

按測試時對象的可見度：黑盒測試、白盒測試
按狀態(tài)：靜態(tài)測試、動態(tài)測試
按測試執(zhí)行的方式：手工測試、自動化測試

黑盒測試

過程

輸入 ——> 用戶需求/事件驅(qū)動 ——> 輸出

優(yōu)點

• 容易實施，不需要關(guān)注內(nèi)部的實現(xiàn)
• 更貼近用戶的實用角度

缺點

• 測試覆蓋率較低，一般只能覆蓋到代碼量的不到40%
• 針對黑盒的自動化測試，復(fù)用率較低，維護(hù)成本較高

黑盒測試主要測試什么？

• 是否有不正確或遺漏的功能？
• 在接口上，輸入是否能正確的接受？能否輸出正確的結(jié)果？
• 是否在數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息（例如數(shù)據(jù)文件）訪問錯誤？
• 性能上是否能夠滿足要求？

黑盒測試的主要設(shè)計方法

• 等價類劃分法
• 邊界值分析法
• 錯誤推斷法
• 因果圖法
• 正交試驗分析法
• 狀態(tài)遷移圖法
• 流程分析法

白盒測試

過程

輸入 ——> 邏輯覆蓋 ——> 輸出

主要的邏輯單位

語句、條件、條件組合、分支、路徑

優(yōu)點

• 迫使測試人員去仔細(xì)思考軟件的實現(xiàn)，理解原理
• 可以檢測代碼中的每條分支和路徑
• 揭示隱藏在代碼中的錯誤
• 對代碼的測試比較徹底

缺點

• 成本高，昂貴
• 無法檢測代碼中遺漏的路徑和數(shù)據(jù)敏感性錯誤
• 不能直接驗證需求的正確性

白盒測試的主要設(shè)計方法

• 代碼檢測法：多面檢查，代碼審查和走查
• 靜態(tài)結(jié)構(gòu)分析法：通過測試工具分析代碼結(jié)構(gòu)邏輯
• 靜態(tài)質(zhì)量度量法：質(zhì)量標(biāo)準(zhǔn)
• 邏輯覆蓋法：語句、條件、條件組合、分支、路徑覆蓋
• 基本路徑測試法：非常主要的方法

灰盒測試

介于黑、白盒測試之間的，關(guān)注輸出對于輸入的正確性，同時也關(guān)注內(nèi)部表現(xiàn)。

靜態(tài)測試

定義

靜態(tài)測試是指無需執(zhí)行被測程序，而是通過評審軟件文檔或代碼，度量程序靜態(tài)復(fù)雜度，檢查軟件是否符合變成標(biāo)準(zhǔn)，借以發(fā)現(xiàn)編寫的程序的不足之處，減少錯誤出現(xiàn)的概率。

方式

互審 —— 走查 —— 會議（不正式 —— 正式）

動態(tài)測試

動態(tài)測試是指通過運行被測程序，檢查運行結(jié)果與預(yù)期結(jié)果的差異，并分析運行效率、正確性和健壯性等。

手工測試

由專門的測試人員從用戶視角來驗證軟件是否滿足設(shè)計要求的行為，更適用針對深度的測試和強(qiáng)調(diào)主觀判斷的測試。
例如：眾包測試、探索式測試

自動化測試

定義

使用單獨的測試工具軟件控制測試的自動化執(zhí)行以及對預(yù)期和結(jié)果進(jìn)行**自動檢查。
例如：單元測試、接口測試、性能測試等

手工測試 VS 自動化測試

• 手工測試
  • 優(yōu)點：1）易發(fā)現(xiàn)缺陷；2）容易實施；3）創(chuàng)造性、靈活性
  • 缺點：1）覆蓋量化難；2）重復(fù)測試效率低；3）不一致性、可靠性低；4）人力資源依賴
• 自動化測試
  • 優(yōu)點：1）高效率、速度快；2）高復(fù)用性；3）覆蓋率容易度量；4）準(zhǔn)確、可靠；5）不知疲勞
  • 缺點：1）機(jī)械、發(fā)現(xiàn)缺陷率低；2）一次性投入較大

2-3 軟件測試模式

按測試模式來分類：敏捷測試、基于腳本的測試、基于風(fēng)險的測試、探索式測試等。

傳統(tǒng)的瀑布模型

流程

項目計劃—>需求分析—>軟件設(shè)計—>程序開發(fā)—>軟件測試—>集成維護(hù)

瀑布模型的優(yōu)缺點

• 優(yōu)點
  • 強(qiáng)調(diào)需求、設(shè)計的作用；
  • 前一階段完成后，只需關(guān)注后續(xù)階段；
  • 為項目提供了按階段劃分的檢查點，里程碑清晰；
  • 文檔規(guī)范
• 缺點
  • 難以適應(yīng)需求的頻繁變化；
  • 項目周期后段才能看到成果；
  • 強(qiáng)制的里程碑、完成時間點；
  • 文檔工作量大

V模型

流程

需求分析—>概要設(shè)計—>詳細(xì)設(shè)計—>軟件編碼—>單元測試—>集成測試—>系統(tǒng)測試—>驗收測試

局限性

• 僅僅將測試放在后半段，忽視了測試對需求的分析和驗證
• 違背了測試需要盡早進(jìn)行的原則

W模型

W模型

X模型

X模型

H模型

H模型

2-4 軟件測試模式—敏捷測試

敏捷測試

定義

Agile Testing，遵循敏捷宣言的一種測試實踐。

敏捷宣言

我們通過身體力行和幫助他人來揭示更好的軟件開發(fā)方式，借由這種工作，我們形成了如下的價值觀：
個人與交互 重于 過程和工具
可用的軟件 重于 完備的文檔
客戶協(xié)作 重于 合同談判
響應(yīng)變化 重于 遵循計劃
在每對比較中，后者并非全無價值，但我們更看重前者。

特點

• 強(qiáng)調(diào)從客戶角度進(jìn)行測試
• 重點關(guān)注迭代測試新功能，不再強(qiáng)調(diào)測試階段
• 盡早測試，不間斷測試，具備條件即測試
• 強(qiáng)調(diào)持續(xù)反饋
• 預(yù)防缺陷重于發(fā)現(xiàn)缺陷

敏捷測試 VS 傳統(tǒng)測試

• 傳統(tǒng)測試
  • 測試是質(zhì)量的最后保護(hù)者
  • 嚴(yán)格的變更管理
  • 預(yù)先的計劃和細(xì)節(jié)的準(zhǔn)備
  • 重量級文檔
  • 各階段測試嚴(yán)格的入口和出口標(biāo)準(zhǔn)
  • 更多在回歸測試時進(jìn)行重量級的自動化測試
  • 嚴(yán)格依賴流程執(zhí)行
  • 測試團(tuán)隊和開發(fā)團(tuán)隊是相互獨立的
• 敏捷測試
  • 開發(fā)和測試人員是緊密合作，大家都有責(zé)任對軟件負(fù)責(zé)
  • 變更是可接受的，擁抱變更
  • 計劃隨著進(jìn)展時常調(diào)整
  • 只需要絕對必要的文檔
  • 各迭代之間已經(jīng)沒有明顯的入口和出口標(biāo)準(zhǔn)
  • 所有階段都需要自動測試，每個人都需要做，是項目集成的一部分
  • 流程不再需要嚴(yán)格執(zhí)行
  • 團(tuán)隊合作是無縫隙合作

基于腳本的測試—SBT

• Scirpt-based Testing
• Scripted Testing（ST） 腳本測試
• Exploratory Testing （ET） 探索式測試

探索式測試

完全拋開測試腳本的測試，是一種測試風(fēng)格、思維而不是測試技術(shù)。

ST vs ET

• ST
  • 系統(tǒng)性強(qiáng)
  • 容易管理、控制
  • 設(shè)計在先，執(zhí)行在后
  • 主要是驗證自己的思路
  • 可預(yù)見性
• ET
  • 自由靈活
  • 和ST是互補(bǔ)的
  • 執(zhí)行和設(shè)計（思考）并行
  • 不斷和系統(tǒng)交互，帶著問題測試
  • 學(xué)習(xí)的過程

探索式測試的優(yōu)點

• 更能激發(fā)測試人員的創(chuàng)造性和工作樂趣
• 增加了發(fā)現(xiàn)新的或較深入Bug的可能性
• 在較短時間內(nèi)找到更多Bug以及對SUT做一個快速的評估
• 有利于更加有效地實施自動化
• 更加適用于敏捷項目
• 減少了在簡單、繁復(fù)上用例的無謂編寫時間

探索式測試的缺點

• 測試管理上有局限性，較難協(xié)調(diào)和控制
• 對于Bug的重復(fù)利用和重現(xiàn)上作用有限
• 對測試人員的測試技能和業(yè)務(wù)知識深度依賴較大
• 只有在SUT已完全可用的前提下才更有作用
• ET的生產(chǎn)率很難定義
• ET本身較難進(jìn)行自動化

局部探索式測試

五大要素：

• 輸入（接受輸入，產(chǎn)生輸出，存儲數(shù)據(jù)，進(jìn)行運算）（測試要點：輸入順序，輸入內(nèi)容，輸出異常）
• 狀態(tài)（臨時狀態(tài)，永久狀態(tài)）（測試要點：運行時有效，階段有效，數(shù)據(jù)庫保存，文件保存）
• 代碼路徑（對代碼的覆蓋）
• 用戶數(shù)據(jù)（盡量使用真實的數(shù)據(jù)）
• 執(zhí)行環(huán)境

全局探索式測試

漫游測試法

• 商業(yè)區(qū)：軟件從啟動到關(guān)閉之間客戶可能使用到的主功能
• 旅館區(qū)：軟件休息或未運行時的功能，一般在后臺
• 歷史區(qū)：歷史遺留代碼或問題
• 旅游區(qū)：新用戶使用或比較關(guān)注的功能
• 娛樂區(qū)：系統(tǒng)主要功能之外的一些輔助功能
• 破舊區(qū)：已廢棄或隱藏的功能

基于風(fēng)險的測試—RBT

定義

Risk-based Testing，一種基于對軟件失效的風(fēng)險評估并以此指導(dǎo)測試計劃、設(shè)計、執(zhí)行、結(jié)果評價的軟件測試類型。

哪些是風(fēng)險？

• 質(zhì)量風(fēng)險
• 管理風(fēng)險
  風(fēng)險級別 = 風(fēng)險可能性 * 風(fēng)險嚴(yán)重度

識別風(fēng)險

• 可能性：復(fù)雜度、時間壓力、高變更率、技能水平、地理分散度
• 嚴(yán)重程度：使用頻率、失效可視性、商業(yè)損失、組織負(fù)面影響和損害、社會損失和法律責(zé)任
  風(fēng)險要素分 = Sum(單項權(quán)重 * 得分)

基于模型的測試—MBT

定義

Model-based testing is software testing in which test cases are derived in whole or in part from a model that describes some (usually functional) aspects of the system under test (SUT).

主要的MBT工具

• Spec Explorer (Microsoft)
• GraphWalker (OpenSource)
• Tcases (OpenSource)
• Modeljunit (OpenSource)

3-1 軟件測試類型

按測試類型來分類：
功能測試，性能測試，部署測試，文檔測試，安全測試，兼容性測試，易用性測試，本地化測試，無障礙測試，可靠性測試

功能測試

定義

根據(jù)產(chǎn)品特性、操作描述和用戶方法，測試一個產(chǎn)品的特性和可操作行為以確定他們滿足設(shè)計需求。

針對的問題

功能錯誤或遺漏、界面問題、性能錯誤（軟件本身的性能）、數(shù)據(jù)及訪問錯誤、初始化及終止錯誤

功能測試工具

• 商用：QTP、Winrunner、silk Test、Rational robot
• 開源：selenium(Web)、Watir(Web)、Sikuli(基于屏幕截圖)

性能測試

細(xì)分

• 負(fù)載測試：在測試過程中，逐步增加負(fù)載，并記錄下被測系統(tǒng)的性能表現(xiàn)，最終確認(rèn)出系統(tǒng)在正常指標(biāo)下的最大負(fù)載
• 壓力測試：測試系統(tǒng)在極限負(fù)載下的壓力情況，確定系統(tǒng)在什么壓力下會導(dǎo)致系統(tǒng)失敗，不能正常運行，測試系統(tǒng)所能承受的極限。
• 穩(wěn)定性測試：一般是稍大于業(yè)務(wù)量的負(fù)載，進(jìn)行長時間的測試。

性能指標(biāo)

并發(fā)用戶數(shù)VU、每秒事務(wù)數(shù)TPS、系統(tǒng)響應(yīng)時間、設(shè)備性能

性能測試工具

Loadrunner、Silkperformer、JMeter、WebLoad、Apache Bench、LoadUI

靜態(tài)性能評估

• 定義：開發(fā)Web應(yīng)用時，基于一系列Web應(yīng)用頁面性能優(yōu)化的最佳實踐對Web應(yīng)用的頁面進(jìn)行靜態(tài)分析，并給出評估結(jié)果的性能分析方法。
• 工具：YSlow、PageSpeed

應(yīng)用性能管理(APM)

Application performance Management，提供對系統(tǒng)的實時監(jiān)控以實現(xiàn)性能管理、故障管理的解決方案。

安全測試

定義

對軟件產(chǎn)品進(jìn)行測試以確保其符合產(chǎn)品安全需求和質(zhì)量標(biāo)準(zhǔn)。

滲透測試

通過模擬對軟件系統(tǒng)的惡意攻擊行為來評估系統(tǒng)安全性的一種測試。

滲透測試 VS 安全測試

• 滲透測試：攻、點
• 安全測試：防、面

OWASP (Open Web Application Security Project)

• OWASP Top10
• Test Guide

兼容性測試

多維度

• 軟件本身的兼容性（版本之間）
• 不同平臺下的兼容性（如底層系統(tǒng)）
• 軟件對運行設(shè)備的兼容性（如硬件設(shè)備）
• 軟件互操作性（同一個廠商或者其他主流應(yīng)用）

瀏覽器內(nèi)核

• Trident4-6：IE6-8、9、10
• Gecko：Firefox
• WebKit：Safari、Chrome
• Presto：Opera

瀏覽器兼容性測試工具

• BrowserShots（截圖對比）
• Brower Sandbox
• Chrome插件：w3help

文檔測試

定義

針對軟件產(chǎn)品的交付品，配套的文檔類部件的測試，如用戶手冊、使用說明、用戶幫助文檔等。

文檔測試關(guān)注要點

完整性、正確性、一致性、易理解性、易瀏覽性

可靠性測試

軟件可靠性、硬件可靠性（主要）

易用性測試

易用性測試是指測試用戶使用軟件時是否感覺方便，是否能保證用戶使用體驗的測試類型。

本地化測試

定義

針對軟件的本地化版本實施的針對性測試

主要測試內(nèi)容

• 語言、書寫習(xí)慣
• 時區(qū)、日期格式、貨幣
• 當(dāng)?shù)亓?xí)俗、法律法規(guī)
• 政治敏感內(nèi)容

部署測試

定義

也稱安裝測試，主要驗證系統(tǒng)部署過程，并確保軟件經(jīng)過安裝測試后可以正常使用。

主要測試內(nèi)容

• 在不同環(huán)境下的部署驗證
• 參照部署文檔執(zhí)行，過程的合理、正確性
• 基礎(chǔ)數(shù)據(jù)

無障礙測試

Accessibility Test，也稱可訪問性測試。是指軟件需要提供便于特殊人群使用的功能，包括視障、聽障、老年人、身體殘疾用戶等，無障礙測試則是針對這部分功能的測試。

4-1 其他測試分類

其他的一些測試類型概念
回歸測試、冒煙測試、Monkey測試、AB測試

回歸測試

定義

軟件功能修改后，對軟件進(jìn)行重新測試以確認(rèn)修改沒有引入新的錯誤或?qū)е缕渌糠之a(chǎn)生錯誤。

回歸測試的中心在關(guān)鍵模塊和重點功能組件。

軟件研發(fā)周期中會進(jìn)行多次回歸測試，且盡量實現(xiàn)自動化。

冒煙測試

定義

來自于硬件板卡驗證術(shù)語。軟件上則用于確認(rèn)代碼中的更改會按預(yù)期運行，且不會破壞整個版本的穩(wěn)定性。

“每日構(gòu)建”中用冒煙測試來確認(rèn)合入的代碼沒有影響主要功能的正常。

Monkey測試

定義

也稱搞怪測試。就是用一些隨機(jī)、稀奇古怪的方式來操作軟件，以測試系統(tǒng)的健壯性和穩(wěn)定性。

A/B測試

定義

多用于互聯(lián)網(wǎng)行業(yè)，通過為頁面提供2個版本給用戶使用并記錄相關(guān)的用戶行為數(shù)據(jù)，來確定更優(yōu)化設(shè)計的一種測試方案。

A/B測試實施要點

• 多個方案并行
• 每次測試僅改動一個變量
• 按照某種規(guī)則進(jìn)行優(yōu)勝劣汰

A/B測試工具

• Google Analytics Content Experiments
• Visual Website Optimizer