針對(duì)不同研發(fā)階段的測(cè)試目的，測(cè)試活動(dòng)分為需求測(cè)試、組件/單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試、Alpha測(cè)試、Beta測(cè)試、UAT測(cè)試等級(jí)別。

一、需求測(cè)試

軟件測(cè)試雙V模型要求測(cè)試工程師在需求階段就開(kāi)始制定系統(tǒng)測(cè)試計(jì)劃，考慮系統(tǒng)測(cè)試方法，但這還不夠。全面的質(zhì)量管理要求在每個(gè)階段都要進(jìn)行驗(yàn)證和確認(rèn)的活動(dòng)。因此在需求階段，測(cè)試工程師還需對(duì)需求本身進(jìn)行測(cè)試。這個(gè)測(cè)試是必要的，因?yàn)樵谠S多失敗的項(xiàng)目中，70%～85%的返工是由于需求方面的錯(cuò)誤所導(dǎo)致。因需求錯(cuò)誤導(dǎo)致大量返工，造成進(jìn)度延遲，缺陷發(fā)散甚至項(xiàng)目失敗，這是一件極其痛苦的事情。因此測(cè)試工程師需在軟件生產(chǎn)源頭-需求就開(kāi)始測(cè)試。

需求測(cè)試（Requirement Test）的重點(diǎn)是檢查需求規(guī)格說(shuō)明書中是否存在描述不準(zhǔn)確、定義模糊、需求用例不正確、語(yǔ)言存在二義性等問(wèn)題。主要從以下幾個(gè)方面考慮。

1. 完整性。

每一項(xiàng)需求都必須將所要實(shí)現(xiàn)的功能描述清楚，為開(kāi)發(fā)人員設(shè)計(jì)和實(shí)現(xiàn)這些功能提供所有必要的需求依據(jù)。

2. 正確性。

每一項(xiàng)需求都必須準(zhǔn)確地陳述其要開(kāi)發(fā)的功能。

3. 一致性。

一致性是指與其他軟件需求或高層（系統(tǒng)、業(yè)務(wù)）需求不相矛盾，或者與項(xiàng)目宣傳資料一致。

4. 可行性。

每一項(xiàng)需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實(shí)施的。

5. 無(wú)二義性。

對(duì)所有需求說(shuō)明書的讀者都只能有一個(gè)明確統(tǒng)一的解釋，由于自然語(yǔ)言極易導(dǎo)致二義性，所以盡量把每項(xiàng)需求用簡(jiǎn)潔明了的用戶語(yǔ)言表達(dá)出來(lái)。

6. 健壯性。

需求說(shuō)明中是否對(duì)可能出現(xiàn)的異常進(jìn)行了分析，并且對(duì)這些異常進(jìn)行了容錯(cuò)處理。

7. 必要性。

必要性可理解為每項(xiàng)需求都是用來(lái)授權(quán)編寫文檔的“根源”。要使每項(xiàng)需求都能回溯至某項(xiàng)客戶的輸入，如需求用例或其他來(lái)源。

8. 可測(cè)試性。

每項(xiàng)需求都能通過(guò)設(shè)計(jì)測(cè)試用例或其他的驗(yàn)證方法來(lái)進(jìn)行測(cè)試。

9. 可修改性。

每項(xiàng)需求只應(yīng)在軟件需求規(guī)格說(shuō)明書中出現(xiàn)一次。這樣更改時(shí)易于保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規(guī)格說(shuō)明書更容易修改。

二、 組件/單元測(cè)試

軟件系統(tǒng)中，系統(tǒng)對(duì)象的基本組成單元稱為組件或程序單元。程序代碼中的函數(shù)或者類稱為“單元”，或者實(shí)現(xiàn)某個(gè)獨(dú)立需求的功能模塊，稱為組件/單元。組件可能由多個(gè)單元組成。

組件/單元測(cè)試（Unit Test）是針對(duì)軟件基本組成單元（軟件設(shè)計(jì)的最小單位）來(lái)進(jìn)行正確性檢驗(yàn)的測(cè)試工作，其目的是檢測(cè)被測(cè)組件/單元與詳細(xì)設(shè)計(jì)說(shuō)明書的符合程度。通過(guò)組件/單元測(cè)試活動(dòng)驗(yàn)證被測(cè)對(duì)象的功能特性或非功能性特性，發(fā)現(xiàn)其可能存在的內(nèi)存泄露、算法冗余、分支覆蓋率低、循環(huán)調(diào)用效率低等問(wèn)題，此類缺陷在系統(tǒng)測(cè)試層面很難發(fā)現(xiàn)。因此，組件/單元測(cè)試能夠盡早地發(fā)現(xiàn)缺陷，修復(fù)缺陷成本相對(duì)較低。

