軟件測試方法與技術(shù)實(shí)踐指南-Java篇-課件

第二篇基于JavaEE產(chǎn)品線的項目實(shí)踐4第4章：項目初期各階段的主要工作第5章：軟件測試計劃的制定

第6章：軟件測試用例的編寫第7章：軟件項目各部門相互協(xié)作第8章：執(zhí)行測試案例并報告缺陷第9章：產(chǎn)品功能完善與修復(fù)缺陷階段第10章：測試工程師在產(chǎn)品發(fā)布前后的工作1ppt課件軟件生產(chǎn)的幾個主要階段（第4至10章從測試角度逐步展開）軟件生產(chǎn)流程：(本篇重點(diǎn))該圖能清晰看出軟件生產(chǎn)各環(huán)節(jié)開發(fā)與測試的主要工作學(xué)生需要清晰的知道每個英文代表的環(huán)節(jié)與意義本書所有章節(jié),以及軟件工程師的工作都是圍繞本圖展開2ppt課件第4章項目初期各階段的主要工作

項目立項與擬定產(chǎn)品的發(fā)展方向階段產(chǎn)品規(guī)格說明書制定階段產(chǎn)品技術(shù)文檔設(shè)計階段3ppt課件第4章項目初期各階段的主要工作

項目立項與擬定產(chǎn)品的發(fā)展方向階段產(chǎn)品需求文檔的形成及其實(shí)例產(chǎn)品需求文檔PRDPRD如何形成PRD的主要內(nèi)容與格式PRD實(shí)例介紹產(chǎn)品需求形成階段測試工程師需要做什么閱讀PRD中的詳細(xì)功能需求給PM反饋信息并協(xié)助PM去修改跟蹤提交的問題解決狀態(tài)4ppt課件IEEE軟件工程標(biāo)準(zhǔn)詞匯表定義需求為：用戶解決問題或達(dá)到目標(biāo)所需的條件或能力。系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力。一種反映上面(1)或(2)所描述的條件或能力的文檔說明。MerlinDorfman和RichardH.Thayer提出了一個包容且更為精練的定義：用戶解決某一問題或達(dá)到某一目標(biāo)所需的軟件功能。系統(tǒng)或系統(tǒng)構(gòu)件為了滿足合同、規(guī)約、標(biāo)準(zhǔn)或其他正式實(shí)行的文檔而必須滿足或具備的軟件功能。軟件的需求-需求的定義5ppt課件需求分析的任務(wù)：確定用戶需求，準(zhǔn)確地回答“系統(tǒng)必須做什么？”的問題，獲得需求規(guī)格說明書。軟件需求-需求分析的任務(wù)6ppt課件

