前言

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

1-1 軟件測(cè)試概要

什么是軟件測(cè)試竭恬？

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

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

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

軟件測(cè)試的測(cè)試對(duì)象

測(cè)試對(duì)象是貫穿整個(gè)測(cè)試過(guò)程的：

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

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

• 要素
  質(zhì)量、人員盟萨、資源凉翻、流程、技術(shù)
• 目標(biāo)
  測(cè)試覆蓋率捻激、測(cè)試效率

軟件測(cè)試所遵循的原則

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

1-2 軟件測(cè)試階段

按測(cè)試階段來(lái)分類：單元測(cè)試旺垒、集成測(cè)試彩库、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試

單元測(cè)試

什么是單元測(cè)試

對(duì)軟件中的最小可測(cè)試單元進(jìn)行檢查和驗(yàn)證先蒋。

單元測(cè)試的原則

• 盡可能保證各個(gè)測(cè)試用例是互相獨(dú)立的骇钦；
• 一般由代碼的開(kāi)發(fā)人員來(lái)實(shí)施，用以檢驗(yàn)所開(kāi)發(fā)的代碼功能符合自己的設(shè)計(jì)要求

單元測(cè)試的益處

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

單元測(cè)試的限制

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

單元測(cè)試框架

Xunit业岁，如：Junit坦仍、nunit、PHPUnit叨襟、CppUnit

集成測(cè)試

定義

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

集成測(cè)試的主要實(shí)施方案

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

集成測(cè)試 VS 單元測(cè)試

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

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

定義

是將經(jīng)過(guò)集成測(cè)試的軟件提澎，作為計(jì)算機(jī)系統(tǒng)的一個(gè)部分，與系統(tǒng)中其它部分結(jié)合起來(lái)念链，在實(shí)際運(yùn)行環(huán)境下對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行的一系列嚴(yán)格有效地測(cè)試盼忌，以發(fā)現(xiàn)軟件潛在的問(wèn)題积糯，保證系統(tǒng)的正常運(yùn)行。

關(guān)注點(diǎ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)在真實(shí)使用環(huán)境下的使用

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

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

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

定義

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

細(xì)分

• 用戶驗(yàn)收測(cè)試
• 運(yùn)行驗(yàn)收測(cè)試
• 合同和規(guī)范驗(yàn)收測(cè)試
• Alpha測(cè)試（開(kāi)發(fā)者提供的場(chǎng)景琴拧，用戶運(yùn)行）
• Beta測(cè)試（用戶提供的場(chǎng)景下測(cè)試）

2-2 軟件測(cè)試手段

按測(cè)試時(shí)對(duì)象的可見(jiàn)度：黑盒測(cè)試、白盒測(cè)試
按狀態(tài)：靜態(tài)測(cè)試嘱支、動(dòng)態(tài)測(cè)試
按測(cè)試執(zhí)行的方式：手工測(cè)試艾蓝、自動(dòng)化測(cè)試

黑盒測(cè)試

過(guò)程

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

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

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

缺點(diǎn)

• 測(cè)試覆蓋率較低斗塘，一般只能覆蓋到代碼量的不到40%
• 針對(duì)黑盒的自動(dòng)化測(cè)試，復(fù)用率較低亮靴，維護(hù)成本較高

黑盒測(cè)試主要測(cè)試什么馍盟？

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

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

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

白盒測(cè)試

過(guò)程

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

主要的邏輯單位

語(yǔ)句、條件讶踪、條件組合芯侥、分支、路徑

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

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

缺點(diǎn)

• 成本高柱查，昂貴
• 無(wú)法檢測(cè)代碼中遺漏的路徑和數(shù)據(jù)敏感性錯(cuò)誤
• 不能直接驗(yàn)證需求的正確性

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

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

灰盒測(cè)試

介于黑淋硝、白盒測(cè)試之間的雹熬，關(guān)注輸出對(duì)于輸入的正確性，同時(shí)也關(guān)注內(nèi)部表現(xiàn)谣膳。

靜態(tài)測(cè)試

定義

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

方式

互審 —— 走查 —— 會(huì)議（不正式 —— 正式）

動(dòng)態(tài)測(cè)試

動(dòng)態(tài)測(cè)試是指通過(guò)運(yùn)行被測(cè)程序僧界，檢查運(yùn)行結(jié)果與預(yù)期結(jié)果的差異，并分析運(yùn)行效率臭挽、正確性和健壯性等捂襟。

