軟件測(cè)試簡(jiǎn)介

1、軟件測(cè)試簡(jiǎn)介第十二章 軟件測(cè)試簡(jiǎn)介軟件測(cè)試基本概念軟件測(cè)試分類(lèi)自動(dòng)化測(cè)試常見(jiàn)測(cè)試工具BUG管理流程軟件測(cè)試的定義：使用人工或自動(dòng)的手段來(lái)運(yùn)行或測(cè)定某個(gè)軟件系統(tǒng)的過(guò)程，其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。是幫助識(shí)別開(kāi)發(fā)完成（中間或最終的版本）的計(jì)算機(jī)軟件（整體或部分）的正確度(Correctness) 、完全度(Completeness)和質(zhì)量(Quality)的軟件過(guò)程；軟件測(cè)試是為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行的過(guò)程。定義軟件測(cè)試歷史1947年 ，測(cè)試等同于調(diào)試1957年，測(cè)試是為了表明程序正確而進(jìn)行的1972年，測(cè)試是為發(fā)現(xiàn)錯(cuò)誤而至此能夠的一個(gè)程序或者系統(tǒng)的過(guò)程

2、1996年，提出測(cè)試能力成熟度TCMM(Testing Capability Maturity Model)，測(cè)試支持度TSM（Testability Support Model)，測(cè)試成熟度TMM（Testing Maturity Model)，測(cè)試工具流行。2002年，測(cè)試是為了度量和提高被測(cè)軟件的質(zhì)量，對(duì)測(cè)試件進(jìn)行工程設(shè)計(jì)、實(shí)施和維護(hù)的整個(gè)生命周期過(guò)程。軟件測(cè)試著名失敗案例獅子王案例：缺乏配置測(cè)試Intel浮點(diǎn)除法軟件缺陷美國(guó)航天局火星登陸愛(ài)國(guó)者導(dǎo)彈防御系統(tǒng)軟件缺陷軟件未達(dá)到產(chǎn)品說(shuō)明書(shū)（簡(jiǎn)稱(chēng)，SPEC）標(biāo)明的功能；軟件出現(xiàn)了產(chǎn)品說(shuō)明書(shū)指明不會(huì)出現(xiàn)的錯(cuò)誤；軟件功能超出產(chǎn)品說(shuō)明書(shū)指明范圍；軟

3、件未達(dá)到產(chǎn)品說(shuō)明書(shū)雖未指出但應(yīng)達(dá)到的目標(biāo)，此條的目的是抓住產(chǎn)品說(shuō)明書(shū)上遺漏之處；軟件測(cè)試員認(rèn)為軟件難以理解、不易使用、運(yùn)行速度緩慢，或者最終用戶(hù)認(rèn)為不好。軟件模型或者說(shuō)業(yè)務(wù)建模制定不正確，更直觀的理解是，SEPC本身不明確或有錯(cuò)誤，沒(méi)有能很好的描述要開(kāi)發(fā)的軟件，這類(lèi)原因占了70%左右，并且很難于糾正；軟件龐大，功能十分復(fù)雜；編程過(guò)程出錯(cuò)，此類(lèi)原因?qū)е碌腻e(cuò)誤大概占20%，一般來(lái)說(shuō)比較容易糾正；個(gè)別功能要求改變而影響到其他部分；與要開(kāi)產(chǎn)的軟件對(duì)接的第三方軟件有缺陷；人為因素，常見(jiàn)的因素包括：項(xiàng)目組管理方法、項(xiàng)目進(jìn)度要求時(shí)間緊、項(xiàng)目組配備人力不足、組內(nèi)及組外溝通不充分等幾種情況。產(chǎn)生軟件缺陷的原因糾

