微軟測試培訓大綱課件

軟件測試技術(shù)軟件測試技術(shù)課程特點用真實應(yīng)用的案例和技術(shù)來講解如何解決測試中的實際難題課程的中心思想是如何建立質(zhì)量保證體系，做到缺陷的預(yù)防用一個大型的真實產(chǎn)品作為案例，講解從立項計劃到發(fā)布的每一步是如何實施的對于同一個測試環(huán)節(jié)，開發(fā)人員、測試人員、測試管理者應(yīng)該分別關(guān)注什么、做哪些工作來最終保證測試質(zhì)量不僅講解要做好測試都需要做什么，更注重講解怎么做、為什么這樣做、如果不這樣做會出現(xiàn)什么情況課程特點用真實應(yīng)用的案例和技術(shù)來講解如何解決測試中的實際難題課程安排與實踐相關(guān)的軟件測試理論

這一部分只會用很少的一點時間，基礎(chǔ)知識略過，僅對實踐中最重要的、最容易混淆或最容易出問題的地方強調(diào)一下測試計劃

這部分內(nèi)容將分別從測試執(zhí)行者和測試管理者的角度出發(fā)，講解如何制定能覆蓋到細節(jié)的測試計劃，以及準備資源的依據(jù)，并最終評定每一個測試人員的測試執(zhí)行情況課程安排與實踐相關(guān)的軟件測試理論課程安排測試用例設(shè)計方法

這部分內(nèi)容會著重講解如何進行深度驗證和解決白盒測試的難點，以及各種用例設(shè)計方法的綜合使用

課程安排測試用例設(shè)計方法課程安排測試方法及技巧

這部分內(nèi)容將對每一種測試方法的重點、難點和實施技巧進行講解，用一個真實的企業(yè)級軟件項目作為案例，講解如何在一個真實項目中逐一實施這些測試方法，其中絕大部分的測試方法都以自動化測試的技術(shù)和實現(xiàn)方法來講解。當所有的測試方法都部署完成，講解何如把這些獨立的測試方法和測試活動整合成自動化測試體系。從而實現(xiàn)缺陷預(yù)防的持續(xù)改進。

課程安排測試方法及技巧課程安排測試度量體系的建立

這部分內(nèi)容會在課程中分兩個層面講解。第一個層面是技術(shù)方面的，包括與缺陷相關(guān)的各種度量數(shù)據(jù)，軟件可靠性分析、缺陷分析等；第二個層面是管理方面的，包括如何應(yīng)用數(shù)據(jù)進行輔助決策、需要積累和建立哪些數(shù)據(jù)內(nèi)容、以及根據(jù)缺陷狀態(tài)預(yù)估項目進度和質(zhì)量等級等。課程安排測試度量體系的建立

這部分內(nèi)容會在課程中分兩個層面講課程安排自動化測試技術(shù)

這部分內(nèi)容先從自動化測試技術(shù)的初級部分入手，介紹最新的自動化測試技術(shù)和挑選工具的方法，然后分析自動化測試技術(shù)的核心價值課程安排自動化測試技術(shù)課程安排缺陷預(yù)防的持續(xù)改進

這部分內(nèi)容是核心中的核心，它是建立在前面用例設(shè)計、測試計劃和各種測試方法的基礎(chǔ)上的，可以說前面的內(nèi)容都是在為這一塊打基礎(chǔ)課程安排缺陷預(yù)防的持續(xù)改進課程安排測試管理

沒有科學的測試管理就不可能建立完備的質(zhì)量保證體系，這部分內(nèi)容講解在實踐中如何進行缺陷的度量。軟件質(zhì)量的度量以及測試質(zhì)量的度量課程安排測試管理在課程中要逐一解決的問題測試人員不足，尤其是有經(jīng)驗的測試工程師不足團隊對Bug的理解不一致，有時測試團隊開的Bug開發(fā)團隊不認可沒有有效的技術(shù)手段保證測試速度，甚至測試被認為額外增加了項目進度時間測試量很大，測試報告不能及時反映最新版本中存在的問題測試中重復(fù)勞動太多，長期下來，測試工程師缺乏成就感和創(chuàng)造力軟件發(fā)布前是否經(jīng)歷了足夠的測試？能否發(fā)布到底誰說了算？缺陷預(yù)防的持續(xù)改進建立質(zhì)量保證體系在課程中要逐一解決的問題測試人員不足，尤其是第一章軟件測試基礎(chǔ)理論

第一章軟件測試基礎(chǔ)理論

什么是軟件測試軟件測試的引出軟件測試的定義軟件測試的存在階段什么是軟件測試軟件測試的引出軟件測試的引出什么是有效代碼？怎么知道寫出的代碼是不是有效的？測試僅僅是一種技術(shù)嗎？測試僅僅是一種活動嗎？測試是在開發(fā)進度的基礎(chǔ)上額外投入一塊時間嗎？測試是要建立起一套質(zhì)量保證體系，使得項目按照既定的方向和標準前進軟件測試的引出什么是有效代碼？怎么知道寫出的代碼是不是有效的軟件測試的定義為了保證軟件的質(zhì)量和可靠性，應(yīng)力求在分析，設(shè)計等各個階段結(jié)束前，對軟件進行嚴格的評審。也就是說軟件測試是在軟件投入運行前，對軟件需求分析，設(shè)計規(guī)格說明和編碼的最終審查，它是軟件質(zhì)量保證的關(guān)鍵步驟。軟件測試的定義為了保證軟件的質(zhì)量和可靠性，應(yīng)力求在分析，設(shè)計軟件測試的存在階段需求階段的SpecReview編碼階段的單元測試編碼完成后的各種綜合測試測試可以加速軟件開發(fā)進度，在實踐上必須讓測試滲透到每一個階段、每一個細節(jié)軟件測試的存在階段需求階段的SpecReview什么是軟件缺陷缺陷的定義：軟件缺陷這一概念用來描述各種軟件錯誤，是所有軟件錯誤的統(tǒng)稱。

把符合下列5種特征之一的軟件錯誤認為是軟件缺陷：（1）軟件未達到軟件產(chǎn)品需求說明書中指明的要求；（2）軟件出現(xiàn)了軟件產(chǎn)品需求說明書中指明不會出現(xiàn)的錯誤；（3）軟件功能超出了軟件產(chǎn)品需求說明書中指明的范圍；（4）軟件未達到軟件產(chǎn)品需求說明書中雖未指明但應(yīng)達到的要求；（5）難以理解、不易使用、運行速度緩慢或者最終用戶認為不好的問題。什么是軟件缺陷缺陷的定義：軟件缺陷這一概念用來描述各種軟件缺陷的分類缺陷和BUG，它的分類要根據(jù)不同的公司不同的產(chǎn)品來確定，但是基本的分類思想是一致的。CodebugSpecbugPerformanceSecurityUIBugAccessibility缺陷的分類缺陷和BUG，它的分類要根據(jù)不同的公司不同的產(chǎn)品來可能發(fā)生的風險以下方面是很容易引入風險的：軟件在發(fā)布或交付使用之前沒有經(jīng)歷足夠的測試采用產(chǎn)量很少的硬件、芯片，及即將停產(chǎn)的型號購買剛被兼并的軟件公司的產(chǎn)品不明確的需求未經(jīng)充分論證的架構(gòu)

可能發(fā)生的風險以下方面是很容易引入風險的：Myers軟件測試目的1979年，GlenfordMyers在《TheArtofSoftwareTesting》一書中提出“測試的目的是證偽”這一概念，推翻了過去“為表明軟件正確而進行測試”的錯誤認識，為軟件測試的發(fā)展指出了方向，軟件測試的理論、方法在之后得到了長足的發(fā)展。Myers軟件測試目的1979年，GlenfordMyer軟件測試的原則1.應(yīng)當把“盡早地和不間斷地進行軟件測試”作為測試團隊的座右銘。2.如何做到盡早測試和不間斷測試？3.程序員應(yīng)避免檢查自己的程序。4.在設(shè)計測試用例時，應(yīng)包括合理的輸入條件和不合理的輸入條件。軟件測試的原則1.應(yīng)當把“盡早地和不間斷地進行軟件測試”作5.Bug的標準：測試后程序中殘存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目成正比。6.嚴格執(zhí)行測試計劃，排除測試的隨意性。7.應(yīng)當對每一個測試結(jié)果做全面檢查。8.讓數(shù)據(jù)說話：通過對測試用例和Bug的追蹤統(tǒng)計，看出項目組發(fā)生了什么、正在發(fā)生什么、甚至將會發(fā)生什么。測試團隊需要建立Case管理平臺和缺陷追蹤體系

