（1）軟件基本概念

軟件（software）是指一系列按照某種特定規(guī)則組織在一起，實(shí)現(xiàn)用戶需求的計(jì)算機(jī)數(shù)據(jù)和指令的集合體。從狹義理解即運(yùn)行在計(jì)算機(jī)、手機(jī)、手持設(shè)備等電子設(shè)備上的應(yīng)用程序，都稱為軟件。從廣義理解，軟件不僅僅包含實(shí)現(xiàn)用戶需求的源代碼（計(jì)算機(jī)數(shù)據(jù)、指令），還包含與之相匹配的數(shù)據(jù)文檔、支撐源代碼運(yùn)行的配置數(shù)據(jù)。三者構(gòu)成一個(gè)完整的軟件實(shí)體。

（2）軟件生命周期

計(jì)劃-需求分析-計(jì)劃-編碼-測(cè)試-運(yùn)維

計(jì)劃工作內(nèi)容：

?確定軟件開發(fā)總目標(biāo)；

?給出軟件的功能、性能、可靠性以及接口等方面的設(shè)想；

?研究完成該項(xiàng)目的可行性，探討問題解決方案；

?對(duì)可供開發(fā)使用的資源、成本、可取得的效益和開發(fā)進(jìn)度作出估計(jì)；

?制定完成開發(fā)任務(wù)的實(shí)施計(jì)劃。

需求分析：

有需求分析人員和客戶共同商討制定軟件需求說(shuō)明書srs（SoftwareRequirement? Specification2%22%7D;）

設(shè)計(jì)：

?設(shè)計(jì)是軟件工程的技術(shù)核心，這個(gè)階段需要完成設(shè)計(jì)說(shuō)明書

?概要設(shè)計(jì)（HLD），在設(shè)計(jì)階段把各項(xiàng)需求轉(zhuǎn)換成相應(yīng)的體系結(jié)構(gòu)，每一部分是功能明確的模塊；

? 詳細(xì)設(shè)計(jì)（LLD），對(duì)每個(gè)模塊要完成的工作進(jìn)行具體的描述

編碼:

?把軟件設(shè)計(jì)轉(zhuǎn)換成計(jì)算機(jī)可以接受的程序，即寫成以某個(gè)程序設(shè)計(jì)語(yǔ)言表示的源程序清單，使用RDBMS工具建立數(shù)據(jù)庫(kù)。

測(cè)試：

?測(cè)試是檢驗(yàn)軟件是否符合客戶需求，達(dá)到質(zhì)量要求，一般由獨(dú)立的小組執(zhí)行，測(cè)試工作分為：

?單元測(cè)試

?集成測(cè)試

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

運(yùn)維：

這個(gè)階段將軟件交付用戶投入正式使用，以后便進(jìn)入維護(hù)階段，可能有多種原因需要對(duì)它進(jìn)行修改，如軟件錯(cuò)誤、系統(tǒng)軟件升級(jí)、增強(qiáng)軟件功能、提高性能等。

（3）軟件開發(fā)模式

軟件研發(fā)模型（software development model）是軟件生產(chǎn)過程中分析、設(shè)計(jì)、研發(fā)活動(dòng)所遵循的框架模式。

瀑布模型

嚴(yán)格遵循預(yù)先計(jì)劃的需求分析、設(shè)計(jì)、編碼、集成、測(cè)試、維護(hù)的步驟順序進(jìn)行。

主要的問題

?嚴(yán)格分級(jí)導(dǎo)致的自由度降低

?開發(fā)成果輸出過晚，風(fēng)險(xiǎn)高

?后期需求的變化難以調(diào)整，代價(jià)高昂

瀑布式方法在需求不明并且在項(xiàng)目進(jìn)行過程中可能變化的情況下基本是不可行的

原型模型

