ch5-單元測(cè)試與集成

第4章回顧4.1傳統(tǒng)的軟件測(cè)試過程

V模型、W模型、TMap4.2敏捷測(cè)試過程4.3軟件測(cè)試學(xué)派4.4基于風(fēng)險(xiǎn)的測(cè)試策略4.5測(cè)試過程改進(jìn)

TMMi、TPI、CTP、STEP4.6軟件測(cè)試規(guī)范第二篇軟件測(cè)試的技術(shù)從方法到技術(shù)，熟悉業(yè)務(wù)領(lǐng)域知識(shí)，深入系統(tǒng)架構(gòu)、設(shè)計(jì)模式和開發(fā)框架，靈活運(yùn)用測(cè)試工具，才能真正解決問題

第5章單元測(cè)試與集成測(cè)試第6章系統(tǒng)測(cè)試第7章驗(yàn)收測(cè)試

第8章軟件本地化測(cè)試第9章測(cè)試自動(dòng)化及其框架

軟件測(cè)試方法和技術(shù)第5章單元測(cè)試與集成測(cè)試第五章單元測(cè)試與集成測(cè)試5.1單元測(cè)試的目標(biāo)和任務(wù)5.2單元的靜態(tài)測(cè)試5.3驅(qū)動(dòng)程序和樁程序5.4單元測(cè)試工具5.5集成測(cè)試5.1單元測(cè)試的目標(biāo)和任務(wù)

單元測(cè)試的定義定義

單元測(cè)試是對(duì)軟件基本的組成單元進(jìn)行獨(dú)立的測(cè)試時(shí)機(jī)

單元測(cè)試和編碼是同步進(jìn)行，但在TDD中，強(qiáng)調(diào)測(cè)試在先，編碼在后。單元測(cè)試一般由開發(fā)人員完成,QA人員輔助.概念模塊、組件、單元

為何要進(jìn)行單元測(cè)試?盡早發(fā)現(xiàn)錯(cuò)誤錯(cuò)誤發(fā)現(xiàn)越早,成本越低.發(fā)現(xiàn)問題比較容易修正問題更容易檢查代碼是否符合設(shè)計(jì)和規(guī)范，有利于將來代碼的維護(hù)

單元測(cè)試的背景編程過程中，每寫1000行代碼會(huì)犯幾十個(gè)錯(cuò)誤編程與編譯運(yùn)行結(jié)束后，每1000行代碼中大約殘留有2-6個(gè)Bug尋找與修改程序錯(cuò)誤的代價(jià)占總體開發(fā)投資的30%

-60%Bug在整個(gè)研發(fā)流程中被發(fā)現(xiàn)的越早，修改的代價(jià)就越低單元測(cè)試的目標(biāo)目標(biāo):單元模塊被正確編碼信息能否正確地流入和流出單元在單元工作過程中，其內(nèi)部數(shù)據(jù)能否保持其完整性，包括內(nèi)部數(shù)據(jù)的形式、內(nèi)容及相互關(guān)系不發(fā)生錯(cuò)誤，全局變量在單元中的處理和影響為限制數(shù)據(jù)加工而設(shè)置的邊界處，能否正確工作單元的運(yùn)行能否做到滿足特定的邏輯覆蓋任務(wù)１:模塊獨(dú)立執(zhí)行路徑測(cè)試檢查每一條獨(dú)立執(zhí)行路徑的測(cè)試，并保證每條語(yǔ)句被至少執(zhí)行一次。Checklist:

誤解或用錯(cuò)了算符優(yōu)先級(jí)混合類型運(yùn)算變量初值錯(cuò)精度不夠表達(dá)式符號(hào)錯(cuò)其它任務(wù)2:局部數(shù)據(jù)結(jié)構(gòu)測(cè)試檢查局部數(shù)據(jù)結(jié)構(gòu)完整性Checklist:

不適合或不相容的類型說明變量無初值變量初始化或默認(rèn)值有錯(cuò)不正確的變量名或從來未被使用過出現(xiàn)上溢或下溢和地址異常其它任務(wù)３:模塊接口測(cè)試檢查模塊接口是否正確checklist:輸入的實(shí)際參數(shù)與形式參數(shù)是否一致(個(gè)數(shù)、屬性、量綱)調(diào)用其他模塊的實(shí)際參數(shù)與被調(diào)模塊的形參是否一致。