手工測(cè)試

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

自動(dòng)化測(cè)試

定義

使用單獨(dú)的測(cè)試工具軟件控制測(cè)試的自動(dòng)化執(zhí)行以及對(duì)預(yù)期和結(jié)果進(jìn)行**自動(dòng)檢查。
例如：?jiǎn)卧獪y(cè)試纽帖、接口測(cè)試宠漩、性能測(cè)試等

手工測(cè)試 VS 自動(dòng)化測(cè)試

• 手工測(cè)試
  • 優(yōu)點(diǎn)：1）易發(fā)現(xiàn)缺陷；2）容易實(shí)施懊直；3）創(chuàng)造性扒吁、靈活性
  • 缺點(diǎn)：1）覆蓋量化難；2）重復(fù)測(cè)試效率低室囊；3）不一致性雕崩、可靠性低；4）人力資源依賴
• 自動(dòng)化測(cè)試
  • 優(yōu)點(diǎn)：1）高效率融撞、速度快盼铁；2）高復(fù)用性；3）覆蓋率容易度量尝偎；4）準(zhǔn)確饶火、可靠；5）不知疲勞
  • 缺點(diǎn)：1）機(jī)械致扯、發(fā)現(xiàn)缺陷率低趁窃；2）一次性投入較大

2-3 軟件測(cè)試模式

按測(cè)試模式來(lái)分類：敏捷測(cè)試、基于腳本的測(cè)試急前、基于風(fēng)險(xiǎn)的測(cè)試醒陆、探索式測(cè)試等。

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

流程

項(xiàng)目計(jì)劃—>需求分析—>軟件設(shè)計(jì)—>程序開(kāi)發(fā)—>軟件測(cè)試—>集成維護(hù)

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

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

V模型

流程

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

局限性

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

W模型

W模型

X模型

X模型

H模型

H模型

2-4 軟件測(cè)試模式—敏捷測(cè)試

敏捷測(cè)試

定義

Agile Testing攒岛，遵循敏捷宣言的一種測(cè)試實(shí)踐。

敏捷宣言

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

特點(diǎn)

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

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

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

基于腳本的測(cè)試—SBT

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

探索式測(cè)試

完全拋開(kāi)測(cè)試腳本的測(cè)試嘲碱，是一種測(cè)試風(fēng)格、思維而不是測(cè)試技術(shù)局蚀。

ST vs ET

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

探索式測(cè)試的優(yōu)點(diǎn)

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

探索式測(cè)試的缺點(diǎn)

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

局部探索式測(cè)試

五大要素：

• 輸入（接受輸入千扶，產(chǎn)生輸出料祠，存儲(chǔ)數(shù)據(jù)，進(jìn)行運(yùn)算）（測(cè)試要點(diǎn)：輸入順序澎羞，輸入內(nèi)容髓绽，輸出異常）
• 狀態(tài)（臨時(shí)狀態(tài)，永久狀態(tài)）（測(cè)試要點(diǎn)：運(yùn)行時(shí)有效妆绞，階段有效顺呕，數(shù)據(jù)庫(kù)保存枫攀，文件保存）
• 代碼路徑（對(duì)代碼的覆蓋）
• 用戶數(shù)據(jù)（盡量使用真實(shí)的數(shù)據(jù)）
• 執(zhí)行環(huán)境

全局探索式測(cè)試

漫游測(cè)試法

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

基于風(fēng)險(xiǎn)的測(cè)試—RBT

定義

Risk-based Testing株茶，一種基于對(duì)軟件失效的風(fēng)險(xiǎn)評(píng)估并以此指導(dǎo)測(cè)試計(jì)劃来涨、設(shè)計(jì)、執(zhí)行启盛、結(jié)果評(píng)價(jià)的軟件測(cè)試類型蹦掐。

哪些是風(fēng)險(xiǎn)？

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

識(shí)別風(fēng)險(xiǎn)

• 可能性：復(fù)雜度僵闯、時(shí)間壓力卧抗、高變更率、技能水平棍厂、地理分散度
• 嚴(yán)重程度：使用頻率颗味、失效可視性、商業(yè)損失牺弹、組織負(fù)面影響和損害浦马、社會(huì)損失和法律責(zé)任
  風(fēng)險(xiǎn)要素分 = Sum(單項(xiàng)權(quán)重 * 得分)