用戶很難將需求表達(dá)得既具體又明確，用戶與需求開發(fā)人員的知識(shí)背景不同。當(dāng)需求表述錯(cuò)誤時(shí)，在瀑布模型下往往到后期才能發(fā)現(xiàn)。原型模型在很大程度上解決了這個(gè)問題。原型模型是在瀑布模型基礎(chǔ)上演進(jìn)的一種較為先進(jìn)的研發(fā)模型。利用該模型，產(chǎn)品設(shè)計(jì)者實(shí)現(xiàn)用戶與軟件系統(tǒng)的交互，當(dāng)原型研發(fā)生產(chǎn)完成后，由用戶根據(jù)自身的實(shí)際需求對(duì)原型進(jìn)行評(píng)價(jià)，從而進(jìn)一步細(xì)化待開發(fā)軟件的需求

迭代模型

?迭代模型(iterative ? model)是由IBM公司提出的一種軟件開發(fā)方法，該方法包括一系列的增量的步驟或迭代，每個(gè)迭代都包括很多的開發(fā)活動(dòng)(需求、分析、設(shè)計(jì)、實(shí)現(xiàn)等)

?實(shí)現(xiàn)軟件的每項(xiàng)功能反復(fù)求精的過程，是從模糊到清晰的開發(fā)過程。每次迭代是從功能的深度和細(xì)化程度來(lái)劃分的。

?迭代模型最適合使用與前期需求不穩(wěn)定，需求多變的項(xiàng)目

增量模型

增量模型是把待開發(fā)的軟件系統(tǒng)模塊化，將每個(gè)模塊作為一個(gè)增量組件，從而分批次地分析、設(shè)計(jì)、編碼和測(cè)試這些增量組件。運(yùn)用增量模型的軟件開發(fā)過程是遞增式的過程。相對(duì)于瀑布模型而言，采用增量模型進(jìn)行開發(fā)，開發(fā)人員不需要一次性地把整個(gè)軟件產(chǎn)品提交給用戶，而是可以分批次進(jìn)行提交。

敏捷開發(fā)

?敏捷軟件開發(fā)又稱敏捷開發(fā)， 是一種從1990年代開始逐漸引起廣泛關(guān)注的一些新型軟件開發(fā)方法，是一種應(yīng)對(duì)快速變化的需求的一種軟件開發(fā)能力。

?在敏捷開發(fā)中，軟件項(xiàng)目在構(gòu)建初期被切分成多個(gè)子項(xiàng)目，各個(gè)子項(xiàng)目的成果都經(jīng)過測(cè)試，具備可視、可集成和可運(yùn)行使用的特征。換言之，就是把一個(gè)大項(xiàng)目分為多個(gè)相互聯(lián)系，但也可獨(dú)立運(yùn)行的小項(xiàng)目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。

-人和交互?? 重于過程和工具。

-可以工作的軟件??? 重于求全而完備的文檔。

-客戶協(xié)作???? 重于合同談判。

-隨時(shí)應(yīng)對(duì)變化???? 重于循規(guī)蹈矩。

?因此敏捷方法更適用于較小的隊(duì)伍，40、30、20、10人或者更少。

原則： 主張簡(jiǎn)單 擁抱變化 遞增的變化 快速反饋

（4）測(cè)試定義，目的，原則：

定義：使用人工和自動(dòng)手段來(lái)運(yùn)行或測(cè)試某個(gè)系統(tǒng)的過程，其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或是弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別

目的：

1.發(fā)現(xiàn)被測(cè)對(duì)象與用戶需求之間的差異，即缺陷

2.通過測(cè)試發(fā)現(xiàn)并解決問題，讓客戶對(duì)軟解質(zhì)量有信心

3.通過測(cè)試了解軟件質(zhì)量，為決策提供數(shù)據(jù)

4.通過測(cè)試積累經(jīng)驗(yàn)，預(yù)防缺陷出現(xiàn)，降低產(chǎn)品失敗風(fēng)險(xiǎn)

原則：

1.測(cè)試證明軟件存在缺陷

2.不能執(zhí)行無(wú)窮盡的測(cè)試

3.測(cè)試應(yīng)盡早介入