業(yè)務(wù)需求（businessrequirement）客戶對系統(tǒng)的高層次的目標(biāo)要求。用戶需求（userrequirement）用戶使用產(chǎn)品必須要完成的任務(wù)功能需求（functionalrequirement）開發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，滿足業(yè)務(wù)需求非功能需求（non-functionalrequirement）對系統(tǒng)提供的服務(wù)或者功能提出的約束，包括時間、開發(fā)過程、軟件質(zhì)量、標(biāo)準(zhǔn)等約束軟件需求-需求類型7ppt課件需求獲取的內(nèi)容系統(tǒng)分析人員通過與用戶的交流、對現(xiàn)有系統(tǒng)的觀察及對任務(wù)進(jìn)行分析，確定：系統(tǒng)或產(chǎn)品范圍的限制性描述與系統(tǒng)或產(chǎn)品有關(guān)的人員及特征列表系統(tǒng)的技術(shù)環(huán)境的描述系統(tǒng)功能的列表及應(yīng)用于每個需求的領(lǐng)域限制一組描述不同運(yùn)行條件下系統(tǒng)或產(chǎn)品使用狀況的應(yīng)用場景為更好地定義需求而開發(fā)的任意原型。8ppt課件需求獲取方法與策略建立順暢的通信途徑訪談與調(diào)查觀察用戶操作流程組成聯(lián)合小組9ppt課件第4章項目初期各階段的主要工作產(chǎn)品規(guī)格說明書制定階段產(chǎn)品規(guī)格說明書的形成及其實(shí)例產(chǎn)品規(guī)格說明書SPECSPEC如何形成SPEC的主要內(nèi)容與格式SPEC實(shí)例介紹產(chǎn)品規(guī)格說明書階段測試工程師需要做什么閱讀并查看SPEC中的功能是否符合PRD要求和EM保持良好的溝通，并且一起閱讀SPEC的詳細(xì)內(nèi)容根據(jù)SPEC設(shè)計TestCase跟蹤SPEC中提出的問題解決狀態(tài)10ppt課件第4章項目初期各階段的主要工作產(chǎn)品技術(shù)文檔設(shè)計階段編寫技術(shù)設(shè)計文檔什么是產(chǎn)品的技術(shù)文檔技術(shù)文檔中包括哪些內(nèi)容技術(shù)文檔實(shí)例介紹技術(shù)設(shè)計文檔階段測試工程師需要做什么為測試環(huán)境做準(zhǔn)備了解產(chǎn)品的邏輯流程，數(shù)據(jù)庫結(jié)構(gòu)，以及各個模塊的具體功能了解產(chǎn)品設(shè)計中的一些技術(shù)問題了解產(chǎn)品的性能，為性能測試作準(zhǔn)備11ppt課件參與需求的分析及評審，從測試角度分析需求的可測試性，具體為：閱讀PRD中的詳細(xì)功能需求，對需求文檔進(jìn)行檢查跟蹤提交的問題解決狀態(tài)測試在需求階段的工作12ppt課件什么是評審軟件評審是對軟件元素或者項目狀態(tài)的一種評估手段，以確定其是否與計劃的結(jié)果保持一致，并使其得到改進(jìn)。產(chǎn)品需求審查是軟件開發(fā)重要環(huán)節(jié)之一，也是測試活動之一，即靜態(tài)測試——需求驗證。借助需求審查保證用戶需求在市場/產(chǎn)品需求文檔及其相關(guān)文檔中得到準(zhǔn)確、完整、無歧義的反映，并使各類開發(fā)人員在需求理解上達(dá)成一致。13ppt課件1.軟件缺陷并不只是在編程階段才產(chǎn)生，需求和設(shè)計階段同樣會產(chǎn)生缺陷2.軟件測試對需求的依賴為什么需要需求評審在制定測試計劃之前，必須清楚測試需求明確測試需求的優(yōu)先級測試需求分解得越細(xì)，對測試用例的設(shè)計質(zhì)量越有幫助詳細(xì)的測試需求還是衡量測試覆蓋率的重要依據(jù)測試需求是規(guī)劃具體項目資源和時間的基礎(chǔ)。14ppt課件需求評審的重要性：1.軟件需求是軟件開發(fā)最重要的一個輸入，好的開始是成功的一半!所以，需求的質(zhì)量很大程度上決定了項目質(zhì)量或產(chǎn)品質(zhì)量。2.需求風(fēng)險常常是軟件開發(fā)過程中最大的一個風(fēng)險，要降低需求階段帶來的風(fēng)險，就要把需求評審做好。3.需求評審做不好的后果：

需求變更需求不明確需求不可測需求不可實(shí)現(xiàn)導(dǎo)致后續(xù)工作難于開展或經(jīng)常出現(xiàn)變更。需求評審的重要性15ppt課件需求評審重要性的直觀描述16ppt課件評審會議角色主持人作者記錄員列席人員內(nèi)審員技術(shù)專業(yè)人員17ppt課件測試人員在需求評審中作用明確自己的角色和責(zé)任熟悉評審內(nèi)容，為評審做好準(zhǔn)備針對問題闡述觀點(diǎn)，而非針對個人從客戶角度想問題，多問幾個為什么在會前或會后提出自己建設(shè)性的意見對發(fā)現(xiàn)的問題跟蹤到底