基于模型的測(cè)試—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 軟件測(cè)試類型

按測(cè)試類型來(lái)分類：
功能測(cè)試，性能測(cè)試张漂，部署測(cè)試晶默，文檔測(cè)試，安全測(cè)試航攒，兼容性測(cè)試磺陡，易用性測(cè)試，本地化測(cè)試漠畜，無(wú)障礙測(cè)試币他，可靠性測(cè)試

功能測(cè)試

定義

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

針對(duì)的問(wèn)題

功能錯(cuò)誤或遺漏、界面問(wèn)題瘾敢、性能錯(cuò)誤（軟件本身的性能）拍冠、數(shù)據(jù)及訪問(wèn)錯(cuò)誤、初始化及終止錯(cuò)誤

功能測(cè)試工具

• 商用：QTP簇抵、Winrunner庆杜、silk Test、Rational robot
• 開(kāi)源：selenium(Web)碟摆、Watir(Web)晃财、Sikuli(基于屏幕截圖)

性能測(cè)試

細(xì)分

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

性能指標(biāo)

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

性能測(cè)試工具

Loadrunner丧叽、Silkperformer、JMeter公你、WebLoad踊淳、Apache Bench、LoadUI

靜態(tài)性能評(píng)估

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

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

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

安全測(cè)試

定義

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

滲透測(cè)試

通過(guò)模擬對(duì)軟件系統(tǒng)的惡意攻擊行為來(lái)評(píng)估系統(tǒng)安全性的一種測(cè)試。

滲透測(cè)試 VS 安全測(cè)試

• 滲透測(cè)試：攻益兄、點(diǎn)
• 安全測(cè)試：防锻梳、面

OWASP (Open Web Application Security Project)

• OWASP Top10
• Test Guide

兼容性測(cè)試

多維度

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

瀏覽器內(nèi)核

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

瀏覽器兼容性測(cè)試工具

• BrowserShots（截圖對(duì)比）
• Brower Sandbox
• Chrome插件：w3help

文檔測(cè)試

定義

針對(duì)軟件產(chǎn)品的交付品，配套的文檔類部件的測(cè)試灸叼，如用戶手冊(cè)神汹、使用說(shuō)明庆捺、用戶幫助文檔等古今。

文檔測(cè)試關(guān)注要點(diǎn)

完整性、正確性滔以、一致性捉腥、易理解性、易瀏覽性

可靠性測(cè)試

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

易用性測(cè)試

易用性測(cè)試是指測(cè)試用戶使用軟件時(shí)是否感覺(jué)方便抵碟，是否能保證用戶使用體驗(yàn)的測(cè)試類型桃漾。

本地化測(cè)試

定義

針對(duì)軟件的本地化版本實(shí)施的針對(duì)性測(cè)試

主要測(cè)試內(nèi)容

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

部署測(cè)試

定義

也稱安裝測(cè)試敦迄，主要驗(yàn)證系統(tǒng)部署過(guò)程恋追，并確保軟件經(jīng)過(guò)安裝測(cè)試后可以正常使用。

主要測(cè)試內(nèi)容

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

無(wú)障礙測(cè)試

Accessibility Test，也稱可訪問(wèn)性測(cè)試脾猛。是指軟件需要提供便于特殊人群使用的功能撕彤，包括視障、聽(tīng)障猛拴、老年人羹铅、身體殘疾用戶等，無(wú)障礙測(cè)試則是針對(duì)這部分功能的測(cè)試漆弄。

4-1 其他測(cè)試分類

其他的一些測(cè)試類型概念
回歸測(cè)試睦裳、冒煙測(cè)試、Monkey測(cè)試撼唾、AB測(cè)試

回歸測(cè)試

定義

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

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

軟件研發(fā)周期中會(huì)進(jìn)行多次回歸測(cè)試蛛蒙，且盡量實(shí)現(xiàn)自動(dòng)化。

冒煙測(cè)試

定義

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

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

Monkey測(cè)試

定義

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

A/B測(cè)試

定義

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

A/B測(cè)試實(shí)施要點(diǎn)

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

A/B測(cè)試工具

• Google Analytics Content Experiments
• Visual Website Optimizer