4、錯(cuò)階段糾錯(cuò)階段單位費(fèi)用單位費(fèi)用1功能需求搜集分析/軟件設(shè)計(jì)階段1單位費(fèi)用2編程或分塊測(cè)試階段5單位費(fèi)用3整體或系統(tǒng)測(cè)試階段10單位費(fèi)用4早期用戶(hù)試用或Beta測(cè)試階段15單位費(fèi)用5軟件推出市場(chǎng)后30單位費(fèi)用發(fā)現(xiàn)階段修正花費(fèi)對(duì)照表軟件測(cè)試的原則為了能夠更好的進(jìn)行軟件測(cè)試，提高測(cè)試的整體效率，降低項(xiàng)目的整體成本，我們?cè)趫?zhí)行軟件測(cè)試過(guò)程中可以參照以下幾點(diǎn)原則：1、完全測(cè)試程序是不可能的，不可能找出軟件的所有缺陷，這是因?yàn)椋狠斎肓刻筝敵鼋Y(jié)果太多軟件實(shí)現(xiàn)途徑太多軟件說(shuō)明書(shū)沒(méi)有客觀標(biāo)準(zhǔn)，從不同的角度來(lái)看，軟件缺陷的標(biāo)準(zhǔn)不同。2、軟件測(cè)試是有風(fēng)險(xiǎn)的行為，如果決定不去測(cè)試所有的情況，那就是選擇了風(fēng)險(xiǎn)。軟件測(cè)

5、試人員要學(xué)會(huì)的一個(gè)主要原則是如何把無(wú)邊無(wú)際的可能減少到可以控制的范圍，以及如何針對(duì)風(fēng)險(xiǎn)制訂作出明智抉擇，去粗存精。3、測(cè)試無(wú)法顯示潛伏的軟件缺陷，軟件測(cè)試工作與防疫員的工作極為相似，可以報(bào)告已發(fā)現(xiàn)的軟件缺陷，卻無(wú)法報(bào)告潛伏的軟件缺陷，更不可能保證找到全部的缺陷。4、找到的軟件缺陷越多，就說(shuō)明軟件缺陷越多。生活中的寄生蟲(chóng)和軟件缺陷幾乎完全一樣，兩者都成群出現(xiàn)。發(fā)現(xiàn)一個(gè)附近就會(huì)有一群。軟件測(cè)試的原則（續(xù)）5、殺蟲(chóng)劑怪事，與農(nóng)藥殺蟲(chóng)是一樣的，軟件對(duì)測(cè)試方法及技術(shù)也有免疫力，只有發(fā)明新的殺蟲(chóng)劑（測(cè)試技術(shù)或方法）去找蟲(chóng)子。6、并非所有軟件缺陷都能修復(fù)。7、難以說(shuō)清的軟件缺陷，因?yàn)殚_(kāi)發(fā)小組使用的最佳工作方

6、式千差萬(wàn)別，大家對(duì)缺陷的理解也不一致。8、產(chǎn)品說(shuō)明書(shū)不斷變化，整個(gè)行業(yè)變化太快，同時(shí)軟件變得更龐大、更復(fù)雜，功能越來(lái)越多，這些都會(huì)導(dǎo)致用戶(hù)描述和定義軟件的產(chǎn)品說(shuō)明書(shū)一變?cè)僮儭?、軟件測(cè)試員在小組中不受歡迎，軟件測(cè)試員的任務(wù)是檢查和批評(píng)同事的工作，挑毛病，公布發(fā)現(xiàn)的問(wèn)題。10、軟件測(cè)試是一項(xiàng)講究條理的技術(shù)專(zhuān)業(yè)，當(dāng)前軟件行業(yè)已經(jīng)發(fā)展到強(qiáng)制使用專(zhuān)業(yè)軟件測(cè)試員的階段了，因?yàn)樯a(chǎn)低劣軟件的代價(jià)太高。軟件測(cè)試的原則（續(xù)）軟件常見(jiàn)的版本在整個(gè)軟件開(kāi)發(fā)的生命周期中，可能會(huì)出現(xiàn)各種版，每個(gè)公司對(duì)版本的定義也不一樣，通常情況下有以下的幾個(gè)版本是比較通用的：1、Alpha版公司內(nèi)部測(cè)試的版本，該版本的特征為：軟件的

