CMMI培訓教材(測試技術-測試基礎)課件_第1頁
CMMI培訓教材(測試技術-測試基礎)課件_第2頁
CMMI培訓教材(測試技術-測試基礎)課件_第3頁
CMMI培訓教材(測試技術-測試基礎)課件_第4頁
CMMI培訓教材(測試技術-測試基礎)課件_第5頁
已閱讀5頁,還剩97頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領

文檔簡介

測試交流會2007-8-9測試交流會2007-8-91自我介紹自我介紹2測試中遇到的問題請大家討論一下(5-10分鐘)測試中遇到的問題請大家討論一下(5-10分鐘)3什么是缺陷軟件未達到產(chǎn)品說明書標明的功能;軟件出現(xiàn)了產(chǎn)品說明書指明不會出現(xiàn)的錯誤;軟件功能超出產(chǎn)品說明書指明范圍;軟件未達到產(chǎn)品說明書雖未指出但應達到的目標;軟件測試員認為軟件難以理解、不易使用、運行速度緩慢,或者最終用戶認為不好。什么是缺陷軟件未達到產(chǎn)品說明書標明的功能;4缺陷產(chǎn)生的原因軟件方面:需求解釋有錯誤用戶定義錯了需求需求記錄錯誤設計說明有誤編碼說明有誤程序代碼有誤數(shù)據(jù)輸入有誤測試錯誤問題修改不正確正確的結(jié)果是由于其它的缺陷產(chǎn)生的缺陷產(chǎn)生的原因軟件方面:5軟件測試困難完全測試程序是不可能的;軟件測試是有風險的行為;測試無法顯示潛伏的軟件缺陷;找到的軟件缺陷越多,說明缺陷越多;不是所有的軟件缺陷都能修復;難以說清的軟件缺陷;測試員在小組中不受歡迎。軟件測試困難完全測試程序是不可能的;6提綱會議目標軟件測試的基本概念軟件測試的過程軟件測試的跟蹤提綱會議目標7會議目標掌握軟件測試的基本概念和術語了解測試基本技術掌握軟件測試過程會議目標掌握軟件測試的基本概念和術語8基本概念和術語基本概念和術語9軟件測試的定義傳統(tǒng)定義:軟件測試是根據(jù)軟件開發(fā)各階段的說明書和程序的內(nèi)部結(jié)構(gòu),設計一批測試用例,并利用這些測試用例去運行程序,以發(fā)現(xiàn)程序錯誤的過程;測試是為了證明程序有錯,而不是為了證明程序無錯誤;一個好的測試用例是它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤;一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。軟件測試的定義傳統(tǒng)定義:軟件測試是根據(jù)軟件開發(fā)各階段的說明書10軟件測試的定義換言之,測試就是想以最少的時間和人力,系統(tǒng)地找出軟件中潛在的各種錯誤和缺陷。如果我們成功地實施了測試,我們就能夠發(fā)現(xiàn)軟件中的錯誤。測試的附帶收獲是,它能夠證明軟件的功能和性能與需求說明相符合。實施測試收集到的測試結(jié)果數(shù)據(jù)為可靠性分析提供了依據(jù)。測試不能表明軟件中不存在錯誤,它只能說明軟件中存在錯誤。軟件測試的定義換言之,測試就是想以最少的時間和人力,系統(tǒng)地找11術語解釋軟件測試的方式:白盒測試:基于一個應用代碼的內(nèi)部邏輯知識,測試是基于覆蓋全部代碼、分支、路徑、條件黑盒測試:不是基于內(nèi)部設計和代碼的任何知識,而是基于需求和功能性術語解釋軟件測試的方式:12術語解釋軟件測試的階段:單元測試:最微小規(guī)模的測試;以測試某個功能或代碼塊。典型地由程序員而非測試員來做,因為它需要知道內(nèi)部程序設計和編碼的細節(jié)知識。這個工作不容易作好,除非應用系統(tǒng)有一個設計很好的體系結(jié)構(gòu);還可能需要開發(fā)測試驅(qū)動器模塊或測試套具。集成測試:一個應用系統(tǒng)的各個部件的聯(lián)合測試,以決定他們能否在一起共同工作。系統(tǒng)測試:基于系統(tǒng)整體需求說明書的黑盒類測試;應覆蓋系統(tǒng)所有聯(lián)合的部件術語解釋軟件測試的階段:13術語解釋驗收測試:基于客戶或最終用戶的規(guī)格書的最終測試,或基于用戶一段時間的使用后,看軟件是否滿足客戶要求。Alpha測試:在系統(tǒng)開發(fā)接近完成時對應用系統(tǒng)的測試;測試后,仍然會有少量的設計變更。這種測試一般由最終用戶或其他人員員完成,不能由程序員或測試員完成。Beta測試:當開發(fā)和測試根本完成時所做的測試,而最終的錯誤和問題需要在最終發(fā)行前找到。這種測試一般由最終用戶或其他人員員完成,不能由程序員或測試員完成。術語解釋驗收測試:基于客戶或最終用戶的規(guī)格書的最終測試,或基14術語解釋回歸測試:對某些已經(jīng)進行過測試的子集在重新測試一遍,確保新模塊的加入未引起副作用。當測試發(fā)現(xiàn)錯誤,錯誤要被修改,每當軟件修改時(程序、文檔、數(shù)據(jù)被修改),回歸測試是保證這些修改不會帶來不可預料的行為或另外的錯誤回歸測試包括三種類型的測試用例:能夠測試軟件所有功能的代表性測試用例專門針對被修改可能會影響的軟件功能的附加測試針對修改過的軟件的部分測試術語解釋回歸測試:15術語解釋確認(Validation)確認是在開發(fā)過程之中或結(jié)束時評估系統(tǒng)或組成部分的過程,目的是判斷該系統(tǒng)是否滿足規(guī)定的需求。它可分為靜態(tài)確認與動態(tài)確認。靜態(tài)確認一般不實際執(zhí)行程序,而是通過人工分析或者程序正確性證明來確認程序的正確性;動態(tài)確認主要通過動態(tài)分析和程序測試來檢查程序的執(zhí)行狀態(tài),以確認程序是否有問題。驗證(Verification)驗證是對工作產(chǎn)品進行人工檢查或評審,目的是證明軟件生命周期的各個階段,以及階段間的邏輯協(xié)調(diào)性、完備性和正確性。術語解釋確認(Validation)16測試與軟件開發(fā)過程的關系用戶需求和驗收測試計劃軟件需求和系統(tǒng)測試計劃概要設計和集成測試計劃詳細設計和單元測試計劃單元測試集成測試系統(tǒng)測試驗收測試時間編碼驗證確認測試與軟件開發(fā)過程的關系用戶需求和驗收測試計劃軟件需求和系統(tǒng)17軟件測試的原則盡早和不斷地進行軟件測試;測試輸入數(shù)據(jù)及與之對應的預期輸出結(jié)果是每個測試用例的必要組成部分;既要編寫使用有效輸入條件的測試用例,也要編寫使用非法輸入條件的測試用例;充分注意測試中的群集現(xiàn)象。即沒有發(fā)現(xiàn)的缺陷數(shù)與已發(fā)現(xiàn)的缺陷數(shù)成正比;嚴格執(zhí)行測試計劃,杜絕不能重現(xiàn)的測試;深入細致地審查測試結(jié)果;妥善保存測試計劃,測試用例、測試缺陷記錄及測試報告,為維護提供方便。軟件測試的原則盡早和不斷地進行軟件測試;18軟件測試的過程軟件測試的過程19我們的測試過程測試不是軟件生命周期中一個單一的階段,測試是一個平行于開發(fā)過程的過程我們的測試過程測試不是軟件生命周期中一個單一的階段,測試是一20我們的測試過程測試不是軟件生命周期中一個單一的階段,測試是一個平行于開發(fā)過程的過程我們的測試過程測試不是軟件生命周期中一個單一的階段,測試是一21測試過程的劃分計劃測試活動設計用例單元測試集成測試系統(tǒng)測試驗收測試測試過程的劃分計劃測試活動22計劃測試活動目的:明確并描述針對項目要進行的測試活動主要活動:參與需求評審,驗證需求的完整性、正確性、一致性和可測試性參與項目WBS分解、工作量估計、風險分析明確測試需求、評價測試風險、建立測試策略、明確測試資源、建立測試進度、形成測試計劃評審測試計劃:組內(nèi)評審、正式評審計劃測試活動目的:明確并描述針對項目要進行的測試活動23計劃時考慮測試風險如果決定不測試所有的情況,那就是選擇了風險。測試員的一個主要原則是把無邊無際的可能減少到可以控制的范圍。太少的測試是不負責任,過多的測試是一種浪費。優(yōu)化測試量遺漏缺陷數(shù)目測試費用測試工作量數(shù)量計劃時考慮測試風險如果決定不測試所有的情況,那就是選擇了風險24軟件測試計劃內(nèi)容概述測試策略測試的類型測試的階段測試的風險分析列表測試的資源:人員,軟件,硬件測試的進度測試的接口驗收標準:內(nèi)部驗收標準和外部驗收標準軟件測試計劃內(nèi)容概述測試策略25軟件測試計劃內(nèi)容概述驗收標準的意義外部驗收標準是和客戶達成的一致,通過了外部驗收標準就可以提交給客戶內(nèi)部驗收標準是和開發(fā)組達成的一致,通過了內(nèi)部驗收標準就可以進入下一個測試階段或提交給客戶驗收標準內(nèi)容基于測試覆蓋(測試類型的覆蓋,測試內(nèi)容的覆蓋)基于測試用例和測試用例的通過情況基于軟件問題和解決情況軟件測試計劃內(nèi)容概述驗收標準的意義26設計測試用例目的:根據(jù)測試策略中明確的不同測試類型,形成測試大綱,設計測試用例,實現(xiàn)完成測試用例所需要的各種支持(數(shù)據(jù)、文件…)主要活動:形成測試大綱明確測試用例,設計測試用例執(zhí)行步驟形成需求跟蹤矩陣生成測試數(shù)據(jù)和測試文件設計測試用例目的:根據(jù)測試策略中明確的不同測試類型,形成測27設計測試用例對需求規(guī)格說明書的仔細閱讀SRS是測試的基礎,對SRS的熟悉程度在很大程度上決定了測試用例設計的有效性熟悉需求點的要求和相互關系做什么?有什么限制?什么是正確的做法,出錯處理是什么?和其他需求之間有什么引用和制約關系多問一些為什么和如果?設計測試用例對需求規(guī)格說明書的仔細閱讀28設計測試用例測試用例的內(nèi)容測試的目的或需求測試環(huán)境和入口條件測試的步驟測試的支持數(shù)據(jù)或支持文件測試的預期結(jié)果其它一些記錄和控制字段測試用例需要管理和維護設計測試用例測試用例的內(nèi)容29設計測試用例設計測試用例的思路以SRS為出發(fā)點對于每一個需求點:正確的執(zhí)行是什么,錯誤的或非法的執(zhí)行是什么,一個操作者,一般會犯怎樣的錯誤需求點之間有什么相互聯(lián)系,某一個需求點是否依賴于其他的內(nèi)容,是如何依賴的對于功能點組合才可以完成的功能,有怎樣的組合方式,各有怎樣的結(jié)果最主要的商業(yè)流程是怎樣的,找出重要的流程設計測試用例設計測試用例的思路30設計測試用例提高測試用例的質(zhì)量步驟明確,告訴測試人員做什么,系統(tǒng)做什么,系統(tǒng)的反映是什么,不要混淆步驟和結(jié)果測試用例避免步驟太多,10-15步足夠了(一個步驟不要執(zhí)行很多的操作)盡量將測試用例分開,一個測試用例只測試一個內(nèi)容如果測試用例有前后依賴關系,一定要明確設計測試用例提高測試用例的質(zhì)量31設計測試用例編寫測試用例常見的錯誤步驟太多不完整,錯誤或不連貫的步驟遺漏步驟沒有清楚說明是測試工程師還是系統(tǒng)做事情沒有明確定義通過和失敗的結(jié)果設計測試用例編寫測試用例常見的錯誤32設計測試用例需求跟蹤距陣對需求的提取要完備盡量細化到功能點需求跟蹤距陣明確了測試的覆蓋測試數(shù)據(jù)和測試文件設計測試用例需求跟蹤距陣33設計測試用例其他活動:對設計和編碼的活動進行一定程度的評審、測試或測試支持活動對流程圖進行評審對UI設計文檔進行評審對代碼進行規(guī)范檢查提供單元測試測試用例設計的支持設計測試用例其他活動:對設計和編碼的活動進行一定程度的評審、34單元測試目的驗證程序?qū)崿F(xiàn)與詳細設計說明書中的描述是否一致,消除程序模塊內(nèi)部邏輯及功能上的缺陷。單元測試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設計白盒測試為主,黑盒測試為輔。單元測試目的35集成測試的目的檢測和排除子系統(tǒng)或系統(tǒng)結(jié)構(gòu)上的錯誤,發(fā)現(xiàn)并解決模塊間聯(lián)接時出現(xiàn)的問題,最終構(gòu)成要求的軟件系統(tǒng)。集成測試的目的檢測和排除子系統(tǒng)或系統(tǒng)結(jié)構(gòu)上的錯誤,發(fā)現(xiàn)并解決36系統(tǒng)測試的目的在模擬環(huán)境(可能就是開發(fā)環(huán)境)下,運用黑盒測試來驗證軟件系統(tǒng)是否滿足軟件需求規(guī)格說明書中所描述的功能需求、質(zhì)量特性和性能等方面的特性。系統(tǒng)測試的目的在模擬環(huán)境(可能就是開發(fā)環(huán)境)下,運用黑盒測試37系統(tǒng)測試的類型功能測試容量測試負載/強度測試安全性測試可用性測試性能測試配置測試兼容性測試可安裝性測試恢復性測試可靠性測試系統(tǒng)測試的類型功能測試配置測試38系統(tǒng)測試進入的條件已經(jīng)完成集成測試;系統(tǒng)測試計劃、測試用例已編寫完成,并經(jīng)過批準。系統(tǒng)測試進入的條件已經(jīng)完成集成測試;39執(zhí)行系統(tǒng)測試測試人員應依據(jù)系統(tǒng)測試計劃和用例進行系統(tǒng)測試。發(fā)現(xiàn)的軟件缺陷應記入缺陷跟蹤系統(tǒng),盡快將其提交給被測代碼的作者,由其負責解決缺陷。測試負責人評判缺陷及其解決方法中存在的疑問。系統(tǒng)測試的過程中,回歸測試可能會非常多,因此回歸測試的測試用例應當設計成針對那些主要的軟件功能中可能出現(xiàn)的錯誤。執(zhí)行系統(tǒng)測試測試人員應依據(jù)系統(tǒng)測試計劃和用例進行系統(tǒng)測試。40執(zhí)行系統(tǒng)測試(續(xù))當測試人員依據(jù)系統(tǒng)測試計劃和用例(包括進行回歸測試時新添加的測試用例)完成系統(tǒng)測試,且缺陷跟蹤系統(tǒng)中報告的軟件缺陷均已修改完成之后,測試組負責人可通知項目經(jīng)理系統(tǒng)測試已完成。執(zhí)行系統(tǒng)測試(續(xù))當測試人員依據(jù)系統(tǒng)測試計劃和用例(包括進行41系統(tǒng)測試退出條件已按照系統(tǒng)測試計劃和用例完成了系統(tǒng)測試;測試中發(fā)現(xiàn)的問題、缺陷均已得到解決;系統(tǒng)測試報告獲得項目經(jīng)理的批準;系統(tǒng)測試退出條件已按照系統(tǒng)測試計劃和用例完成了系統(tǒng)測試;42驗收測試驗證軟件的功能和性能及其他特性是否與用戶的要求一致。需求規(guī)格說明書中的有效性準則是軟件驗收測試的基礎。驗收測試驗證軟件的功能和性能及其他特性是否與用戶的要求一致。43軟件測試的跟蹤軟件測試的跟蹤44測試跟蹤的目的對測試的執(zhí)行情況進行跟蹤,獲得實用的測試管理信息。4、軟件測試過程的跟蹤測試跟蹤的目的對測試的執(zhí)行情況進行跟蹤,獲得實用的測試管理信45跟蹤的用例分類計劃的:計劃開發(fā)的測試用例??捎玫模嚎捎糜趫?zhí)行的計劃的測試用例。(可用的測試用例數(shù)少于或等于計劃的測試用例數(shù))執(zhí)行的:已執(zhí)行的可用測試用例。通過的:已執(zhí)行的測試用例,在最近執(zhí)行的過程中沒有檢測出錯誤。4、軟件測試過程的跟蹤跟蹤的用例分類計劃的:計劃開發(fā)的測試用例。4、軟件測試過程的46跟蹤的方法建立起測試用例的數(shù)量與時間之間的矩陣按時間跟蹤根據(jù)通過的測試用例與計劃的測試用例之間的比例跟蹤通過對測試狀態(tài)執(zhí)行圖的分析獲得所需的測試管理信息4、軟件測試過程的跟蹤跟蹤的方法建立起測試用例的數(shù)量與時間之間的矩陣4、軟件測試過47測試狀態(tài)跟蹤圖300250200150100500