針對需求文檔等報告問題需求評審歸為靜態(tài)測試范疇，包含了文檔評審和技術(shù)評審雙重內(nèi)容，通常通過正式的評審會議來進(jìn)行。而測試人員主要起著評審員的作用，檢查需求定義是否合理和清楚。18ppt課件相互評審、交叉評審：甲和乙在一個項目組，處在一個領(lǐng)域，但工作內(nèi)容不同，甲的工作成果交給乙審查，乙的工作成果交給甲審查。相互評審是最不正式的一種評審形式，但應(yīng)用方便、有效。輪查：又稱分配審查方法，是一種異步評審方式。作者將需要評審的內(nèi)容發(fā)送給各位評審員，并收集他們的反饋意見走查：作者將測試需求在現(xiàn)場向一組同事介紹，以收集大家的意見。希望參與評審的其他同事可以發(fā)現(xiàn)其中的錯誤，并能進(jìn)行現(xiàn)場討論。這種形式介于正式和非正式之間。小組評審：通過正式的小組會議完成評審工作，是有計劃的和結(jié)構(gòu)化的評審方式。評審定義了評審會議中的各種角色和相應(yīng)的責(zé)任，所有參與者在評審會議的前幾天就拿到了評審材料，并對該材料進(jìn)行了獨(dú)立研究。審查：審查和小組評審很相似，但更為嚴(yán)格，是最系統(tǒng)化、最嚴(yán)密的評審形式，包含了制定計劃、準(zhǔn)備和組織會議、跟蹤和分析審查結(jié)果等。評審的形式19ppt課件軟件需求評審的輸入1、軟件需求規(guī)格說明書；2、項目工作任務(wù)書；3、軟件需求規(guī)格說明書的檢查列表（Checklist）；檢查表（checklist）是一種常用的的質(zhì)量保證手段，也是正式技術(shù)評審的必要工具，評審過程往往由檢查表驅(qū)動。一份精心設(shè)計的檢查表，對于提高評審效率、改進(jìn)評審質(zhì)量具有很大幫助。可靠性。人們借助檢查表以確認(rèn)被檢查對象的所有質(zhì)量特征均得到滿足，避免遺漏任何項目。效率。檢查表歸納了所有檢查要點(diǎn)，比起冗長的文檔，使用檢查表具有更高的工作效率。20ppt課件產(chǎn)品需求的正確性產(chǎn)品需求的實(shí)踐性產(chǎn)品需求的完整性產(chǎn)品需求的可行性和成本預(yù)算產(chǎn)品需求的質(zhì)量屬性產(chǎn)品需求的可實(shí)驗性需求評審的內(nèi)容21ppt課件需求規(guī)格說明的正確性體現(xiàn)在：是否有需求與其他需求相互沖突或者重復(fù)？是否清晰、簡潔、無二義地表達(dá)了每個需求?是否每個需求都通過了演示、測試、評審，分析是否得到了驗證?是否每個需求都沒有內(nèi)容和語法上的錯誤?在現(xiàn)有的資源內(nèi),是否能實(shí)現(xiàn)所有的需求?是否每個需求都在項目的范圍內(nèi)?每一條特定的錯誤信息，是否都是唯一的和具有含義的?

需求規(guī)格說明的正確性評審22ppt課件實(shí)踐性是指需求本身是否來源于目前企業(yè)的相關(guān)業(yè)務(wù)規(guī)則和文件制度,而非源于分析師們經(jīng)驗主義的臆測。有經(jīng)驗的系統(tǒng)分析師通常會迷信自己的經(jīng)驗,把從前的經(jīng)驗嫁接到目前的企業(yè)需求分析中。也許由于行業(yè)性質(zhì)相同,但如果不經(jīng)過當(dāng)前的實(shí)踐調(diào)研則給出需求，仍然會無法體現(xiàn)出企業(yè)自身的特征。因而不能為企業(yè)帶來真正的價值,也會造成與用戶需求的鴻溝。需求規(guī)格說明的實(shí)踐性評審23ppt課件編寫的所有需求，其詳細(xì)程度是否一致和合適?需求是否能為設(shè)計提供足夠的基礎(chǔ)?所有對其他需求的內(nèi)部引用是否正確?是否包含了每個需求的實(shí)現(xiàn)優(yōu)先級?是否定義了功能說明的內(nèi)在算法?是否包含了所有已知的客戶需求或系統(tǒng)需求?是否遺漏了必要的信息?如果有遺漏的話,把他們標(biāo)記為待確定的問題(TBD)?是否對所有預(yù)期的錯誤條件所產(chǎn)生的系統(tǒng)行為都編制了文檔?需求規(guī)格說明的完整性評審24ppt課件需求方案的可行性和成本預(yù)算評審的目的，是從需求的多項方案中選擇最優(yōu)化的或者是性價比最高的方案。一般而言,需求說明書可以給出同一個問題的幾種方案，并給出各自的優(yōu)缺點(diǎn)和成本差異,經(jīng)過比較由決策者作出最終選擇。如果可行性高,則還要考慮它需要哪些資源和預(yù)算。我們需要確定技術(shù)是否確實(shí)滿足業(yè)務(wù)需求,同時,也要考慮整個產(chǎn)品成本,包括開發(fā)人員、服務(wù)器、許可和升級費(fèi)用,還需要考慮初始硬件、軟件和支持、基礎(chǔ)結(jié)構(gòu)和培訓(xùn)的費(fèi)用。需求方案的可行性和成本預(yù)算評審25ppt課件