7、所有功能已基本實(shí)現(xiàn)所有的功能已通過(guò)測(cè)試，一般情況下推向市場(chǎng)前不再增減（一般為集成測(cè)試）已到的缺陷中，嚴(yán)重級(jí)別的已修正并通過(guò)復(fù)測(cè)軟件性能測(cè)試可提供基本數(shù)據(jù)2、Beta版對(duì)外發(fā)布公測(cè)，該版本的特征為：次嚴(yán)重缺陷基本完成修正并通過(guò)復(fù)測(cè)完成測(cè)試計(jì)劃中的每一項(xiàng)具體測(cè)試（一般為系統(tǒng)測(cè)試計(jì)劃）一段時(shí)間內(nèi)缺陷的發(fā)現(xiàn)離低于修正率所有相關(guān)文件（用戶(hù)指南、軟件說(shuō)明、版本說(shuō)明等）得到最后修正3、發(fā)布版正式發(fā)布版本，該版本的特征為：缺陷發(fā)現(xiàn)率低于修正率，此距離逐漸拉開(kāi)并一直保持穩(wěn)定的一段時(shí)間測(cè)試部門(mén)對(duì)所有已修正的缺陷重新測(cè)試并通過(guò)技術(shù)支持部門(mén)對(duì)產(chǎn)品的提出認(rèn)為可行所有用戶(hù)反饋都已妥善處理所有文件準(zhǔn)備就緒得到測(cè)試部門(mén)認(rèn)可軟

8、件常見(jiàn)的版本（續(xù)）優(yōu)秀軟件測(cè)試員必備想成為一名優(yōu)秀的軟件測(cè)試員，可以從以下幾方面去努力：1、探索精神，軟件測(cè)試員不會(huì)害怕進(jìn)入陌生環(huán)境。2、故障排除能手，軟件測(cè)試員善于發(fā)現(xiàn)問(wèn)題的癥結(jié)，喜歡猜謎。3、不懈努力，軟件測(cè)試員總是不停嘗試。4、創(chuàng)造性想出富有創(chuàng)意甚至超常的手段來(lái)尋找軟件缺陷。5、追求完美，他們力求完美，但是知道某些無(wú)法企及時(shí)，不去苛求，而是盡力接近目標(biāo)。6、判斷準(zhǔn)確，軟件測(cè)試員要決定測(cè)試內(nèi)容、測(cè)試時(shí)間，以及看到的問(wèn)題是否算作真正的缺陷。7、老練穩(wěn)重，軟件測(cè)試員不害怕壞消息，必須告訴程序員，你的孩子很丑，知道和不夠冷靜的程序員怎樣合作。8、表達(dá)能力，軟件測(cè)試員要善于表達(dá)觀點(diǎn)，表明軟件缺陷為

9、何必須修復(fù)，并通過(guò)實(shí)際演示力陳觀點(diǎn)。9、在編程方面受過(guò)教育。第十二章 軟件測(cè)試簡(jiǎn)介軟件測(cè)試基本概念軟件測(cè)試分類(lèi)自動(dòng)化測(cè)試常見(jiàn)測(cè)試工具BUG管理流程軟件測(cè)試分類(lèi)按軟件測(cè)試特性可以把軟件測(cè)試分為白盒測(cè)試、灰盒測(cè)試和黑盒測(cè)試三種，其特征及包含的內(nèi)容如下：、白盒測(cè)試測(cè)試人員直接在軟件的源程序上進(jìn)行測(cè)試、修改、復(fù)測(cè)。要求測(cè)試工程師對(duì)軟件的內(nèi)部結(jié)構(gòu)及邏輯有深入的了解，并掌握寫(xiě)成該源程序的語(yǔ)言。分為：語(yǔ)句測(cè)試；分支測(cè)試；路徑測(cè)試；條件測(cè)試；目測(cè)、灰盒測(cè)試介于白、黑兩者之間，是兩者的結(jié)合。測(cè)試工程師對(duì)軟件程序結(jié)構(gòu)有一定了解，但了解的程度又不需要達(dá)到白盒測(cè)試的深度。、黑盒測(cè)試測(cè)試人員不必深入了解軟件的內(nèi)部設(shè)計(jì)，