個(gè)數(shù)、屬性、量綱全程變量的定義在各模塊是否一致。外部輸入、輸出文件、緩沖區(qū)、錯(cuò)誤處理其它任務(wù)４:單元邊界條件測(cè)試檢查臨界數(shù)據(jù)處理的正確性Checklist:

普通合法數(shù)據(jù)的處理。普通非法數(shù)據(jù)的處理。邊界值內(nèi)合法邊界數(shù)據(jù)的處理。邊界值外非法邊界數(shù)據(jù)的處理。其它任務(wù)5:單元容錯(cuò)測(cè)試預(yù)設(shè)的各種出錯(cuò)處理是否正確有效。Checklist:

輸出的出錯(cuò)信息難以理解記錄的錯(cuò)誤與實(shí)際不相符異常處理不當(dāng)未提供足夠的定位出錯(cuò)的信息其它5.2靜態(tài)測(cè)試技術(shù)的運(yùn)用靜態(tài)測(cè)試技術(shù)：不運(yùn)行被測(cè)試程序，對(duì)代碼通過檢查、閱讀進(jìn)行分析。三步曲：

互查（PeerReview）

走查（WalkThrough）評(píng)審（Inspection）編碼的標(biāo)準(zhǔn)和規(guī)范標(biāo)準(zhǔn)：建立起來必須遵守的規(guī)則規(guī)范：建議最佳做法，推薦更好方式實(shí)施代碼規(guī)范的原因：

可靠性可讀性和可維護(hù)性可移植性來自Google的說明目的是通過詳細(xì)闡述C++注意事項(xiàng)來駕馭其復(fù)雜性.這些規(guī)則在保證代碼易于管理的同時(shí),高效使用C++的語(yǔ)言特性.風(fēng)格,亦被稱作可讀性,也就是指導(dǎo)C++編程的約定使代碼易于管理的方法之一是加強(qiáng)代碼一致性.保持統(tǒng)一編程風(fēng)格并遵守約定意味著可以很容易根據(jù)“模式匹配”規(guī)則來推斷各種標(biāo)識(shí)符的含義.創(chuàng)建通用,必需的習(xí)慣用語(yǔ)和模式可以使代碼更容易理解C++是一門包含大量高級(jí)特性的龐大語(yǔ)言.某些情況下,我們會(huì)限制甚至禁止使用某些特性.這么做是為了保持代碼清爽,避免這些特性可能導(dǎo)致的各種問題示例教材P100~102給出Java編程規(guī)范

代碼復(fù)審代碼互查一次檢查少于200～400行代碼努力達(dá)到一個(gè)合適的檢查速度：300～500LOC/hour有足夠的時(shí)間、以適當(dāng)?shù)乃俣取⒆屑?xì)地檢查，但不宜超過60～90分鐘在復(fù)審前，代碼作者應(yīng)該對(duì)代碼進(jìn)行注釋使用檢查表（checklist）肯定能改進(jìn)雙方（作者和復(fù)審者）的結(jié)果驗(yàn)證缺陷是否真正被修復(fù)……BestPracticesforPeerCodeReview

(

)示例走查（WalkThrough）定義：采用講解、討論和模擬運(yùn)行的方式進(jìn)行的查找錯(cuò)誤的活動(dòng)。注意：

引導(dǎo)小組成員在走查前通讀設(shè)計(jì)和編碼。限時(shí)，避免跑題發(fā)現(xiàn)問題適當(dāng)記錄，避免現(xiàn)場(chǎng)修改檢查要點(diǎn)是代碼是否符合標(biāo)準(zhǔn)和規(guī)范，是否有邏輯錯(cuò)誤審查（Inspection）以會(huì)議形式，制定目標(biāo)、流程和規(guī)則按缺陷檢查表（不斷完善）逐項(xiàng)檢查發(fā)現(xiàn)問題適當(dāng)記錄，避免現(xiàn)場(chǎng)修改發(fā)現(xiàn)重大缺陷，改正后會(huì)議需要重開。走查與審查的比較走查審查準(zhǔn)備通讀設(shè)計(jì)和編碼事先準(zhǔn)備Spec、程序設(shè)計(jì)文檔、源代碼清單、代碼缺陷檢查表等形式非正式會(huì)議正式會(huì)議參加人員開發(fā)人員為主項(xiàng)目組成員包括測(cè)試人員主要技術(shù)方法無缺陷檢查表生成文檔會(huì)議記錄靜態(tài)分析錯(cuò)誤報(bào)告目標(biāo)代碼標(biāo)準(zhǔn)規(guī)范無邏輯錯(cuò)誤代碼標(biāo)準(zhǔn)規(guī)范無邏輯錯(cuò)誤5.3動(dòng)態(tài)測(cè)試動(dòng)態(tài)測(cè)試需要真正將程序運(yùn)行起來，需要設(shè)計(jì)系列的測(cè)試用例保證測(cè)試的完整性和有效性。

