-
- 素材大。
- 2.81 MB
- 素材授權(quán):
- 免費下載
- 素材格式:
- .ppt
- 素材上傳:
- ppt
- 上傳時間:
- 2016-04-03
- 素材編號:
- 51863
- 素材類別:
- 培訓(xùn)教程PPT
-
素材預(yù)覽
這是一個關(guān)于軟件測試培訓(xùn)教程PPT(部分ppt內(nèi)容已做更新升級),主要介紹了軟件測試?yán)碚摶A(chǔ)、軟件測試流程、軟件項目運作流程、軟件測試工作流程、軟件測試用例設(shè)計方法、軟件缺陷、測試的技巧、測試工具的選擇、軟件的測試整個過程等內(nèi)容。培訓(xùn)是給新員工或現(xiàn)有員工傳授其完成本職工作所必需的正確思維認(rèn)知、基本知識和技能的過程。是一種有組織的知識傳遞、技能傳遞、標(biāo)準(zhǔn)傳遞、信息傳遞、管理訓(xùn)誡行為。其中以技能傳遞為主,側(cè)重上崗前進行。為了達(dá)到統(tǒng)一的科學(xué)技術(shù)規(guī)范、標(biāo)準(zhǔn)化作業(yè),通過目標(biāo)規(guī)劃設(shè)定知識和信息傳遞、技能熟練演練、作業(yè)達(dá)成評測、結(jié)果交流公告等現(xiàn)代信息化的流程,讓員工通過一定的教育訓(xùn)練技術(shù)手段,達(dá)到預(yù)期的水平,提高目標(biāo)。目前國內(nèi)培訓(xùn)以技能傳遞為主,時間在側(cè)重上崗前。
軟件測試培訓(xùn)教程PPT是由紅軟PPT免費下載網(wǎng)推薦的一款培訓(xùn)教程PPT類型的PowerPoint.
軟件測試培訓(xùn)教程
研發(fā)部
2010年11月
培訓(xùn)內(nèi)容
軟件測試?yán)碚摶A(chǔ)
軟件測試流程
軟件項目運作流程
軟件測試工作流程
軟件測試用例設(shè)計方法
軟件缺陷
測試的技巧
測試工具的選擇
軟件的測試整個過程
軟件測試?yán)碚摶A(chǔ)
測試行業(yè)簡介
軟件測試在軟件生命周期中占據(jù)重要作用。
軟件生命周期的每個階段都應(yīng)該包含測試從而檢驗本階段的成果是否接近預(yù)期的目標(biāo),盡可能早的發(fā)現(xiàn)錯誤并加以修正。
由于測試的重要性和復(fù)雜度,它慢慢的獨立發(fā)展成為一個行業(yè),并且在迅猛發(fā)展。
在典型的軟件開發(fā)項目中,軟件測試工作量往往占軟件開發(fā)總工作量的 40 %以上。而在軟件開發(fā)的總成本中,用在測試上的開銷要占 30 %到 50 %
軟件測試概論(概述)
1975年,“測試數(shù)據(jù)選擇的原理”(Toward a theory of Test Data)的文章,軟件測試才被確定為一種研究方向。
1979年,“軟件測試時為發(fā)現(xiàn)錯誤而執(zhí)行一個程序或者系統(tǒng)的過程”
1983年,“測試是以評價一個程序或者系統(tǒng)屬性為目標(biāo)的任何一種活動,測試是對軟件質(zhì)量的一種度量”。
2002年,“測試是為了度量和提高被測試軟件的質(zhì)量,對測試軟件進行工程設(shè)計、實施、維護的的整個生命周期過程”。
軟件測試概論(行情)
國外:
A、軟件測試在軟件公司中占有重要的地位
B、軟件測試?yán)碚撗芯颗畈l(fā)展,引領(lǐng)軟件測試?yán)碚撗芯康膰H潮流
C、軟件測試市場繁榮
國內(nèi):
1、我國著名的軟件公司都已經(jīng)或者正在建立獨立的專職軟件測試隊伍
2、國家開始對軟件測試職業(yè)高度重視和認(rèn)可(軟考中級資格中增加軟件評測師)
軟件測試概論(行情)
3、用戶對軟件質(zhì)量要求越來越高,通過第三方測試機構(gòu)的嚴(yán)格測試來判定
4、市場需求量不斷增大,軟件測試工程師的待遇也在不斷提高。北京地區(qū)的薪資趨勢大致如圖1-1所示。
測試工程師的職業(yè)發(fā)展
軟件測試工程師一般有幾個方向可走,如圖1-2所示。
一個理想的測試工程師應(yīng)該有開發(fā)經(jīng)驗,至少要有開發(fā)的概念。僅僅發(fā)現(xiàn)Bug是測試的初步,而分析出根本原因,卻要有很深的功底。
企業(yè)需要怎樣的測試人才?
一年以上軟件測試經(jīng)驗
計算機相關(guān)專業(yè)大專以上學(xué)歷
了解軟件工程,熟悉軟件測試過程和標(biāo)準(zhǔn),熟悉配置管理技術(shù)和工具
能夠編制測試計劃、設(shè)計測試用例、編寫B(tài)ug報告和測試總結(jié)報告、使用測試工具、開發(fā)測試腳本
熟練使用Windows或Unix或Linux操作系統(tǒng)
企業(yè)需要怎樣的測試人才?
熟練C、C++、Java、VB、Delphi、C#中的一種以上
熟練使用SQL Server或Oracle數(shù)據(jù)庫
了解業(yè)務(wù)領(lǐng)域(ERP、OA、電子商務(wù)、稅務(wù)系統(tǒng)、電信計費系統(tǒng)……)
熟練掌握至少一種以上的測試工具,如TestDirector、QTP、LoadRunner、Robot
進取、合作、表達(dá)、溝通、責(zé)任心、耐心、認(rèn)真程度
測試學(xué)習(xí)路線
對于軟件測試初學(xué)者,我們要切合實際、循序漸進的學(xué)習(xí),在學(xué)習(xí)中可參考圖1-3所示的軟件測試學(xué)習(xí)路線圖,從軟件測試的理論基礎(chǔ),到項目實戰(zhàn),逐步學(xué)習(xí),掌握技術(shù)技能,最終勝任軟件測試工作。
軟件測試由來
調(diào)試
在已知錯誤的情況下,對軟件程序代碼做出的一系列檢查,校正的過程。
測試
在未知錯誤的情況下,檢查程序代碼是否有問題的過程。
區(qū)分:軟件測試從軟件質(zhì)量保證的角度來檢查程序代碼是否有誤,而調(diào)試是為了解決當(dāng)前已知的錯誤,調(diào)試活動無法替代軟件測試活動。
軟件測試定義
定義:軟件測試就是為了發(fā)現(xiàn)錯誤而審查軟件文檔、檢查軟件數(shù)據(jù)和執(zhí)行程序代碼的過程。
軟件測試應(yīng)該是對軟件形成過程的文檔,數(shù)據(jù)以及程序進行的測試,而不僅是對程序進行的測試。
60%以上的軟件錯誤并不是程序錯誤,而是分析和設(shè)計的錯誤,提倡軟件全生命周期測試的理念。
什么是軟件質(zhì)量
1991年國際標(biāo)準(zhǔn)ISO 9126中定義為:軟件滿足規(guī)定或潛在用戶需求的總和。
1999年國際標(biāo)準(zhǔn)ISO 14598中定義為:軟件特性的總和,軟件滿足規(guī)定或潛在用戶需求的能力。
2001年國際標(biāo)準(zhǔn)ISO 9126中定義為:軟件滿足規(guī)定用戶或潛在用戶需求的能力,要從軟件在內(nèi)部,外部和使用過程中的表現(xiàn)來衡量,包含內(nèi)部質(zhì)量、外部質(zhì)量、和使用質(zhì)量。
軟件測試與質(zhì)量保證的區(qū)別
軟件質(zhì)量保證和軟件測試是軟件質(zhì)量工程中兩個不同層面的工作。
質(zhì)量保證(QA):質(zhì)量保證的重要工作通過預(yù)防,檢查與改進來保證軟件質(zhì)量(所關(guān)注的是軟件質(zhì)量的檢查與測量,著眼于軟件開發(fā)的過程,步驟和產(chǎn)物)。
軟件測試:測試過程雖然與開發(fā)過程緊密相關(guān)但,關(guān)心的不是過程的活動,而是對過程的產(chǎn)物以及開發(fā)出的軟件進行剖析。
軟件測試的目的和原則
基于不同的立場,存在著兩種完全不同的測試目的:
用戶角度:希望軟件測試暴露軟件中隱藏的錯誤和缺陷,已考慮是否接受產(chǎn)品。
軟件開發(fā)者角度:希望測試成為表明軟件產(chǎn)品中不存在錯誤的過程,驗證被測軟件已正確的實現(xiàn)了用戶的需求,確立人們對軟件質(zhì)量的信心。
軟件測試的目的和原則
換言之,測試的目的是:
想以最少的時間和人力,系統(tǒng)地找出軟件中潛在的各種錯誤和缺陷。如果我們成功地實施了測試,我們就能夠發(fā)現(xiàn)軟件中的錯誤。
測試的附帶收獲是,它能夠證明軟件的功能和性能與需求說明相符合。
實施測試收集到的測試結(jié)果數(shù)據(jù)為可靠性分析提供了依據(jù)
測試不能表明軟件中不存在錯誤,它只能說明軟件中存在錯誤
軟件測試的目的和原則
軟件測試的原則:
所有的軟件測試都應(yīng)追溯到用戶需求。
應(yīng)當(dāng)把“盡早地和不斷地進行軟件測試”作為軟件測試者的座右銘。
完全測試是不可能的,測試需要終止。
測試無法顯示軟件潛在的缺陷。也就是說測試只能證明軟件存在錯誤而不能證明軟件沒有錯誤。
軟件測試的對象
根據(jù)軟件定義,軟件包括程序,數(shù)據(jù)和文檔,所以軟件測試并不僅僅是程序測試,軟件測試應(yīng)該貫穿整個軟件生命周期中。
需求分析,概要設(shè)計,詳細(xì)設(shè)計以及程序編碼等各階段所得到的文檔,包括需求規(guī)格說明,概要設(shè)計規(guī)格說明,詳細(xì)設(shè)計規(guī)格說明以及源程序。
軟件測試的對象
為了把握各個環(huán)節(jié)的正確性,人們需要進行各種驗證和確認(rèn)工作 :
驗證(verification): 是保證軟件正確實現(xiàn)特定功能的一系統(tǒng)活動和過程,目的是保證軟件生命周期中的每一個階段的成果滿足上一個階段所設(shè)定的目標(biāo)。
確認(rèn)(validation): 是保證軟件滿足用戶需求的一系列的活動和過程,目的是在軟件開發(fā)完成后保證軟件,用戶需求相符合。
軟件測試的對象
軟件測試分類
一般的,我們將軟件測試活動分為以下幾類:
黑盒測試、
白盒測試、
灰盒測試、
靜態(tài)測試、
動態(tài)測試、
手動測試、
自動測試
軟件測試分類—黑盒測試
黑盒測試又叫功能測試、數(shù)據(jù)驅(qū)動測試或基于需求規(guī)格說明書的功能測試。該測試類別注重于測試軟件的功能性需求。
測試工程師無需了解程序代碼的內(nèi)部構(gòu)造,完全模擬軟件產(chǎn)品的最終端用戶使用該軟件,檢查軟件產(chǎn)品是否達(dá)到了用戶的需求。
如圖1-4所示為黑盒測試實例圖。
黑盒測試能更好的從用戶角度來考察被測系統(tǒng)的功能性需求實現(xiàn)情況。
軟件測試分類—白盒測試
白盒測試又稱結(jié)構(gòu)測試、邏輯驅(qū)動測試或基于程序代碼內(nèi)部構(gòu)成的測試。
白盒測試需要測試工程師深入考查程序代碼的內(nèi)部結(jié)構(gòu)、邏輯設(shè)計等。
就像前面的例子,我們拆開手機,觀察手機電路板的設(shè)計,液晶屏的構(gòu)成等。
對于白盒測試工程師來說,軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)是敞開的。如圖1-5所示是白盒測試示例圖。
軟件測試分類—灰盒測試
灰盒測試介于白盒和黑盒測試之間。
灰盒測試一方面考慮程序代碼的功能性表現(xiàn),另一方面,又需要考慮程序代碼的內(nèi)部結(jié)構(gòu)。
通俗地講,灰盒測試就是白加黑。
像我們的性能測試,自動化功能測試就是采用了灰盒測試的方法。
圖1-6是灰盒測試的示例圖。
軟件測試分類—靜態(tài)測試
定義:靜態(tài)的、不執(zhí)行被測對象程序代碼而尋找缺陷的過程。
在進行靜態(tài)測試時可采用一些代碼走查工具,如QAC++、C++Test等。
軟件測試分類—動態(tài)測試
實際的執(zhí)行被測對象的程序代碼,輸入實現(xiàn)設(shè)計好的測試用例,檢查程序代碼運行得到的結(jié)果與測試用力中設(shè)計的預(yù)期結(jié)果之間是否有差異,判定實際結(jié)果與預(yù)測結(jié)果是否一致。
動態(tài)測試有四部分組成:設(shè)計測試用例、執(zhí)行測試用例、分析比較輸出結(jié)果、輸出測試報告。
動態(tài)測試有三種主要方法:黑盒測試、白盒測試和灰盒測試
軟件測試分類—手動測試
它是測試人員設(shè)計測試用例并執(zhí)行測試用例,然后根據(jù)實際的結(jié)果去和預(yù)期的結(jié)果相比較并記錄測試結(jié)果,最終輸出測試報告的測試活動。
可充分發(fā)揮測試工程師的主觀能動性,將其智力體現(xiàn)在測試工作中,能發(fā)現(xiàn)許多的缺陷,但同時又有一定的局限性和單調(diào)枯燥性。
軟件測試分類—自動化測試
定義
利用測試工具,模擬用戶業(yè)務(wù)使用流程,讓他們自動運行來查找缺陷。
優(yōu)點
快、廣泛、可重復(fù)性工作
缺點
只可檢查比較主要的問題,如崩潰、死機,無法發(fā)現(xiàn)一般的日常錯誤。編寫腳本工作量 也很大,有時會超過手動測試時間。
我們要根據(jù)實際情況選擇或者不選擇測試工具,選擇使用何種測試工具,不能為了實用工具而可以的去使用工具。
軟件測試人員職業(yè)要求
從個人素質(zhì)角度要求測試工程師需要具備以下6種素質(zhì):
責(zé)任心
溝通能力
團隊合作精神
耐心、細(xì)心和信心
時時保持懷疑態(tài)度、并且有缺陷預(yù)防的意識
不斷學(xué)習(xí)的能力
軟件測試流程
軟件測試流程圖
軟件測試雖然是軟件生存周期的一個獨立階段,但測試工作卻滲透到從分析、設(shè)計直到編程的各個階段中(1-7是軟件測試所經(jīng)階段的一般流程)。
需求測試、單元測試、集成測試、系統(tǒng)測試、性能測試、用戶測試、回歸測試
需求測試
要從以下幾個方面考慮需求測試:
完整性 正確性
一致性 可行性
無二義性 健壯性
必要性 可測試性
可修改性
單元測試
又稱模塊測試,就是對程序代碼中最小的涉及模塊單元進行測試。
在單元測試中我們主要采用靜態(tài)測試與動態(tài)測試相結(jié)合的辦法。
單元測試要求需要幾年的代碼編寫經(jīng)驗,并且要十分熟悉當(dāng)前的被測系統(tǒng),以及該系統(tǒng)是否與其他系統(tǒng)的接口關(guān)聯(lián)情況。
單元測試在編碼階段占據(jù)非常重要的地位。
可以降低編碼的錯誤率,提高編碼質(zhì)量
集成測試
又稱組裝測試,是將軟件產(chǎn)品各個模塊組裝起來,檢查接口是否存在問題,以及組裝后的整體功能、性能表現(xiàn)。
一般可采用非增式集成方法、增式集成方法(自底向上集成、自頂向下集成、組合方式集成)等策略進行測試,利用一黑盒測試為主,白盒測試為輔的測試方法進行測試。
主要解決各個組成但源代碼是否符合開發(fā)規(guī)范、接口是否存在問題,整體功能有無錯誤、界面是否符合設(shè)計規(guī)范、性能是否滿足用戶需求等。
系統(tǒng)測試
將通過集成測試的軟件部署到某種較為復(fù)雜的計算機永華環(huán)境進行測試。
目的:通過與系統(tǒng)的需求定義作比較,發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。
這個階段主要進行的是安裝卸載測試、兼容性測試、功能確認(rèn)測試、安全測試等。
采用黑盒測試法,主要考察被測軟件的功能與性能表現(xiàn)。
性能測試
性能測試要求被測軟件在業(yè)務(wù)處理速度、處理能力和所耗用的硬件系統(tǒng)資源比率滿足用戶的需求。
不要嘗試用手動方式進行性能測試,應(yīng)當(dāng)編寫一段相應(yīng)的程序或者使用專門的工具進行,如利用LoadRunner自動化性能測試工具。
性能測試相對難度較大,要求測試人員掌握編程語言,精通業(yè)務(wù)流程,擁有深厚的項目經(jīng)驗。
用戶測試
可稱為用戶確認(rèn)測試。
正式驗收前,需要用戶對本系統(tǒng)做出一個評價,用戶可對交付的系統(tǒng)做測試,并將測試結(jié)果反饋回來,進行修改、分析。
用戶測試環(huán)節(jié)是被測試軟件首次作為正式的系統(tǒng)交友用戶使用,用戶會根據(jù)他們的實際使用情況進行測試、使用,并提出實際使用過程中的問題。
用戶測試是軟件生產(chǎn)流程中的最后質(zhì)檢關(guān)。
回歸測試
回歸測試是經(jīng)過一段時間以后再回過頭來對以前修復(fù)過的Bug重新進行測試,看該Bug是否會重新出現(xiàn)。
有些時候可采用自動化測試工具來進行回歸測試,如利用QTP
一般情況下,都由測試工程師手動的執(zhí)行一千的測試用例。來檢查用例通過情況。
軟件項目運作流程
軟件項目運作圖
市場調(diào)研
1、主動模式
將公司或者企業(yè)作為需求接收的被動方,而需求的提出作為主動方。
2、被動模式
在沒有明確的需求提出者時,有公司或企業(yè)主動提出給特定使用用戶群提供某種產(chǎn)品的模式。
市場調(diào)研主體:市場人員、銷售人員
調(diào)研方式:客戶走訪,市場觀察,報刊媒體等
輸出文件:《XXX項目市場調(diào)研分析報告》
可行性研究
以預(yù)測為前提,以投資效果為目的,從技術(shù)上、管理上進行全面綜合分析研究的方法。
基本任務(wù):對新開發(fā)產(chǎn)品或升級產(chǎn)品從技術(shù)經(jīng)濟角度進行全面的分析研究,并對其投產(chǎn)后的經(jīng)濟效益進行預(yù)測,在既定的范圍內(nèi)進行方案論證的選擇,以便最合理的利用資源,達(dá)到預(yù)定的社會效益和經(jīng)濟效益。
主體:市場人員、銷售人員
對象:在市場調(diào)研階段產(chǎn)生的《XXX項目市場調(diào)研分析報告》
輸出文件:《XXX項目可行性分析報告》
產(chǎn)品立項
在前期的市場調(diào)研、可行性研究經(jīng)過評審可行后,則由需求調(diào)研人員牽頭,進行產(chǎn)品立項,并進行產(chǎn)品小組的建立,同時制定產(chǎn)品的運作計劃,如需求調(diào)研、產(chǎn)品設(shè)計、產(chǎn)品測試、產(chǎn)品發(fā)布等一系列的工作步驟及時間點。
立項負(fù)責(zé)人:市場調(diào)研人員
工作內(nèi)容:提交產(chǎn)品立項申請,審批通過后,指定產(chǎn)品計劃書,確定產(chǎn)品各個階段的工作流程及時間進度表。
需求調(diào)研
1、主動模式
2、被動模式
需求調(diào)研參與人員:市場人員、開發(fā)人員、測試人員等
調(diào)研對象:客戶或假象客戶(廣泛應(yīng)用群)
輸出:需求規(guī)格說明書
設(shè)計開發(fā)
由系統(tǒng)架構(gòu)師進行系統(tǒng)的概要設(shè)計,主要從穩(wěn)定性、安全性、擴展性、可維持性等方面進行設(shè)計。
設(shè)計人員:系統(tǒng)架構(gòu)師、項目開發(fā)小組
輸出:項目開發(fā)計劃、概要設(shè)計文檔、詳細(xì)設(shè)計文檔、數(shù)據(jù)庫文檔等
系統(tǒng)測試
按照前期的測試計劃,利用測試用例進行系統(tǒng)的功能、性能測試。在經(jīng)過多次版本的迭代后,完成系統(tǒng)測試,輸出測試報告。
測試人員:項目測試小組
輸出:測試計劃、測試方案、測試用例、功能測試報告、性能測試報告等
產(chǎn)品發(fā)布
經(jīng)過開發(fā)部門、測試部門和其他部門的努力,產(chǎn)品在預(yù)定的日期完成,有項目組擇日發(fā)布。
發(fā)布人員:項目實施人員、市場部等
輸出:客戶現(xiàn)場項目實施報告等
產(chǎn)品維護
交付使用后,需根據(jù)需求調(diào)研階段協(xié)議,制定產(chǎn)品維護流程,出現(xiàn)問題需及時解決,直到產(chǎn)品使用廢棄或升級,進入新的生命周期。
產(chǎn)品升級
在軟件產(chǎn)品使用到一定期限后,可以根據(jù)先前的約定進行升級,或根據(jù)客戶新的需求,再次進行新需求的調(diào)研開發(fā)等。
軟件測試工作流程
測試部門組織結(jié)構(gòu)
1、人員構(gòu)成
測試主管、測試組長、環(huán)境保障人員、配置管理員、測試設(shè)計人員、測試工程師
測試部門組織結(jié)構(gòu)
2、測試主管
負(fù)責(zé)測試部門日常管理工作。
3、測試組長
測試主管根據(jù)項目情況,指派合適的測試人員但當(dāng)測試組長。
4、環(huán)境保障人員
維護整個項目過程中的系統(tǒng)環(huán)境,如硬件、軟件方便的。由測試人員兼任。
5、配置管理員
是軟件開發(fā)過程中的一個重要工作流程面對需求變更、版本迭代、文檔審核起到相當(dāng)大的作用。
測試部門組織結(jié)構(gòu)
6、測試設(shè)計人員
一般由高級測試工程師擔(dān)當(dāng),負(fù)責(zé)測試方法設(shè)計、測試用例設(shè)計及功能測試、性能測試的步驟、流程設(shè)計。
7、測試工程師
執(zhí)行測試用例,進行系統(tǒng)的功能測試,經(jīng)過多次版本迭代,完成系統(tǒng)測試。
8、技術(shù)構(gòu)成
白盒測試技術(shù)、黑盒測試技術(shù)、自動化測試技術(shù)人員、項目管理技術(shù)人員
測試部門組織結(jié)構(gòu)
9、白盒測試技術(shù)人員
該職位測試人員需要精通軟件開發(fā)語言,要有幾年的開發(fā)經(jīng)驗,能進行底層的代碼review,測試樁設(shè)計等,同時能夠食用百合測試工具對系統(tǒng)的最小功能單元進行測試,找出代碼、系統(tǒng)架構(gòu)方面的缺陷。
10、黑盒測試技術(shù)人員
要求測試人員有一定的軟件工程理論、軟件質(zhì)量保證知識。
11、自動化測試人員
需測試人員掌握軟件開發(fā)的知識,系統(tǒng)的調(diào)優(yōu),自動化測試工具,如QuickTest Professional LaodRunner。
測試部門組織結(jié)構(gòu)
12、項目管理技術(shù)人員
要求掌握一般的項目管理知識,如配置管理、版本控制、評審管理、項目實施與進度控制等。
13、資源構(gòu)成
14、硬件資源
需要齊備的測試環(huán)境,如測試PC機、測試服務(wù)器、測試芯片、測試手機等。
測試部門組織結(jié)構(gòu)
15、軟件資源
測試需要的操作系統(tǒng)、應(yīng)用軟件、管理軟件等。如Windows、Linux等操作系統(tǒng),SQL Server、Oracle等數(shù)據(jù)庫軟件,QuickTest Professional LaodRunner等自動化測試工具。
16、技術(shù)支持
當(dāng)測試人元遇到問題不能解決時,可由兄弟部門給予支持。確保在一個團隊合作的環(huán)境下,更高效的完成測試工作。
測試工作流程
測試工作流程
1、測試準(zhǔn)備階段
測試計劃制定
測試小組建立
測試工作流程
需求測試啟動
測試需求提取
測試工作流程
測試用例編寫
測試工作流程
2、測試開展階段
搭建測試環(huán)境—測試組長,可根據(jù)說明說中的軟件產(chǎn)品運行環(huán)境配置要求搭建。測試環(huán)境最好與開發(fā)環(huán)境分開
文檔引入—工作日報、功能測試報告、性能測試報告等模板
執(zhí)行測試—根據(jù)項目的Bug管理流程,經(jīng)過多次的版本迭代,完成測試工作。
測試工作流程
3、測試輸出階段
測試計劃
測試方案
測試用例
測試工程師的工作日報
功能測試報告
性能測試報告
思考與練習(xí)
1、軟件測試共有幾種模型?具體的內(nèi)容是什么?相互之間有什么區(qū)別與聯(lián)系?
2、簡要描述同行評審與階段評審的區(qū)別。
3、軟件測試與軟件開發(fā)的關(guān)系是什么?
4、什么叫軟件測試?軟件測試的目的是什么?
思考與練習(xí)
5、軟件測試的一般工作流程是什么?
6、軟件測試的測試流程是什么?各階段的工作內(nèi)容重點是什么?
7、當(dāng)你接到一個測試任務(wù)后,你如何開展測試工作?
軟件測試用例設(shè)計方法
什么是測試用例
測試用例( Test Case )是指對一項特定的軟件產(chǎn)品進行測試任務(wù)的描述,體現(xiàn)測試方案、方法、技術(shù)和策略。內(nèi)容包括測試目標(biāo)、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預(yù)期結(jié)果、測試腳本等,并形成文檔。
測試用例包含要素
每個具體測試用例都將包括下列詳細(xì)信息:編制人、審定人、編制日期、版本、用例類型、設(shè)計說明書編號、用例編號、用例名稱、輸入說明、期望結(jié)果(含判斷標(biāo)準(zhǔn))、環(huán)境要求、備注等。
具體可以參考建行測試用例模板
黑盒測試案例設(shè)計技術(shù)
測試用例設(shè)計:將軟件測試的行為活動,作為一個科學(xué)化的組織歸納。
測試用例:設(shè)計一個情況,軟件程序在這種情況下,必須能夠正常運行并且達(dá)到程序所設(shè)計的執(zhí)行結(jié)果。
因為我們不可能進行窮舉測試,為了節(jié)省時間和資源、提供測試效率,必須從數(shù)量極大的可用測試數(shù)據(jù)精心挑選出具有代表性或者特殊性的測試數(shù)據(jù)來進行測試。
測試測試用例的好處
在開始實施測試之前設(shè)計好測試用例,可以避免盲目測試并提高測試效率。
測試用例的使用令軟件測試的實施重點突出、目的明確。
在軟件版本更新后只修正少部分的測試用例便可展開測試工作,降低工作強度,縮短項目周期。
功能測試模塊的通用化和復(fù)用化使軟件易于開發(fā),而測試用例的通用化和復(fù)用化則會使軟件測試易于開展,并隨著測試用例的不斷精化其效率也不斷攀升。
常見黑盒測試用例設(shè)計方法
等價類劃分法
邊界值分析法
錯誤推測法
因果圖法
判定表驅(qū)動法
正交試驗設(shè)計法
功能圖法
場景法
等價類劃分法
等價類劃分的辦法是把程序的輸入域劃分成若干部分,然后從每個部分中選取少數(shù)代表性數(shù)據(jù)作為測試用例。
劃分等價類和列出等價類表
確定測試用例
劃分等價類和列出等價類表
等價類是指輸入域的子集合。在該子集合中,各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效,并合理地假設(shè):測試某等價類的代表值就等于對這類其他值的測試。
等價類劃分有兩種不同的情況:有效等價類和無效等價類。
劃分等價類和列出等價類表
有效等價類:指對于程序的規(guī)格說明書來說是合理的、有意義的輸入數(shù)據(jù)構(gòu)成的集合。利用有效等價類可以檢驗程序是否實現(xiàn)了規(guī)格說明書中所規(guī)定的功能和性能。
無效等價類:與有效等價類的定義恰巧相反。
6條確定等價類的原則
1、在輸入條件規(guī)定了取值范圍或者值個數(shù)的情況下,可以確定一個有效等價類和兩個無效等價類。
2、在輸入條件規(guī)定了輸入值的集合或者規(guī)定了“必須如何”的條件的情況下,可以確定一個有效等價類和一個無效等價類。
3、在輸入條件是一個布爾量的情況下,可以確定一個有效的等價類和一個無效的等價類
6條確定等價類的原則
4、在規(guī)定了輸入數(shù)據(jù)的一組值(假定n個),并且程序要對每一個輸入值分別處理的情況下,可以確定n個有效的等價類和一個無效的等價類。
5、在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下,可以確定一個有效等價類類(符合規(guī)則)和若干個無效等價類(從不同角度違反規(guī)則)。
6、在確知已劃分的等價類中,各元素在程序處理中的方式不同的情況下,則應(yīng)再將該等價類進一步地劃分為更小的等價類。
確定測試用例步驟
為每個等價類規(guī)定一個惟一的編號。
設(shè)計一個新的測試用例,使其盡可能多地覆蓋尚未覆蓋的有效等價類,重復(fù)這一步,最后使得所有的有效等價類均被測試用例所覆蓋。
設(shè)計一個新的測試用例,使其只覆蓋一個無效等價類。重復(fù)這一步使所有無效等價類均被覆蓋。
等價類劃分法例題
一個程序讀入3個整數(shù),把這3個數(shù)值看作一個三角形的3條邊的長度值。這個程序要打印出信息,說明這個三角形是不等邊的、是等腰的、還是等邊的。
構(gòu)成三角形的3條邊必須滿足:
A>0,B>0,C>0,且A+B>C,B+C>A,A+C>B
如果是等腰的,還要判斷A=B,或者B=C,或者A=C
如果是等邊的,則需要判斷是否A=B,且B=C,且A=C.
等價類表
設(shè)計測試用例
邊界值分析法
邊界值分析:是考慮邊界條件而選取測試用例的一種 黑盒測試方法,是對等價類劃分方法的補充。
實踐證明,軟件在輸入、輸出域的邊界附近容易出現(xiàn)差錯, 而不是在輸入范圍的內(nèi)部。因此針對各種邊界情況設(shè)計測試用例,可以查出更多的錯誤。
邊界值分析法
使用邊界值分析方法設(shè)計測試方案首先應(yīng)該確定邊界情況,通常輸入等價類和輸出等價類的邊界,就是應(yīng)該注重測試的程序邊界情況。
選取的測試數(shù)據(jù)應(yīng)該正好等于、剛剛小于和剛剛大于邊界值,也就是說,按照邊界值分析法,應(yīng)該選取剛好等于、稍小于和稍大于等價類邊界值作為測試數(shù)據(jù),而不是選取每個等價類內(nèi)的典型值或任意值作為測試數(shù)據(jù)。
基于邊界值分析方法選擇測試用例的原則
如果輸入條件規(guī)定了值的范圍,則應(yīng)取剛達(dá)到這個范圍的邊界的值,以及剛剛超越這個范圍邊界的值作為測試輸入數(shù)據(jù)。
如果輸入條件規(guī)定了值的個數(shù),則用最大個數(shù),最小個數(shù),比最小個數(shù)少一,比最大個數(shù)多一的數(shù)作為測試數(shù)據(jù)。
根據(jù)規(guī)格說明的每個輸出條件 ,考慮值的范圍情況。
基于邊界值分析方法選擇測試用例的原則
。根據(jù)規(guī)格說明的每個輸出條件 ,考慮值的個數(shù)情況。
如果程序的規(guī)格說明給出的輸入域或輸出域是有序集合,則應(yīng)選取集合的第一個元素和最后一個元素作為測試用例。
如果程序中使用了一個內(nèi)部數(shù)據(jù)結(jié)構(gòu),則應(yīng)當(dāng)選擇這個內(nèi)部數(shù)據(jù)結(jié)構(gòu)的邊界上的值作為測試用例
分析規(guī)格說明,找出其它可能的邊界條件。
錯誤推測方法
基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設(shè)計測試用例的方法。
錯誤推測方法的基本思想:列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況,根據(jù)他們選擇測試用例。
錯誤推測方法常見依據(jù)
在單元測試時曾列出的許多在模塊中常見的錯誤。
以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等。
已發(fā)現(xiàn)缺陷的測試方法的推廣。
容易發(fā)生錯誤的情況。
補充等價類和邊界值法遺漏的一些等價類組合。
一些位置使用了共享變量,設(shè)計測試用例,修改一個共享變量,看其他位置有沒有同 時做修改
因果圖設(shè)計方法
因果圖方法是對等價類的擴展 , 可以理解為 “ 等價類組合判定表 ” 。因果圖即輸入等價類與輸出等價類的關(guān)系圖
因果圖生成測試用例的基本步驟
分析軟件規(guī)格說明描述中, 那些是原因 ( 即輸入條件或輸入條件的等價類 ) ,那些是結(jié)果 ( 即輸出條件 ) , 并給每個原因和結(jié)果賦予一個標(biāo)識符。
分析軟件規(guī)格說明描述中的語義。找出原因與結(jié)果之間, 原因與原因之間對應(yīng)的關(guān)系 。根據(jù)這些關(guān)系,畫出因果圖。
因果圖生成測試用例的基本步驟
表明約束條件。由于語法或環(huán)境限制, 有些原因與原因之間,原因與結(jié)果之間的組合情況不不可能出現(xiàn)。 為表明這些特殊情況, 在因果圖上用一些記號表明約束或限制條件。
把因果圖轉(zhuǎn)換成判定表
為判定表中每一列表示的情況設(shè)計測試用例。
正交試驗法
正交試驗設(shè)計方法:是從大量的試驗數(shù)據(jù)中挑選適量的、有代表性的點,從而合理的安排測試的一種科學(xué)的試驗設(shè)計方法
正交試驗測試用例設(shè)計步驟
提取功能說明,構(gòu)造因子 狀態(tài)表。
加權(quán)篩,生成因素分析表
利用正交表構(gòu)造測試數(shù)據(jù)集。
正交試驗法優(yōu)點
節(jié)省測試工時。
可控制測試用例的數(shù)量。
測試用例具有一定的覆蓋率。
正交試驗法在軟件測試中是一種有效的方法,例如在平臺參數(shù)配置方面,我們要選擇哪種組合方式是最好的,每個參數(shù)可能就是一個因子,參數(shù)的不同取值就是平水,采用正交試驗法設(shè)計出最少的測試組合,達(dá)到有效測試目的。
功能圖分析方法
功能圖方法:用功能圖形象地表示程序功能說明,并生成功能圖的測試用例。
又可以稱作流程測試或狀態(tài)遷移測試
類似于白盒測試中的邏輯覆蓋和路徑法
需要懂得控制語句(循環(huán),順序,選擇,重復(fù))
功能圖生成測試用例過程
在每個狀態(tài)生成局部測試用例。
測試路徑生成:從初始狀態(tài)到最后狀態(tài)的測試路徑
測試用例合成:合成測試路徑和功能圖中每個狀態(tài)的局部測試用例。
測試用例合成算法:條件構(gòu)造樹。
場景法
事件觸發(fā)控制流程,事件觸發(fā)時的情景便形成場景。
同一事件不同的觸發(fā)順序和處理結(jié)果就形成事件流
用例場景用來描述流經(jīng)用例的路徑,從用例開始到結(jié)束遍歷這條路徑的有基本流和備選流。
測試用例選擇的綜合策略
1、首先進行等價類劃分,包括輸入條件和輸出條件的等價類劃分,將無限測試變成有限測試,這是減少工作量和提高測試效率的有效方法。
2、在任何情況下都必須使用邊界值分析方法。經(jīng)驗表明,用這種方法設(shè)計出的測試用例發(fā)現(xiàn)程序錯誤的能力最強
測試用例選擇的綜合策略
3、可以用錯誤推測法追加一些測試用例,這些需要依靠測試工程師的智慧和經(jīng)驗。
4、對照程序邏輯,檢查已 設(shè)計的測試用例的邏輯覆蓋程序,如果沒有達(dá)到要求的覆蓋標(biāo)準(zhǔn),應(yīng)當(dāng)再補充足夠的測試用例。
5、如果程序的功能說明中含有輸入條件的組合,則一開始就可以選因果圖法和判定表驅(qū)動法。
6、對參數(shù)配置類的軟件,要用正交試驗法選擇較少的組合方式達(dá)到最佳的測試效果
測試用例選擇的綜合策略
7、功能圖法也是很好的測試用例設(shè)計方法,我們可以通過不同時期條件的有效性設(shè)計不同的測試數(shù)據(jù)。
8、對于業(yè)務(wù)流清晰的系統(tǒng),可以利用場景法貫穿整個測試案例過程,在案例中綜合使用各種測試方法。
軟件缺陷
什么是軟件缺陷
符合下面 5 條規(guī)則之一的問題稱為軟件缺陷:
1、軟件未達(dá)到產(chǎn)品說明書標(biāo)明的功能。
2、軟件出現(xiàn)產(chǎn)品說明書指明不會出現(xiàn)的錯誤。 (如果軟件含有產(chǎn)品說明中根本沒有存在的功能,這是缺陷)
3、軟件功能超出產(chǎn)品說明書指明的范圍。
4、軟件未達(dá)到產(chǎn)品說明書未指出但應(yīng)達(dá)到的目標(biāo)。 (產(chǎn)品說明書雖然沒有提到,但是按照常理應(yīng)該達(dá)到的功能)
5、軟件測試人員或用戶認(rèn)為軟件難以理解,不易使用,運行速度緩慢等問題。
缺陷的生命周期
簡單周期:
測試員找到并登記軟件缺陷,軟件缺陷移交到程序員=>程序員修復(fù)軟件缺陷,軟件缺陷移交到測試員=>測試員確定軟件缺陷被修復(fù),測試員關(guān)閉軟件缺陷。
缺陷的生命周期
復(fù)雜周期:
發(fā)現(xiàn)缺陷(測試員發(fā)現(xiàn)并登記缺陷,軟件缺陷轉(zhuǎn)到程序員)=>軟件缺陷移交到項目管理員=>(以不修復(fù)形式解決)項目管理員認(rèn)為軟件缺陷不重要,軟件缺陷移交到測試員=>重新激活缺陷(測試員不同意,找出通用失敗案例,軟件缺陷移交到項目管理員)=>項目管理員同意缺陷需要修復(fù),缺陷轉(zhuǎn)給程序員=>以修復(fù)形式解決(測試員確認(rèn)軟件缺陷得以修復(fù),測試員關(guān)閉軟件缺陷)=>缺陷關(guān)閉
報告缺陷的要點
復(fù)雜周期:
發(fā)現(xiàn)了軟件缺陷,需要記錄下來,不但要記錄結(jié)果,同時需要詳細(xì)描述發(fā)現(xiàn)的步驟,以備程序員重現(xiàn)問題,并解決它。
要求報告寫的清楚明了和準(zhǔn)確。有時利用截屏技術(shù)把當(dāng)時的情況保存成圖片,可以達(dá)到一圖勝千言的效果。
參考軟件測試缺陷跟蹤管理說明.pdf文檔
( vss\09_測試團隊\公共\規(guī)范說明)
缺陷的嚴(yán)重性分類
A類——致命性:
不能完全滿足系統(tǒng)要求,基本業(yè)務(wù)功能未實現(xiàn)系統(tǒng)崩潰、不穩(wěn)定或掛起等導(dǎo)致系統(tǒng)不能繼續(xù)運行、導(dǎo)致系統(tǒng)出現(xiàn)不可預(yù)料的嚴(yán)重錯誤的問題。
缺陷的嚴(yán)重性分類
B 類 —— 嚴(yán)重錯誤:
嚴(yán)重地影響系統(tǒng)要求或基本功能的實現(xiàn),且沒有辦法更正(重新安裝 或重新啟動不屬于更正辦法)。使系統(tǒng)不穩(wěn)定、破壞數(shù)據(jù)、產(chǎn)生錯誤結(jié)果,部分功能無法執(zhí)行 。
缺陷的嚴(yán)重性分類
C 類 —— 一般性錯誤:
1、界面錯誤。
2、非重要功能無法正確執(zhí)行, 實現(xiàn)不正確, 實現(xiàn)不完整,但不影響功能
3、非嚴(yán)重性產(chǎn)生錯誤結(jié)果,但不影響一起功能。
4、正確性不受影響,但系統(tǒng)性能和響應(yīng)時間受到影響。
缺陷的嚴(yán)重性分類
D 類 —— 輕微錯誤:
使操作者不方便或遇到麻煩,但它不影響執(zhí)行工作功能或重要功能, 或?qū)ψ罱K結(jié)果影響有限的問題。
缺陷的嚴(yán)重性分類
E 類 —— 測試建議:
不影響系統(tǒng)運行,對系統(tǒng)的可用性等提示的建議性的問題。
例如:
1、系統(tǒng)各個位置初始值的建議。
2、流程優(yōu)化建議等等。
缺陷分析
缺陷分析就是分析缺陷在與缺陷關(guān)聯(lián)關(guān)系的一個或多個參數(shù)值上的分布。缺陷分析提供了一個軟件可靠性指標(biāo)
缺陷分析主要參數(shù)
狀態(tài):缺陷的當(dāng)前狀態(tài)(打開的、正在修復(fù)或關(guān)閉的等)。
優(yōu)先級:必須處理和解決缺陷的相對重要性。
嚴(yán)重性:缺陷的相關(guān)影響。對最終用戶、組織或第三方的影響等等。
起源:導(dǎo)致缺陷的起源故障及其位置,或排除該缺陷需要修復(fù)的構(gòu)件
缺陷分析報告
可以將缺陷計數(shù)作為時間的函數(shù)來報告,即創(chuàng)建缺陷趨勢圖或報告;
也可以將缺陷計數(shù)作為一個或多個缺陷參數(shù)的函數(shù)來報告,如作為缺陷密度報告中采用的嚴(yán)重性或狀態(tài)參數(shù)的函數(shù)。
這些分析類型分別為揭示軟件可靠性的缺陷趨勢或缺陷分布提供了判斷依據(jù)
軟件測試的技巧
測試技巧分類
結(jié)構(gòu)測試相對于功能測試
動態(tài)測試相對于靜態(tài)測試
手工測試相對于自動測試
結(jié)構(gòu)測試技巧
壓力測試
執(zhí)行測試
恢復(fù)測試
操作測試
復(fù)合性測試(與過程的復(fù)合性)
安全測試
壓力測試
目標(biāo)
模擬出實際用戶環(huán)境
怎么用
產(chǎn)生測試數(shù)據(jù)
測試組模擬用戶處理被創(chuàng)建的數(shù)據(jù)
例子
確定是否分配了足夠的磁盤空間
通訊的容量是否足夠
測試系統(tǒng)過載的情況
什么時間使用
當(dāng)關(guān)于容量的信息不確定的時候
性能測試技巧
目標(biāo)
確定系統(tǒng)達(dá)到了希望達(dá)到的性能水平
如何使用
使用軟件和硬件的監(jiān)視器
使用模擬的監(jiān)控模型,對關(guān)心的性能指標(biāo)進行監(jiān)控
創(chuàng)建一個小程序
例子
計算通信的時間
單位時間處理的信息量
什么時候使用
- 在程序開發(fā)的早期進行
恢復(fù)測試
目標(biāo)
當(dāng)在進行安裝或組裝操作過程中,文件丟失時或發(fā)生意外后系統(tǒng)有能力重新進行操作
如何使用
程序的安裝,運行方式,工具的使用和關(guān)鍵技術(shù)經(jīng)過足夠的評估
系統(tǒng)開發(fā)完畢后,介紹一下發(fā)生失敗后的處理過程
例子
人為的使一個系統(tǒng)在安裝或者組裝過程中產(chǎn)生錯誤
什么時間去使用
當(dāng)操作的連續(xù)性是個重點的時候
操作測試
目標(biāo)
確定計算機的操作文檔已經(jīng)完整
如何使用
作為計算機正常操作的一部分來執(zhí)行測試
例子
操作的介紹被文檔化,操作者被培訓(xùn)
什么時候使用
預(yù)先將程序進行產(chǎn)品化。操作性是系統(tǒng)的一個重要指標(biāo)的時候。
復(fù)合性測試
目標(biāo)
校驗程序的開發(fā)是否依照已定義的標(biāo)準(zhǔn),流程和操作方式進行的。
如何去使用
將文檔/程序同標(biāo)準(zhǔn)相比較
比較有效的方法是檢查過程
例子
代碼互查(一行一行)
什么時候使用
依賴于管理的需要
安全性測試
目標(biāo)
安全性的缺陷很難被發(fā)現(xiàn)。
大多數(shù)的情況下組織能夠防止一般性的破壞者。
如何使用
對安全性的需求進行評審
分析與安全性有關(guān)的處理流程
轉(zhuǎn)包給專業(yè)的人員
例子
定義了被保護的資源,權(quán)限進行了控制,日志文件和審查追蹤是可用的。
什么時間使用
當(dāng)被保護的資源對于組織具有重要的價值的時候
功能測試技巧
需求測試
回歸測試
錯誤處理測試
支持手冊的測試
系統(tǒng)兼容測試
控制性測試
并行測試
需求測試
目標(biāo)
用戶的需求可以被實現(xiàn)
如何使用
創(chuàng)建測試用例和功能檢查列表
例子
建立測試矩陣去證實系統(tǒng)需求均被文檔化
什么時候使用
每一個應(yīng)用程序都要進行需求測試
回歸測試
目標(biāo)
程序修改后,確保功能的正確性
如何使用
重新測試應(yīng)用程序中沒有改變的部分
例子
重新執(zhí)行以前的測試用例
什么時間使用
當(dāng)新的程序有可能影響老的功能的時候
錯誤處理測試
目標(biāo)
所有可能的錯誤條件均經(jīng)過了驗證
如何使用
一組有經(jīng)驗的人員預(yù)測在那里會出現(xiàn)問題
例子
建立一個錯誤處理的列表
什么時候使用
貫穿整個開發(fā)生命周期
支持手冊測試
目標(biāo)
檢驗操作過程被文檔化了,并且完整了。
如何使用
對過程有足夠的介紹
可以協(xié)助用戶正常使用
例子
系統(tǒng)在一定的條件下產(chǎn)生一個提示,用戶被告知如何采取必要的操作。
什么時候使用
最佳時機是在安裝測試的時候,但是應(yīng)該在開發(fā)全過程中。
兼容性測試
目標(biāo)
檢驗當(dāng)使用適當(dāng)?shù)膮?shù)和數(shù)據(jù)時,需要的信息可以在兩個系統(tǒng)中正確的交換
如何使用
文件和數(shù)據(jù)被用來在多系統(tǒng)之間傳遞。
例子
典型的由一個系統(tǒng)到另一個系統(tǒng)的數(shù)據(jù)交換程序。
什么時候使用
當(dāng)兩個應(yīng)用程序之間的參數(shù)有可能發(fā)生變化的時候
管理能力測試
目標(biāo)
驗證數(shù)據(jù)交換時有足夠的審計追蹤能力
如何使用
關(guān)鍵數(shù)據(jù)或者有價值的數(shù)據(jù)
例子
從負(fù)面來看程序,是否確保了會出錯的條件都被保護了。
什么時候使用
系統(tǒng)測試的一部分
并行測試
目的
新版本和老版本同時運行,用以確保新版本的程序運行正確。
如何使用
需要對兩個系統(tǒng)輸入相同的數(shù)據(jù)來運行
例子
運行新舊兩個工資支付系統(tǒng)
什么時間使用
當(dāng)對新系統(tǒng)的的運行情況不確定的時候
單元測試
關(guān)注單元一級
代碼分析和測試
功能分析和測試
結(jié)構(gòu)分析和測試
以錯誤為導(dǎo)向的分析和測試
測試要素/測試技巧矩陣
測試要素/測試技巧矩陣
測試工具的選擇
測試工具
測試標(biāo)準(zhǔn)
邊界值分析
因果圖
檢查表
代碼比較對照
以編譯為基礎(chǔ)的分析
確認(rèn)/檢查
控制流分析
測試工具
能證明正確性的數(shù)據(jù)
以覆蓋為基礎(chǔ)的測試
數(shù)據(jù)字典
數(shù)據(jù)流分析
以設(shè)計為基礎(chǔ)的功能測試
設(shè)計評審
桌面檢查
災(zāi)難性測試
測試工具
錯誤猜測
執(zhí)行的規(guī)則
全面的測試
實況調(diào)查
流程圖
檢查,視察
使用儀器設(shè)備
綜合測試設(shè)備
映射圖
測試工具
建模
并行操作
并行模擬
代碼互查
風(fēng)險矩陣
系統(tǒng)控制的評審
得分
快照(把系統(tǒng)一個時刻的情況保存下來)
測試工具
完成特征
系統(tǒng)日志
測試用例
測試用例的產(chǎn)生形式
跟蹤
工具程序
容量的測試
走查(講解開發(fā)思路)
選擇和使用測試工具
按照用途選擇匹配的工具
在適當(dāng)?shù)纳芷谶x擇工具
按照測試人員的實際技能選擇匹配的工具
選擇一個可提供的工具
測試工具/測試技巧矩陣
測試工具/測試技巧矩陣
測試工具/測試技巧矩陣
測試工具/測試技巧矩陣
測試工具/測試技巧矩陣
軟件開發(fā)生命周期/測試工具對照表
軟件開發(fā)生命周期/測試工具對照表
軟件開發(fā)生命周期/測試工具對照表
軟件開發(fā)生命周期/測試工具對照表
測試工具管理
工具管理者的職責(zé)
對工具負(fù)責(zé)
幫助同事使用這些工具
培訓(xùn)工具得使用方法
負(fù)責(zé)同工具的廠家聯(lián)系
每年給出有關(guān)工具使用和購買得計劃
工具得升級
工具情況報告
工具管理者得任期不易太長
測試工具管理
工具管理者的職責(zé)
對工具負(fù)責(zé)
幫助同事使用這些工具
培訓(xùn)工具得使用方法
負(fù)責(zé)同工具的廠家聯(lián)系
每年給出有關(guān)工具使用和購買得計劃
工具得升級
工具情況報告
工具管理者得任期不易太長
軟件的測試整個過程
估算
測試計劃
需求
設(shè)計
編碼
測試總結(jié)
安裝,交付
維護
估算
估算什么
測試對軟件工作量的估算的準(zhǔn)確性
測試評估軟件系統(tǒng)的狀況的準(zhǔn)確性
關(guān)注點:
不準(zhǔn)確的估算
不適當(dāng)?shù)拈_發(fā)過程
不真實的狀態(tài)報告
對工作量的估算
如何知道對工作量的估算是正確的
估算工作量的工具很容易出錯
對軟件工作量的估算需要策略
五個一般的方法
猜
加入一些約束條件
以一些數(shù)據(jù)為基礎(chǔ)
模擬進行工作
將一些參數(shù)模型化
參數(shù)模型法
回歸模型:將現(xiàn)有的參數(shù)與已有的歷史數(shù)據(jù)相擬和。
啟發(fā)式模型:對歷史數(shù)據(jù)進行觀察和解釋
現(xiàn)象模型:假設(shè)軟件開發(fā)過程可以依據(jù)一些更廣泛的可適用的過程解釋。
模型遵循的共同模式
估算軟件的大小
將大小轉(zhuǎn)化成人力的估算,并且作出可能的成本的估算
依據(jù)項目的特性進行估算的調(diào)整
將整體的估算劃分到不同的項目階段中
估算不包括技巧上面的人力和計算機的運行時間
將以上內(nèi)容相加
對估算進行檢驗
檢驗估算模型的合理性
檢驗?zāi)P褪欠癜吮仨毜臏y試要素
檢驗?zāi)P偷恼_性
校驗估算模型的正確性
重新進行估算
校驗輸入是否正確
校驗輸入是否合理
校驗對數(shù)據(jù)的計算是否合理有效
比較延期的估算是否符合項目實際情況
讓謹(jǐn)慎的人來作測試驗證工作
對軟件中的冗余價值估算
影響估算正確與否的因素
軟件規(guī)模
新設(shè)計新代碼的比例
復(fù)雜程度
設(shè)計和編碼的困難
使用什么語言
安全性
需求的揮發(fā)性
影響估算正確與否的因素
組織因素
項目計劃
人員
開發(fā)環(huán)境
計算機資源
人員利用率
膨脹因素
估算就是估算,不是保證書
軟件進展測試
追蹤系統(tǒng)的瓶頸
工作完成點
同配置管理系統(tǒng)緊密的結(jié)合
如何使用
模塊列表
里程碑
工作完成點
用計算所有工作的完成度來檢查系統(tǒng)工作過程。
測試計劃
開發(fā)測試計劃
目標(biāo)
詳細(xì)的描述怎樣能成功的完成測試工作,其中應(yīng)包含必須的資源和實施計劃。
可能的不利因素:
沒有得到足夠的培訓(xùn)
心里準(zhǔn)備不足
缺乏測試工具
缺乏管理的標(biāo)準(zhǔn)和支持
缺乏客戶和最終使用者的參與
沒有足夠的時間進行測試
對于獨立的測試人員過度信任
版本改變的太快
測試人員處于不受重視的情況中
不能說不
實施過程
聽取各方面的意見和建議
標(biāo)明項目風(fēng)險
測試要素
聯(lián)系測試矩陣
建立測試計劃
對計劃進行評審
建立測試計劃
定義測試目標(biāo)
開發(fā)測試矩陣
軟件模型
結(jié)構(gòu)特性
批量測試的階段和用例
為在線系統(tǒng)作概念上的測試腳本
軟件測試矩陣
定義測試管理
測試計劃的一般性信息
定義測試?yán)锍瘫?span style="display:none">PRP紅軟基地
定義管理上的檢查點
書寫測試計劃
評審測試計劃
涉及評審的問題
評審測試的開始時間是否會延期
有沒有抵觸評審的角色
一段時間內(nèi)是否很難得到工作的檢查信息。
更換工具有可能導(dǎo)致他們反感評審工作
評審結(jié)果可能會影響對個人的工作評價
對于最終成品的檢查
項目的需求規(guī)格說明書
軟件返工/維護的文檔
升級后的技術(shù)文檔
被更改的源程序
測試計劃
用戶手冊(包括在線幫助)
評審測試計劃
正式評審中的角色
緩和劑(SQA)
讀者
記錄者
作者
檢測員
正式評審發(fā)現(xiàn)的缺陷應(yīng)包含的信息
起因
類型
分類
級別
評審流程
計劃和組織
通篇的講解(可選)
個人準(zhǔn)備
評審會議
修訂和反復(fù)
需求階段的測試
測試成本
在軟件開發(fā)的所有階段進行測試
被設(shè)計用來減少測試成本
IBM的數(shù)據(jù)
大約 60個缺陷/千行
2/3的缺陷產(chǎn)生在需求和設(shè)計階段
在需求和設(shè)計階段發(fā)現(xiàn)的缺陷修正的花費最小
修正系統(tǒng)測試階段發(fā)現(xiàn)的缺陷,花費是以上的10倍
發(fā)布產(chǎn)品以后,修正缺陷的花費是原來的100倍
生命周期的測試概念
在軟件開發(fā)過程中持續(xù)的進行測試
在盡可能早的階段點去修正缺陷
需要正式的開發(fā)流程來支持
組建測試團隊
當(dāng)開發(fā)開始進行的時候,測試就開始進行了
需求階段的測試
準(zhǔn)備風(fēng)險列表
確定風(fēng)險組
確定風(fēng)險
風(fēng)險分析
風(fēng)險檢查表
建立控制目標(biāo)
確定有足夠的控制力度
分析測試要素
需求的設(shè)計是否遵循了已定義的方法
提交了已定義的功能說明
定義了系統(tǒng)界面
已經(jīng)估計了性能標(biāo)準(zhǔn)
容忍度被預(yù)先估計
預(yù)先定義了權(quán)限規(guī)則
需求中預(yù)先定義了文件完整性
預(yù)先定義了需求的變更流程
預(yù)先定義了失敗的影響
權(quán)限定義
需求走查
建立基本規(guī)則
選擇小組/通報參與者
項目介紹
問題/建議
形成最終報告
需求階段測試
所有的花費都是值得的
大部分缺陷將不會進入到設(shè)計&編碼階段
目標(biāo)
需求正確的表現(xiàn)出了用戶的需要
需求已經(jīng)被定義和文檔化了
花費和收益成正比
需求的控制被明確
有合理的流程可遵循
有合理的方法可供選擇
設(shè)計階段的測試
設(shè)計階段的測試
交付的產(chǎn)品
輸入說明
過程說明
文件說明
輸出說明
控制說明
系統(tǒng)流程圖
硬件和軟件的需求
操作手冊說明書
數(shù)據(jù)保留的策略
設(shè)計階段測試任務(wù)
給測試要素打分
分析測試要素
對設(shè)計進行評審
檢查修改的部分
分析測試要素
測試涉及的內(nèi)容:
設(shè)計了對數(shù)據(jù)完整性的控制
設(shè)計了權(quán)限規(guī)則
設(shè)計了對文件完整性的控制
設(shè)計了審計追蹤
設(shè)計了發(fā)生意外情況時的計劃
設(shè)計了如何達(dá)到服務(wù)水平的方法
定義了權(quán)限流程
定義了完整的方法學(xué)
設(shè)計了保證需求一致性的方法
進行了易用性的設(shè)計
設(shè)計是可維護的
設(shè)計是簡單的
交互界面設(shè)計完畢
定義了成功的標(biāo)準(zhǔn)
需要同實際操作者溝通
對設(shè)計進行評審
選擇評審組成員
對評審組進行培訓(xùn)
通報項目組
分配足夠的時間
只對文檔化的事實進行評審
和項目組一起進行評審
對評審形成建議
和項目組對建議一起進行評審
準(zhǔn)備正式的報告
編碼階段的測試
形成的輸出
編碼說明書
程序文檔
計算機程序列表
可執(zhí)行的程序
程序流程圖
操作介紹
單元測試結(jié)果
測試活動的關(guān)注點
完成對數(shù)據(jù)完整性的控制
定義完畢授權(quán)的規(guī)則
完成對文件完整性的控制
實現(xiàn)審計追蹤
規(guī)劃出意外情況發(fā)生后的處理計劃
對系統(tǒng)如何達(dá)到預(yù)定義的服務(wù)水平做了計劃
完成了對安全問題的處理流程
編碼工作是依據(jù)規(guī)定的方法完成的
編碼與設(shè)計相一致(正確性)
編碼與設(shè)計相一致(易用性)
代碼是可維護的
編碼與設(shè)計相一致(簡潔性)
編碼與設(shè)計相一致(耦合性)
已開發(fā)了操作流程
定義出程序成功的標(biāo)準(zhǔn)(性能上)
測試的職責(zé)
編碼是一個純技術(shù)的工作,幾乎不需要用戶的參與
項目領(lǐng)導(dǎo)者有參與測試的責(zé)任
監(jiān)督過程的有效性
建議的測試方式
桌面調(diào)試
語法上的
結(jié)構(gòu)上的
功能上的
代碼互查
建立基本的互查規(guī)則
選擇互查的team
對成員進行培訓(xùn)
選擇互查的方法
提供互查的材料
流程圖,源程序,典型的處理流程
對互查進行必要的管理
給出互查結(jié)論
提供最終的報告
編碼階段的測試需解決的問題
系統(tǒng)是可維護的嗎?
系統(tǒng)說明是否已經(jīng)完成了?
編碼是否按照既有的標(biāo)準(zhǔn)進行,過程是否易于實踐?
是否有足夠的測試計劃用來評估可執(zhí)行的程序?
是否編制了足夠的文檔。
測試關(guān)注點
在需求,設(shè)計,編碼階段多進行一些測試,在系統(tǒng)測試階段就會少一些問題。
文檔
測試階段的測試計劃
測試用例
前期測試的測試結(jié)果
第三方測試反饋,例如:計算機操作人員
正式的測試總結(jié)報告
典型測試類型
手冊,回歸,功能點測試
一致性測試(授權(quán))
功能點測試(完整性)
功能點測試(審計,追蹤)
覆蓋性的測試(測試的連續(xù)性)
壓力測試(服務(wù)水平)
一致性測試(安全性)
依照預(yù)先定義的測試方法
功能點測試(正確性)
支持手冊的測試(易用性)
檢查(可維護性)
災(zāi)難性的測試(可攜帶性)
功能和回歸測試(耦合性)
一致性的測試(性能)
操作性的測試(易用性)
建議測試方法
測試方法
測試用例的概念是簡單的
建立有效的測試用例是復(fù)雜的
設(shè)計測試文件
測試用例應(yīng)當(dāng)包含合法的和非法的輸入
每一個動作只進行一次關(guān)鍵操作
輸入測試數(shù)據(jù)
分析結(jié)果
嘗試將測試文件違反程序的規(guī)則進行輸入
容量測試的測試工具
以大信息量的數(shù)據(jù)進行輸入
這是一個昂貴的測試,應(yīng)根據(jù)需要來選擇
在線系統(tǒng)需要做壓力測試
測試總結(jié)
測試報告
目標(biāo)
表示出目前項目的實際狀況
明確什么是測試做的工作,什么是不作的工作。
給出系統(tǒng)的操作性能的評價
明確什么時候系統(tǒng)可以進行產(chǎn)品化的工作
關(guān)注點
測試報告只有真正需要的時候才有用,需要配合市場和管理
測試的信息是不充分的(對于評價一個項目來說)
測試狀況并不能真實的反應(yīng)個人的狀況
測試期間數(shù)據(jù)的收集
有關(guān)測試結(jié)果的積累數(shù)據(jù)
測試任務(wù),測試集合和測試事件的描述
缺陷分析
由于計劃的問題,導(dǎo)致沒有發(fā)現(xiàn)的缺陷的數(shù)據(jù)
嚴(yán)重的缺陷
缺陷類型
為什么缺陷沒有發(fā)現(xiàn)
效果
測試報告
報告目前的軟件狀態(tài)
功能/測試矩陣
功能測試的狀態(tài)報告,側(cè)重點分析
關(guān)于功能的工作時間軸
期望發(fā)現(xiàn) VS 實際發(fā)現(xiàn)的缺陷比
沒有發(fā)現(xiàn)的缺陷和改正的缺陷的差距
按照類型分類,沒有改正的缺陷的平均值
缺陷分類報告
測試活動報告
最終的報告匯總
各個階段的項目測試總結(jié)報告
繼承性測試報告
系統(tǒng)測試報告
確認(rèn)測試報告培訓(xùn)ppt課件模板:這是培訓(xùn)ppt課件模板,包括了文章背景知識,認(rèn)字識詞朗誦,課文賞析,拓展訓(xùn)練/分組練習(xí)等內(nèi)容,歡迎點擊下載。
幼兒教師師德培訓(xùn)ppt1:這是幼兒教師師德培訓(xùn)ppt1,包括了引言,幼兒園教師師德現(xiàn)狀,幼兒園師德建設(shè)存在的問題,原因分析,對策建議等內(nèi)容,歡迎點擊下載。
釘釘培訓(xùn)ppt:這是釘釘培訓(xùn)ppt,包括了釘釘軟件介紹,釘釘常用功能,公司啟用釘釘考勤操作指南,公司啟用釘釘時間等內(nèi)容,歡迎點擊下載。