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