白盒測(cè)試黑盒（灰盒）測(cè)試驅(qū)動(dòng)程序和樁程序運(yùn)行單元程序有時(shí)需要基于被測(cè)單元的接口，開發(fā)相應(yīng)的驅(qū)動(dòng)模塊和樁模塊。驅(qū)動(dòng)模塊（drive）:對(duì)底層或子層模塊進(jìn)行測(cè)試所編寫的調(diào)用這些模塊的程序。樁模塊（stub）：對(duì)頂層或上層模塊進(jìn)行測(cè)試時(shí)所編寫的替代下層模塊的程序。示例DriverStubFunctionundertest前置條件和后置條件前置條件示例：

Contract.Requires(x!=null);后置條件示例：Contract.EnsuresOnThrow<T>(this.F>0);Contract.Result<T>()

對(duì)象交互性測(cè)試匯集類測(cè)試：可以使用測(cè)試原始類的方法來測(cè)試匯集類，創(chuàng)建一些實(shí)例，確保實(shí)例作為消息中的參數(shù)被傳遞給正在測(cè)試的集合：存放這些對(duì)象的引用（對(duì)象之間一對(duì)多的關(guān)系）創(chuàng)建、刪除這些對(duì)象的實(shí)例協(xié)作類測(cè)試：集中測(cè)試對(duì)象之間調(diào)用關(guān)系，包括對(duì)象在被使用過程中屬性是否按定義的要求被正確使用、或被修改分布式對(duì)象測(cè)試注意事項(xiàng)

局部故障超時(shí)結(jié)構(gòu)的動(dòng)態(tài)性線程同步空指針保護(hù)案例分析格式化數(shù)字錯(cuò)誤案例分析字符串或數(shù)組越界案例分析其它示例指定的頁(yè)面找不到的錯(cuò)Error404或Error500案例分析沒有合理的關(guān)閉資源導(dǎo)致系統(tǒng)性能下降或最終崩潰不當(dāng)使用synchronized導(dǎo)致系統(tǒng)性能下降或最終崩潰調(diào)用不當(dāng)方法導(dǎo)致結(jié)果出錯(cuò)8.4.4~8.4.6P.170~P.172Action層的單元測(cè)試Mock就是模型，模擬被測(cè)試對(duì)象關(guān)聯(lián)的對(duì)象及測(cè)試數(shù)據(jù)StrutsTestCase是JUnitTestCase類的擴(kuò)展，提供基于Struts框架的代碼測(cè)試。用MockStrutsTestCase測(cè)試舉例

見P.173~P.174Biz邏輯事務(wù)層的單元測(cè)試DbUnit是為數(shù)據(jù)庫(kù)驅(qū)動(dòng)、對(duì)JUnit擴(kuò)展的解決方法有效的單元測(cè)試必須隔離測(cè)試對(duì)象和外部依賴，以便管理測(cè)試對(duì)象的狀態(tài)和行為。使用DbUnit，開發(fā)人員可以控制測(cè)試數(shù)據(jù)庫(kù)的狀態(tài)，包括準(zhǔn)備好初始化數(shù)據(jù)以及將數(shù)據(jù)庫(kù)狀態(tài)恢復(fù)到測(cè)試前的狀態(tài)。示例見：P.175~P.176Servlet的單元測(cè)試HttpUnit可提供一個(gè)模擬的Servlet容器，讓Servlet代碼不需要發(fā)布到Servlet容器（如tomcat）就可以直接測(cè)試使用HttpUnit測(cè)試Servlet時(shí)，先創(chuàng)建一個(gè)ServletRunner的實(shí)例，負(fù)責(zé)模擬Servlet容器環(huán)境。如果只測(cè)試單個(gè)Servlet,可直接使用registerServlet方法注冊(cè)其Servlet，如果需要配置多個(gè)Servlet，需編寫自己的web.xml，然后在初始化ServletRunner時(shí)將其作為參數(shù)傳給ServletRunner的構(gòu)造器示例見：P.177~P.178Struts