4.缺陷存在群集現(xiàn)象（二八原理）

5.殺蟲劑悖論

6.不同的測(cè)試活動(dòng)依賴于不同的測(cè)試背景

7.不存在缺陷謬論

（5）測(cè)試階段

單元測(cè)試（unit testing）

集成測(cè)試（integration testing）

系統(tǒng)測(cè)試（system testing）

驗(yàn)收測(cè)試（acceptance testing）

UT

單元測(cè)試是針對(duì)軟件基本組成單元函數(shù)內(nèi)部的語(yǔ)句、條件分支來(lái)進(jìn)行正確性檢驗(yàn)的測(cè)試工作

單元測(cè)試的目的是檢測(cè)軟件模塊對(duì)《詳細(xì)設(shè)計(jì)說(shuō)明書》LLD的符合程度

IT（集成測(cè)試）

集成測(cè)試是在單元測(cè)試的基礎(chǔ)上，將所有模塊按照概要設(shè)計(jì)要求組裝成為子系統(tǒng)或系統(tǒng)，驗(yàn)證組裝后功能以及模塊間接口是否正確的測(cè)試工作?

?集成測(cè)試的目的是檢測(cè)軟件模塊對(duì)《概要設(shè)計(jì)說(shuō)明書》HLD的符合程度

ST

?系統(tǒng)測(cè)試是將已經(jīng)集成好的軟件系統(tǒng)，作為整個(gè)基于計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實(shí)際運(yùn)行（使用）環(huán)境下，對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的測(cè)試工作

?系統(tǒng)測(cè)試的目的在于通過與《需求規(guī)格說(shuō)明書》作比較，發(fā)現(xiàn)軟件與系統(tǒng)需求定義不符合或與之矛盾的地方

單元測(cè)試（ut） 集成測(cè)試（it） 系統(tǒng)測(cè)試（st）之間的區(qū)別

?測(cè)試方法不同

–? 單元測(cè)試屬于白盒測(cè)試范疇

–? 集成測(cè)試屬于灰盒測(cè)試范疇

–? 系統(tǒng)測(cè)試屬于黑盒測(cè)試范疇

??測(cè)試對(duì)象不同

–?單元測(cè)試主要測(cè)試單元內(nèi)部的數(shù)據(jù)結(jié)構(gòu)、邏輯控制、異常處理等

–?集成測(cè)試主要測(cè)試模塊之間的接口和接口數(shù)據(jù)傳遞關(guān)系，以及模塊

??組合后的整體功能

–? 系統(tǒng)測(cè)試主要測(cè)試整個(gè)系統(tǒng)相對(duì)于需求的符合度

??判斷標(biāo)準(zhǔn)不同

–? 單元測(cè)試判斷標(biāo)準(zhǔn)是詳細(xì)設(shè)計(jì)說(shuō)明書

–? 集成測(cè)試的判斷標(biāo)準(zhǔn)是概要設(shè)計(jì)說(shuō)明書

–? 系統(tǒng)測(cè)試的判斷標(biāo)準(zhǔn)是軟件需求規(guī)格說(shuō)明書

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

是以用戶為主的測(cè)試，主要測(cè)試方法有3種

α測(cè)試:開發(fā)環(huán)境下進(jìn)行，軟件在自然狀態(tài)下使用，有開發(fā)人員在旁，測(cè)試可控制。目的主要是評(píng)價(jià)軟件產(chǎn)品的FLURPS（即功能、局域化、可用性、可靠性、性能和技術(shù)支持）

β測(cè)試：多個(gè)用戶在多個(gè)實(shí)際情況下使用，開發(fā)人員不在旁，測(cè)試不可控制。

UAT測(cè)試：即用戶接受度測(cè)試。一般用于商業(yè)用戶驗(yàn)收系統(tǒng)的可用性。

?一般用于商業(yè)用戶驗(yàn)證系統(tǒng)的可用性，通常情況由終端用戶或利益相關(guān)方對(duì)被測(cè)試對(duì)象進(jìn)行選擇性功能驗(yàn)證。

