測試需求分析

測試需求分析目錄測試需求概要什么是測試需求測試需求的特征為什么需要測試需求測試需求分析過程測試需求采集測試需求分析測試需求評審2需求?背景：馮大勇吃魚時(shí)嗓子被魚刺卡住了?，F(xiàn)在正坐在椅子上候診。?大夫：（在桌上拿起一份掛號單，大聲的喊）馮大勇！?馮大勇：（病怏怏的樣子，邊走邊咳嗽）我是。?大夫：怎么了？（低頭整理手中的資料，自言自語，并打手勢，示意馮大勇坐下）?馮大勇：我...咳嗽...我今天...咳嗽...?大夫：不用說了，我知道了。（從桌子下面拿出一個(gè)大盒子，放在桌子上）

我看你適合吃這種藥。這是本院獨(dú)家開創(chuàng)的哮喘新藥“咽喉糖漿”，療程短，見效快，一個(gè)療程吃3盒，平均每天只需花費(fèi)3塊錢。給你先開6盒吧！（邊說邊開藥方）?馮大勇非常驚訝地瞪大眼睛并止不住地彎腰大聲咳嗽，以至于把魚刺都咳出來了。馮大勇從口里掏出一條巨型魚刺，遞給醫(yī)生。醫(yī)生見到魚刺先是吃驚，而后又非常尷尬。測試需求主要解決“測什么”的問題，即細(xì)化被測對象。測試需求通常是以軟件開發(fā)需求為基礎(chǔ)進(jìn)行分析，通過對開發(fā)需求的細(xì)化和分解，形成可測試的內(nèi)容。測試需求應(yīng)全部覆蓋已定義的業(yè)務(wù)流程，以及功能和非功能方面的需求。4什么是測試需求？什么是需求

需求是產(chǎn)品必須完成的事以及必須具備的品質(zhì)。分類：顯式需求：明確定義的一系列約束軟件實(shí)現(xiàn)的要求。隱式需求：并不是需求設(shè)計(jì)人員特意隱藏，更多的是由理解人員對某方面專業(yè)知識，或?qū)Ξa(chǎn)品的業(yè)務(wù)了解程度有限導(dǎo)致的。5需求分析沒有做好的后果一般會有下列現(xiàn)象：浪費(fèi)時(shí)間和資源來滿足用戶并不需要的需求（過度實(shí)現(xiàn)一些功能）總是需要比較長的時(shí)間來達(dá)成對產(chǎn)品設(shè)計(jì)的共識員工會厭倦因需求不斷被重新解釋而導(dǎo)致的返工不穩(wěn)定的產(chǎn)品，用戶的不滿意對我們未來的市場造成損失開發(fā)出來的產(chǎn)品技術(shù)上先進(jìn)，但并不滿足用戶需求在產(chǎn)品設(shè)計(jì)，開發(fā)和測試對于用戶需求的解釋不一致未說明的或不正確的需求

會導(dǎo)致員工與用戶間的不滿浪費(fèi)時(shí)間，增加成本，使得在一些投標(biāo)的項(xiàng)目中不能低價(jià)需求分析的重要性如果你在編碼的時(shí)候發(fā)現(xiàn)某幾行有誤，那么改掉這幾行就行了。而如果在編碼階段發(fā)現(xiàn)需求有誤，那么你很可能需要改變所有代碼來適應(yīng)新的需求在需求階段消除問題的代價(jià)最小，而如果需求問題等到產(chǎn)品發(fā)布出去后才發(fā)現(xiàn)的話，那修復(fù)的成本就會N倍的增加。穩(wěn)定的需求是軟件開發(fā)的關(guān)鍵。有了穩(wěn)定的需求，軟件開發(fā)工作可能從結(jié)構(gòu)設(shè)計(jì)到詳細(xì)設(shè)計(jì)到代碼到測試都會平穩(wěn)順利的進(jìn)行。開頭錯(cuò)-----》全盤錯(cuò)-----》全盤輸如何進(jìn)行需求分析一般可以從三個(gè)方面去考慮：1.功能需求2.非功能性需求3.限制條件了功能性需求功能性需求是產(chǎn)品必須完成的那些事，要求一定的功能和品質(zhì)。例：