5.Bug的標準：測試后程序中殘存的錯誤數(shù)目與該程序中已發(fā)微軟測試培訓大綱需求分析設(shè)計程序編碼單元測試集成測試確認測試詳細設(shè)計規(guī)格說明概要設(shè)計規(guī)格說明需求規(guī)格說明怎樣理解經(jīng)典模型需求分析設(shè)計程序編碼單元測試集成測試確認測試詳細設(shè)計規(guī)格說明Review缺陷和Bug的區(qū)別軟件測試的意義Review缺陷和Bug的區(qū)別第二章測試計劃

第二章測試計劃

如何在需求和設(shè)計階段有效的介入對需求和設(shè)計的頻繁變更如何應(yīng)對測試文檔的核心價值是什么？為什么要寫測試計劃？測試文檔如何在需求和設(shè)計階段有效的介入測試文檔TestSpecINTRODUCTIONObjectiveStatementRelatedDocumentsandLinksGlossaryTestSpecINTRODUCTIONTestSpecSCOPEGoalsNon-GoalsDependenciesandPartnersRisksAssumptionsandLimitationsAssumptionsLimitationsTestSpecSCOPETestSpecFEATUREOVERVIEWFeatureDescriptionReleaseCriteriaFunctionalAreaBreakdownFeatureDataFlowDiagram(DFD)TestSpecFEATUREOVERVIEWReleaseCreteriaCC：CodeCompletePassRate：這是RC的核心衡量指標之一，我們的要求是必須保證95％的case通過率Case和Bug的級別：允許存在5％不通過的case，但這些case決不能是重要caseZBB：這是ZeroBugBounce的縮寫，意為“零Bug邊界”CodeCoverage：代碼覆蓋率ReleaseCreteriaCC：CodeCompleTestSpecFEATUREVALIDATIONForallfeaturesOverviewValidScenarioInvalidScenariosTestSpecFEATUREVALIDATIONTestSpecGENERALAPPROACHESSecurityPermissionHelpanddocumentationInternationalSufficiency(Globalization/localization)AccessibilityScalability/PerformanceStressGeo/Political/LegalLogging/MessageformatTracing/Counters(Diagnosability)TestabilityTestHooksTestSpecGENERALAPPROACHESTestSpecSCENARIOBASEDTESTSReliability/LongHaulMemoryUsageCPUUsageTimeConsumptionIntegrationInteroperabilityCompatibilityTestSpecSCENARIOBASEDTESTSTestSpecTESTCOMPONENTCHECKLISTtool/libnameFeaturelistTestSpecTESTCOMPONENTCHECKLTestSpecTopologyrequirementsTestSpecTopologyrequirementsTestSpecOPENISSUESTestSpecOPENISSUESTestSpecSIGN-OFFCHANGEHISTORYTestSpecSIGN-OFFReview一篇好的測試文檔應(yīng)當包含哪些內(nèi)容、注意哪些方面Review一篇好的測試文檔應(yīng)當包含哪些內(nèi)容、注意哪些方面第三章測試用例設(shè)計

第三章測試用例設(shè)計

測試用例設(shè)計黑盒測試等價類劃分邊界值分析錯誤推測法因果圖白盒測試邏輯覆蓋判定結(jié)構(gòu)分析循環(huán)結(jié)構(gòu)分析基本路徑覆蓋測試用例設(shè)計黑盒測試白盒測試黑盒測試這種方法是把測試對象看做一個黑盒，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求和功能規(guī)格說明，檢查程序的功能是否符合它的功能說明。黑盒測試叫做功能測試或數(shù)據(jù)驅(qū)動測試。一種特殊的黑盒測試叫做接口測試，它不管程序的需求和實現(xiàn)細節(jié)，僅依據(jù)程序與其外部環(huán)境的接口來選擇測試數(shù)據(jù)。黑盒測試這種方法是把測試對象看做一個黑盒，測試人員完全不考慮黑盒測試方法是在程序接口上進行測試，主要是為了發(fā)現(xiàn)以下錯誤:

是否有不正確或遺漏了的功能？

在接口上，輸入能否正確地接受？

能否輸出正確的結(jié)果？

是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息(例如數(shù)據(jù)文件)訪問錯誤？

性能上是否能夠滿足要求？

是否有初始化或終止性錯誤？

黑盒測試方法是在程序接口上進行測試，主要是為了發(fā)現(xiàn)以下錯誤:用黑盒測試發(fā)現(xiàn)程序錯誤，必須在所有可能的輸入條件和輸出條件中確定測試數(shù)據(jù)，檢查程序能否產(chǎn)生正確的輸出。但這是不可能的。例如，設(shè)一個程序P有輸入量X和Y及輸出量Z。在字長為32位的計算機上運行。若X、Y取整數(shù)，按黑盒方法進行窮舉測試：可能采用的測試數(shù)據(jù)組個數(shù)：232×232＝264

如果測試一組數(shù)據(jù)需要1毫秒,一年工作365×24小時，完成所有測試需5億年。用黑盒測試發(fā)現(xiàn)程序錯誤，必須在所有可能的輸入條件和輸出條件中白盒測試此方法把測試對象看做一個透明的盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序的狀態(tài)，確定實際的狀態(tài)是否與預(yù)期的狀態(tài)一致。因此白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。白盒測試此方法把測試對象看做一個透明的盒子，它允許測試人員利軟件人員使用白盒測試方法，主要想對程序模塊進行如下的檢查：對程序模塊的所有獨立的執(zhí)行路徑至少測試一次—路徑覆蓋測試；對所有的邏輯判定，取“真”與取“假”的兩種情況都至少測試一次

—邏輯覆蓋測試；在循環(huán)的邊界和運行界限內(nèi)執(zhí)行循環(huán)體—控制流測試；測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性

—數(shù)據(jù)流測試、領(lǐng)域測試等。軟件人員使用白盒測試方法，主要想對程序模塊進行如下的檢查：對一個具有多重選擇和循環(huán)嵌套的程序，不同的路徑數(shù)目可能是天文數(shù)字。給出一個小程序的流程圖，它包括了一個執(zhí)行20次的循環(huán)。包含的不同執(zhí)行路徑數(shù)達520條，對每一條路徑進行測試需要1毫秒，假定一年工作365×24小時，要想把所有路徑測試完，需3170年。對一個具有多重選擇和循環(huán)嵌套的程序，不同的路徑數(shù)目可能是天文微軟測試培訓大綱灰盒測試

灰盒測試，確實是介于二者之間的，可以這樣理解，灰盒測試關(guān)注輸出對于輸入的正確性，同時也關(guān)注內(nèi)部表現(xiàn)，但這種關(guān)注不象白盒那樣詳細、完整，只是通過一些表征性的現(xiàn)象、事件、標志來判斷內(nèi)部的運行狀態(tài)，有時候輸出是正確的，但內(nèi)部其實已經(jīng)錯誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要采取這樣的一種灰盒的方法。灰盒測試

灰盒測試，確實是介于二者之間的，可以這樣理

灰盒測試結(jié)合了白盒測試盒黑盒測試的要素.它考慮了用戶端、特定的系統(tǒng)知識和操作環(huán)境。它在系統(tǒng)組件的協(xié)同性環(huán)境中評價應(yīng)用軟件的設(shè)計。

灰盒測試由方法和工具組成，這些方法和工具取材于應(yīng)用程序的內(nèi)部知識盒與之交互的環(huán)境，能夠用于黑盒測試以增強測試效率、錯誤發(fā)現(xiàn)和錯誤分析的效率。