10、只是從一個(gè)終端用戶(hù)的角度，根據(jù)產(chǎn)品說(shuō)明書(shū)的指標(biāo)，從外部測(cè)試軟件的各項(xiàng)功能及性能。黑盒測(cè)試主要是功能測(cè)試。按軟件開(kāi)發(fā)過(guò)程可以把軟件測(cè)試分為單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、用戶(hù)驗(yàn)收測(cè)試以及回歸測(cè)試。此分類(lèi)一般可以使用V模型來(lái)表示，如下圖所示：軟件測(cè)試分類(lèi)（續(xù)）各類(lèi)測(cè)試用時(shí)表按開(kāi)發(fā)過(guò)程分類(lèi)測(cè)試用時(shí)按軟件測(cè)試要求可以把軟件測(cè)試分為基本功能測(cè)試、全面測(cè)試和基準(zhǔn)測(cè)試。按此方法分類(lèi)的各種測(cè)試解釋如下：、基本功能測(cè)試（Smoke test）：只對(duì)軟件的關(guān)鍵功能做測(cè)試，而不必卷入細(xì)致的測(cè)試，不必面面俱到。、全面測(cè)試（Sanity test）：不僅對(duì)軟件關(guān)鍵功能測(cè)試，還要覆蓋軟件的全部功能，是回歸測(cè)試的主要組成部分

11、。、基準(zhǔn)測(cè)試（Benchmark test）：對(duì)指定的一個(gè)或一組程序及數(shù)據(jù)在不同的計(jì)算機(jī)上執(zhí)行測(cè)試，以測(cè)定其在標(biāo)準(zhǔn)情況下、特定配置下的工作性能，并將其執(zhí)行速度、完成需時(shí)等加以比較。軟件測(cè)試分類(lèi)（續(xù)）l按軟件特性可以把軟件測(cè)試分為功能測(cè)試和非功能測(cè)試：功能測(cè)試主要包括：等價(jià)區(qū)間測(cè)試，把輸入空間劃分幾個(gè)“等價(jià)區(qū)間”，在每個(gè)區(qū)間中只需要測(cè)試一個(gè)典型值即可；邊界值測(cè)試；隨機(jī)測(cè)試；狀態(tài)轉(zhuǎn)換測(cè)試；流程測(cè)試等。非功能測(cè)試主要包括：安裝/卸載測(cè)試；使用性測(cè)試；恢復(fù)測(cè)試；兼容性測(cè)試；安全測(cè)試；性能測(cè)試；強(qiáng)度/壓力測(cè)試；容量測(cè)試；任意測(cè)試等。軟件測(cè)試分類(lèi)（續(xù)）第十二章 軟件測(cè)試簡(jiǎn)介軟件測(cè)試基本概念軟件測(cè)試分類(lèi)自動(dòng)

12、化測(cè)試常見(jiàn)測(cè)試工具BUG管理流程自動(dòng)化測(cè)試優(yōu)點(diǎn)l自動(dòng)化測(cè)試：就是使用（自動(dòng)化測(cè)試）工具來(lái)進(jìn)行的測(cè)試，一般不需要人干預(yù)。l自動(dòng)化測(cè)試優(yōu)點(diǎn)：一旦積累了一套自動(dòng)化測(cè)試的程序，日后自動(dòng)化測(cè)試節(jié)省大量的時(shí)間和資源；沒(méi)有時(shí)間限制一般安排在下班后；可以反復(fù)執(zhí)行；保證測(cè)試執(zhí)行過(guò)程的一致性及準(zhǔn)確性；有較高的功能測(cè)試覆蓋率；模擬操作，進(jìn)行壓力測(cè)試，這是手測(cè)很難實(shí)現(xiàn)的。并非所有的測(cè)試都可用自動(dòng)測(cè)試來(lái)實(shí)現(xiàn)，比如使用性測(cè)試、兼容性測(cè)試等；沒(méi)有創(chuàng)造性，只能安排設(shè)計(jì)好的用例去測(cè)，碰到新問(wèn)題不會(huì)應(yīng)變；受具體項(xiàng)目資源限制：受時(shí)間及人力的限制，因?yàn)樽詣?dòng)化測(cè)試編程很費(fèi)時(shí)；受資金預(yù)算的限制，商用測(cè)試軟件價(jià)格比較高；對(duì)測(cè)試工程師要求比

