為什么要分析需求

1.1、必要性

如果把測試活動比作軟件生命周期，測試需求分析就相當(dāng)于軟件的需求規(guī)格說明，測試策略相當(dāng)于軟件的架構(gòu)設(shè)計，測試用例相當(dāng)于軟件的詳細(xì)設(shè)計，測試執(zhí)行相當(dāng)于軟件的編碼過程。所以整個測試活動的依據(jù)來源于測試需求，測試需求分析是整個測試活動環(huán)節(jié)必不可少的環(huán)節(jié)。需求分析越詳細(xì)越精準(zhǔn)，表明對所測軟件的了解越深，對所要進(jìn)行的任務(wù)內(nèi)容越清晰，就更有把握保證測試的質(zhì)量和進(jìn)度。

1.2、不做的后果

• 時間&資源的浪費，實現(xiàn)了用戶不需要的需求。

• 重復(fù)需求的遺漏，降低客戶滿意度。

• 錯誤預(yù)估工作量，延誤發(fā)布周期，可能降低發(fā)布質(zhì)量。

1.3、測試及早介入原則

根據(jù)統(tǒng)計表面，在軟件開發(fā)生命周期早期引入的錯誤占軟件過程中出現(xiàn)所有錯誤（包括最終的缺陷）數(shù)量的50%~60%。此外，缺陷存在放大趨勢，如需求階段的一個錯誤可能會導(dǎo)致N個設(shè)計的錯誤。因此，越是測試后期，為修復(fù)缺陷所付出的代價就會越大。所以，軟件測試人員要盡早且不斷地進(jìn)行軟件測試（測試左移思想），以提高軟件質(zhì)量，降低軟件開發(fā)成本。

1.4、需求分類

一般需求分為業(yè)務(wù)需求、用戶需求、功能需求：

• 業(yè)務(wù)需求：業(yè)務(wù)需求描述了組織為什么要開發(fā)一個系統(tǒng)，即組織希望達(dá)到的目。業(yè)務(wù)需求通常來自項目投資人、購買產(chǎn)品的客戶、實際用戶管理者、組織內(nèi)部市場營銷部門或業(yè)務(wù)部門根據(jù)自己的業(yè)務(wù)需求和后續(xù)策劃的活動方法所整理記錄成的需求文檔，這份文檔有時也被稱作項目輪廓圖或市場需求文檔。

• 用戶需求：描述的是用戶的目標(biāo)，是用戶能通過這個產(chǎn)品在什么場景（什么情況下）能完成什么動作（做什么）。例如：軟件的界面是否好看、功能使用便捷等。用戶需求可以認(rèn)可為業(yè)務(wù)需求的一個具體目標(biāo)。

• 功能需求：規(guī)定開發(fā)人員必須在產(chǎn)品中實現(xiàn)的軟件功能，用戶利用這些功能來完成任務(wù)，滿足業(yè)務(wù)需求。功能需求也被稱為行為需求，功能需求是去解決業(yè)務(wù)需求、用戶需求的具體解決方案。也就是通常所說的需求說明書（通常由軟件開發(fā)方編寫，一般為產(chǎn)品經(jīng)理，使得用戶和軟件開發(fā)方都對軟件的初始規(guī)定有一個共同的理解，是整個開發(fā)的基礎(chǔ)），對用戶需求做具體的分析、提出實施方案。

什么是測試需求

2.1、概述

測試需求通常是以功能需求為基礎(chǔ)，通過對功能需求的細(xì)化和分解，形成可測內(nèi)容。

2.2、范圍

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

2.3、目的

測試需求用于解決“測什么”的問題，即指明被測對象中什么需要測試。測試需求分析主要用于：

• 明確需求的范圍

• 明確每一個功能的業(yè)務(wù)處理過程

• 明確不同功能點業(yè)務(wù)組合

• 挖掘顯式需求背后的隱式需求

測試需求的特征

3.1測試需求的特征

• 測試需求必須是可核實的，即必須有一個可觀察、可評測的結(jié)果，無法核實的需求不是測試需求。

• 測試需求應(yīng)指明滿足需求的正常前置條件，同時也要指明不滿足需求時的出錯條件。

• 測試需求不涉及具體的測試數(shù)據(jù)，測試數(shù)據(jù)設(shè)計是在測試用例設(shè)計環(huán)節(jié)解決的問題。

3.2測試需求的重要性

• 測試需求是編寫測試用例的重要依據(jù)。

• 測試需求有助于保障測試的質(zhì)量和進(jìn)度。

• 衡量測試覆蓋率的重要指標(biāo)。

測試需求和功能需求關(guān)系

測試需求和功能需求的關(guān)系

功能需求：系統(tǒng)應(yīng)該做什么。例如ATM取款機(jī)的業(yè)務(wù)需求：每次取款額度在100-2000之間；取款金額為100的倍數(shù)；每日取款總額不得超過20000，這是功能需求。

