匯智動力——軟件測試級別詳解
匯智動力針對不同研發(fā)階段的測試目的，測試活動分為需求測試、組件/單元測試、集成測試、系統(tǒng)測試、驗收測試、Alpha測試、Beta測試、UAT測試等級別。
一、需求測試
軟件測試雙V模型要求測試工程師在需求階段就開始制定系統(tǒng)測試計劃，考慮系統(tǒng)測試方法，但這還不夠。全面的質量管理要求在每個階段都要進行驗證和確認的活動。因此在需求階段，測試工程師還需對需求本身進行測試。這個測試是必要的，因為在許多失敗的項目中，70%～85%的返工是由于需求方面的錯誤所導致。因需求錯誤導致大量返工，造成進度延遲，缺陷發(fā)散甚至項目失敗，這是一件極其痛苦的事情。因此測試工程師需在軟件生產源頭-需求就開始測試。
需求測試（Requirement Test）的重點是檢查需求規(guī)格說明書中是否存在描述不準確、定義模糊、需求用例不正確、語言存在二義性等問題。主要從以下幾個方面考慮。
1. 完整性。
每一項需求都必須將所要實現的功能描述清楚，為開發(fā)人員設計和實現這些功能提供所有必要的需求依據。
2. 正確性。
每一項需求都必須準確地陳述其要開發(fā)的功能。
3. 一致性。
一致性是指與其他軟件需求或高層（系統(tǒng)、業(yè)務）需求不相矛盾，或者與項目宣傳資料一致。
4. 可行性。
每一項需求都必須是在已知系統(tǒng)和環(huán)境的權能和限制范圍內可以實施的。
5. 無二義性。
對所有需求說明書的讀者都只能有一個明確統(tǒng)一的解釋，由于自然語言極易導致二義性，所以盡量把每項需求用簡潔明了的用戶語言表達出來。
6. 健壯性。
需求說明中是否對可能出現的異常進行了分析，并且對這些異常進行了容錯處理。
7. 必要性。
必要性可理解為每項需求都是用來授權編寫文檔的“根源”。要使每項需求都能回溯至某項客戶的輸入，如需求用例或其他來源。
8. 可測試性。
每項需求都能通過設計測試用例或其他的驗證方法來進行測試。
9. 可修改性。
每項需求只應在軟件需求規(guī)格說明書中出現一次。這樣更改時易于保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規(guī)格說明書更容易修改。
二、 組件/單元測試
軟件系統(tǒng)中，系統(tǒng)對象的基本組成單元稱為組件或程序單元。程序代碼中的函數或者類稱為“單元”，或者實現某個獨立需求的功能模塊，稱為組件/單元。組件可能由多個單元組成。
組件/單元測試（Unit Test）是針對軟件基本組成單元（軟件設計的最小單位）來進行正確性檢驗的測試工作，其目的是檢測被測組件/單元與詳細設計說明書的符合程度。通過組件/單元測試活動驗證被測對象的功能特性或非功能性特性，發(fā)現其可能存在的內存泄露、算法冗余、分支覆蓋率低、循環(huán)調用效率低等問題，此類缺陷在系統(tǒng)測試層面很難發(fā)現。因此，組件/單元測試能夠盡早地發(fā)現缺陷，修復缺陷成本相對較低。
組件/單元測試一般由開發(fā)人員負責，成本較高。在敏捷研發(fā)模型中，測試工程師也可能需要實施此測試活動。組件/單元測試活動亦可以使用自動化測試方法。
組件/單元測試活動依據包括組件/單元需求說明、詳細設計文檔、被測代碼、編程規(guī)范等，典型的測試對象一般有組件、函數、類、數據轉換/移植程序、數據庫模型、關鍵字典等，關注被測對象內部數據結構、邏輯控制、異常處理等實現的正確性。
【案例1 計算器單元測試】
一個計算器軟件具有加、減、乘、除4種基本功能，對其實現單元測試，利用Junit單元測試工具實施如下。
計算器功能代碼：
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("除數不能為0!");
}
return a - b;//為了演示效果，此處構造錯誤的除法算法
}
}
單元測試代碼：
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);
}
}
測試結果圖1所示。
圖1——單元測試示例
從上述案例可以看出，除法功能測試失敗，期望結果是4，但實際結果為3，查看代碼，原因是除法功能代碼錯誤，“a/b”錯誤寫成“a-b”。執(zhí)行單元測試時，僅關注每個函數或類單元的輸入輸出，根據預期結果與實際結果的對比，判斷被測對象的正確與否。
三、集成測試
組件/單元測試通過后的組件或單元，即可進行集成測試。集成測試（Integration Testing）是對組件/單元之間及組件/單元與第三方接口之間進行測試，其目的是驗證接口是否與設計相符，是否與需求相符。
集成測試根據被測對象的集成程度，可分為3種集成：組件/單元間集成、模塊間集成、子系統(tǒng)間集成。集成的規(guī)模越大，發(fā)現定位缺陷的難度就越大，所以一般根據被測對象的系統(tǒng)結構特性，先從組件/單元間的集成測試開始，使用自底向上或自頂向下漸增式策略實施集成測試活動，大爆炸式集成策略已漸漸被淘汰。
【案例2計算器集成測試】
案例1單元測試中的計算器功能，假設加、減、乘、除4個功能為獨立的類文件，使用集成測試自頂向上策略時，首先對各個類進行測試，然后測試主控模塊，當除法代碼如下時：
publicint divd(int a,int b) throws Exception
{
return a / b;
}
在實施集成測試，構造測試輸入a=4，b=0時，將會拋出異常，如圖2所示。
圖2——集成測試異常示例
集成測試的目的是檢測軟件模塊對《概要設計說明書》的符合程度，關注于模塊間接口和接口數據傳遞關系，以及模塊組合后的整體功能。集成測試實施人員一般是開發(fā)人員，當然也可以是測試工程師，現在不少企業(yè)集成測試實現了自動化測試，更聚焦于接口測試。
四、 系統(tǒng)測試
系統(tǒng)測試（System Test）是將通過集成測試的軟件，部署到某種較為復雜的計算機用戶環(huán)境進行測試，這里所說的復雜計算機用戶環(huán)境，其實就是模擬的用戶真實計算機環(huán)境。
集成測試階段大多數情況下，是在一種比較干凈的系統(tǒng)中進行測試。所謂的干凈，即是在測試機上沒有多余的軟件，僅有所需的操作系統(tǒng)和被測軟件。集成測試完成后，將被測軟件置入比較復雜的運行環(huán)境下，進行集成和確認測試。在此過程中，往往有很大的收獲，例如，進行安裝測試時，會發(fā)現在集成階段安裝沒有問題，但在復雜用戶環(huán)境下，卻不能安裝。例如，某公司研發(fā)一款財務軟件，軟件中采用Excel 2000版中的某些繪圖控件，在集成測試階段，測試環(huán)境中僅安裝了該財務軟件和Excel 2000，但系統(tǒng)測試過程中，測試環(huán)境可能還安裝了其他也需調用Excel控件的軟件，這時可能會出現控件資源爭用錯誤。
系統(tǒng)測試的目的在于通過與系統(tǒng)的需求定義做比較，發(fā)現軟件與系統(tǒng)的需求定義不符合或與之矛盾的地方。系統(tǒng)測試階段主要進行安裝卸載測試、兼容性測試、功能確認測試、性能測試、安全性測試等。系統(tǒng)測試階段采用黑盒測試方法，主要考查被測軟件的功能與性能表現。如果軟件可以按照用戶合理的期望方式工作，即可認為通過系統(tǒng)測試，相反則表現為缺陷。圖3所示是系統(tǒng)測試階段發(fā)現的修改資產類別時，備注信息無法正確讀取的缺陷，未能實現用戶期望。
圖3——系統(tǒng)測試備注讀取錯誤缺陷示例
系統(tǒng)軟件測試過程其實也是一種配置檢查過程，檢查在軟件生產過程中是否有遺漏的地方，做到查漏補缺，以確保交付產品符合用戶質量要求。
系統(tǒng)測試通常由獨立的測試團隊完成，其測試依據一般包括需求規(guī)格說明書、需求用例、功能規(guī)格說明、功能需求列表、風險分析報告等，以需求規(guī)格說明書為主。測試對象包括軟件系統(tǒng)、用戶手冊、操作使用說明書、系統(tǒng)配置和配置數據等。
五、 驗收測試
系統(tǒng)測試完成，在交付用戶部署應用前，往往需要進行驗收測試。驗收測試（Acceptance Test）是以用戶為主的測試，驗收組應當由項目組成員、用戶代表或系統(tǒng)的其他利益相關者等組成，原則上在用戶所在地進行，但如經用戶同意，也可以在公司內模擬用戶環(huán)境進行。
驗收測試根據合同、《需求規(guī)格說明書》或《驗收測試計劃》對成品進行驗收測試。在此階段，發(fā)現缺陷并不是其主要目的，期望通過驗收測試，使用戶建立對即將交付應用的軟件系統(tǒng)的信心。
對于項目類的軟件系統(tǒng)，一般都需要進行驗收測試。驗收測試通常情況下可有Alpha測試、Beta測試、UAT測試等驗收測試形式。
六、 Alpha測試
Alpha測試是由用戶在開發(fā)環(huán)境下進行的測試，也可以是在開發(fā)機構內部的用戶模擬實際操作環(huán)境中進行測試。進行Alpha測試時，軟件在一個自然設置狀態(tài)下使用。開發(fā)者坐在用戶旁，隨時記下錯誤情況和使用問題，Alpha測試在受控的測試環(huán)境下實施，其目的主要是評價軟件產品的FLURPS（即功能、局域化、可用性、可靠性、性能和技術支持）是否達標。
七、 Beta測試
Beta測試是由軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進行的測試。與Alpha測試不同的是，進行Beta測試時，開發(fā)者通常不在測試現場。因而，Beta測試是在開發(fā)者無法控制的環(huán)境下進行的軟件現場應用，測試者發(fā)現問題后，統(tǒng)一收集提交至開發(fā)人員進行修復。
八、UAT測試
UAT測試（User Acceptance Test）即用戶接受度測試。一般用于商業(yè)用戶驗證系統(tǒng)的可用性。通常情況下，由采購方組織終端用戶或軟件利益相關方對被測對象進行選擇性功能試用，關注被測對象核心功能的應用表現，從而為接受該軟件系統(tǒng)提供數據依據。例如，銀行在外包項目交付時，組織部分行方終端應用人員（如柜臺服務人員）進行驗收性測試，即為UAT測試。
UAT模式測試還有一種可能，就是根據法律法規(guī)、行業(yè)現行標準進行驗收測試。例如，某政府機關采購的環(huán)保監(jiān)控系統(tǒng)，需遵守政府管理需求及環(huán)保法規(guī)的約定。