灰盒測試涉及輸入和輸出，但使用關(guān)于代碼和程序操作等通常在測試人員視野之外的信息設(shè)計測試?；液袦y試結(jié)合了白盒測試盒黑盒測試的要素.它考慮了用戶端邏輯覆蓋

語句覆蓋

判定覆蓋

條件覆蓋

判定－條件覆蓋

條件組合覆蓋

路徑覆蓋邏輯覆蓋是以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎(chǔ)的設(shè)計測試用例的技術(shù)。它屬白盒測試。邏輯覆蓋語句覆蓋邏輯覆蓋是以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎(chǔ)的設(shè)計(A>1)

and

(B=0)(A=2)

or

(X>1)X=X/AX=X+1TTFFabdce(A>1)and(B=0)(A=2)or(X>1)XL1(ace)={(A>1)and(B=0)}and{(A=2)or(X/A>1)}=(A>1)and(B=0)and(A=2)or(A>1)and(B=0)and(X/A>1)=(A=2)and(B=0)

or

(A>1)and(B=0)and(X/A>1)

L1(ace)L2(abd)=not{(A>1)and(B=0)}

andnot{(A=2)or(X>1)}={not(A>1)ornot(B=0)}and

{not(A=2)andnot(X>1)}=

not(A>1)andnot(A=2)andnot(X>1)

or

not(B=0)and

not(A=2)andnot(X>1)L2(abd)L3(abe)=not{(A>1)and(B=0)}and

{(A=2)or(X>1)}={not(A>1)ornot(B=0)}and

{(A=2)or(X>1)}=not(A>1)and(A=2)

or

not(A>1)and

(X>1)

or

not(B=0)and(A=2)

or

not(B=0)and(X>1)L3(abe)L4(acd)={(A>1)and(B=0)}

andnot

{(A=2)or(X/A>1)}=(A>1)and(B=0)andnot(A=2)and

not(X/A>1)L4(acd)語句覆蓋語句覆蓋就是設(shè)計若干個測試用例，運行被測程序，使得每一可執(zhí)行語句至少執(zhí)行一次。在圖例中，正好所有的可執(zhí)行語句都在路徑L1上，所以選擇路徑L1設(shè)計測試用例，就可以覆蓋所有的可執(zhí)行語句。

語句覆蓋語句覆蓋就是設(shè)計若干個測試用例，運行被測程序，使得每測試用例的設(shè)計格式如下

【輸入的(A,B,X)，輸出的(A,B,X)】為圖例設(shè)計滿足語句覆蓋的測試用例是:

【(2,0,4)，(2,0,3)】

覆蓋ace【L1】(A=2)and(B=0)

or

(A>1)and(B=0)and(X/A>1)

測試用例的設(shè)計格式如下

【輸入的(A,B,X)，輸出的(

判定覆蓋判定覆蓋就是設(shè)計若干個測試用例，運行被測程序，使得程序中每個判斷的取真分支和取假分支至少經(jīng)歷一次。判定覆蓋又稱為分支覆蓋。對于圖例，如果選擇路徑L1和L2，就可得滿足要求的測試用例:判定覆蓋判定覆蓋就是設(shè)計若干個測試用例，運行被測程序，使得【(2,0,4)，(2,0,3)】覆蓋ace【L1】

【(1,1,1)，(1,1,1)】覆蓋abd【L2】(A=2)and(B=0)

or

(A>1)and(B=0)and(X/A>1)

not(A>1)andnot(A=2)andnot(X>1)

ornot(B=0)and

not(A=2)andnot(X>1)【(2,0,4)，(2,0,3)】覆蓋ace【L1如果選擇路徑L3和L4，還可得另一組可用的測試用例:

【(2,1,1)，(2,1,2)】覆蓋abe【L3】

【(3,0,3)，(3,0,1)】覆蓋acd【L4】

not(A>1)and(X>1)

ornot(B=0)and

(A=2)

ornot(B=0)and(X>1)(A>1)and(B=0)andnot(A=2)and

not(X/A>1)如果選擇路徑L3和L4，還可得另一組可用的測試用例:

【(2條件覆蓋條件覆蓋就是設(shè)計若干個測試用例，運行被測程序，使得程序中每個判斷的每個條件的可能取值至少執(zhí)行一次。在圖例中，我們事先可對所有條件的取值加以標記。例如，對于第一個判斷：條件A＞1取真為，取假為

條件B＝0取真為，取假為

條件覆蓋條件覆蓋就是設(shè)計若干個測試用例，運行被測程序，使得程對于第二個判斷：條件A＝2取真為，取假為

條件X＞1取真為，取假為測試用例

覆蓋分支

條件取值【(2,0,4)，(2,0,3)】L1(c,e)

【(1,0,1)，(1,0,1)】L2(b,d)【(2,1,1)，(2,1,2)】L3(b,e)或?qū)τ诘诙€判斷：

測試用例

覆蓋分支

條件取值【(1,0,3)，(1,0,4)】L3(b,e)【(2,1,1)，(2,1,2)】L3(b,e)

判定－條件覆蓋就是設(shè)計足夠的測試用例，使得判斷中每個條件的所有可能取值至少執(zhí)行一次，每個判斷中的每個分支至少執(zhí)行一次。判定－條件覆蓋測試用例 覆蓋分支 條件取值判定

測試用例

覆蓋分支

條件取值【(2,0,4)，(2,0,3)】L1(c,e)【(1,1,1)，(1,1,1)】L2(b,d)(A=2)and(B=0)

or

(A>1)and(B=0)and(X/A>1)

not(A>1)andnot(A=2)andnot(X>1)

ornot(B=0)and

not(A=2)andnot(X>1)測試用例 覆蓋分支 條件取值(A

andorA>1TB=0TX=X/ATFFA=2TFX>1FX=X+1 andorA>1TB=0TX=X/ATFFA=2TFX>1條件組合覆蓋條件組合覆蓋就是設(shè)計足夠的測試用例，運行被測程序，使得每個判斷的所有可能的條件取值組合至少執(zhí)行一次。記①A＞1,B＝0作

②A＞1,B≠0作

③A≯1,B＝0作④A≯1,B≠0作條件組合覆蓋條件組合覆蓋就是設(shè)計足夠的測試用例，運行被測程序

⑤A＝2,X＞1作

⑥A＝2,X≯1作

⑦A≠2,X＞1作

⑧A≠2,X≯1作

測試用例

覆蓋條件

覆蓋組合【(2,0,4),(2,0,3)】(L1) ①,⑤【(2,1,1),(2,1,2)】(L3) ②,⑥【(1,0,3),(1,0,4)】(L3) ③,⑦【(1,1,1),(1,1,1)】(L2) ④,⑧ ⑤A＝2,X＞1作

⑥路徑測試路徑測試就是設(shè)計足夠的測試用例，覆蓋程序中所有可能的路徑。

測試用例

通過路徑

覆蓋條件【(2,0,4),(2,0,3)】ace(L1)

【(1,1,1),(1,1,1)】abd

(L2)

【(1,1,2),(1,1,3)】abe

(L3)

【(3,0,3),(3,0,1)】acd

(L4)

路徑測試路徑測試就是設(shè)計足夠的測試用例，覆蓋程序中所有可能的判定結(jié)構(gòu)分析當程序中判定多于一個時，形成的分支結(jié)構(gòu)可以分為兩類：嵌套型分支結(jié)構(gòu)和連鎖型分支結(jié)構(gòu)。對于嵌套型分支結(jié)構(gòu)，若有n個判定語句，需要n+1個測試用例；對于連鎖型分支結(jié)構(gòu)，若有n個判定語句，需要有2n個測試用例，覆蓋它的2n條路徑。判定結(jié)構(gòu)分析當程序中判定多于一個時，形成的分支結(jié)構(gòu)可以分為兩嵌套型分支結(jié)構(gòu)連鎖型分支結(jié)構(gòu)s1s2s3s4p1p2p3s1s2s3s4s5s6p1p2p3嵌套型分支結(jié)構(gòu)連鎖型分支結(jié)構(gòu)s1s2s3s4p1p2p3s1對于連鎖型分支結(jié)構(gòu)，當n較大時將無法測試。為減少測試用例的數(shù)目，可采用試驗設(shè)計法，抽取部分路徑進行測試。對于連鎖型分支結(jié)構(gòu)，當n較大時將無法測試。這樣，測試路徑數(shù)目從23＝8條減少到3＋1＝4條。

L40001010111101231234用例s1s3s5s2s3s6s1s4s6s2s4s5p1p2p31234s1–s3–s5s2–s3–s6s1–s4–s6s2–s4–s5路徑這樣，測試路徑數(shù)目從23＝8條減少到3＋1＝4條。L40s1s3s5p1p2p3s2s3s6p1p2p3s1s4s6p1p2p3s2s4s5p1p2p3s1s3s5p1p2p3s2s3s6p1p2p3s1s4s6循環(huán)結(jié)構(gòu)分析循環(huán)分為4種不同類型：簡單循環(huán)、連鎖循環(huán)、嵌套循環(huán)和非結(jié)構(gòu)循環(huán)。

(1)簡單循環(huán)①零次循環(huán)：從循環(huán)入口到出口

②一次循環(huán)：檢查循環(huán)初始值

③二次循環(huán)：檢查多次循環(huán)

④m次循環(huán)：檢查在多次循環(huán)

⑤最大次數(shù)循環(huán)、比最大次數(shù)多一次、少一次的循環(huán)。循環(huán)結(jié)構(gòu)分析循環(huán)分為4種不同類型：簡單循環(huán)、連鎖循環(huán)、嵌套循微軟測試培訓大綱基本路徑測試基本路徑測試方法把覆蓋的路徑數(shù)壓縮到一定限度內(nèi)，程序中的循環(huán)體最多只執(zhí)行一次。它是在程序控制流圖的基礎(chǔ)上，分析控制構(gòu)造的環(huán)路復(fù)雜性，導出基本可執(zhí)行路徑集合，設(shè)計測試用例的方法。設(shè)計出的測試用例要保證在測試中，程序的每一個可執(zhí)行語句至少要執(zhí)行一次。

基本路徑測試基本路徑測試方法把覆蓋的路徑數(shù)壓縮到一定限度內(nèi)，程序的控制流圖符號○為控制流圖的一個結(jié)點，表示一個或多個無分支的PDL語句或源程序語句。箭頭為邊，表示控制流的方向。程序的控制流圖符號○為控制流圖的一個結(jié)點，表示一個或多個無分在選擇或多分支結(jié)構(gòu)中，分支的匯聚處應(yīng)有一個匯聚結(jié)點。邊和結(jié)點圈定的區(qū)域叫做區(qū)域，當對區(qū)域計數(shù)時，圖形外的區(qū)域也應(yīng)記為一個區(qū)域。如果判斷中的條件表達式是由一個或多個邏輯運算符(OR,AND,...)連接的復(fù)合條件表達式，則需改為一系列只有單個條件的嵌套的判斷。在選擇或多分支結(jié)構(gòu)中，分支的匯聚處應(yīng)有一個匯聚結(jié)點。微軟測試培訓大綱等價類劃分等價類劃分是一種典型的黑盒測試方法，使用這一方法時，完全不考慮程序的內(nèi)部結(jié)構(gòu)，只依據(jù)程序的規(guī)格說明來設(shè)計測試用例。等價類劃分方法把所有可能的輸入數(shù)據(jù)，即程序的輸入域劃分成若干部分，然后從每一部分中選取少數(shù)有代表性的數(shù)據(jù)做為測試用例。等價類劃分等價類劃分是一種典型的黑盒測試方法，使用這一方法時使用這一方法設(shè)計測試用例要經(jīng)歷劃分等價類（列出等價類表）和選取測試用例兩步。(1)劃分等價類

等價類是指某個輸入域的子集合。在該子集合中，各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的。測試某等價類的代表值就等價于對這一類其他值的測試。使用這一方法設(shè)計測試用例要經(jīng)歷劃分等價類（列出等價類表）和選等價類的劃分有兩種不同的情況：

①有效等價類：是指對于程序的規(guī)格說明來說，是合理的，有意義的輸入數(shù)據(jù)構(gòu)成的集合。②無效等價類：是指對于程序的規(guī)格說明來說，是不合理的，無意義的輸入數(shù)據(jù)構(gòu)成的集合。在設(shè)計測試用例時，要同時考慮有效等價類和無效等價類的設(shè)計。等價類的劃分有兩種不同的情況：

①有效等價類：是指對于程序劃分等價類等價類的原則。

1)如果輸入條件規(guī)定了取值范圍，或值的個數(shù)，則可以確立一個有效等價類和兩個無效等價類。例如，在程序的規(guī)格說明中，對輸入條件有一句話：“……項數(shù)可以從1到999……”則有效等價類是“1≤項數(shù)≤999”兩個無效等價類是“項數(shù)＜1”或“項數(shù)＞999”。

劃分等價類等價類的原則。

1)如果輸入條件規(guī)定了取值范圍，在數(shù)軸上表示成:

2)如果輸入條件規(guī)定了輸入值的集合，或者是規(guī)定了“必須如何”的條件，這時可確立一個有效等價類和一個無效等價類。例如，在Pascal語言中對變量標識符規(guī)定為“以字母打頭的……串”。那么所有以字母打頭的構(gòu)成有效等價類，而不在此集合內(nèi)（不以字母打頭）的歸于無效等價類。在數(shù)軸上表示成: 2)如果輸入條件規(guī)定了輸入值的集合，或者 3)如果輸入條件是一個布爾量，則可以確定一個有效等價類和一個無效等價類。

4)如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序要對每個輸入值分別進行處理。這時可為每一個輸入值確立一個有效等價類，此外針對這組值確立一個無效等價類，它是所有不允許的輸入值的集合。 3)如果輸入條件是一個布爾量，則可以確定一個有效等價

例如，在教師上崗方案中規(guī)定對教授、副教授、講師和助教分別計算分數(shù)，做相應(yīng)的處理。因此可以確定4個有效等價類為教授、副教授、講師和助教，一個無效等價類，它是所有不符合以上身分的人員的輸入值的集合。5)如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則，則可以確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同角度違反規(guī)則）。例如，在教師上崗方案中規(guī)定對教授、副教授、講師和助教

例如，Pascal語言規(guī)定“一個語句必須以分號‘;’結(jié)束”。這時可以確定一個有效等價類“以‘;’結(jié)束”，若干個無效等價類“以‘:’結(jié)束”、“以‘,’結(jié)束”、“以‘’結(jié)束”、“以LF結(jié)束”等。(2)確立測試用例

在確立了等價類之后，建立等價類表，列出所有劃分出的等價類。

例如，Pascal語言規(guī)定“一個語句必須以分號‘;再從劃分出的等價類中按以下原則選擇測試用例：

1)為每一個等價類規(guī)定一個唯一編號；

2)設(shè)計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，重復(fù)這一步，直到所有的有效等價類都被覆蓋為止；

3)設(shè)計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復(fù)這一步，直到所有的無效等價類都被覆蓋為止。再從劃分出的等價類中按以下原則選擇測試用例：

1)為每一個

用等價類劃分法設(shè)計測試用例的實例在某一PASCAL語言版本中規(guī)定：“標識符是由字母開頭，后跟字母或數(shù)字的任意組合構(gòu)成。有效字符數(shù)為8個，最大字符數(shù)為80個?！辈⑶乙?guī)定：“標識符必須先說明，再使用?！薄霸谕徽f明語句中，標識符至少必須有一個?！?/p>

用等價類劃分法設(shè)計測試用例的實例用等價類劃分方法，建立輸入等價類表:用等價類劃分方法，建立輸入等價類表:下面選取了9個測試用例，它們覆蓋了所有的等價類。①VARx，T1234567：REAL；

BEGINx:=3.414；

T1234567:=2.732；

...…

(1),(2),(4),(8),(9),(12),(14)

②VAR：REAL；

(3)

③VARx，：REAL;

(5)

下面選取了9個測試用例，它們覆蓋了所有的等價類。④VART12345678：REAL；(6)⑤VART12345：REAL；(7)

多于80個字符⑥VART$：CHAR；(10)⑦VARGOTO：INTEGER；(11)⑧VAR2T：REAL；(13)⑨VARPAR：REAL；(15)