+Spring

+Hibernate的測(cè)試Struts:MVCFramework，用于快速開發(fā)JavaWeb應(yīng)用

Spring：輕型容器，其核心是BeanFactory，用以構(gòu)造所需的Model

Hibernate：對(duì)象關(guān)系映射框架，對(duì)JDBC使用進(jìn)行了封裝，這樣可以隨心所欲使用對(duì)象編程思維來操縱數(shù)據(jù)庫(kù)

Spring的測(cè)試機(jī)制

用SpringMock對(duì)Spring進(jìn)行單元測(cè)試

用HSQLDB對(duì)Hibernate進(jìn)行單元測(cè)試

jdbc:hsqldb:mem:dbname

對(duì)Spring進(jìn)行單元測(cè)試Spring從Web端為每個(gè)關(guān)鍵接口提供了Mock類Spring對(duì)JUnit框架擴(kuò)展使用Spring-mock.jar：

創(chuàng)建BaseTestCase來繼承AbstractTransactionalDataSourceSpringContextTests，其他測(cè)試用例繼承BaseTestCase類BussinessObjectbo=(BussinessObject)applicationContext.getBean("BussinessObject");調(diào)用方法：用HSQLDB對(duì)Hibernate進(jìn)行單元測(cè)試下載hsqldb.jar放在web-inf/lib目錄下。編寫test.script文件，創(chuàng)建數(shù)據(jù)庫(kù)結(jié)構(gòu)，如createtable……編寫perties文件，配置hsqldb數(shù)據(jù)屬性。在spring中配置sessionFactorybean，其中dataSource配置成hsqldb，hibernate方言為org.hibernate.dialect.HSQLDialect示例：?jiǎn)卧獪y(cè)試檢查表關(guān)鍵測(cè)試項(xiàng)是否已糾正有無任何輸入?yún)?shù)沒有使用？有無任何輸出參數(shù)沒有產(chǎn)生？有無任何數(shù)據(jù)類型不正確或不一致？有無任何算法與PDL或功能需求中的描述不一致？有無任何局部變量使用前沒有初始化？有無任何外部接口編碼錯(cuò)誤？即調(diào)用語(yǔ)句、文件存取、數(shù)據(jù)庫(kù)錯(cuò)誤。有無任何邏輯路徑錯(cuò)誤？該單元是否有多個(gè)入口或多個(gè)正常的出口？額外測(cè)試項(xiàng)該單元中有任何地方與PDL與PROLOG中的描述不一致？代碼中有無任何偏離本項(xiàng)目標(biāo)準(zhǔn)的地方？代碼中有無任何對(duì)于用戶來說不清楚的錯(cuò)誤提示信息？如果該單元是設(shè)計(jì)為可重用的，代碼中是有可能妨礙重用的地方？5.4單元測(cè)試常用工具簡(jiǎn)介JUnit介紹在Eclipse中JUnit應(yīng)用舉例Junit+Ant構(gòu)建自動(dòng)的單元測(cè)試CheckStyle/PMD與FindBug的使用SourceMonitor檢測(cè)代碼復(fù)雜度開源的單元測(cè)試工具商業(yè)的單元測(cè)試工具單元測(cè)試工具種類

代碼規(guī)則/風(fēng)格檢查工具內(nèi)存資源泄漏檢查工具代碼覆蓋率檢查工具代碼性能檢查工具單元測(cè)試工具列表5.7.1