13、較高。自動(dòng)化測(cè)試缺點(diǎn)l根據(jù)自動(dòng)化測(cè)試的特點(diǎn)，建議以下測(cè)試優(yōu)先考慮自動(dòng)測(cè)試：回歸測(cè)試，每次有新版本發(fā)布前都必須執(zhí)行，在整個(gè)開(kāi)發(fā)過(guò)程中需要多次執(zhí)行，很適合編寫(xiě)成自動(dòng)測(cè)試程序。涉及大量不同數(shù)據(jù)輸入的功能測(cè)試。如各種各樣的邊界值測(cè)試，需要大量時(shí)間去完成的網(wǎng)頁(yè)連接測(cè)試等等。用手測(cè)完成難度較大的測(cè)試，如性能測(cè)試、壓力（負(fù)荷）測(cè)試、強(qiáng)度測(cè)試等。例如：對(duì)于一個(gè)網(wǎng)站，要測(cè)試1萬(wàn)個(gè)用戶(hù)在某一時(shí)間內(nèi)同時(shí)登錄時(shí)，服務(wù)器運(yùn)行是否正常及速度是否仍然可以接受，這是手測(cè)很難完成的。自動(dòng)化測(cè)試應(yīng)用場(chǎng)景編寫(xiě)測(cè)試用例；分析、分析、驗(yàn)證測(cè)試用例；對(duì)已有測(cè)試用例歸類(lèi)，編寫(xiě)測(cè)試自動(dòng)化計(jì)劃方案；編寫(xiě)自動(dòng)化測(cè)試程序；盡量用“數(shù)據(jù)驅(qū)動(dòng)”來(lái)提高

14、測(cè)試覆蓋率；將測(cè)試用例編寫(xiě)成自動(dòng)測(cè)試程序；執(zhí)行測(cè)試程序，記錄并反饋BUG；不斷完善自動(dòng)化測(cè)試系統(tǒng)或程序。自動(dòng)化測(cè)試實(shí)現(xiàn)步驟第十二章 軟件測(cè)試簡(jiǎn)介軟件測(cè)試基本概念軟件測(cè)試分類(lèi)自動(dòng)化測(cè)試常見(jiàn)測(cè)試工具BUG管理流程不是專(zhuān)業(yè)測(cè)試工具的工具查看器和監(jiān)視器，各類(lèi)編譯器的代碼調(diào)試器均可看作查看器；任何能夠洞察系統(tǒng)，看到一般用戶(hù)看不到的數(shù)據(jù)的工具，都可以稱(chēng)之為查看測(cè)試工具；驅(qū)動(dòng)程序，用于控制和操作測(cè)試軟件的工具，最簡(jiǎn)單的是批處理文件；仿真器，為測(cè)試工具或程序提供數(shù)據(jù)或響應(yīng)軟件發(fā)送的數(shù)據(jù)；分析工具，電子表格軟件、文件比較軟件、抓屏軟件和比較軟件、計(jì)算器、秒表等；干擾發(fā)射器和噪聲發(fā)生器，模擬由于數(shù)據(jù)中斷、干擾能產(chǎn)

15、生的通信錯(cuò)誤。常見(jiàn)測(cè)試工具窗口/網(wǎng)絡(luò)軟件用戶(hù)界面測(cè)試WinRunner、QuickTest ProfessionalSilkTestFunctional TesterTest PartnerVisualTest性能測(cè)試LoadRunnerSilkPerformerRational Performance TesterQALoad常見(jiàn)測(cè)試工具（續(xù))軟件測(cè)試管理工具TestDirectorSilkCentral Test ManagerRational TestManager/ClearQuestQADirector/TrackRecordX窗口軟件測(cè)試X Runner自開(kāi)發(fā)測(cè)試軟件，適用于特定領(lǐng)