BEGIN

PAP:=SIN(3.14*0.8)/6；④VART12345678：REAL；(6)邊界值分析邊界值分析也是一種黑盒測試方法，是對等價類劃分方法的補充。人們從長期的測試工作經(jīng)驗得知，大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內(nèi)部。因此針對各種邊界情況設(shè)計測試用例，可以查出更多的錯誤。

邊界值分析邊界值分析也是一種黑盒測試方法，是對等價類劃分方法比如，在做三角形計算時，要輸入三角形的三個邊長：A、B和C。我們應(yīng)注意到這三個數(shù)值應(yīng)當滿足

A＞0、B＞0、C＞0、

A＋B＞C、A＋C＞B、B＋C＞A，才能構(gòu)成三角形。但如果把六個不等式中的任何一個大于號“＞”錯寫成大于等于號“≥”，那就不能構(gòu)成三角形。問題恰出現(xiàn)在容易被疏忽的邊界附近。比如，在做三角形計算時，要輸入三角形的三個邊長：A、B和C。這里所說的邊界是指，相當于輸入等價類和輸出等價類而言，稍高于其邊界值及稍低于其邊界值的一些特定情況。使用邊界值分析方法設(shè)計測試用例，首先應(yīng)確定邊界情況。應(yīng)當選取正好等于，剛剛大于，或剛剛小于邊界的值做為測試數(shù)據(jù)，而不是選取等價類中的典型值或任意值做為測試數(shù)據(jù)。這里所說的邊界是指，相當于輸入等價類和輸出等價類而言，稍高于錯誤推測法人們也可以靠經(jīng)驗和直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的例子。這就是錯誤推測法。錯誤推測法的基本想法是：列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，根據(jù)它們選擇測試用例。錯誤推測法人們也可以靠經(jīng)驗和直覺推測程序中可能存在的各種錯誤因果圖因果圖的適用范圍如果在測試時必須考慮輸入條件的各種組合，可使用一種適合于描述對于多種條件的組合，相應(yīng)產(chǎn)生多個動作的形式來設(shè)計測試用例，這就需要利用因果圖。

因果圖方法最終生成的就是判定表。它適合于檢查程序輸入條件的各種組合情況。用因果圖生成測試用例的基本步驟因果圖因果圖的適用范圍1)分析軟件規(guī)格說明描述中，哪些是原因(即輸入條件或輸入條件的等價類)，哪些是結(jié)果(即輸出條件)，并給每個原因和結(jié)果賦予一個標識符。

2)分析軟件規(guī)格說明描述的語義，找出原因與結(jié)果之間，原因與原因之間對應(yīng)的關(guān)系?根據(jù)這些關(guān)系，畫出因果圖。

3)由于語法或環(huán)境限制,有些原因與原因之間，原因與結(jié)果之間的組合情況不可能出現(xiàn)。為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件。

1)分析軟件規(guī)格說明描述中，哪些是原因(即輸入條4)把因果圖轉(zhuǎn)換成判定表。

5)把判定表的每一列拿出來作為依據(jù)，設(shè)計測試用例。在因果圖中出現(xiàn)的基本符號通常在因果圖中用Ci表示原因，用Ei表示結(jié)果，各結(jié)點表示狀態(tài)，可取值“0”或“1”。“0”表示某狀態(tài)不出現(xiàn)，“1”表示某狀態(tài)出現(xiàn)。

4)把因果圖轉(zhuǎn)換成判定表。主要的原因和結(jié)果之間的關(guān)系有:主要的原因和結(jié)果之間的關(guān)系有:表示約束條件的符號

為了表示原因與原因之間，結(jié)果與結(jié)果之間可能存在的約束條件，在因果圖中可以附加一些表示約束條件的符號。表示約束條件的符號

為了表示原因與原因之間，結(jié)果與結(jié)果之間可

例如，有一個處理單價為5角錢的飲料的自動售貨機軟件測試用例的設(shè)計。其規(guī)格說明如下： 若投入5角錢或1元錢的硬幣，押下〖橙汁〗或〖啤酒〗的按鈕，則相應(yīng)的飲料就送出來。若售貨機沒有零錢找，則一個顯示〖零錢找完〗的紅燈亮，這時在投入1元硬幣并押下按鈕后，飲料不送出來而且1元硬幣也退出來；若有零錢找，則顯示〖零錢找完〗的紅燈滅，在送出飲料的同時退還5角硬幣?！崩纾幸粋€處理單價為5角錢的飲料的自動售貨機軟件1)分析這一段說明，列出原因和結(jié)果

原因:1.售貨機有零錢找

2.投入1元硬幣

3.投入5角硬幣

4.押下橙汁按鈕

5.押下啤酒按鈕 建立中間結(jié)點，表示處理中間狀態(tài)

11.投入1元硬幣且押下飲料按鈕

12.押下〖橙汁〗或〖啤酒〗的按鈕

13.應(yīng)當找5角零錢并且售貨機有零錢找

14.錢已付清

1)分析這一段說明，列出原因和結(jié)果

原因:1.售貨機有

結(jié)果：21.

售貨機〖零錢找完〗燈亮

22.

退還1元硬幣

23.

退還5角硬幣

24.

送出橙汁飲料

25.

送出啤酒飲料

2)畫出因果圖。所有原因結(jié)點列在左 邊，所有結(jié)果結(jié)點列在右邊。

3)

由于2與3，4與5不能同時發(fā)生，

分別加上約束條件E。

4)因果圖

5)轉(zhuǎn)換成判定表結(jié)果：21.售貨機〖零錢找完〗燈亮

使用各種設(shè)計方法的綜合策略測試素材的復(fù)用在任何情況下都必須使用邊界值分析法。用這種方法設(shè)計出測試用例發(fā)現(xiàn)程序錯誤的能力最強。必要時用等價類劃分法補充一些測試用例。用錯誤推測法再追加一些測試用例。不要因為實現(xiàn)的困難程度而影響設(shè)計用例GenericTest自動生成測試用例使用各種設(shè)計方法的綜合策略測試素材的復(fù)用Review編寫測試PropertyPage的TestCaseReview編寫測試PropertyPage的TestC第四章測試度量體系的建立

第四章測試度量體系的建立

一個完備的測試度量體系的構(gòu)成要素：缺陷庫的建立用例庫的建立測試結(jié)果庫的建立自動化測試體系高效的工作流程數(shù)據(jù)統(tǒng)計和數(shù)據(jù)挖掘缺陷追蹤體系科學的測試管理測試度量體系構(gòu)成一個完備的測試度量體系的構(gòu)成要素：測試度量體系構(gòu)成用例庫的建立不能把用例庫只建成一個詳細的記錄平臺，它是自動化測試體系的支撐平臺用例庫的具體實現(xiàn)缺陷庫的建立同樣地，缺陷庫也不只是記錄Bug的數(shù)據(jù)庫，建設(shè)時要考慮缺陷追蹤和為管理提供支撐缺陷庫的具體實現(xiàn)測試結(jié)果庫的建立用例庫、缺陷庫和結(jié)果庫是數(shù)據(jù)輔助決策的支撐平臺測試度量體系——平臺建設(shè)用例庫的建立測試度量體系——平臺建設(shè)測試度量體系（一）Bug和Case的關(guān)聯(lián)KnownFailure與NewFailure測試度量體系（一）Bug和Case的關(guān)聯(lián)缺陷的生命期（1）Open態(tài)-->pending態(tài)-->resolve態(tài)/open態(tài)（2）Open態(tài)-->Close態(tài)（3）Open態(tài)-->delay態(tài)opencloseresolvedelaypending缺陷的生命期（1）Open態(tài)-->pending態(tài)-->測試度量體系——流程測試度量體系——流程Review從開一個Bug到關(guān)閉一個Bug經(jīng)歷的階段、處理的方法、判斷的依據(jù)Review從開一個Bug到關(guān)閉一個Bug經(jīng)歷的階段、處理的第五章測試方法及技巧

第五章測試方法及技巧