測試需求：系統(tǒng)應(yīng)該做什么、系統(tǒng)不應(yīng)該做什么、發(fā)現(xiàn)系統(tǒng)設(shè)計中存在的問題。例如取款金額可選在100-2000之間且為100倍數(shù)可??；小于100或者大于2000不可取；在100-2000之間但不是100倍數(shù)不可??；當(dāng)日取款總額必須小于等于20000；取款金額必須小于等于賬戶余額等等，這是測試需求。

如何開展測試需求分析

5.1、概述

開展測試需求分析的前提是要明確業(yè)務(wù)需求、用戶需求、功能需求以及需求的背景、場景。測試流程各環(huán)節(jié)都應(yīng)該與此保持一致。

5.2、測試需求采集

測試需求采集是將需求規(guī)格說明書（不限于）中具有可測試性的需求或特性提取出來，形成原始測試需求。（可測試性：指提取的需求或特性必須存在一個明確的期望結(jié)果，通過某種方法可以對期望結(jié)果進(jìn)行驗證是否符合文檔中的要求。）

測試需求采集方法：

• 通過列表的形式（excel）對軟件開發(fā)需求進(jìn)行梳理，形成原始需求列表，列表內(nèi)容可包含需求標(biāo)識、原始測試需求描述、信息來源等。

• 軟件需求說明書對應(yīng)的開發(fā)文檔及章節(jié)號可作為原始測試需求標(biāo)識。

• 軟件需求說明書的描述作為原始測試需求的描述。

• 軟件需求說明書的來源信息可作為原始測試需求的信息來源。

• “去重”（刪除列表中重復(fù)的、冗余的原始測試需求描述）、“細(xì)化”（對太簡略的原始測試需求描述進(jìn)行細(xì)化）、“合并”（若有類似的原始測試需求需要對其進(jìn)行合并）

5.3、測試需求分析流程

需求項整理：可通過上方需求采集方法進(jìn)行需求項的整理，測試方還需要與項目組確認(rèn)功能需求的優(yōu)先級或重要程度，并對其達(dá)成一致，此為產(chǎn)品質(zhì)量等級目標(biāo)的重要依據(jù)之一。但不是所有項目需求都是清晰的、有需求說明書的，可能會遇到以下幾種情況：

• 有詳細(xì)的需求文檔：一般情況下，比較嚴(yán)謹(jǐn)?shù)捻椖繄F(tuán)隊都會有詳細(xì)的需求說明書文檔，這種情況我們只需要詳細(xì)閱讀需求文檔來進(jìn)行需求項的整理和測試點的提取工作。對于需求不明確的地方可以直接找項目負(fù)責(zé)人（一般為項目經(jīng)理）進(jìn)行溝通，做到對需求整體的把握和理解，利于更好的進(jìn)行測試。

• 需求文檔不明確，即有文檔但文檔粗糙：如果開發(fā)團(tuán)隊很配合，可以要求開發(fā)或者需求分析人員完善需求文檔；如果時間緊張無法完善需求文檔，測試人員需將文檔中每一處不理解的地方和開發(fā)溝通清楚，切忌不要含糊不清的測試。

• 沒有需求文檔：可以直接通過與項目經(jīng)理、開發(fā)等進(jìn)行溝通、詢問、收集、梳理、理解需求，自己寫一個概要的需求描述，進(jìn)行評審，讓各方確認(rèn)需求描述是否符合業(yè)務(wù)、用戶、功能需求，使研發(fā)和測試方對需求的理解達(dá)成一致。

測試點整理：測試點的提取主要依據(jù)的是前面我們講到的六大質(zhì)量模型以及測試類型和測試方法，結(jié)合功能需求被測對象（功能點）進(jìn)行測試需求分析，就可以知道我們需要從哪些方面進(jìn)行測試，從而提取出測試點。測試點優(yōu)先級劃分一般分為高中低，功能場景為高，異常功能場景為中，非功能場景為低。后續(xù)測試用例可延用測試點的優(yōu)先級劃分。

• 顯性需求：顯而易見的，直觀的功能需求。

• 隱性需求：用戶也不能完全清晰的感受和用語言進(jìn)行描述的，需要結(jié)合業(yè)務(wù)、用戶、功能需求對需求進(jìn)行延伸，比如：用戶的顯性需求被滿足時，用戶不會感到驚喜和興奮；但精準(zhǔn)推送用戶想要的東西時，用戶會感到十分驚喜，這個過程，激發(fā)的用戶的隱性需求，隱性需求是培養(yǎng)用戶忠誠度的最好方式。

5.4、輸出測試需求跟蹤矩陣

測試需求跟蹤矩陣明確功能點與測試點的對應(yīng)關(guān)系，列出所有整理需求項的功能點與之對應(yīng)的測試點，同時需要包括測試類型以及優(yōu)先級&重要程度。

5.5、測試需求分析評審

測試需求分析產(chǎn)出的需求跟蹤矩陣需要與項目組進(jìn)行評審，需要各方達(dá)成一致。

總結(jié)

到此這篇關(guān)于軟件測試需求分析的文章就介紹到這了,更多相關(guān)軟件測試需求分析內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論