16、域第十二章 軟件測(cè)試簡(jiǎn)介軟件測(cè)試基本概念軟件測(cè)試分類(lèi)自動(dòng)化測(cè)試常見(jiàn)測(cè)試工具BUG管理流程微軟研發(fā)中的BUG管理微軟有一個(gè)研發(fā)框架叫MSF（微軟解決方案框架），開(kāi)發(fā)過(guò)程中主要有三個(gè)角色：PM(程序規(guī)劃經(jīng)理）、Dev（軟件開(kāi)發(fā)工程師）、Tester（軟件測(cè)試工程師）。在研發(fā)過(guò)程中，三者分工明確、接口清晰。PM來(lái)定義需求、書(shū)寫(xiě)每個(gè)功能特性的設(shè)計(jì)文檔(SPEC)；Dev寫(xiě)代碼來(lái)實(shí)現(xiàn)這些SPEC；Tester來(lái)測(cè)試Dev做出來(lái)的東西是否符合PM定義的SPEC。微軟不少項(xiàng)目都使用完善的研發(fā)管理工具，其中Bug管理系統(tǒng)（原來(lái)叫Raid系統(tǒng)，現(xiàn)集成在VSTS中）居于核心地位。整個(gè)軟件研發(fā)過(guò)程中，特別是在測(cè)試產(chǎn)

17、品、修復(fù)BUG的中后期，團(tuán)隊(duì)中所有人都生活在Raid中。Tester只要發(fā)現(xiàn)問(wèn)題就立即新建一個(gè)Bug予以跟蹤并指派給相關(guān)的開(kāi)發(fā)小組長(zhǎng)（Dev Leader)，開(kāi)發(fā)小組長(zhǎng)會(huì)判斷這個(gè)BUG屬于某個(gè)特定的開(kāi)發(fā)人員并指派他處理。開(kāi)發(fā)人員會(huì)根據(jù)BUG的詳細(xì)描述信息找到問(wèn)題所在，修改程序解決這個(gè)BUG，并把BUG返回給當(dāng)初的測(cè)試人員；或者有爭(zhēng)議的時(shí)候，把BUG指派給這個(gè)需求定義者PM，要求澄清說(shuō)明。測(cè)試人員在看到某個(gè)BUG被解決后，就去驗(yàn)證這個(gè)BUG是否真的不存在了，根據(jù)最初的發(fā)現(xiàn)步驟去證實(shí)問(wèn)題真的解決了就關(guān)閉這個(gè)BUG；否則，可以激活這個(gè)BUG，返回給當(dāng)初的開(kāi)發(fā)人員做進(jìn)一步處理。當(dāng)測(cè)試人員與開(kāi)發(fā)人員無(wú)法

18、達(dá)成一致意見(jiàn)時(shí)，由對(duì)應(yīng)的PM出面做協(xié)調(diào)，判斷這個(gè)BUG的嚴(yán)重程序，對(duì)用戶(hù)可能的影響。根據(jù)產(chǎn)品的進(jìn)度和項(xiàng)目資源做出評(píng)估，是否真的需要解決這個(gè)問(wèn)題。管理團(tuán)隊(duì)利用BUG管理系統(tǒng)來(lái)跟蹤整個(gè)進(jìn)度，單個(gè)人的工作、小組的進(jìn)度、整個(gè)產(chǎn)品研發(fā)進(jìn)度。微軟研發(fā)中的BUG管理（續(xù)）l在微軟的BUG管理或者說(shuō)研發(fā)管理思想里有以下幾點(diǎn)需要注意：報(bào)告BUG不僅僅是測(cè)試人員的事情，團(tuán)隊(duì)的每個(gè)人發(fā)現(xiàn)問(wèn)題時(shí)都會(huì)提交一個(gè)BUG來(lái)跟蹤；BUG管理系統(tǒng)不僅僅是跟蹤軟件功能方面的BUG，其他各種問(wèn)題，如需求文檔的變更、界面上錯(cuò)別字、幫助文檔的語(yǔ)言、某項(xiàng)任務(wù)指源等都可以通過(guò)此來(lái)跟蹤。在VSTS中全部被稱(chēng)之為工作項(xiàng)。Everything should be tracked in VSTS（Raid）。微軟研發(fā)中的BUG管理（續(xù)）通用BUG管理流程l比較通用的Bug管理流程如下：BUG登記測(cè)試工程師，初始；指派任務(wù)項(xiàng)目經(jīng)理，激活；修改BUG開(kāi)發(fā)工程師，修改；驗(yàn)證測(cè)試工程師，通過(guò)則轉(zhuǎn)第五步，否則轉(zhuǎn)二步，狀態(tài)為再激活；關(guān)閉測(cè)試工程師。l為了能使開(kāi)發(fā)人員準(zhǔn)確理解Bug，Bug描述應(yīng)當(dāng)具有以下特征：短小只解釋