? 也有可能根據(jù)法律法規(guī)、行業(yè)現(xiàn)行標(biāo)準(zhǔn)進(jìn)行驗(yàn)收測(cè)試。

（6）測(cè)試方法

按是否關(guān)系產(chǎn)品內(nèi)部結(jié)構(gòu)劃分: 黑盒測(cè)試，灰盒測(cè)試，白盒測(cè)試；

按是否運(yùn)行程序劃分：靜態(tài)測(cè)試 動(dòng)態(tài)測(cè)試；

按測(cè)試執(zhí)行方式：手工測(cè)試 ?自動(dòng)化測(cè)試；

軟件測(cè)試兩種極端情況：

1.已知產(chǎn)品的需求規(guī)格，但不知道其內(nèi)部實(shí)現(xiàn)，可以進(jìn)行測(cè)試證明每個(gè)需求是否實(shí)現(xiàn)。

2.已知產(chǎn)品的內(nèi)部實(shí)現(xiàn)過程，可以通過測(cè)試證明每種內(nèi)部操作是否符合設(shè)計(jì)規(guī)格的要求，所有內(nèi)部成分是否已經(jīng)過檢查

白盒測(cè)試：

分析軟件內(nèi)部構(gòu)造，?根據(jù)內(nèi)部構(gòu)造設(shè)計(jì)用例，對(duì)內(nèi)部控制流程進(jìn)行測(cè)試，不顧軟件整體功能實(shí)現(xiàn)情況

是基于內(nèi)部結(jié)構(gòu)的邏輯驅(qū)動(dòng)測(cè)試

又可稱為玻璃盒測(cè)試、透明盒測(cè)試、開放盒測(cè)試、結(jié)構(gòu)化測(cè)試、邏輯驅(qū)動(dòng)測(cè)試

白盒測(cè)試一般在測(cè)試前期進(jìn)行，通過測(cè)試讓內(nèi)部結(jié)構(gòu)達(dá)到一定邏輯覆蓋率指標(biāo)，使內(nèi)部控制問題盡可能達(dá)到最小，使軟件代碼達(dá)到更大質(zhì)量保證，而且而且測(cè)試前期發(fā)現(xiàn)問題解決成本低

黑盒測(cè)試:

考慮整體功能實(shí)現(xiàn)情況，不顧內(nèi)部構(gòu)造

基于規(guī)則的測(cè)試

對(duì)更大的代碼單元（子系統(tǒng)甚至系統(tǒng)級(jí)）測(cè)試效率比白盒高，對(duì)測(cè)試人員的代碼語(yǔ)音能力要求比白盒低，從用戶的角度測(cè)試，容易被理解接受，有助于暴露任何規(guī)格不一致或有歧義的問題。

灰盒測(cè)試：

?根據(jù)利用的被測(cè)對(duì)象信息的不同，會(huì)采用不同的方法進(jìn)行測(cè)試。?

?利用被測(cè)對(duì)象的整體特性信息，采用黑盒測(cè)試方法?

??利用被測(cè)對(duì)象的內(nèi)部具體實(shí)現(xiàn)信息，采用白盒測(cè)試方法?

?如果既利用被測(cè)對(duì)象的整體特性信息，又利用被測(cè)對(duì)象的內(nèi)部具體實(shí)現(xiàn)信息，采用的就是灰盒測(cè)試方法。兩種信息占的比例不同，相應(yīng)的灰度就不同。完全是整體特性信息，就是黑盒測(cè)試，完全是內(nèi)部具體實(shí)現(xiàn)信息，就是白盒測(cè)試?

??典型的灰盒測(cè)試比如集成測(cè)試和系統(tǒng)測(cè)試時(shí)借助log信息

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