從兩個小故事想到的香皂盒測試太空用筆WorkAround和徹底解決問題從兩個小故事想到的香皂盒測試軟件測試的種類FunctionalityTestBlackboxandWhiteboxSecurityHelpanddocumentationInternationalSufficiency(Globalization/localization)AccessibilityScalability/PerformanceStress軟件測試的種類FunctionalityTest軟件測試的種類Geo/Political/LegalLogging/MessageformatTracing/Counters(Diagnosability)TestabilityTestHooksSCENARIOBASEDTESTSReliability/LongHaul

Integration

Interoperability

Compatibility

UE測試軟件測試的種類Geo/Political/Legal功能測試功能測試是在規(guī)定的一段時間內(nèi)運行軟件系統(tǒng)的所有功能，以驗證這個軟件系統(tǒng)有無嚴重錯誤。功能測試可靠性測試也叫穩(wěn)定性測試在正常負載下的測試，記錄資源占用曲線結(jié)合負載測試進行可靠性測試也叫穩(wěn)定性測試可靠性測試如果系統(tǒng)需求說明書中有對可靠性的要求，則需進行可靠性測試。 ①平均失效間隔時間MTBF

(MeanTimeBetweenFailures)是否超過規(guī)定時限?

②因故障而停機的時間MTTR

(MeanTimeToRepairs)在一年中應(yīng)不超過多少時間。

可靠性測試強度測試強度測試也叫壓力測試，是要檢查在系統(tǒng)運行環(huán)境不正常乃至發(fā)生故障的情況下，系統(tǒng)可以運行到何種程度的測試。例如：把輸入數(shù)據(jù)速率提高一個數(shù)量級，確定輸入功能將如何響應(yīng)。設(shè)計需要占用最大存儲量或其他資源的測試用例進行測試。設(shè)計出在虛擬存儲管理機制中引起“顛簸”的測試用例進行測試。強度測試壓力測試和性能測試的區(qū)別壓力測試的難點一般情況下需要借助工具進行（LoadRunner，UISpider）壓力測試和性能測試的區(qū)別設(shè)計出會對磁盤常駐內(nèi)存的數(shù)據(jù)過度訪問的測試用例進行測試。強度測試的一個變種就是敏感性測試。在程序有效數(shù)據(jù)界限內(nèi)一個小范圍內(nèi)的一組數(shù)據(jù)可能引起極端的或不平穩(wěn)的錯誤處理出現(xiàn)，或者導致極度的性能下降的情況發(fā)生。此測試用以發(fā)現(xiàn)可能引起這種不穩(wěn)定性或不正常處理的某些數(shù)據(jù)組合。設(shè)計出會對磁盤常駐內(nèi)存的數(shù)據(jù)過度訪問的測試用例進行測試。性能測試性能測試是要檢查系統(tǒng)是否滿足在需求說明書中規(guī)定的性能。特別是對于實時系統(tǒng)或嵌入式系統(tǒng)。性能測試常需要與強度測試結(jié)合起來進行，并常要求同時進行硬件和軟件檢測。通常，對軟件性能的檢測表現(xiàn)在以下幾個方面：響應(yīng)時間、吞吐量、輔助存儲區(qū)，例如緩沖區(qū)，工作區(qū)的大小等、處理精度，等等。性能測試檢驗系統(tǒng)的能力最高能達到什么程度。例如，對于編譯程序，讓它處理特別長的源程序；對于操作系統(tǒng)，讓其作業(yè)隊列“滿員”；對于信息檢索系統(tǒng)，讓它使用頻率達到最大。在使系統(tǒng)的全部資源達到“滿負荷”的情形下，測試系統(tǒng)的承受能力。檢驗系統(tǒng)的能力最高能達到什么程度。例如，需要定義詳盡的界定值（Benchmark）一般情況下需要借助工具進行性能測試性能測試的原則和難點需要定義詳盡的界定值（Benchmark）安全性測試安全性測試是要檢驗在系統(tǒng)中已經(jīng)存在的系統(tǒng)安全性、保密性措施是否發(fā)揮作用，有無漏洞。力圖破壞系統(tǒng)的保護機構(gòu)以進入系統(tǒng)的主要方法有以下幾種：正面攻擊或從側(cè)面、背面攻擊系統(tǒng)中易受損壞的那些部分；以系統(tǒng)輸入為突破口，利用輸入的容錯性進行正面攻擊；

安全性測試

申請和占用過多的資源壓垮系統(tǒng)，以破壞安全措施，從而進入系統(tǒng)；故意使系統(tǒng)出錯，利用系統(tǒng)恢復(fù)的過程，竊取用戶口令及其他有用的信息；通過瀏覽殘留在計算機各種資源中的垃圾（無用信息），以獲取如口令，安全碼，譯碼關(guān)鍵字等信息；瀏覽全局數(shù)據(jù)，期望從中找到進入系統(tǒng)的關(guān)鍵字；瀏覽那些邏輯上不存在，但物理上還存在的各種記錄和資料等。申請和占用過多的資源壓垮系統(tǒng)，以破壞安全措施，從而進入系統(tǒng)安全性測試

安全測測試本質(zhì)上也是功能測試的一種對于非桌面型應(yīng)用、CS/BS應(yīng)用、電信/金融/企業(yè)級的應(yīng)用尤為重要安全性測試的前提條件是清晰詳盡的權(quán)限定義安全性測試

安全測測試本質(zhì)上也是功能測試的一種可使用性測試可使用性測試主要從使用的合理性和方便性等角度對軟件系統(tǒng)進行檢查，發(fā)現(xiàn)人為因素或使用上的問題。要保證在足夠詳細的程度下，用戶界面便于使用；對輸入量可容錯、響應(yīng)時間和響應(yīng)方式合理可行、輸出信息有意義、正確并前后一致；出錯信息能夠引導用戶去解決問題；軟件文檔全面、正規(guī)、確切?？墒褂眯詼y試這個測試更多的是針對設(shè)計，發(fā)bug時designchange類型多于codebug無效頁、步驟等UI界面不能完成，需要用命令行或腳本用戶干預(yù)困難這個測試更多的是針對設(shè)計，發(fā)bug時designchang安裝測試安裝測試的目的不是找軟件錯誤，而是找安裝錯誤。在安裝軟件系統(tǒng)時，會有多種選擇。要分配和裝入文件與程序庫布置適用的硬件配置進行程序的聯(lián)結(jié)。而安裝測試就是要找出在這些安裝過程中出現(xiàn)的錯誤。安裝測試安裝測試是在系統(tǒng)安裝之時進行測試。它要檢驗：用戶選擇的一套任選方案是否相容；安裝失敗的測試系統(tǒng)的每一部分是否都齊全；所有文件是否都已產(chǎn)生并確有所需要的內(nèi)容；硬件的配置是否合理，等等。