組件/單元測(cè)試一般由開(kāi)發(fā)人員負(fù)責(zé)，成本較高。在敏捷研發(fā)模型中，測(cè)試工程師也可能需要實(shí)施此測(cè)試活動(dòng)。組件/單元測(cè)試活動(dòng)亦可以使用自動(dòng)化測(cè)試方法。

組件/單元測(cè)試活動(dòng)依據(jù)包括組件/單元需求說(shuō)明、詳細(xì)設(shè)計(jì)文檔、被測(cè)代碼、編程規(guī)范等，典型的測(cè)試對(duì)象一般有組件、函數(shù)、類、數(shù)據(jù)轉(zhuǎn)換/移植程序、數(shù)據(jù)庫(kù)模型、關(guān)鍵字典等，關(guān)注被測(cè)對(duì)象內(nèi)部數(shù)據(jù)結(jié)構(gòu)、邏輯控制、異常處理等實(shí)現(xiàn)的正確性。

【案例1 計(jì)算器單元測(cè)試】

一個(gè)計(jì)算器軟件具有加、減、乘、除4種基本功能，對(duì)其實(shí)現(xiàn)單元測(cè)試，利用Junit單元測(cè)試工具實(shí)施如下。

計(jì)算器功能代碼：

package com.test.junit3;

public class Calculator {

public static void main(String[] agrs)

{

}

public int add(int a,int b)

{

return a + b;

}

public int minus(int a,int b)

{

return a - b;

}

public int multi(int a,int b)

{

return a * b;

}

public int divd(int a,int b) throws Exception

{

if(b==0)

{

throw new Exception("除數(shù)不能為0!");

}

return a - b;//為了演示效果，此處構(gòu)造錯(cuò)誤的除法算法

}

}

單元測(cè)試代碼：

package com.test.junit3;

import junit.framework.Assert;

import junit.framework.TestCase;

publicclass CalculatorTest extends TestCase{

publicvoid testAdd()

{

Calculator cal=newCalculator();

int result=cal.add(1, 2);

Assert.assertEquals(3, result);

}

publicvoid testMinus()

{

Calculator cal=newCalculator();

int result=cal.minus(1, 2);

Assert.assertEquals(-1, result);

}

publicvoidtestMulti()

{

Calculator cal=newCalculator();

int result=cal.multi(1, 2);

Assert.assertEquals(2, result);

}

publicvoid testDivd() throws Exception

{

Calculator cal=newCalculator();

int result=cal.divd(4, 1);

Assert.assertEquals(4, result);

}

}

測(cè)試結(jié)果圖1所示。

圖1——單元測(cè)試示例

從上述案例可以看出，除法功能測(cè)試失敗，期望結(jié)果是4，但實(shí)際結(jié)果為3，查看代碼，原因是除法功能代碼錯(cuò)誤，“a/b”錯(cuò)誤寫成“a-b”。執(zhí)行單元測(cè)試時(shí)，僅關(guān)注每個(gè)函數(shù)或類單元的輸入輸出，根據(jù)預(yù)期結(jié)果與實(shí)際結(jié)果的對(duì)比，判斷被測(cè)對(duì)象的正確與否。

三、集成測(cè)試

組件/單元測(cè)試通過(guò)后的組件或單元，即可進(jìn)行集成測(cè)試。集成測(cè)試（Integration Testing）是對(duì)組件/單元之間及組件/單元與第三方接口之間進(jìn)行測(cè)試，其目的是驗(yàn)證接口是否與設(shè)計(jì)相符，是否與需求相符。

集成測(cè)試根據(jù)被測(cè)對(duì)象的集成程度，可分為3種集成：組件/單元間集成、模塊間集成、子系統(tǒng)間集成。集成的規(guī)模越大，發(fā)現(xiàn)定位缺陷的難度就越大，所以一般根據(jù)被測(cè)對(duì)象的系統(tǒng)結(jié)構(gòu)特性，先從組件/單元間的集成測(cè)試開(kāi)始，使用自底向上或自頂向下漸增式策略實(shí)施集成測(cè)試活動(dòng)，大爆炸式集成策略已漸漸被淘汰。

【案例2計(jì)算器集成測(cè)試】