不運(yùn)行被測(cè)試的軟件系統(tǒng)，而是采用其他手段和技術(shù)對(duì)被測(cè)試軟件進(jìn)行檢測(cè)的一種測(cè)試技術(shù)。例如：代碼走讀、文檔評(píng)審、程序分析等都是靜態(tài)測(cè)試的范疇。常用技術(shù)有靜態(tài)分析技術(shù)。

靜態(tài)分析技術(shù)：

?定義：靜態(tài)分析是一種不通過執(zhí)行程序而分析程序執(zhí)行的技術(shù)

?功能：檢查軟件的表示和描述是否一致，沒有沖突或者沒有歧義，它瞄準(zhǔn)的是糾正軟件系統(tǒng)在描述、表示和規(guī)格上的錯(cuò)誤，因此是任何進(jìn)一步測(cè)試執(zhí)行的前提。

主要有三種不同的程序測(cè)試可能性：

?考慮程序是否滿足編碼規(guī)則，語(yǔ)法上是否具有一致性和完整性；

?考慮文檔描述是否規(guī)范、準(zhǔn)確、便于查閱；

?考慮程序和文檔之間的一致性。

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

按照預(yù)先設(shè)計(jì)的數(shù)據(jù)和步驟去運(yùn)行被測(cè)軟件系統(tǒng)，從而對(duì)被測(cè)軟件系統(tǒng)進(jìn)行檢測(cè)的一種測(cè)試技術(shù)。常用技術(shù)有動(dòng)態(tài)分析技術(shù)

人工測(cè)試：

測(cè)試活動(dòng)（如評(píng)審、測(cè)試設(shè)計(jì)、測(cè)試執(zhí)行等）由人來(lái)完成，狹義上是指測(cè)試執(zhí)行由人工完成，這是最基本的測(cè)試形式

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

一般是指通過計(jì)算機(jī)模擬人的測(cè)試行為，替代人的測(cè)試活動(dòng)，狹義上是指測(cè)試執(zhí)行由計(jì)算機(jī)來(lái)完成

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

?對(duì)程序新版本運(yùn)行前一版本執(zhí)行的測(cè)試，提高回歸測(cè)試效率

?可以運(yùn)行更多更頻繁的測(cè)試，比如冒煙測(cè)試

?可以執(zhí)行手工測(cè)試?yán)щy或不可能做的測(cè)試，比如大量的重復(fù)操作或者集成測(cè)試

?更好地利用資源，比如測(cè)試儀器或者被測(cè)對(duì)象

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

?不能取代手工測(cè)試，自動(dòng)化測(cè)試只能提高測(cè)試效率，不能提高測(cè)試有效性，即不可能發(fā)現(xiàn)更多缺陷

?手工測(cè)試比自動(dòng)測(cè)試發(fā)現(xiàn)的缺陷更多

?對(duì)測(cè)試設(shè)計(jì)依賴性極大，測(cè)試設(shè)計(jì)的不好會(huì)遺漏問題

?自動(dòng)化測(cè)試對(duì)軟件開發(fā)具有很大的依賴性，開發(fā)上出現(xiàn)變更可能導(dǎo)致前面的自動(dòng)化測(cè)試完全失效

?工具本身并不具備想象力，工具不具有智能

(7)測(cè)試模型

與開發(fā)模型一樣，軟件測(cè)試根據(jù)不同的被測(cè)對(duì)象、測(cè)試背景、被測(cè)對(duì)象質(zhì)量要求、項(xiàng)目進(jìn)度要求等，可以采用不同的測(cè)試模型實(shí)施測(cè)試活動(dòng)，來(lái)指導(dǎo)軟件測(cè)試活動(dòng)安排。

業(yè)界常見模型：

V模型 ? ? 從上至下 ?從左至右 ? ? ? ?缺點(diǎn)：項(xiàng)目早期的缺陷，在后期才能發(fā)現(xiàn)

W模型（雙V模型） ? 測(cè)試活動(dòng)與研發(fā)并行， 文檔測(cè)試

X模型?單獨(dú)的程序片段進(jìn)行獨(dú)立的編碼和測(cè)試活動(dòng) ? ?探測(cè)性測(cè)試