我們需要評審需求規(guī)格說明是否合理地確定了所有的性能目標(biāo)，是否合理地確定了安全性方面要考慮到的問題。用戶通常難以忍受運(yùn)行或響應(yīng)速度過慢的系統(tǒng)。系統(tǒng)的安全性也是一個很重要的指標(biāo),尤其是作為企業(yè)級的系統(tǒng),它的安全考量完全繼承于組織對安全的基本訴求。需求的質(zhì)量屬性評審

26ppt課件是否對每個需求都設(shè)置了維一性標(biāo)志并且可以正確地識別它？是否每個功能需求都可以跟蹤到高層需求需求必須可以測試,每個需求在特定的輸入條件下應(yīng)當(dāng)能給出已知的輸出結(jié)果。同時,需求應(yīng)當(dāng)層次分明,需要把單個需求下面的相關(guān)需求綜合在一起形成一組需求功能。需求的可實(shí)施性除了可跟蹤性還包括可測試性。需求的可實(shí)施性評審

27ppt課件軟件需求評審輸出根據(jù)評審專家意見修改后的軟件需求規(guī)格說明書軟件需求規(guī)格說明書評審表格（評審記錄表單）28ppt課件第5章軟件測試計劃的制定為何要制定測試計劃怎樣設(shè)計測試計劃測試計劃設(shè)計實(shí)例測試計劃修改與維護(hù)29ppt課件第5章軟件測試計劃的制定為何要制定測試計劃可以讓項目有條理有計劃地進(jìn)行可以提前預(yù)知項目過程中可能出現(xiàn)的問題明確測試目標(biāo)、測試范圍和測試重點(diǎn)明確測試任務(wù)和測試方法，保證測試實(shí)施過程的順暢溝通說明：測試計劃是每一個測試項目組長一定要會寫的，并且能準(zhǔn)確執(zhí)行的。好的測試計劃能讓測試有條不紊的進(jìn)行，做到事半功倍。30ppt課件ANSI/IEEE把測試計劃定義為：

一個敘述了預(yù)定的測試活動的范圍、途徑、資源及進(jìn)度安排的文檔。它確認(rèn)了測試項。被測特征、測試任務(wù)、人員安排以及任何偶發(fā)事件的風(fēng)險測試計劃的定義31ppt課件ANSI/IEEE把測試計劃定義為：

一個敘述了預(yù)定的測試活動的范圍、途徑、資源及進(jìn)度安排的文檔。它確認(rèn)了測試項。被測特征、測試任務(wù)、人員安排以及任何偶發(fā)事件的風(fēng)險測試計劃的定義32ppt課件第5章軟件測試計劃的制定怎樣設(shè)計測試計劃產(chǎn)品基本情況調(diào)研測試需求說明計劃表測試資源配置系統(tǒng)風(fēng)險評估測試的策略和記錄問題跟蹤報告測試計劃的發(fā)布33ppt課件如何編制測試計劃根據(jù)測試策略，選定測試計劃包含的測試范圍劃分測試階段，明確測試方法，確定測試任務(wù)評估測試工作量確定時間并生成進(jìn)度計劃評估進(jìn)度計劃風(fēng)險34ppt課件測試策略一般描述軟件測試活動的一般方法和目標(biāo)。其中包括要進(jìn)行的測試階段（單元測試、集成測試和系統(tǒng)測試）以及要執(zhí)行的測試類型（功能測試、性能測試、負(fù)載測試、強(qiáng)度測試等）。

確定測試需求：明確測試的工作范圍，需要測試的對象、達(dá)到的指標(biāo)等?？梢詠碓从谲浖枨?，個人經(jīng)驗，以前發(fā)生的錯誤等。（一）確定軟件測試策略35ppt課件（二）確定測試任務(wù)根據(jù)本階段測試需求，細(xì)化測試任務(wù)劃分任務(wù)優(yōu)先級，和主要任務(wù)關(guān)聯(lián)關(guān)系確定輔助任務(wù)清單（如培訓(xùn)等）確定資源情況形成WBS（工作任務(wù)細(xì)分）圖36ppt課件