測試需求分析與測試計劃

章測試需求分析與測試計劃2021/5/91目錄測試目標(biāo)和準(zhǔn)則1測試需求分析2測試項目的估算與進(jìn)度安排3測試風(fēng)險和測試策略4測試計劃的內(nèi)容與編制52021/5/921測試目標(biāo)和準(zhǔn)則2021/5/931.測試的目標(biāo)明確測試目標(biāo)是測試需求分析和計劃測試的前提測試目標(biāo)向風(fēng)險管理活動提供信息提供軟件系統(tǒng)質(zhì)量有關(guān)信息評估軟件產(chǎn)品是否滿足相關(guān)利益者的期望評估缺陷修正（清除）而不帶來負(fù)面效應(yīng)評估軟件變更實施而不帶來負(fù)面效應(yīng)評估軟件是否完全符合合規(guī)性要求2021/5/941.測試的目標(biāo)項目的具體測試目標(biāo)提供哪些質(zhì)量風(fēng)險信息新改動的業(yè)務(wù)是否正確實現(xiàn)，對已有業(yè)務(wù)是否有負(fù)面影響是否滿足功能性要求和非功能性要求在測試覆蓋率、測試效率上的具體要求2021/5/951.測試的目標(biāo)如何確定測試目標(biāo)哪些業(yè)務(wù)改動，會影響哪些已有業(yè)務(wù)？系統(tǒng)改動會影響哪些系統(tǒng)功能和非功能特性？測試覆蓋率：新業(yè)務(wù)/功能？已有業(yè)務(wù)/功能呢?如何最大程度提高測試效率？2021/5/962.測試進(jìn)入的準(zhǔn)則清楚了解項目的整體計劃框架；完成需求規(guī)格說明書評審；技術(shù)知識或業(yè)務(wù)知識的儲備；標(biāo)準(zhǔn)環(huán)境技術(shù)設(shè)計文檔；足夠的資源；人員組織結(jié)構(gòu)及其責(zé)任已確定。2021/5/972測試需求分析2021/5/981.測試需求什么是測試需求？簡單來說，測試需求就是確定在項目中需要測試什么，即細(xì)化被測對象。測試需求通常是以軟件開發(fā)需求為基礎(chǔ)進(jìn)行分析，通過對開發(fā)需求的細(xì)化和分解，形成可測試的內(nèi)容。測試需求應(yīng)全部覆蓋已定義的業(yè)務(wù)流程，以及功能和非功能方面的需求。測試需求描述測試的目標(biāo)，特別是描述了產(chǎn)品的質(zhì)量需求，測試需求分析目的是幫助定義測試對象和測試范圍，發(fā)現(xiàn)軟件需求中不完善和不明確的地方并加以完善以節(jié)省測試時間的投入，便于軟件需求基線化和跟蹤業(yè)務(wù)需求的變更。2021/5/991.測試需求為什么要做測試需求分析測試需求是測試計劃的基礎(chǔ)與依據(jù)，我們在測試活動中，首先需要明確測試需求（What），才能決定怎么測（How），測試時間（When），需要多少人（Who），測試的環(huán)境是什么（Where）。是衡量測試覆蓋率的重要指標(biāo)。