H模型 開發(fā)與測(cè)試獨(dú)立 ? ? 分測(cè)試準(zhǔn)備，測(cè)試執(zhí)行

敏捷模型 客戶角度進(jìn)行測(cè)試 預(yù)防缺陷重于發(fā)現(xiàn)缺陷

V模型：

?V模型是所有軟件測(cè)試模型中最為大家熟知的一種模型。它是從瀑布研發(fā)模型演變而來(lái)的測(cè)試模型，如圖所示。

V模型流程是從上至下，從左到右

①測(cè)試工程師在研發(fā)人員編程過程中，對(duì)其生成的代碼函數(shù)做單元測(cè)試

②單元測(cè)試通過后進(jìn)行集成測(cè)試

③集成測(cè)試通過后做系統(tǒng)測(cè)試、驗(yàn)收測(cè)試

V模型缺點(diǎn)：項(xiàng)目早期的缺陷，在后期才能

W模型：

W模型是在V模型的基礎(chǔ)上演變而來(lái)的，一般又稱為雙V模型。在V模型中，研發(fā)活動(dòng)沒有完成、無(wú)任何輸出物時(shí)，測(cè)試工程師無(wú)法開展測(cè)試工作，相對(duì)而言，測(cè)試活動(dòng)嚴(yán)重滯后。為了解決V模型的缺點(diǎn)，W模型提出了測(cè)試活動(dòng)與研發(fā)活動(dòng)并行的概念，并且在生產(chǎn)流程演進(jìn)過程中，增加了驗(yàn)證與確認(rèn)活動(dòng)

W模型從用戶需求開始，研發(fā)團(tuán)隊(duì)根據(jù)用戶需求進(jìn)行需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼開發(fā)等活動(dòng)，測(cè)試團(tuán)隊(duì)則根據(jù)用戶需求進(jìn)行驗(yàn)收測(cè)試、系統(tǒng)測(cè)試、集成測(cè)試及單元測(cè)試設(shè)計(jì)。測(cè)試工作與研發(fā)活動(dòng)分離，實(shí)現(xiàn)了并行操作。測(cè)試活動(dòng)伴隨著整個(gè)研發(fā)過程，而不僅在研發(fā)有成果輸出后才參與。

W模型強(qiáng)調(diào)了測(cè)試活動(dòng)不僅僅包括研發(fā)活動(dòng)所產(chǎn)生的軟件源代碼，還考慮各種文檔，如需求文檔、概要設(shè)計(jì)文檔、詳細(xì)設(shè)計(jì)文檔、代碼等。

W模型要求測(cè)試活動(dòng)從用戶需求階段就介入，有利于盡早地發(fā)現(xiàn)問題，在模型實(shí)施過程中，時(shí)刻進(jìn)行確認(rèn)（validation）、驗(yàn)證（verification）活動(dòng)

X模型：

?X模型產(chǎn)生的背景亦與V模型有關(guān)，V模型的缺點(diǎn)是測(cè)試活動(dòng)滯后于研發(fā)活動(dòng)，無(wú)法盡早地開展測(cè)試活動(dòng)。而X模型與W模型一樣，提出的初衷都是解決V模型的缺點(diǎn)。

?X模型的基本思想是由Marick提出的， Robin F.Goldsmith進(jìn)行了完善。X模型如圖所示。

X模型左邊表明針對(duì)單獨(dú)的程序片段n進(jìn)行獨(dú)立的編碼和測(cè)試活動(dòng)，以此為基本過程，不斷迭代，通過集成活動(dòng)最終成為可執(zhí)行程序，然后再對(duì)這些可執(zhí)行程序進(jìn)行測(cè)試。通過集成測(cè)試的成品可以進(jìn)行封裝并提交給系統(tǒng)測(cè)試環(huán)節(jié)或直接給用戶。多條并行的曲線表示變更可以在各個(gè)部分發(fā)生。