JUnit提供了編寫測(cè)試類的框架，使測(cè)試代碼的編寫更方便共享測(cè)試數(shù)據(jù)的測(cè)試工具方便地組織和運(yùn)行測(cè)試的測(cè)試套件可以使測(cè)試代碼與產(chǎn)品代碼分開，這更有利于代碼的打包發(fā)布和測(cè)試代碼的管理易于集成到程序構(gòu)建過程中，JUnit和Ant的結(jié)合還可以實(shí)施增量開發(fā)。具有很強(qiáng)的擴(kuò)展性Junit（）是一個(gè)開放源代碼的Java測(cè)試框架（單元測(cè)試框架體系xUnit的一個(gè)實(shí)例），用在編寫和運(yùn)行可重復(fù)的的測(cè)試上，包括如下特性：在Eclipse中JUnit應(yīng)用舉例

JUnit結(jié)構(gòu)JUnit安裝JUnit設(shè)置JUnit腳本示例一JUnit腳本示例二JUnit+Ant構(gòu)建自動(dòng)的單元測(cè)試5.7.2

微軟VSTS的單元測(cè)試VisualStudioTeamSystem（VSTS）是一套工具集，全面整合了軟件設(shè)計(jì)、開發(fā)、測(cè)試、部署和人員協(xié)作工具，其開發(fā)版（DevelopmentEdition）提供了靜態(tài)分析、代碼剖析、代碼涵蓋以及其它單元測(cè)試所需的功能特性。創(chuàng)建單元測(cè)試項(xiàng)目。設(shè)置項(xiàng)目引用。添加適當(dāng)?shù)臏y(cè)試類（一個(gè)或多個(gè)）。生成主干的單元測(cè)試框架（UnitTestFramework）類和屬性。創(chuàng)建單個(gè)測(cè)試方法。創(chuàng)建適合特定接口的邏輯VSTS架構(gòu)VSTS單元測(cè)試屬性VSTS斷言[TestMethod]publicvoidTestDeposit(){

BanckAccountaccount=newBanckAccount();

account.Deposit(125.0);

account.Deposit(25.0);

Assert.AreEqual(150.0,account.Balance,

"Balanceiswrong.");}Unittest-示例1Unittest-示例2usingMicrosoft.VisualStudio.TestTools.UnitTesting;[TestClass]publicclassAccountTest(publicclassAccount){[TestMethod]publicvoidTransferFunds(){Accountsource=newAccount();source.Deposit(200.00M);Accountdest=newAccount();dest.Deposit(150.00F);source.TransferFunds(dest,100.00F);

Assert.AreEqual(250.00F,dest.Balance);Assert.AreEqual(100.00F,source.Balance);}}Unittest-示例3

FindBugsinEclipseCheckStyle

CheckStyle

CheckStylePMD

PMDFlexPMDCheckStyle/PMD與FindBugs比較SourceMonitor檢測(cè)代碼復(fù)雜度測(cè)試各類源代碼的復(fù)雜度、深度嵌套類和性能，生成相應(yīng)的圖表

開源單元測(cè)試工具C/C++語(yǔ)言單元測(cè)試工具：CppTest、CppUnit、…Java語(yǔ)言單元測(cè)試工具：TestNG、PMD、Checkstyle、Findbugs、Jalopy……MockObject類工具:MockObjects、Xdoclet、EasyMock、MockCreator、MockEJB、ObjcUnit、jMock等

其它商業(yè)單元測(cè)試工具

C/C++語(yǔ)言的單元測(cè)試工具以商業(yè)工具為主，例如ParasoftC++、PRQA?C/C++、CompuWareDevPartnerforVisualC++BoundsCheckerSuite、PanoramaC++等內(nèi)存資源泄漏檢查工具，如CompuWareBounceChecker，IBMRationalPurifyPlus等代碼覆蓋率檢查工具，如CompuWareTrueCoverage，IBMRationalPureCoverage，TeleLogicLogiscope等。代碼性能檢查工具，如Logiscope和Macabe等5.5系統(tǒng)集成的模式與方法集成測(cè)試前的準(zhǔn)備集成測(cè)試的模式自頂向下和自底向上集成方法大棒與三明治集成方法持續(xù)集成見教材6.1為什么總是集成不起來？集成測(cè)試的模式漸增式測(cè)試模式與非漸增式測(cè)試模式非漸增式測(cè)試模式：先分別測(cè)試每個(gè)模塊，再把所有模塊按設(shè)計(jì)要求放在一起結(jié)合成所要的程序，如大棒模式。漸增式測(cè)試模式：把下一個(gè)要測(cè)試的模塊同已經(jīng)