培訓(xùn)機(jī)構(gòu)的班主任可以給所在班級學(xué)員打考勤9非功能性需求非功能性需求是產(chǎn)品必須具備的屬性或品質(zhì)。諸如觀感、可用性、安全性和法律限制等。例：平臺用戶數(shù)為5萬人,每天登錄用戶數(shù)為1000左右，網(wǎng)絡(luò)的帶寬為100M帶寬。在工作時(shí)間根據(jù)資料名稱條件進(jìn)行搜索，可以在3秒內(nèi)得到搜索結(jié)果。這類需求通常在產(chǎn)品的功能確定之后，一旦知道了產(chǎn)品要做的事情，就可以確定它的行為方式，它需要具備什么品質(zhì)以及它的響應(yīng)速度、可用性、可讀性和安全性。10限定條件限制條件是全局性的需求。它們可以是對項(xiàng)目本身的限制,或是對產(chǎn)品最終設(shè)計(jì)的限制。

例：南京平臺必須在2010年開學(xué)的第一學(xué)期上線

客戶是在說，如果顧客不能在給定的時(shí)間前使用該產(chǎn)品，那么它就沒有什么用了。其效果是需求分析師必須對需求進(jìn)行限制，只包括那些在最后期限前能夠提供最大價(jià)值的需求。需求分析的步驟熟悉需求背景及商業(yè)目標(biāo)：1)了解清楚項(xiàng)目發(fā)起的原因，是為了解決用戶的什么問題。2)當(dāng)前的解決方案是不是最優(yōu)的，為什么會這樣做？業(yè)務(wù)模型法：

1)考慮本項(xiàng)目與外部系統(tǒng)的交互，劃分系統(tǒng)邊界（除了本項(xiàng)目的需求中要求做的事情，其他的都可以是外部系統(tǒng)，本系統(tǒng)和外部系統(tǒng)之間的交互就是系統(tǒng)的邊界），可以參考系統(tǒng)分析說明書。