安裝測試是在系統(tǒng)安裝之時進行測試。它要檢驗：文檔測試這種測試是檢查用戶文檔(如用戶手冊)的清晰性和精確性。用戶文檔中所使用的例子必須在測試中一一試過，確保敘述正確無誤。隨產(chǎn)品發(fā)布Help文檔隨機手冊內(nèi)部文檔文檔測試Globalization/localization語言的兼容性文化考慮，如日期格式等不推薦使用硬編碼（HardCode）這個測試方法對定制開發(fā)同樣有效Globalization/localization語言的兼靈活性/可擴展性測試可擴展性是衡量軟件品質(zhì)的重要指標之一，擴展性好的軟件不僅有助于保護客戶投資，同時可以提高用戶對產(chǎn)品的忠誠度容量擴展功能擴展靈活性/可擴展性測試可擴展性是衡量軟件品質(zhì)的重要指標之一，擴Geo/Political/Legal非技術(shù)性測試專業(yè)顧問、專家支持用戶圖標官司Geo/Political/Legal非技術(shù)性測試可診斷性測試Logging/MessageformatTracing/Counters(Diagnosability)可診斷性測試Logging/Messageformat可測性測試Testability這是對軟件設(shè)計的一項要求，繼承層次、接口行為、函數(shù)調(diào)用等可測性測試Testability測試探針TestHooks代碼注射，事件捕捉等，對測試人員要求較高測試探針TestHooks場景測試是集成測試的濃縮版，覆蓋產(chǎn)品最關(guān)鍵的用況自動化測試小組協(xié)同測試場景測試是集成測試的濃縮版，覆蓋產(chǎn)品最關(guān)鍵的用況集成測試大規(guī)模集成測試涉及到軟件、硬件、拓撲、復(fù)雜場景等測試成本較高需要良好的協(xié)調(diào)組織模擬真網(wǎng)，盡可能模擬真實用戶環(huán)境集成測試大規(guī)模集成測試涉及到軟件、硬件、拓撲、復(fù)雜場景等兼容性測試經(jīng)驗表明，越符合計算機界通用標準的產(chǎn)品，生命周期越長與標準的兼容性與其他產(chǎn)品的兼容性兼容性指標直接影響市場效益兼容性測試經(jīng)驗表明，越符合計算機界通用標準的產(chǎn)品，生命周期越交互性測試與兼容性測試的區(qū)別，現(xiàn)代軟件測試將交互性測試從兼容性測試中分離出來Word交互性測試與兼容性測試的區(qū)別，現(xiàn)代軟件測試將交互性測試從兼容α測試和β測試在軟件交付使用后，用戶將如何實際使用程序，對于開發(fā)者來說是無法預(yù)測的。α測試是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進行的測試。α測試的目的是評價軟件產(chǎn)品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持）。尤其注重產(chǎn)品的界面和特色。α測試和β測試在軟件交付使用后，用戶將如何實際使用程序，對于UE測試ErrorMessage界面風格描述性語言的表達風格一致性UE測試ErrorMessageReviewFunctionalityTestBlackboxandWhiteboxSecurityHelpanddocumentationInternationalSufficiency(Globalization/localization)AccessibilityScalability/PerformanceStressReviewFunctionalityTestReviewGeo/Political/LegalLogging/MessageformatTracing/Counters(Diagnosability)TestabilityTestHooksSCENARIOBASEDTESTSReliability/LongHaul

Integration

Interoperability

CompatibilityUE測試ReviewGeo/Political/Legal程序的靜態(tài)測試代碼會審（CodeReview）代碼會審是由若干程序員和測試員組成一個會審小組，通過閱讀、討論和爭議，對程序進行靜態(tài)分析的過程。

CodeReview的條件是清晰的Guildeline程序的靜態(tài)測試代碼會審（CodeReview）人工測試

經(jīng)驗表明，使用人工測試能夠有效地發(fā)現(xiàn)30％到70％的邏輯設(shè)計和編碼錯誤。桌前檢查（DeskChecking）由程序員自己檢查自己編寫的程序。程序員在程序通過編譯之后，進行單元測試之前，對源代碼進行分析，檢驗，并補充相關(guān)文檔，目的是發(fā)現(xiàn)程序的錯誤。人工測試調(diào)試（Debug）軟件調(diào)試是在進行了成功的測試之后才開始的工作。它與軟件測試不同，調(diào)試的任務(wù)是進一步診斷和改正程序中潛在的錯誤。調(diào)試活動由兩部分組成：確定程序中可疑錯誤的確切性質(zhì)和位置。對程序(設(shè)計,編碼)進行修改，排除這個錯誤。調(diào)試（Debug）軟件調(diào)試是在進行了成功的測試之后才開始的工調(diào)試工作是一個具有很強技巧性的工作。軟件運行失效或出現(xiàn)問題，往往只是潛在錯誤的外部表現(xiàn)，而外部表現(xiàn)與內(nèi)在原因之間常常沒有明顯的聯(lián)系。如果要找出真正的原因，排除潛在的錯誤，不是一件易事?？梢哉f，調(diào)試是通過現(xiàn)象，找出原因的一個思維分析的過程。調(diào)試工作是一個具有很強技巧性的工作。調(diào)試的步驟(1)從錯誤的外部表現(xiàn)形式入手，確定程序中出錯位置；(2)研究有關(guān)部分的程序，找出錯誤的內(nèi)在原因；(3)修改設(shè)計和代碼，以排除這個錯誤；(4)重復(fù)進行暴露了這個錯誤的原始測試或某些有關(guān)測試。

調(diào)試的步驟(1)從錯誤的外部表現(xiàn)形式入手，確定程序中出錯位從技術(shù)角度來看，查找錯誤的難度在于：

現(xiàn)象與原因所處的位置可能相距甚遠。當其他錯誤得到糾正時,這一錯誤所表現(xiàn)出的現(xiàn)象可能會暫時消失，但并未實際排除。現(xiàn)象實際上是由一些非錯誤原因(例如，舍入不精確)引起的。從技術(shù)角度來看，查找錯誤的難度在于：

現(xiàn)象可能是由于一些不容易發(fā)現(xiàn)的人為錯誤引起的。錯誤是由于時序問題引起的，與處理過程無關(guān)?，F(xiàn)象是由于難于精確再現(xiàn)的輸入狀態(tài)（例如，實時應(yīng)用中輸入順序不確定）引起?，F(xiàn)象可能是周期出現(xiàn)的。在軟、硬件結(jié)合的嵌入式系統(tǒng)中常常遇到。

現(xiàn)象可能是由于一些不容易發(fā)現(xiàn)的人為錯誤引起的。幾種主要的調(diào)試方法調(diào)試的關(guān)鍵在于推斷程序內(nèi)部的錯誤位置及原因?？梢圆捎靡韵路椒ǎ簭娦信佩e 這種調(diào)試方法目前使用較多，效率較低。它不需要過多的思考，比較省腦筋。例如：

通過內(nèi)存全部打印來調(diào)試，在這大量的數(shù)據(jù)中尋找出錯的位置。幾種主要的調(diào)試方法調(diào)試的關(guān)鍵在于推斷程序內(nèi)部的錯誤位置及原因

在程序特定部位設(shè)置打印語句，把打印語句插在出錯的源程序的各個關(guān)鍵變量改變部位、重要分支部位、子程序調(diào)用部位，跟蹤程序的執(zhí)行，監(jiān)視重要變量的變化。

自動調(diào)試工具。利用某些程序語言的調(diào)試功能或?qū)ｉT的交互式調(diào)試工具，分析程序的動態(tài)過程，而不必修改程序。

在程序特定部位設(shè)置打印語句，把打印語句插在出錯的源程序的各

