如何做基于需求的測試

蒲冬梅

本文先簡單介紹了跟需求相關(guān)的幾個概念，接著介紹了基于需求的測試分析的流程，并對每個流程環(huán)節(jié)做了詳細(xì)的介紹。

【關(guān)鍵詞】需求 測試 基于需求的測試

1 需求工程的基礎(chǔ)知識

1.1 需求的定義來源：[IEEEStd610.12-1990]

（1）用戶解決問題或達(dá)到目標(biāo)所需的條件或能力。

（2）系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力。

（3）一種反映上面（1）或（2）所描述的條件或能力的文檔說明。

1.2 需求的層次及關(guān)系

1.2.1 需求的層次

需求從層次上分由客戶需求和系統(tǒng)需求組成。

客戶需求：用戶提出的產(chǎn)品應(yīng)用操作具體的需求。

系統(tǒng)需求：由前面兩種類型衍生出的需求，子需求，包含產(chǎn)品具體的屬性，質(zhì)量，約束，限制等內(nèi)容。

1.2.2 質(zhì)量需求與非功能性需求的區(qū)別

一個非功能需求要么是一個不明確的功能性需求，要么是一個質(zhì)量需求。

例：需求描述為：R1：系統(tǒng)應(yīng)該是安全的。

形容詞“安全的”具體指什么？

為了保證系統(tǒng)是“安全的”系統(tǒng)應(yīng)具備哪些屬性？

如何檢驗(yàn)所實(shí)現(xiàn)的系統(tǒng)是否是“安全的”？針對安全每個涉眾可能都有自己的解讀。這些掩蓋了不明確的功能性需求的非功能性需求應(yīng)當(dāng)進(jìn)行精化。

如何修改？

（1）每個用戶使用系統(tǒng)之前必須使用用戶名和密碼（功能性需求）；

（2）系統(tǒng)應(yīng)每隔4個星期提醒用戶更改密碼（功能性需求）；

（3）用戶修改密碼時，系統(tǒng)應(yīng)確認(rèn)新密碼至少包含8個字符并同時包含數(shù)字和字母（功能性需求）；

（4）存儲于系統(tǒng)中用戶名和密碼必須得到保護(hù)，以防止被盜（質(zhì)量需求—完整性）。

2 基于需求的軟件測試分析

2.1 什么是測試需求？

關(guān)于測試需求，目前業(yè)界并沒有一個明確的標(biāo)準(zhǔn)定義，通常認(rèn)為軟件測試需求是明確現(xiàn)階段需要“測什么”，也即確定測試對象和測試范圍。

測試需求不同于軟件需求，在基于需求的測試中，軟件需求是軟件測試需求分析的主要依據(jù)；測試需求是為了測試“軟件需求”而需要的準(zhǔn)備必要條件。

測試需求應(yīng)該覆蓋全部已定義的業(yè)務(wù)流程，以及功能和非功能方面的需求。

2.2 開展基于需求測試分析的準(zhǔn)備活動

為了便于測試需求分析人員正確、完整地理解需求，需要開展以下活動：

2.2.1 需求文檔閱讀

主要目的是熟悉產(chǎn)品業(yè)務(wù)背景、部署環(huán)境以及產(chǎn)品的功能和非功能特性。

2.2.2 業(yè)務(wù)知識培訓(xùn)

主要目的是提高對產(chǎn)品功能及業(yè)務(wù)的理解能力。

2.2.3 業(yè)務(wù)流程及規(guī)則分析

主要目的是提高需求傳遞的質(zhì)量。

2.2.4 確定測試需求分析方法

根據(jù)產(chǎn)品功能和技術(shù)背景，確定測試需求分析方法、測試類型，同時提取公共需求。

2.3 基于需求測試的分析步驟

2.3.1 測試需求采集

測試需求采集以軟件開發(fā)需求為依據(jù)，首先要確保軟件需求的正確性，繼而從中提取具有可測試性的需求或特性，由此生成原始測試需求。

其中，可測試性是指對于我們提取出的每一條軟件需求或需要實(shí)現(xiàn)的每一個特性，都必須存在一個可以明確預(yù)知的結(jié)果，可以用某種方法來明確的判斷此需求或特性是否符合需求文檔中的描述。

測試需求采集方法：

（1）根據(jù)被測軟件需求規(guī)格說明、其他等效設(shè)計(jì)文檔、相關(guān)標(biāo)準(zhǔn)、背景資料等，建立開發(fā)需求列表；

（2）針對開發(fā)需求列表中的每一條開發(fā)需求，形成可測試的測試需求；測試需求列表包括“需求標(biāo)識”、“測試需求描述”和“信息來源”。