2)確定測試范圍和關(guān)注點(diǎn)。系統(tǒng)的邊界是測試的重點(diǎn)，特別需要關(guān)注邊界交互時(shí)的數(shù)據(jù)交互13需求審查點(diǎn)易讀性二義性一致性統(tǒng)一性是否存在需求過度或不合理測試人員在需求階段應(yīng)做哪些工作用戶的需求是否恰當(dāng)?shù)拿枋鋈绻磺‘?dāng)，那么是否要確認(rèn)——這里存在一個(gè)隱患，用戶可能會在開發(fā)的后期突然要求讓你的需求變動(dòng)，所以要事先明確好一.是用戶是否真的能正確地描述自己的需求；二.是需求人員是否真的能正確地理解需求。三.是需求文檔被正確的撰寫制定的測試需求項(xiàng)必須是可核實(shí)的。即它們必須有一個(gè)可觀察、可評測的結(jié)果，無法核實(shí)的需求不是測試需求；即-期望輸出。測試需求應(yīng)指明滿足需求的正常的前提條件，同時(shí)也要指明不滿足需求時(shí)的出錯(cuò)條件。測試需求不涉及具體的測試數(shù)據(jù)，測試數(shù)據(jù)設(shè)計(jì)是測試設(shè)計(jì)(用例設(shè)計(jì))環(huán)節(jié)應(yīng)解決的內(nèi)容。16測試需求的特征軟件測試需求是開發(fā)測試用例的依據(jù)。有助于保證測試的質(zhì)量與進(jìn)度。測試需求是衡量測試覆蓋率的重要指標(biāo)。17為什么需要測試需求測試需求分析過程a）對原始測試需求列表中列出的每一條開發(fā)需求，形成可測試的分層描述的測試要點(diǎn)；b）對步驟a）所確定的測試要點(diǎn)，分析測試執(zhí)行時(shí)需要實(shí)施的測試類型；d）建立測試需求跟蹤矩陣，對測試需求進(jìn)行管理。測試需求分析需求采集的過程是將軟件開發(fā)需求中的那些具有可測試性的需求或特性提取出來，形成原始測試需求。一句話定義：可測試性是指這些提取的需求或特性必須存在一個(gè)可以明確預(yù)知的結(jié)果(期望輸出)，可以用某種方法對這個(gè)明確的結(jié)果進(jìn)行判斷(實(shí)際輸出)、驗(yàn)證，驗(yàn)證是否符合文檔中的要求。需求采集需求采集的提取方法：a)通過列表的形式對軟件開發(fā)需求進(jìn)行梳理，形成原始測試需求列表，列表的內(nèi)容包括需求標(biāo)識、原始測試需求描述、信息來源。b)需求標(biāo)識：產(chǎn)品版本號/功能模塊版本號/LOGOc)將每一條軟件需求對應(yīng)的開發(fā)文檔及章節(jié)號作為軟件需求標(biāo)識。d)使用軟件需求的簡述作為原始測試需求描述。e)軟件需求獲取的來源信息作為信息來源。需求采集提取的原始測試需求中，可能存在重復(fù)和冗余，在提取原始測試需求過程中，可以通過以下方法整理原始測試需求：a）刪除：刪除原始測試需求表中重復(fù)的、冗余的含有包含關(guān)系的原始測試需求描述；b）細(xì)化：對太簡略的原始測試需求描述進(jìn)行細(xì)化；c）合并：如果有類似的原測試始需求，在整理時(shí)需要對其進(jìn)行合并。需求采集“人力資源管理系統(tǒng)”原始測試需求表序號軟件需求標(biāo)識原始測試需求描述信息來源13.1.1基本信息管理增加員工信息人事部門招聘專員對于新招聘的職員信息可以錄入到HRMIS系統(tǒng)中，主要職員信息如下：姓名、性別、出生日期、政治面貌、文化水平、婚姻情況、家庭住址、身份證號、辦公電話、移動(dòng)電話、緊急情況下的聯(lián)系人和聯(lián)系方式、畢業(yè)院校、入職時(shí)間、崗位及職責(zé)，其中，性別包含男、女兩個(gè)類別；婚姻情況包括未婚、已婚、離異三種情況。人力資源管理系統(tǒng)業(yè)務(wù)需求說明書刪除員工信息刪除需用戶確認(rèn)，可以逐條刪除或多條一次刪除GB/T17544-199823.2.2時(shí)間特性要求并發(fā)15個(gè)用戶，平均登錄時(shí)間小于10秒人力資源管理系統(tǒng)業(yè)務(wù)需求說明書3隱含需求：在使用中操作錯(cuò)誤的易恢復(fù)性程序應(yīng)對關(guān)鍵數(shù)據(jù)的操作給出警告或在執(zhí)行前確認(rèn)GB/T17544-1998需求采集---舉例測試需求分析測試要點(diǎn)是對原始測試需求表每一條開發(fā)需求的細(xì)化和分解，形成的可測試的分層描述的軟件需求。對開發(fā)需求的細(xì)化和分解具體包括：a）通過分析每條開發(fā)需求描述中的輸入、輸出、處理、限制、約束等，給出對應(yīng)的驗(yàn)證內(nèi)容；b）通過分析各個(gè)功能模塊之間的業(yè)務(wù)順序，和各個(gè)功能模塊之間傳遞的信息和數(shù)據(jù)（功能交互分析），對存在功能交互的功能項(xiàng)，給出對應(yīng)的驗(yàn)證內(nèi)容。）測試要點(diǎn)分析功能交互分析測試要點(diǎn)分析進(jìn)行細(xì)化和分解還需考慮：a）需求的完整性，經(jīng)過分解獲得的需求必須能夠充分覆蓋軟件需求的各種特征（包括隱含的特征），每個(gè)需求必須可以獨(dú)立完成有意義的功能或功能組合，可以進(jìn)行單獨(dú)測試；b）需求的規(guī)模，每個(gè)最低層次的需求能夠使用數(shù)量相當(dāng)?shù)臏y試用例來實(shí)現(xiàn)。測試要點(diǎn)分析測試要點(diǎn)分析---舉例不同的質(zhì)量子特性可以確定出不同的測試內(nèi)容，這些測試內(nèi)容可以通過不同的測試類型來實(shí)施。軟件測試可以劃分為以下測試類型：功能測試、安全性測試、接口測試、容量測試、完整性測試、結(jié)構(gòu)測試、用戶界面測試、負(fù)載測試、壓力測試、疲勞強(qiáng)度測試、恢復(fù)性測試、配置測試、兼容性測試、安裝測試等。根據(jù)質(zhì)量子特性的定義，以及各測試類型的測試內(nèi)容，可以分析出質(zhì)量子特性與測試類型的對應(yīng)關(guān)系。分析測試類型質(zhì)量子特性和測試類型的對應(yīng)關(guān)系基準(zhǔn)表