案例1單元測(cè)試中的計(jì)算器功能，假設(shè)加、減、乘、除4個(gè)功能為獨(dú)立的類文件，使用集成測(cè)試自頂向上策略時(shí)，首先對(duì)各個(gè)類進(jìn)行測(cè)試，然后測(cè)試主控模塊，當(dāng)除法代碼如下時(shí)：

publicint divd(int a,int b) throws Exception

{

return a / b;

}

在實(shí)施集成測(cè)試，構(gòu)造測(cè)試輸入a=4，b=0時(shí)，將會(huì)拋出異常，如圖2所示。

圖2——集成測(cè)試異常示例

集成測(cè)試的目的是檢測(cè)軟件模塊對(duì)《概要設(shè)計(jì)說(shuō)明書》的符合程度，關(guān)注于模塊間接口和接口數(shù)據(jù)傳遞關(guān)系，以及模塊組合后的整體功能。集成測(cè)試實(shí)施人員一般是開(kāi)發(fā)人員，當(dāng)然也可以是測(cè)試工程師，現(xiàn)在不少企業(yè)集成測(cè)試實(shí)現(xiàn)了自動(dòng)化測(cè)試，更聚焦于接口測(cè)試。

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

系統(tǒng)測(cè)試（System Test）是將通過(guò)集成測(cè)試的軟件，部署到某種較為復(fù)雜的計(jì)算機(jī)用戶環(huán)境進(jìn)行測(cè)試，這里所說(shuō)的復(fù)雜計(jì)算機(jī)用戶環(huán)境，其實(shí)就是模擬的用戶真實(shí)計(jì)算機(jī)環(huán)境。

集成測(cè)試階段大多數(shù)情況下，是在一種比較干凈的系統(tǒng)中進(jìn)行測(cè)試。所謂的干凈，即是在測(cè)試機(jī)上沒(méi)有多余的軟件，僅有所需的操作系統(tǒng)和被測(cè)軟件。集成測(cè)試完成后，將被測(cè)軟件置入比較復(fù)雜的運(yùn)行環(huán)境下，進(jìn)行集成和確認(rèn)測(cè)試。在此過(guò)程中，往往有很大的收獲，例如，進(jìn)行安裝測(cè)試時(shí)，會(huì)發(fā)現(xiàn)在集成階段安裝沒(méi)有問(wèn)題，但在復(fù)雜用戶環(huán)境下，卻不能安裝。例如，某公司研發(fā)一款財(cái)務(wù)軟件，軟件中采用Excel 2000版中的某些繪圖控件，在集成測(cè)試階段，測(cè)試環(huán)境中僅安裝了該財(cái)務(wù)軟件和Excel 2000，但系統(tǒng)測(cè)試過(guò)程中，測(cè)試環(huán)境可能還安裝了其他也需調(diào)用Excel控件的軟件，這時(shí)可能會(huì)出現(xiàn)控件資源爭(zhēng)用錯(cuò)誤。

系統(tǒng)測(cè)試的目的在于通過(guò)與系統(tǒng)的需求定義做比較，發(fā)現(xiàn)軟件與系統(tǒng)的需求定義不符合或與之矛盾的地方。系統(tǒng)測(cè)試階段主要進(jìn)行安裝卸載測(cè)試、兼容性測(cè)試、功能確認(rèn)測(cè)試、性能測(cè)試、安全性測(cè)試等。系統(tǒng)測(cè)試階段采用黑盒測(cè)試方法，主要考查被測(cè)軟件的功能與性能表現(xiàn)。如果軟件可以按照用戶合理的期望方式工作，即可認(rèn)為通過(guò)系統(tǒng)測(cè)試，相反則表現(xiàn)為缺陷。圖3所示是系統(tǒng)測(cè)試階段發(fā)現(xiàn)的修改資產(chǎn)類別時(shí)，備注信息無(wú)法正確讀取的缺陷，未能實(shí)現(xiàn)用戶期望。

圖3——系統(tǒng)測(cè)試備注讀取錯(cuò)誤缺陷示例

系統(tǒng)測(cè)試過(guò)程其實(shí)也是一種配置檢查過(guò)程，檢查在軟件生產(chǎn)過(guò)程中是否有遺漏的地方，做到查漏補(bǔ)缺，以確保交付產(chǎn)品符合用戶質(zhì)量要求。