探索性測(cè)試:探索性測(cè)試與常規(guī)的測(cè)試方法不同，無(wú)須事先制定測(cè)試計(jì)劃或設(shè)計(jì)，有經(jīng)驗(yàn)的測(cè)試工程師可根據(jù)自己的思維活動(dòng)及對(duì)被測(cè)對(duì)象的理解，在測(cè)試計(jì)劃之外發(fā)現(xiàn)更多的軟件錯(cuò)誤。但探索性測(cè)試通常情況下僅作為其他測(cè)試方法的補(bǔ)充，因其消耗測(cè)試資源較多，且受制于測(cè)試工程師的經(jīng)驗(yàn)，所以不能成為獨(dú)立的測(cè)試方法。

? ? H模型：

H模型將測(cè)試活動(dòng)與其他研發(fā)流程獨(dú)立，測(cè)試活動(dòng)分為測(cè)試準(zhǔn)備與測(cè)試執(zhí)行兩個(gè)部分，便于測(cè)試設(shè)計(jì)與測(cè)試執(zhí)行活動(dòng)定義，如圖所示。測(cè)試準(zhǔn)備活動(dòng)包括測(cè)試需求分析、測(cè)試計(jì)劃、測(cè)試設(shè)計(jì)、測(cè)試編碼、測(cè)試驗(yàn)證等，測(cè)試執(zhí)行包括測(cè)試運(yùn)行、測(cè)試報(bào)告、測(cè)試結(jié)果分析、確認(rèn)回歸測(cè)試等

? ??H模型與W模型一樣，揭示了軟件測(cè)試活動(dòng)應(yīng)該是一個(gè)獨(dú)立的軟件生產(chǎn)流程，貫穿整個(gè)軟件生命周期，測(cè)試活動(dòng)應(yīng)該盡早準(zhǔn)備、盡早執(zhí)行，當(dāng)測(cè)試準(zhǔn)備工作完成后，一旦到達(dá)測(cè)試就緒點(diǎn)，就可開展測(cè)試執(zhí)行活動(dòng)，不會(huì)受制于研發(fā)活動(dòng)。

敏捷測(cè)試：

強(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)缺陷

?傳統(tǒng)測(cè)試：測(cè)試是質(zhì)量的最后保護(hù)者?????????? ? ? ? ?敏捷測(cè)試：開發(fā)和測(cè)試人員是緊密合作，大家都有責(zé)任對(duì)軟件負(fù)責(zé)；

? ? ? ? ? ? ? ? ? ? ? 嚴(yán)格的變更管理 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 變更是可接受的，擁抱變

? ? ? ? ? ? ? ? ? ? ? 預(yù)先的計(jì)劃和細(xì)節(jié)的準(zhǔn)備 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 計(jì)劃隨著進(jìn)展時(shí)常調(diào)整

? ? ? ? ? ? ? ? ? ? ? ?重量級(jí)文檔 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?只需要絕對(duì)必要的文檔

? ? ? ? ? ? ? ? 各階段測(cè)試嚴(yán)格的入口和出口標(biāo)準(zhǔn) ? ? ? ? ? ? ? ? ? ? ? ? ? 各迭代之間已經(jīng)沒有明顯的入口和出口標(biāo)準(zhǔn)

? ? ? ? ? ? ? ?更多在回歸測(cè)試時(shí)進(jìn)行重量級(jí)的自動(dòng)化測(cè)試 ? ? ? ? ? ?所有階段都需要自動(dòng)測(cè)試，每個(gè)人都需要做，是項(xiàng)目集成 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?的一部分；

? ? ? ? ? ? ? 嚴(yán)格依賴流程執(zhí)行 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?流程不再需要嚴(yán)格執(zhí)行

? ? ? ? ? ? ? 測(cè)試團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)是相對(duì)獨(dú)立的 ? ? ? ? ? ? ? ? ? ? ? ? ? ?團(tuán)隊(duì)合作是無(wú)縫隙合作