分析測試類型分析測試類型---舉例分析測試類型---舉例為了避免遺漏，在確定測試類型時(shí)，還需考慮：a）文檔中是否包含測試類型相對應(yīng)的情況的說明；b）列出的常見測試類型是否已完全覆蓋了被測軟件；c）被測軟件的某些特殊情況是否已包含在所列出的測試類型中。分析測試類型建立測試需求跟蹤矩陣，對測試需求進(jìn)行管理。將上述步驟分析、確定的開發(fā)需求、測試需求、測試類型填入測試跟蹤需求矩陣。測試需求跟蹤矩陣為原始測試需求與測試要點(diǎn)的對應(yīng)關(guān)系表，格式如下：測試需求跟蹤矩陣建立測試需求跟蹤矩陣，對測試需求進(jìn)行管理。將上述步驟分析、確定的開發(fā)需求、測試需求、測試類型填入測試跟蹤需求矩陣。通過測試需求跟蹤矩陣的方式對需求變更實(shí)施。軟件需求一旦發(fā)生變化，就要對需求跟蹤表進(jìn)行維護(hù)，啟動(dòng)配置管理過程，將與軟件需求變更相關(guān)的內(nèi)容進(jìn)行同步變更。測試需求跟蹤矩陣增加培訓(xùn)信息測試需求跟蹤矩陣---舉例增加培訓(xùn)信息測試需求跟蹤矩陣---舉例測試需求跟蹤矩陣需要不斷的維護(hù)。

a）一方面，軟件需求一旦發(fā)生變化，應(yīng)啟動(dòng)配置管理過程，將與軟件需求變更相關(guān)的內(nèi)容進(jìn)行同步變更；b）另一方面，隨著測試工作的進(jìn)行，會不斷添加新的跟蹤內(nèi)容，對跟蹤表進(jìn)行擴(kuò)展。例如，測試設(shè)計(jì)階段的測試用例、測試執(zhí)行階段的測試記錄和測試缺陷都可以添加到跟蹤矩陣中。測試需求跟蹤距陣評審的內(nèi)容：a）完整性審查：應(yīng)保證測試需求能充分覆蓋軟件需求的各種特征，重點(diǎn)關(guān)注功能要求、數(shù)據(jù)定義、接口定義、性能要求、安全性要求、可靠性要求、系統(tǒng)約束等方面，同時(shí)還應(yīng)關(guān)注是否覆蓋開發(fā)人員遺漏的、系統(tǒng)隱含的需求；b）準(zhǔn)確性審查：應(yīng)保證所描述的內(nèi)容能夠得到關(guān)各方的一致理解，各項(xiàng)測試需求之間沒有矛盾和沖突，各項(xiàng)測試需求在詳盡程度上保持一致，每一項(xiàng)測試需求都可以作為測試用例設(shè)計(jì)的依據(jù)。測試需求評審評審的形式a）相互評審、交叉評審：甲和乙在一個(gè)項(xiàng)目組，處在一個(gè)領(lǐng)域，但工作內(nèi)容不同，甲的工作成果交給乙審查，乙的工作成果交給甲審查。相互評審是最不正式的一種評審形式，但應(yīng)用方便、有效。測試需求評審b）小組評審：通過正式的小組會議完成評審工作，是有計(jì)劃的和結(jié)構(gòu)化的評審方式。評審定義了評審會議中的各種角色和相應(yīng)的責(zé)任，所有參與者在評審會議的前幾天就拿到了評審材料，并對該材料進(jìn)行了獨(dú)立研究。測試需求評審需求內(nèi)審需求文檔內(nèi)審問題反饋需求內(nèi)審團(tuán)隊(duì)整理問題反饋需求宣講及問題回復(fù)整改需求需求外審基線需求文檔整理問題反饋內(nèi)審需求文檔整理問題反饋需求負(fù)責(zé)人評審的形式

a）審查：審查和小組評審很相似，但更為嚴(yán)格，是最系統(tǒng)化、最嚴(yán)密的評審形式，包含了制定計(jì)劃、準(zhǔn)備和組織會議、跟蹤和分析審查結(jié)果等。測試需求評審評審的