2021/5/9101.測試需求測試需求分析意味著什么確定測試范圍測試項和測試子項測試優(yōu)先級測試風(fēng)險2021/5/9112.測試需求分析過程熟悉需求需求項整理提取出測試點測試點細(xì)化確定測試范圍制定測試策略2021/5/9123.測試需求分析的基本方法無論是功能測試，還是非功能性測試，其測試需求的分析都有以下兩個基本的出發(fā)點（1）從客戶角度進(jìn)行分析：通過業(yè)務(wù)流程、業(yè)務(wù)數(shù)據(jù)、業(yè)務(wù)操作等分析，明確要驗證的功能、數(shù)據(jù)、場景等內(nèi)容，從而確定業(yè)務(wù)方面的測試需求。（2）從技術(shù)角度分析：通過研究系統(tǒng)架構(gòu)設(shè)計、數(shù)據(jù)庫設(shè)計、代碼實現(xiàn)等，分析其技術(shù)特點，了解設(shè)計和實現(xiàn)要求，包括系統(tǒng)穩(wěn)定可靠、分層處理、接口集成、數(shù)據(jù)結(jié)構(gòu)、性能等方面的測試需求。2021/5/9134.測試需求的分析技術(shù)在軟件測試需求分析過程中，可以借助下列途徑來達(dá)到良好的分析效果：（1）通過提煉，抓住主要線索，或作為整體來進(jìn)行分析，使測試需求分析簡單化。（2）通過業(yè)務(wù)需求或功能層次的整理，使測試需求分析結(jié)構(gòu)化、層次化。（3）通過繪制業(yè)務(wù)流程圖、數(shù)據(jù)流程圖等，使測試需求分析可視化。（4）通過類比、隱喻，加強(qiáng)用戶需求的理解，更好地轉(zhuǎn)化為測試需求。2021/5/9144.測試需求的分析技術(shù)在測試需求分析時，產(chǎn)品本身往往處于需求分析和設(shè)計過程中，靜態(tài)分析技術(shù)是常用的分析技術(shù)。靜態(tài)分析技術(shù)包括如下通過系統(tǒng)建模語言（SysML）的需求圖，可以更好地分析各項需求之間的關(guān)系，比較容易確定測試需求的邊界。通過狀態(tài)圖、活動圖更容易列出的測試場景，了解狀態(tài)轉(zhuǎn)換的路徑和條件，哪些是重要測試場景等。實體關(guān)系圖可以明確測試的具體對象（實體）及其之間的關(guān)系，進(jìn)行相關(guān)分析。2021/5/9154.測試需求的分析技術(shù)魚骨圖法、思維導(dǎo)圖等，有一個清晰的分析思維過程，迅速展開測試需求，隨時補(bǔ)充測試需求等。代碼復(fù)雜度靜態(tài)分析工具，代碼越復(fù)雜，測試的投入也需要越多。還可以用一些普通工具，如檢查表。腦力激蕩法，讓大家發(fā)散思維，相互啟發(fā)，讓任何測試需求不會被錯過。2021/5/9165.功能測試范圍分析在分析測試范圍時，一般先進(jìn)行功能測試的范圍分析，然后再進(jìn)行非功能性測試的范圍分析。對于功能測試，可以借助業(yè)務(wù)流程圖、功能框圖等來幫助我們進(jìn)行測試的需求分析。在面向?qū)ο蟮能浖_發(fā)中，也可借助UML用例圖、活動圖、協(xié)作圖和狀態(tài)圖來進(jìn)行功能測試范圍分析。2021/5/9175.功能測試范圍分析GoogleTalk2021/5/9186.非功能性的系統(tǒng)測試需求對于非功能性的系統(tǒng)測試，主要目的是驗證軟件系統(tǒng)的整體性能等是否滿足其產(chǎn)品設(shè)計規(guī)格所指定的要求，涉及非功能性的質(zhì)量需求有系統(tǒng)性能、安全性、兼容性、擴(kuò)充性等的測試對于每一個應(yīng)用軟件系統(tǒng)，非功能特性的質(zhì)量需求都是存在的，這類測試需求會因不同的項目類型差異比較大，這些需求的程度、重要性不同，因此要求為非功能性測試需求設(shè)置優(yōu)先級系統(tǒng)非功能性測試的需求在不同應(yīng)用領(lǐng)域也體現(xiàn)較大差異。如網(wǎng)上銀行、信用卡服務(wù)等系統(tǒng)，其安全性、可用性和可靠性等多方面的測試至關(guān)重要，因為這方面的缺陷很可能會給用戶造成較大的損失。這些系統(tǒng)需要得到充分的安全性測試、容錯性測試和負(fù)載測試。2021/5/9196.非功能性的系統(tǒng)測試需求對于局域網(wǎng)內(nèi)的企業(yè)級應(yīng)用來說，有關(guān)權(quán)限控制、口令設(shè)置等安全性測試依然重要，但兼容性測試就相對簡單對于企業(yè)級應(yīng)用系統(tǒng)來說，存在著不同的應(yīng)用模式，其系統(tǒng)的架構(gòu)也不一樣，可以分為“以功能為中心、以數(shù)據(jù)庫為中心和以業(yè)務(wù)邏輯（工作流）為中心”等，在進(jìn)行系統(tǒng)測試時，所設(shè)定的目標(biāo)也有一定的區(qū)別。2021/5/9203測試項目的估算與進(jìn)度安排2021/5/9211.測試工作量估算測試工作量是根據(jù)測試范圍、策劃任務(wù)和開發(fā)階段來確定的，測試范圍和測試任務(wù)是測試工作量估算的主要依據(jù)。測試任務(wù)由質(zhì)量需求、測試目標(biāo)決定測試范圍由產(chǎn)品（新）功能特性或測試任務(wù)決定。代碼質(zhì)量越低，測試越要充分，回歸測試次數(shù)與頻率加大。處在不同的開發(fā)階段測試工作量不同。自動化程度高，測試工作量就越低。針對不同的應(yīng)用領(lǐng)域、技術(shù)、編程語言，其估算方法不同。2021/5/9221.測試工作量估算工作量估算過程2021/5/9232.估算方法工作分解結(jié)構(gòu)表方法功能點方法、對象點方法代碼行預(yù)估歷史數(shù)據(jù)推算（相似規(guī)模、同類型）經(jīng)驗法（資深人員或?qū)＜倚〗M）綜合方法2021/5/9243.工作分解結(jié)構(gòu)表方法WBS測試工作量的估算依賴于測試任務(wù)的細(xì)化，對每項測試任務(wù)進(jìn)行分解，然后根據(jù)分解的子任務(wù)進(jìn)行估算。通常分解粒度越小，估算精度越高列出本項目需要完成的各項任務(wù)：測試計劃、需求和設(shè)計評審、測試設(shè)計、腳本開發(fā)、測試執(zhí)行等。對每個任務(wù)進(jìn)一步細(xì)分，可進(jìn)行多層次的細(xì)分，直到不能細(xì)分為止。這建立在對于每一階段工作的細(xì)致把握。列出需要完成的所有任務(wù)之后，根據(jù)任務(wù)的層次給進(jìn)行編號，就形成了完整的工作分解結(jié)構(gòu)表。2021/5/9253.工作分解結(jié)構(gòu)表方法WBS工作分解結(jié)構(gòu)表2021/5/9264.功能點估算法功能點是其中一個比較可靠的工作量估算方法，它先估算每個功能點所需要的工作量，然后進(jìn)行累加獲得總的工作量借助分解結(jié)構(gòu)表（WBS）方法來分解功能國際功能點用戶組(IFPUG)頒布的標(biāo)準(zhǔn)方法主要參數(shù)有：外部輸入數(shù)、外部輸出數(shù)、內(nèi)部邏輯文件、外部接口文件和外部查詢數(shù)詳細(xì)參考功能點實用手冊(FunctionPointCountingPracticesManualRelease4.1,1999)2021/5/9274.功能點估算法AFP(調(diào)整后功能點)=UFP(未調(diào)整功能點數(shù)目)*AF(影響因子)外部輸入數(shù)(EI：externalinput)外部輸出數(shù)(EO：externaloutput)外部查詢數(shù)(EQ：externalquery)內(nèi)部邏輯文件(ILF：internallogicalfile)外部接口文件(EIF：externalinterfacefile)2021/5/9285.測試用例估算法依據(jù)測試用例數(shù)來估算測試工作量，例如用功能模塊所有要執(zhí)行的測試用例總數(shù)，除以每個人日所能執(zhí)行的測試用例平均數(shù)，就得出人日數(shù)工作量估算，往往基于其它一些假定效率假設(shè)，即測試隊伍的工作效率測試假設(shè)，為了驗證一個測試需求所需測試動作的數(shù)目，可能包括每個測試用例的估算時間風(fēng)險假定?？紤]增加10%～20%的工作量來處理風(fēng)險產(chǎn)生的不確定性2021/5/9296.相對比例估算法如果確實沒有任何可行的辦法，就可以按照測試人員和開發(fā)人員的比例來確定大致可以分為3類，其比例分別是1:2、1:1、2:12021/5/9307.總工作量W＝Wo+WoⅹR1+WoⅹR2+WoⅹR3W為總工作量，Wo為一輪測試所需的工作量R1，R2，R3為每輪的遞減系數(shù)。受代碼質(zhì)量、開發(fā)流程和測試周期等影響，R1、R2、R3的值是不同的2021/5/9314測試風(fēng)險和測試策略2021/5/9321.測試風(fēng)險軟件測試存在較高的風(fēng)險，測試風(fēng)險管理就是設(shè)法降低或緩解測試過程中的風(fēng)險，包括確定哪些風(fēng)險是可以避免的、可以采取哪些措施等。風(fēng)險識別的有效方法就是建立風(fēng)險項目檢查表此前，歷史資料、Brainstorming等幫助建立項目檢查表風(fēng)險識別并確定其程度，給出預(yù)防或處理措施。2021/5/9331.測試風(fēng)險風(fēng)險項目檢查表2021/5/9341.測試風(fēng)險風(fēng)險項目檢查表2021/5/9352.控制風(fēng)險的對策消除執(zhí)行風(fēng)險降低進(jìn)度風(fēng)險減少人員風(fēng)險2021/5/9362.控制風(fēng)險的對策風(fēng)險管理2021/5/9372.控制風(fēng)險的對策風(fēng)險的控制方法采取措施避免可以避免的風(fēng)險。高風(fēng)險轉(zhuǎn)移為低風(fēng)險。設(shè)法降低不可避免的風(fēng)險做好風(fēng)險管理計劃。制定處理風(fēng)險一些應(yīng)急、有效的方案。計劃時，對于估算資源、時間、預(yù)算留有余地制定文檔標(biāo)準(zhǔn)，建立機(jī)制，保證文檔及時產(chǎn)生。2021/5/9383.測試策略及其內(nèi)容測試策略描述當(dāng)前測試項目的目標(biāo)和所采用的測試方法，描述不同測試階段的測試對象、范圍和方法以及每個階段內(nèi)所要進(jìn)行的測試類型。針對風(fēng)險（工作量、時間等壓力）采取對策，包括遵照的標(biāo)準(zhǔn)取舍、測試任務(wù)的優(yōu)先級等如何更好地執(zhí)行測試用例以及后續(xù)的回歸測試選定使用測試技術(shù)和工具考慮影響資源分配的特殊情況2021/5/9393.測試策略及其內(nèi)容測試策略影響因素測試方式(靜態(tài)/動態(tài)，探索式方式，黑盒/白盒）測試層次（單元、集成、系統(tǒng)）測試人員（責(zé)任、能力、獨立性）測試用例選擇/優(yōu)化（如用例是否有優(yōu)先級）測試環(huán)境（設(shè)置是否簡單、自動部署）測試工具（能不能用測試工具、使用簡單與否）質(zhì)量標(biāo)準(zhǔn)（采用國內(nèi)標(biāo)準(zhǔn)或美國DO-178C）2021/5/9403.測試策略及其內(nèi)容制定測試策略全面細(xì)致地了解產(chǎn)品的項目信息:應(yīng)用領(lǐng)域,測試范圍,市場需求,產(chǎn)品的特點和主要功能,技術(shù)架構(gòu)基于模塊、功能、整體、系統(tǒng)、版本、壓力、性能、配置和安裝等各個因素對產(chǎn)品的影響,公正客觀地開展測試計劃根據(jù)程序的重要性和一旦發(fā)生故障將造成的損失,來確定它的測試等級和測試重點認(rèn)真研究測試策略,以便能使用盡可能少的有效測試用例,發(fā)現(xiàn)盡可能多的程序錯誤,因為一次完整的軟件測試過后,如果程序中遺漏的錯誤過多并且很嚴(yán)重,則表明本次測試是失敗的,是不足的;而測試不足意味著讓用戶承擔(dān)隱藏錯誤帶來的危險.同時反過來說,如果過度測試,則又會浪費許多寶貴的資源.找到一個最佳平衡點。2021/5/9415測試計劃內(nèi)容與編制2021/5/9421.測試計劃內(nèi)容軟件測試計劃是指導(dǎo)測試過程的綱領(lǐng)性文件，描述測試活動的范圍、方法、策略、資源、任務(wù)安排和進(jìn)度等，并確定測試項、哪些功能特性將被測試、哪些功能特性將無需測試，識別測試過程中的風(fēng)險。內(nèi)容主要集中在測試目標(biāo)和需求說明、測試工作量估算、測試策略、測試資源配置、進(jìn)度表、測試風(fēng)險等2021/5/9431.測試計劃內(nèi)容IEEE829－1998：測試計劃內(nèi)容測試計劃標(biāo)識符（文檔編號）項目總體情況簡介；測試項（testitem）；需要測試的功能；方法（策略）；不需要測試的功能；測試項通過/失敗的標(biāo)準(zhǔn)；測試中斷和恢復(fù)的規(guī)定；測試完成所提交的材料；測試任務(wù)；測試環(huán)境要求；測試人員職責(zé)；人員安排與培訓(xùn)需求；進(jìn)度表；潛在的問題和風(fēng)險；審批2021/5/9442.測試項目的計劃過程計劃初期是收集項目各類信息，理解用戶的真正需求確定測試需求和測試范圍起草計劃。內(nèi)部審查。計劃討論和修改。測試計劃的多方審查。測試計劃的定稿和批準(zhǔn)。。測試計劃的跟蹤。2021/5/9453.制定有效的測試計劃測試計劃的創(chuàng)建和評審MRD/PRDreview測試策略知識傳遞日程測試范圍反饋討論分析FormalReviewmeeting問題QAdraftofTestPlanUpdatedTestPlanFinalTestPlan測試方法任務(wù)UpdatedTestPlan資源Pear-to-PearorInternalReviewChecklist2021/5/9463.制定有效的測試計劃制定有效的測試計劃確定測試項目的任務(wù)，清楚測試范圍和測試目標(biāo)盡量識別出各種測試風(fēng)險，制定出相應(yīng)的對策讓所有合適的相關(guān)人員參與測試項目的計劃制定客觀、準(zhǔn)確、留有余地；制定測試項目的輸入、輸出和質(zhì)量標(biāo)準(zhǔn)識別出可變因素，建立變化處理和控制的流程規(guī)則不要忽視技術(shù)上的問題要對測試的公正性、遵照的標(biāo)準(zhǔn)做一個說明測試計劃應(yīng)簡潔、易讀并有所側(cè)重2021/5/9473.制定有效的測試計劃測試輸入/輸出標(biāo)準(zhǔn)