系統(tǒng)測(cè)試通常由獨(dú)立的測(cè)試團(tuán)隊(duì)完成，其測(cè)試依據(jù)一般包括需求規(guī)格說(shuō)明書、需求用例、功能規(guī)格說(shuō)明、功能需求列表、風(fēng)險(xiǎn)分析報(bào)告等，以需求規(guī)格說(shuō)明書為主。測(cè)試對(duì)象包括軟件系統(tǒng)、用戶手冊(cè)、操作使用說(shuō)明書、系統(tǒng)配置和配置數(shù)據(jù)等。

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

系統(tǒng)測(cè)試完成，在交付用戶部署應(yīng)用前，往往需要進(jìn)行驗(yàn)收測(cè)試。驗(yàn)收測(cè)試（Acceptance Test）是以用戶為主的測(cè)試，驗(yàn)收組應(yīng)當(dāng)由項(xiàng)目組成員、用戶代表或系統(tǒng)的其他利益相關(guān)者等組成，原則上在用戶所在地進(jìn)行，但如經(jīng)用戶同意，也可以在公司內(nèi)模擬用戶環(huán)境進(jìn)行。

驗(yàn)收測(cè)試根據(jù)合同、《需求規(guī)格說(shuō)明書》或《驗(yàn)收測(cè)試計(jì)劃》對(duì)成品進(jìn)行驗(yàn)收測(cè)試。在此階段，發(fā)現(xiàn)缺陷并不是其主要目的，期望通過(guò)驗(yàn)收測(cè)試，使用戶建立對(duì)即將交付應(yīng)用的軟件系統(tǒng)的信心。

對(duì)于項(xiàng)目類的軟件系統(tǒng)，一般都需要進(jìn)行驗(yàn)收測(cè)試。驗(yàn)收測(cè)試通常情況下可有Alpha測(cè)試、Beta測(cè)試、UAT測(cè)試等驗(yàn)收測(cè)試形式。

六、 Alpha測(cè)試

Alpha測(cè)試是由用戶在開(kāi)發(fā)環(huán)境下進(jìn)行的測(cè)試，也可以是在開(kāi)發(fā)機(jī)構(gòu)內(nèi)部的用戶模擬實(shí)際操作環(huán)境中進(jìn)行測(cè)試。進(jìn)行Alpha測(cè)試時(shí)，軟件在一個(gè)自然設(shè)置狀態(tài)下使用。開(kāi)發(fā)者坐在用戶旁，隨時(shí)記下錯(cuò)誤情況和使用問(wèn)題，Alpha測(cè)試在受控的測(cè)試環(huán)境下實(shí)施，其目的主要是評(píng)價(jià)軟件產(chǎn)品的FLURPS（即功能、局域化、可用性、可靠性、性能和技術(shù)支持）是否達(dá)標(biāo)。

七、 Beta測(cè)試

Beta測(cè)試是由軟件的多個(gè)用戶在一個(gè)或多個(gè)用戶的實(shí)際使用環(huán)境下進(jìn)行的測(cè)試。與Alpha測(cè)試不同的是，進(jìn)行Beta測(cè)試時(shí)，開(kāi)發(fā)者通常不在測(cè)試現(xiàn)場(chǎng)。因而，Beta測(cè)試是在開(kāi)發(fā)者無(wú)法控制的環(huán)境下進(jìn)行的軟件現(xiàn)場(chǎng)應(yīng)用，測(cè)試者發(fā)現(xiàn)問(wèn)題后，統(tǒng)一收集提交至開(kāi)發(fā)人員進(jìn)行修復(fù)。

八、UAT測(cè)試

UAT測(cè)試（User Acceptance Test）即用戶接受度測(cè)試。一般用于商業(yè)用戶驗(yàn)證系統(tǒng)的可用性。通常情況下，由采購(gòu)方組織終端用戶或軟件利益相關(guān)方對(duì)被測(cè)對(duì)象進(jìn)行選擇性功能試用，關(guān)注被測(cè)對(duì)象核心功能的應(yīng)用表現(xiàn)，從而為接受該軟件系統(tǒng)提供數(shù)據(jù)依據(jù)。例如，銀行在外包項(xiàng)目交付時(shí)，組織部分行方終端應(yīng)用人員（如柜臺(tái)服務(wù)人員）進(jìn)行驗(yàn)收性測(cè)試，即為UAT測(cè)試。

UAT模式測(cè)試還有一種可能，就是根據(jù)法律法規(guī)、行業(yè)現(xiàn)行標(biāo)準(zhǔn)進(jìn)行驗(yàn)收測(cè)試。例如，某政府機(jī)關(guān)采購(gòu)的環(huán)保監(jiān)控系統(tǒng)，需遵守政府管理需求及環(huán)保法規(guī)的約定。