12345678910星期計劃的可用的執(zhí)行的通過的4、軟件測試過程的跟蹤測試狀態(tài)跟蹤圖300148總結(jié)軟件測試的目的是發(fā)現(xiàn)軟件存在的缺陷。軟件測試工作貫穿整個軟件開發(fā)過程,越早發(fā)現(xiàn)軟件缺陷,解決缺陷的成本越低。軟件測試是一項嚴謹?shù)墓ぷ?,必須是有計劃并按計劃?zhí)行的??偨Y(jié)軟件測試的目的是發(fā)現(xiàn)軟件存在的缺陷。49Questions/Discussion

問題與討論ThankYou謝謝Questions/Discussion

問題與討論Th50演講完畢,謝謝觀看!演講完畢,謝謝觀看!51測試交流會2007-8-9測試交流會2007-8-952自我介紹自我介紹53測試中遇到的問題請大家討論一下(5-10分鐘)測試中遇到的問題請大家討論一下(5-10分鐘)54什么是缺陷軟件未達到產(chǎn)品說明書標明的功能;軟件出現(xiàn)了產(chǎn)品說明書指明不會出現(xiàn)的錯誤;軟件功能超出產(chǎn)品說明書指明范圍;軟件未達到產(chǎn)品說明書雖未指出但應達到的目標;軟件測試員認為軟件難以理解、不易使用、運行速度緩慢,或者最終用戶認為不好。什么是缺陷軟件未達到產(chǎn)品說明書標明的功能;55缺陷產(chǎn)生的原因軟件方面:需求解釋有錯誤用戶定義錯了需求需求記錄錯誤設計說明有誤編碼說明有誤程序代碼有誤數(shù)據(jù)輸入有誤測試錯誤問題修改不正確正確的結(jié)果是由于其它的缺陷產(chǎn)生的缺陷產(chǎn)生的原因軟件方面:56軟件測試困難完全測試程序是不可能的;軟件測試是有風險的行為;測試無法顯示潛伏的軟件缺陷;找到的軟件缺陷越多,說明缺陷越多;不是所有的軟件缺陷都能修復;難以說清的軟件缺陷;測試員在小組中不受歡迎。軟件測試困難完全測試程序是不可能的;57提綱會議目標軟件測試的基本概念軟件測試的過程軟件測試的跟蹤提綱會議目標58會議目標掌握軟件測試的基本概念和術語了解測試基本技術掌握軟件測試過程會議目標掌握軟件測試的基本概念和術語59基本概念和術語基本概念和術語60軟件測試的定義傳統(tǒng)定義:軟件測試是根據(jù)軟件開發(fā)各階段的說明書和程序的內(nèi)部結(jié)構(gòu),設計一批測試用例,并利用這些測試用例去運行程序,以發(fā)現(xiàn)程序錯誤的過程;測試是為了證明程序有錯,而不是為了證明程序無錯誤;一個好的測試用例是它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤;一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。軟件測試的定義傳統(tǒng)定義:軟件測試是根據(jù)軟件開發(fā)各階段的說明書61軟件測試的定義換言之,測試就是想以最少的時間和人力,系統(tǒng)地找出軟件中潛在的各種錯誤和缺陷。如果我們成功地實施了測試,我們就能夠發(fā)現(xiàn)軟件中的錯誤。測試的附帶收獲是,它能夠證明軟件的功能和性能與需求說明相符合。實施測試收集到的測試結(jié)果數(shù)據(jù)為可靠性分析提供了依據(jù)。測試不能表明軟件中不存在錯誤,它只能說明軟件中存在錯誤。軟件測試的定義換言之,測試就是想以最少的時間和人力,系統(tǒng)地找62術語解釋軟件測試的方式:白盒測試:基于一個應用代碼的內(nèi)部邏輯知識,測試是基于覆蓋全部代碼、分支、路徑、條件黑盒測試:不是基于內(nèi)部設計和代碼的任何知識,而是基于需求和功能性術語解釋軟件測試的方式:63術語解釋軟件測試的階段:單元測試:最微小規(guī)模的測試;以測試某個功能或代碼塊。典型地由程序員而非測試員來做,因為它需要知道內(nèi)部程序設計和編碼的細節(jié)知識。這個工作不容易作好,除非應用系統(tǒng)有一個設計很好的體系結(jié)構(gòu);還可能需要開發(fā)測試驅(qū)動器模塊或測試套具。集成測試:一個應用系統(tǒng)的各個部件的聯(lián)合測試,以決定他們能否在一起共同工作。系統(tǒng)測試:基于系統(tǒng)整體需求說明書的黑盒類測試;應覆蓋系統(tǒng)所有聯(lián)合的部件術語解釋軟件測試的階段:64術語解釋驗收測試:基于客戶或最終用戶的規(guī)格書的最終測試,或基于用戶一段時間的使用后,看軟件是否滿足客戶要求。Alpha測試:在系統(tǒng)開發(fā)接近完成時對應用系統(tǒng)的測試;測試后,仍然會有少量的設計變更。這種測試一般由最終用戶或其他人員員完成,不能由程序員或測試員完成。Beta測試:當開發(fā)和測試根本完成時所做的測試,而最終的錯誤和問題需要在最終發(fā)行前找到。這種測試一般由最終用戶或其他人員員完成,不能由程序員或測試員完成。術語解釋驗收測試:基于客戶或最終用戶的規(guī)格書的最終測試,或基65術語解釋回歸測試:對某些已經(jīng)進行過測試的子集在重新測試一遍,確保新模塊的加入未引起副作用。當測試發(fā)現(xiàn)錯誤,錯誤要被修改,每當軟件修改時(程序、文檔、數(shù)據(jù)被修改),回歸測試是保證這些修改不會帶來不可預料的行為或另外的錯誤回歸測試包括三種類型的測試用例:能夠測試軟件所有功能的代表性測試用例專門針對被修改可能會影響的軟件功能的附加測試針對修改過的軟件的部分測試術語解釋回歸測試:66術語解釋確認(Validation)確認是在開發(fā)過程之中或結(jié)束時評估系統(tǒng)或組成部分的過程,目的是判斷該系統(tǒng)是否滿足規(guī)定的需求。它可分為靜態(tài)確認與動態(tài)確認。靜態(tài)確認一般不實際執(zhí)行程序,而是通過人工分析或者程序正確性證明來確認程序的正確性;動態(tài)確認主要通過動態(tài)分析和程序測試來檢查程序的執(zhí)行狀態(tài),以確認程序是否有問題。驗證(Verification)驗證是對工作產(chǎn)品進行人工檢查或評審,目的是證明軟件生命周期的各個階段,以及階段間的邏輯協(xié)調(diào)性、完備性和正確性。術語解釋確認(Validation)67測試與軟件開發(fā)過程的關系用戶需求和驗收測試計劃軟件需求和系統(tǒng)測試計劃概要設計和集成測試計劃詳細設計和單元測試計劃單元測試集成測試系統(tǒng)測試驗收測試時間編碼驗證確認測試與軟件開發(fā)過程的關系用戶需求和驗收測試計劃軟件需求和系統(tǒng)68軟件測試的原則盡早和不斷地進行軟件測試;測試輸入數(shù)據(jù)及與之對應的預期輸出結(jié)果是每個測試用例的必要組成部分;既要編寫使用有效輸入條件的測試用例,也要編寫使用非法輸入條件的測試用例;充分注意測試中的群集現(xiàn)象。即沒有發(fā)現(xiàn)的缺陷數(shù)與已發(fā)現(xiàn)的缺陷數(shù)成正比;嚴格執(zhí)行測試計劃,杜絕不能重現(xiàn)的測試;深入細致地審查測試結(jié)果;妥善保存測試計劃,測試用例、測試缺陷記錄及測試報告,為維護提供方便。軟件測試的原則盡早和不斷地進行軟件測試;69軟件測試的過程軟件測試的過程70我們的測試過程測試不是軟件生命周期中一個單一的階段,測試是一個平行于開發(fā)過程的過程我們的測試過程測試不是軟件生命周期中一個單一的階段,測試是一71我們的測試過程測試不是軟件生命周期中一個單一的階段,測試是一個平行于開發(fā)過程的過程我們的測試過程測試不是軟件生命周期中一個單一的階段,測試是一72測試過程的劃分計劃測試活動設計用例單元測試集成測試系統(tǒng)測試驗收測試測試過程的劃分計劃測試活動73計劃測試活動目的:明確并描述針對項目要進行的測試活動主要活動:參與需求評審,驗證需求的完整性、正確性、一致性和可測試性參與項目WBS分解、工作量估計、風險分析明確測試需求、評價測試風險、建立測試策略、明確測試資源、建立測試進度、形成測試計劃評審測試計劃:組內(nèi)評審、正式評審計劃測試活動目的:明確并描述針對項目要進行的測試活動74計劃時考慮測試風險如果決定不測試所有的情況,那就是選擇了風險。測試員的一個主要原則是把無邊無際的可能減少到可以控制的范圍。太少的測試是不負責任,過多的測試是一種浪費。優(yōu)化測試量遺漏缺陷數(shù)目測試費用測試工作量數(shù)量計劃時考慮測試風險如果決定不測試所有的情況,那就是選擇了風險75軟件測試計劃內(nèi)容概述測試策略測試的類型測試的階段測試的風險分析列表測試的資源:人員,軟件,硬件測試的進度測試的接口驗收標準:內(nèi)部驗收標準和外部驗收標準軟件測試計劃內(nèi)容概述測試策略76軟件測試計劃內(nèi)容概述驗收標準的意義外部驗收標準是和客戶達成的一致,通過了外部驗收標準就可以提交給客戶內(nèi)部驗收標準是和開發(fā)組達成的一致,通過了內(nèi)部驗收標準就可以進入下一個測試階段或提交給客戶驗收標準內(nèi)容基于測試覆蓋(測試類型的覆蓋,測試內(nèi)容的覆蓋)基于測試用例和測試用例的通過情況基于軟件問題和解決情況軟件測試計劃內(nèi)容概述驗收標準的意義77設計測試用例目的:根據(jù)測試策略中明確的不同測試類型,形成測試大綱,設計測試用例,實現(xiàn)完成測試用例所需要的各種支持(數(shù)據(jù)、文件…)主要活動:形成測試大綱明確測試用例,設計測試用例執(zhí)行步驟形成需求跟蹤矩陣生成測試數(shù)據(jù)和測試文件設計測試用例目的:根據(jù)測試策略中明確的不同測試類型,形成測78設計測試用例對需求規(guī)格說明書的仔細閱讀SRS是測試的基礎,對SRS的熟悉程度在很大程度上決定了測試用例設計的有效性熟悉需求點的要求和相互關系做什么?有什么限制?什么是正確的做法,出錯處理是什么?和其他需求之間有什么引用和制約關系多問一些為什么和如果?設計測試用例對需求規(guī)格說明書的仔細閱讀79設計測試用例測試用例的內(nèi)容測試的目的或需求測試環(huán)境和入口條件測試的步驟測試的支持數(shù)據(jù)或支持文件測試的預期結(jié)果其它一些記錄和控制字段測試用例需要管理和維護設計測試用例測試用例的內(nèi)容80設計測試用例設計測試用例的思路以SRS為出發(fā)點對于每一個需求點:正確的執(zhí)行是什么,錯誤的或非法的執(zhí)行是什么,一個操作者,一般會犯怎樣的錯誤需求點之間有什么相互聯(lián)系,某一個需求點是否依賴于其他的內(nèi)容,是如何依賴的對于功能點組合才可以完成的功能,有怎樣的組合方式,各有怎樣的結(jié)果最主要的商業(yè)流程是怎樣的,找出重要的流程設計測試用例設計測試用例的思路81設計測試用例提高測試用例的質(zhì)量步驟明確,告訴測試人員做什么,系統(tǒng)做什么,系統(tǒng)的反映是什么,不要混淆步驟和結(jié)果測試用例避免步驟太多,10-15步足夠了(一個步驟不要執(zhí)行很多的操作)盡量將測試用例分開,一個測試用例只測試一個內(nèi)容如果測試用例有前后依賴關系,一定要明確設計測試用例提高測試用例的質(zhì)量82設計測試用例編寫測試用例常見的錯誤步驟太多不完整,錯誤或不連貫的步驟遺漏步驟沒有清楚說明是測試工程師還是系統(tǒng)做事情沒有明確定義通過和失敗的結(jié)果設計測試用例編寫測試用例常見的錯誤83設計測試用例需求跟蹤距陣對需求的提取要完備盡量細化到功能點需求跟蹤距陣明確了測試的覆蓋測試數(shù)據(jù)和測試文件設計測試用例需求跟蹤距陣84設計測試用例其他活動:對設計和編碼的活動進行一定程度的評審、測試或測試支持活動對流程圖進行評審對UI設計文檔進行評審對代碼進行規(guī)范檢查提供單元測試測試用例設計的支持設計測試用例其他活動:對設計和編碼的活動進行一定程度的評審、85單元測試目的驗證程序?qū)崿F(xiàn)與詳細設計說明書中的描述是否一致,消除程序模塊內(nèi)部邏輯及功能上的缺陷。單元測試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設計白盒測試為主,黑盒測試為輔。單元測試目的86集成測試的目的檢測和排除子系統(tǒng)或系統(tǒng)結(jié)構(gòu)上的錯誤,發(fā)現(xiàn)并解決模塊間聯(lián)接時出現(xiàn)的問題,最終構(gòu)成要求的軟件系統(tǒng)。集成測試的目的檢測和排除子系統(tǒng)或系統(tǒng)結(jié)構(gòu)上的錯誤,發(fā)現(xiàn)并解決87系統(tǒng)測試的目的在模擬環(huán)境(可能就是開發(fā)環(huán)境)下,運用黑盒測試來驗證軟件系統(tǒng)是否滿足軟件需求規(guī)格說明書中所描述的功能需求、質(zhì)量特性和性能等方面的特性。系統(tǒng)測試的目的在模擬環(huán)境(可能就是開發(fā)環(huán)境)下,運用黑盒測試88系統(tǒng)測試的類型功能測試容量測試負載/強度測試安全性測試可用性測試性能測試配置測試兼容性測試可安裝性測試恢復性測試可靠性測試系統(tǒng)測試的類型功能測試配置測試89系統(tǒng)測試進入的條件已經(jīng)完成集成測試;系統(tǒng)測試計劃、測試用例已編寫完成,并經(jīng)過批準。系統(tǒng)測試進入的條件已經(jīng)完成集成測試;90執(zhí)行系統(tǒng)測試測試人員應依據(jù)系統(tǒng)測試計劃和用例進行系統(tǒng)測試。發(fā)現(xiàn)的軟件缺陷應記入缺陷跟蹤系統(tǒng),盡快將其提交給被測代碼的作者,由其負責解決缺陷。測試負責人評判缺陷及其解決方法中存在的疑問。系統(tǒng)測試的過程中,回歸測試可能會非常多,因此回歸測試的測試用例應當設計成針對那些主要的軟件功能中可能出現(xiàn)的錯誤。執(zhí)行系統(tǒng)測

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論