應(yīng)用以上任一種方法之前，都應(yīng)當對錯誤的征兆進行全面徹底的分析，得出對出錯位置及錯誤性質(zhì)的推測，再使用一種適當?shù)恼{(diào)試方法來檢驗推測的正確性?；厮莘ㄕ{(diào)試

這是在小程序中常用的一種有效的調(diào)試方法。

一旦發(fā)現(xiàn)了錯誤，人們先分析錯誤征兆，確定最先發(fā)現(xiàn)“癥狀”的位置。 應(yīng)用以上任一種方法之前，都應(yīng)當對錯誤的征兆進行全面徹底的分

然后，人工沿程序的控制流程，向回追蹤源程序代碼，直到找到錯誤根源或確定錯誤產(chǎn)生的范圍。例如，程序中發(fā)現(xiàn)錯誤處是某個打印語句。通過輸出值可推斷程序在這一點上變量的值。再從這一點出發(fā)，回溯程序的執(zhí)行過程，反復(fù)考慮：“如果程序在這一點上的狀態(tài)（變量的值）是這樣，那么程序在上一點的狀態(tài)一定是這樣...”，直到找到錯誤的位置。

然后，人工沿程序的控制流程，向回追蹤源程序代碼，直到找到錯

歸納法調(diào)試歸納法是一種從特殊推斷一般的系統(tǒng)化思考方法。歸納法調(diào)試的基本思想是：從一些線索(錯誤征兆)著手，通過分析它們之間的關(guān)系來找出錯誤。

收集有關(guān)的數(shù)據(jù)

列出所有已知的測試用例和程序執(zhí)行結(jié)果?？茨男┹斎霐?shù)據(jù)的運行結(jié)果是正確的，哪些輸入數(shù)據(jù)的運行結(jié)果有錯誤。歸納法調(diào)試

組織數(shù)據(jù)

由于歸納法是從特殊到一般的推斷過程，所以需要組織整理數(shù)據(jù)，以發(fā)現(xiàn)規(guī)律。常以3W1H形式組織可用的數(shù)據(jù)：“what”列出一般現(xiàn)象；“where”說明發(fā)現(xiàn)現(xiàn)象的地點；“when”列出現(xiàn)象發(fā)生時所有已知情況；“how”說明現(xiàn)象的范圍和量級；“Yes”描述出現(xiàn)錯誤的3W1H；組織數(shù)據(jù)由于歸納法是從特殊到一般的推斷過程，所以需要提出假設(shè)證明假設(shè)糾正錯誤研究數(shù)據(jù)間的關(guān)系組織數(shù)據(jù)收集有關(guān)數(shù)據(jù)不能能能不能YesNowhatwhenwherehow歸納法中組織數(shù)據(jù)的3W1H表提出假設(shè)證明假設(shè)糾正錯誤研究數(shù)據(jù)組織數(shù)據(jù)收集有關(guān)不能能能不能

“No”作為比較，描述了沒有錯誤的3W1H。通過分析找出矛盾來。

提出假設(shè) 分析線索之間的關(guān)系，利用在線索結(jié)構(gòu)中觀察到的矛盾現(xiàn)象，設(shè)計一個或多個關(guān)于出錯原因的假設(shè)。如果一個假設(shè)也提不出來，歸納過程就需要收集更多的數(shù)據(jù)。此時，應(yīng)當再設(shè)計與執(zhí)行一些測試用例，以獲得更多的數(shù)據(jù)。

“No”作為比較，描述了沒有錯誤的3W1H。通過分析找

證明假設(shè)

把假設(shè)與原始線索或數(shù)據(jù)進行比較，若它能完全解釋一切現(xiàn)象，則假設(shè)得到證明；否則，就認為假設(shè)不合理，或不完全，或是存在多個錯誤，以致只能消除部分錯誤。

證明假設(shè)

演繹法調(diào)試演繹法是一種從一般原理或前提出發(fā)，經(jīng)過排除和精化的過程來推導出結(jié)論的思考方法。演繹法排錯是測試人員首先根據(jù)已有的測試用例，設(shè)想及枚舉出所有可能出錯的原因做為假設(shè)；然后再用原始測試數(shù)據(jù)或新的測試，從中逐個排除不可能正確的假設(shè)；最后，再用測試數(shù)據(jù)驗證余下的假設(shè)確是出錯的原因。演繹法調(diào)試列舉所有可能出錯原因的假設(shè)

把所有可能的錯誤原因列成表。通過它們，可以組織、分析現(xiàn)有數(shù)據(jù)。

利用已有的測試數(shù)據(jù)，排除不正確的假設(shè)

仔細分析已有的數(shù)據(jù)，尋找矛盾，力求排除前一步列出所有原因。如果所有原因都被排除了，則需要補充一些數(shù)據(jù)(測試用例)，以建立新的假設(shè)。列舉所有可能出錯原因的假設(shè)

把所有可能的錯誤原因列成表。通過

改進余下的假設(shè)

利用已知的線索，進一步改進余下的假設(shè)，使之更具體化，以便可以精確地確定出錯位置。

證明余下的假設(shè)列舉可能的原因排除不適當?shù)脑驅(qū)ΡＡ舻募僭O(shè)繼續(xù)推斷有剩余證明假設(shè)糾正錯誤能沒有剩余收集更多的數(shù)據(jù)不能改進余下的假設(shè)

利用已知的線索，進一步改進余下的假設(shè)，使之調(diào)試原則在調(diào)試方面，許多原則本質(zhì)上是心理學方面的問題。調(diào)試由兩部分組成，調(diào)試原則也分成兩組。確定錯誤的性質(zhì)和位置的原則用頭腦去分析思考與錯誤征兆有關(guān)的信息。避開死胡同。

調(diào)試原則在調(diào)試方面，許多原則本質(zhì)上是心理學方面的問題。調(diào)試由只把調(diào)試工具當做輔助手段來使用。利用調(diào)試工具，可以幫助思考，但不能代替思考。避免用試探法，最多只能把它當做最后手段。修改錯誤的原則在出現(xiàn)錯誤的地方，很可能還有別的錯誤。只把調(diào)試工具當做輔助手段來使用。利用調(diào)試工具，可以幫助思考，修改錯誤的一個常見失誤是只修改了這個錯誤的征兆或這個錯誤的表現(xiàn)，而沒有修改錯誤的本身。當心修正一個錯誤的同時有可能會引入新的錯誤。修改錯誤的過程將迫使人們暫時回到程序設(shè)計階段。修改源代碼程序，不要改變目標代碼。修改錯誤的一個常見失誤是只修改了這個錯誤的征兆或這個錯誤的表ReviewCodeReviewDebugReviewCodeReview第六章自動化測試

第六章自動化測試

自動化測試什么是自動化測試自動化測試是用來找Bug的嗎？自動化測試工具AutomationCode自動化測試用例的編碼原則自動化測試的運行自動化測試什么是自動化測試測試度量體系——自動化測試測試體系的核心是由自動化測試構(gòu)成的從找Bug到讓Bug自己跳出來修改一個Bug可能會引入更多的Bug，怎樣杜絕這種情況的發(fā)生計算進行缺陷預(yù)防的投資回報率缺陷分析工具測試度量體系——自動化測試測試體系的核心是由自動化測試構(gòu)成的

測量缺陷預(yù)防活動的有效性測量缺陷預(yù)防活動的有效性自動化測試數(shù)據(jù)驅(qū)動的測試BVT（DOA）和Non－BVTPassRateCodeCoverageFailureTrackGUI測試自動化自動化測試數(shù)據(jù)驅(qū)動的測試缺陷預(yù)防效率:有多少人被卷入一個Bug的處理?避免break和DOAbreak缺陷預(yù)防效率:有多少人被卷入一個Bug的處理?Pre-Checkin代碼在測試文檔里就應(yīng)該定義哪些用例屬于Pre-CheckIncase和產(chǎn)品代碼同時checkin，保證每一塊產(chǎn)品代碼從CheckIn的第一天就處于被測狀態(tài)，這是質(zhì)量保證體系的關(guān)鍵保證至少85%代碼覆蓋率代碼覆蓋率DOA/BasicFeaturePre-Checkin代碼在測試文檔里就應(yīng)該定義哪些用例CodeReview流程GuidelinechangereviewfixreviewCodeReview流程GuidelinechangereSmokeSystemDevChangeTestCodeCaseProfileRunTestSmokeSystemDevChangeTestCodCheckinProcessCodeReviewSanityTestSmokeReviewCodeCoverageCheckinProcessCodeReviewSanNoBugVS.FindingBugs自動化測試最大的價值是什么？SilverBullet？NoBugVS.FindingBugs自動化測試最大第七章測試管理

第七章測試管理

測試管理Bug數(shù)是否意味著開發(fā)人員的水平？Bug的分類和優(yōu)先級產(chǎn)品Bug和測試Bug解決Bug的時間要求測試管理Bug數(shù)是否意味著開發(fā)人員的水平？測試管理測試部門的組建硬件環(huán)境準備測試團隊的人數(shù)和構(gòu)成測試人員的要求按功能塊分工按測試類型分工測試管理測試部門的組建測試度量體系——測試管理測試團隊和其他團隊的配合，尤其是開發(fā)團隊日常測試活動安排周期性測試活動安排突發(fā)性測試活動安排測試人員的考評標準測試紀律測試度量體系——測試管理測試團隊和其他團隊的配合，尤其是開發(fā)測試管理統(tǒng)一測試團隊和開發(fā)團隊對Bug的理解和認識Triage團隊的權(quán)威性和嚴肅性質(zhì)量文化目標工作制限時完成數(shù)據(jù)統(tǒng)計和數(shù)據(jù)挖掘根據(jù)數(shù)據(jù)預(yù)估和控制進度測試管理統(tǒng)一測試團隊和開發(fā)團隊對Bug的理解和認識BugTrendBugTrend測試管理BugBash不同階段的獎勵與懲罰目標負責制不斷探索新方法、內(nèi)部立項開