（3）其中，需求標(biāo)識為軟件需求對應(yīng)的開發(fā)文檔及章節(jié)號；如無對應(yīng)文檔，則可用隱含需求、遺漏需求標(biāo)識；

（4）測試需求描述為對應(yīng)軟件需求的簡述；

（5）信息來源可為：具體開發(fā)文檔、相關(guān)標(biāo)準(zhǔn)、與客戶或開發(fā)人員溝通、培訓(xùn)等。

由以上方法形成的原始測試需求列表中，可能會存在重復(fù)和冗余的測試需求，可對其進(jìn)行刪除或合并；同時也需要對過于簡略的測試需求進(jìn)行細(xì)化。

2.3.2 測試需求分析的方法

（1）功能交互分析法：針對有業(yè)務(wù)需求的產(chǎn)品；需求分析的對象是不同業(yè)務(wù)模塊之間的業(yè)務(wù)流程和業(yè)務(wù)規(guī)則。要求分析人員對整個系統(tǒng)的業(yè)務(wù)比較了解；功能交互的重點(diǎn)在驗(yàn)證數(shù)據(jù)流轉(zhuǎn)的正確性；與測試類型分析法不同的是：測試類型分析法針對需要或功能點(diǎn)，而功能交互分析法是針對需求或功能點(diǎn)之間；可并入測試類型分析法的功能性測試中。

（2）經(jīng)驗(yàn)分析法：該方法是將具有代表性的測試積累形成經(jīng)驗(yàn)庫，以方便重用；如果經(jīng)驗(yàn)有代表性，可并入測試類型分析法。

（3）測試類型分析。軟件測試可以劃分為不同的測試類型，如：功能測試、用戶界面測試、安全性測試、接口測試、壓力測試、結(jié)構(gòu)測試、容量測試、完整性測試、恢復(fù)性測試、兼容性測試等等。

從軟件質(zhì)量子特性角度來看，對每一條測試需求，都可確定對應(yīng)的質(zhì)量子特性。不同的質(zhì)量子特性對應(yīng)不同的測試內(nèi)容，也即對應(yīng)不同的測試類型。

在實(shí)施過程中，我們可以建立一個質(zhì)量子特性和測試類型的對應(yīng)關(guān)系表，那么對于確定的質(zhì)量子特性，我們就可以使用該表格來確定測試類型。

此外，在確定測試類型時，我們還需要考慮以下幾點(diǎn)：

（1）測試類型對應(yīng)的情況說明；

（2）常見測試類型對被測軟件的覆蓋程度；

（3）測試類型是否包含被測軟件的特殊情況。

2.3.3 基于需求的測試管理技術(shù)

在實(shí)際的軟件開發(fā)過程中，軟件需求通常會不斷的變化；軟件需求一旦發(fā)生變更，我們的測試需求也必須隨之變化。如何在不斷變動的需求中確定各階段的測試內(nèi)容，這就需要對測試需求進(jìn)行有效的管理。

一個較為有效的方法是建立測試需求跟蹤矩陣，對測試需求變更進(jìn)行管理。

將按照上文所述的測試需求采集方法、測試需求分析方法確定下來的開發(fā)需求、測試需求、測試類型等內(nèi)容填入表格，我們可以建立測試需求跟蹤矩陣，測試需求跟蹤矩陣可能包括的列有：測試需求編號，原始測試需求描述，測試點(diǎn)編號，測試要點(diǎn)，測試用例編號范圍。測試需求跟蹤矩陣需要跟隨需求變化不斷的維護(hù)。軟件需求一旦變化，就需要啟動配置管理過程，將軟件需求變化相關(guān)的測試內(nèi)容進(jìn)行同步變更。

3 總結(jié)

測試需求明確需要“測什么”，即確定測試對象和測試范圍?；谛枨蟮臏y試以軟件開發(fā)需求為主要依據(jù)，通過測試需求分析，形成可測試內(nèi)容?；谛枨蟮臏y試是一種最根本的軟件測試，可以驗(yàn)證需求的正確性，可以設(shè)計(jì)出充分且必要的測試集，更好地保證測試的質(zhì)量和進(jìn)度。

參考文獻(xiàn)

[1]Bender-Requirements Based Testing Process ? 2009 Bender RBT Inc.17 Cardinale Lane Queensbury， NY 12804 518-743-8755.

[2]劉柏，唐龍利，陳大圣.基于需求的測試用例設(shè)計(jì)方法研究[J].中國船舶工業(yè)綜合技術(shù)經(jīng)濟(jì)研究院，2011.

作者單位

廣州賽寶認(rèn)證中心服務(wù)有限公司 廣東省廣州市 510000