白盒測試技術(shù)工業(yè)和信息化部電子第五研究所中國賽寶實驗室2023年2月2日陳能技課程大綱1白盒測試知識體系2如何開展實施白盒測試項目3靜態(tài)白盒測試方法4動態(tài)白盒測試方法學(xué)習(xí)方法案例講解+演練+討論主題1白盒測試知識體系2如何開展實施白盒測試項目3靜態(tài)白盒測試方法4動態(tài)白盒測試方法5持續(xù)集成一、白盒測試知識體系白盒測試的優(yōu)勢早期測試與白盒測試敏捷測試思想與白盒測試技術(shù)白盒測試工程師的技能要求黑盒測試的缺陷黑盒測試既不充分，而且效率也低。在系統(tǒng)完成之前，測試就無法開始，測試人員只有軟件版本發(fā)布時才能拿到版本進行測試。Findbugsearly!Costeffective!白盒測試的優(yōu)勢盡早測試原則缺陷預(yù)防不治已病治未病，不治已亂治未亂。--《黃帝內(nèi)經(jīng)》克勞士比零缺陷第一次就把事情做對缺陷預(yù)防敏捷測試思想與白盒測試技術(shù)敏捷測試意味著質(zhì)量觀的變化，整個研發(fā)團隊都要對質(zhì)量負(fù)責(zé)敏捷開發(fā)SCRUMSCRUM強調(diào)以有節(jié)奏的流模式生產(chǎn)軟件可預(yù)期的8小時工作日被視為專業(yè)素養(yǎng)和控制力的代表長度為30天的開發(fā)進程可以適用于大多數(shù)項目敏捷XP實踐XP工作流程開始項目編寫故事評估故事估計工作速率創(chuàng)建迭代計劃修改迭代計劃將故事分成任務(wù)選擇任務(wù)選擇合作伙伴編寫單元測試獲取最新的代碼重構(gòu)舊代碼并進行測試編寫新代碼集成并運行單元測試重構(gòu)新代碼并進行測試簽入新代碼運行客戶測試發(fā)布軟件獲得用戶反饋評估工作速率結(jié)束項目規(guī)劃策略迭代任務(wù)白盒測試工程師的技能要求主題1白盒測試知識體系2如何開展實施白盒測試項目3靜態(tài)白盒測試方法4動態(tài)白盒測試方法5持續(xù)集成二、如何開展實施白盒測試項目白盒測試方案介紹試點項目選取策略分階段實施過程白盒測試方案介紹持續(xù)集成持續(xù)質(zhì)量度量

測試用例執(zhí)行

自動化測試代碼質(zhì)量趨勢監(jiān)控代碼質(zhì)量度量角度：-代碼量-文檔量-冗余度-復(fù)雜度-代碼問題、技術(shù)債務(wù)試點項目選取策略質(zhì)量要求相對高的進度相對不緊迫資源相對充足（人的問題）小范圍試驗、逐步推廣分階段實施過程先靜態(tài)、后動態(tài)，先代碼審查、后單元測試小范圍代碼規(guī)則集、待習(xí)慣后、再逐步擴大代碼審查：工具+人工接口測試自動化->細粒度單元測試持續(xù)集成框架搭建->持續(xù)質(zhì)量度量平臺搭建Google的測試策略谷歌采用70/20/10原則:70%小，20%中，10%大主題1白盒測試知識體系2如何開展實施白盒測試項目3靜態(tài)白盒測試方法4動態(tài)白盒測試方法5持續(xù)集成三、靜態(tài)白盒測試方法代碼審查最佳實踐代碼自動化分析工具的應(yīng)用如何結(jié)合工具分析與人工審查代碼質(zhì)量度量方法代碼質(zhì)量度量常用工具介紹代碼審查最佳實踐代碼審查對成本的節(jié)省代碼審查的目的評審制度的建立代碼審查方法、原則、流程規(guī)范代碼審查對成本的節(jié)省代碼審查對成本的節(jié)省代碼審查的目的1、設(shè)計合理性Review2、互為Backup

3、分享知識、設(shè)計、技術(shù)

4、代碼可讀性5、Code中的“地雷區(qū)”Review6、發(fā)現(xiàn)代碼中的業(yè)務(wù)邏輯錯誤“A的代碼有個bug被B發(fā)現(xiàn)，所以A能力不行，B能力更好”，這一類的陷阱很容易被擴散從而影響團隊內(nèi)部的協(xié)作，因此需要避免。評審對軟件質(zhì)量的作用IBM的第一個缺陷預(yù)防的研究包含了數(shù)百個應(yīng)用程序，且歷時超過3年。應(yīng)用程序使用正式審查后，與那些只進行了測試的類似的應(yīng)用程序相比，其工期更短、成本更低。20世紀(jì)70年代IBMIMS數(shù)據(jù)庫產(chǎn)品，在審查之前，IMS測試組需要90天做3輪測試。而進行了審查之后，同樣的測試周期縮短到30天，只做一輪測試。評審對軟件質(zhì)量的作用缺陷起源缺陷起源缺陷發(fā)現(xiàn)缺陷發(fā)現(xiàn)沒有使用正式審查的缺陷起源點和發(fā)現(xiàn)點使用了正式審查的缺陷起源點和發(fā)現(xiàn)點評審對軟件質(zhì)量的作用測試前缺陷清除手段–審查（需求、架構(gòu)、設(shè)計、代碼及其他可交付成果）使用率：超過75%的系統(tǒng)和嵌入式應(yīng)用程序超過35%的大型商業(yè)應(yīng)用程序少于5%的Web和IT應(yīng)用程序少于5%的小型應(yīng)用程序（規(guī)模小于1000個功能點）缺陷清除效率范圍：最小低于65%平均等于85%最大高于97%準(zhǔn)備時間：超過3小時/審查參與者執(zhí)行時間：超過4小時/參與者每次審查會議協(xié)同效應(yīng)：嵌入式、系統(tǒng)、IT、軍用軟件相反指示：敏捷項目、規(guī)模小于500個功能點的小型項目數(shù)據(jù)來源：《軟件質(zhì)量經(jīng)濟學(xué)》3種相對正式的評審審查小組評審走查組織者企業(yè)級常由EPG、QA部門組織團隊級，項目級通常由項目經(jīng)理發(fā)起團隊級，項目級通常由項目內(nèi)發(fā)起主持人專職主持人，不能使作者可專職或由作者兼任通常是作者會前會議一定會召開評審前的會議會前會議通常很簡單通常沒有檢查表一定有規(guī)范的檢查表相對簡單的檢查表通常沒有通用評審流程步驟

介紹會議？1.計劃階段3.準(zhǔn)備階段2.介紹會議YN7.跟蹤階段6.返工階段YN第三小時會議？4.Review會議5.第三小時會議

入口準(zhǔn)則出口準(zhǔn)則同行評審常見問題沒有評審計劃專家選擇不合適沒有充分的準(zhǔn)備評審會議偏離主題和重點評審會議中過多爭論占用大量時間問題修改后跟蹤不力

XX評審CHECKLIST

1、*****************************2、*****************************3、*****************************此處鍵入姓名此處鍵入姓名

沒有使用CheckList作為指導(dǎo)代碼審查方法流程組織：CMMIvs.敏捷審查范圍篩選人工+工具CMMI代碼審查流程準(zhǔn)備代碼審查進入條件：代碼更改集已通過單元測試代碼審查會議進入條件：代碼標(biāo)準(zhǔn)、威脅模型代碼審查活動：NameCorrectnessCodeRelevance（功能相關(guān)、無無用代碼）ExtensibilityMinimalCodeComplexity

AlgorithmicComplexityCodeSecurityCodeReviewWorkItem（代碼審查工作項記錄）代碼審查檢查單模板：CodeReviewChecklist.dotMSFforCMMIProcessImprovement謹(jǐn)慎的使用審查中問題的發(fā)現(xiàn)率作為考評標(biāo)準(zhǔn)在代碼審查中如果發(fā)現(xiàn)問題，對于問題的發(fā)現(xiàn)者來說這是好事，應(yīng)該予以鼓勵。但對于被發(fā)現(xiàn)者，我們不主張使用這個方式予以懲罰。軟件開發(fā)中bug在所難免，過度苛求本身有悖常理。更糟的是，如果造成參與者怕承擔(dān)責(zé)任，不愿意在審查中指出問題，代碼審查就沒有任何的價值和意義。敏捷CodeReview流程Code

Review協(xié)作過程1）先由代碼的開發(fā)人員向檢查人員進行大體的介紹，包括設(shè)計思想、數(shù)據(jù)結(jié)構(gòu)、程序代碼結(jié)構(gòu)介紹等。2）雙方進行討論、交流。3）檢查人員單獨進一步進行CodeReview，并記錄Review結(jié)果和建議。4）由檢查人員和開發(fā)人員一起，檢查人員反饋Code

Review結(jié)果，并和開發(fā)人員一起討論改進方法，重構(gòu)。5）最后把可重用的Code

Review的經(jīng)驗總結(jié)編碼規(guī)范，或者記錄到“地雷區(qū)”中。便于整個團隊復(fù)用經(jīng)驗。MSFforAgileSoftwareDevelopment進入條件：Areviewerfamiliarwiththecodeareaisavailable.代碼審查活動：NameCorrectnessCodeRelevance（功能相關(guān)、無無用代碼）ExtensibilityMinimalCodeComplexityAlgorithmicComplexityCodeSecurityFixReviewChanges（修改評審需要修復(fù)的問題）審查前的代碼開發(fā)者準(zhǔn)備因為代碼開發(fā)者需要重新考慮，并解釋注釋過程中所發(fā)生的更改，所以代碼開發(fā)者需要在評審開始之前就找出許多缺陷，以讓評審變得更加有效。代碼開發(fā)者在評審之前要先注釋他們的源代碼。代碼審查人員組織形式開發(fā)組長負(fù)責(zé)制對小組所有成員的代碼質(zhì)量負(fù)責(zé)開發(fā)組長的開發(fā)任務(wù)不要太多，以便有精力去指導(dǎo)其他成員的設(shè)計，并且復(fù)查他們的代碼項目經(jīng)理或QA進行抽查成員互助制每個組員的代碼簽入前必須請求一位組員進行代碼審查審查者與被審查者對審查的代碼共同擁有質(zhì)量職責(zé)代碼審查的范圍定義每次審查的代碼量增量代碼審查最近一次迭代開發(fā)的代碼專題性的代碼審查（安全、性能等）基于風(fēng)險篩選審查重點系統(tǒng)關(guān)鍵模塊業(yè)務(wù)較復(fù)雜的模塊代碼復(fù)雜度高的模塊代碼審查范圍--每次審查的代碼量根據(jù)smartbear在思科所作的調(diào)查，每次審查200行-400行的代碼效果最好。每次試圖審查的代碼過多，發(fā)現(xiàn)問題的能力就會下降。隨著開發(fā)平臺和開發(fā)語言的不同，最優(yōu)的代碼審查量有所不同。但是限制每次審查的數(shù)量確實非常必要，因為這個過程是高強度的腦力密集型活動。時間一長，代碼在審查者眼里只是字母，無任何邏輯聯(lián)系，自然不會有太多的產(chǎn)出。增量CodeReviewReview應(yīng)該持續(xù)進行，每次一部分，對于新增的需求、新增的代碼、修改的部分實行增量審查代碼審查的效率問題每小時超過400LOC的評審速度會降低效率。花足夠的時間進行適當(dāng)緩慢的評審，但是不要超過60-90分鐘大約60

分鐘后，評審者就會感到疲勞，于是就不會找到額外的缺陷了?；陲L(fēng)險篩選審查重點系統(tǒng)關(guān)鍵模塊、業(yè)務(wù)較復(fù)雜的模塊從業(yè)務(wù)需求重要度、優(yōu)先級出發(fā)篩選缺陷率較高的模塊從歷史缺陷數(shù)據(jù)出發(fā)篩選代碼復(fù)雜度高的模塊從代碼實現(xiàn)的復(fù)雜度（圈復(fù)雜度）度量出發(fā)篩選把工具引入到代碼審查流程中把工具引入到代碼審查流程中編程規(guī)范編程規(guī)范通常包括：數(shù)據(jù)類型檢查代碼縮進換行命名規(guī)范注釋規(guī)范…CodeReview-類型檢查 在Java中，下面的語句雖然符合類型檢查規(guī)則，但是會在運行時失敗，拋出一個ArrayStoreException異常: Object[]objs=newString[1]; objs[0]=newObject();CodeReview-類型檢查CodeReview-風(fēng)格檢查常見工具 C/C++：PC-Lint、PRQAC/C++、CppLint JAVA：PMD、CheckStyle .NET：StyleCop、FxCop風(fēng)格檢查更加挑剔，也更加注重空格、縮進、命名、注釋、程序結(jié)構(gòu)這些表面的東西。風(fēng)格檢查程序所展示的錯誤往往都是影響代碼的可讀性和可維護性的問題。好的代碼編寫風(fēng)格能讓代碼變得“賞心悅目”增強代碼的可讀性和可維護性并且能促進項目組基于代碼的溝通。

public

enumColor{red,green,blue}程序結(jié)構(gòu)的問題CheckStyle、PMDpublic

finalStringgetColorString(finalColorc){Stringret="";switch(c){case

red:System.out.println("red");}returnret;}public

static

voidmain(String[]args){System.out.println("TheBritisharecoming"+revere(1));}public

staticStringrevere(intlights){Stringmanner="byland";

if(lights>0)if(lights==2)manner="bysea";elsemanner="";

returnmanner;}縮進的問題命名規(guī)范駱駝（Camel）帕斯卡（Pascal）匈牙利“匈牙利”法該命名規(guī)則的主要思想是“在變量和函數(shù)名中加入前綴以增進人們對程序的理解”。例如所有的字符變量均以ch為前綴，若是指針變量則追加前綴p。如果一個變量由ppch開頭，則表明它是指向字符指針的指針?！靶傺览狈ǖ娜秉c“匈牙利”法最大的缺點是煩瑣，例如 inti,j,k; floatx,y,z;倘若采用“匈牙利”命名規(guī)則，則應(yīng)當(dāng)寫成 intiI,iJ,ik;//前綴i表示int類型 floatfX,fY,fZ;//前綴f表示float類型如此煩瑣的程序會讓絕大多數(shù)程序員無法忍受。駱駝式命名法正如它的名稱所表示的那樣，是指混合使用大小寫字母來構(gòu)成變量和函數(shù)的名字。例如，下面是分別用駱駝式命名法和下劃線法命名的同一個函數(shù)：

printEmployeePaychecks()；

print_employee_paychecks()；

第一個函數(shù)名使用了駱駝式命名法--函數(shù)名中的每一個邏輯斷點都有一個大寫字母來標(biāo)記；第二個函數(shù)名使用了下劃線法函數(shù)名中的每一個邏輯斷點都有一個下劃線來標(biāo)記。

駱駝式命名法近年來越來越流行了，在許多新的函數(shù)庫和Microsoft

Windows這樣的環(huán)境中，它使用得當(dāng)相多。另一方面，下劃線法是c出現(xiàn)后開始流行起來的，在許多舊的程序和UNIX這樣的環(huán)境中，它的使用非常普遍。帕斯卡（Pascal）與駱駝命名法類似。只不過駱駝命名法是首字母小寫，而帕斯卡命名法是首字母大寫，如：publicvoidDisplayInfo();

stringUserName;

二者都是采用了帕斯卡命名法

在C#和JAVA中，以帕斯卡命名法和駱駝命名法居多。據(jù)考察，沒有一種命名規(guī)則可以讓所有的程序員贊同，程序設(shè)計教科書一般都不指定命名規(guī)則。命名規(guī)則對軟件產(chǎn)品而言并不是“成敗悠關(guān)”的事，我們不要花太多精力試圖發(fā)明世界上最好的命名規(guī)則，而應(yīng)當(dāng)制定一種令大多數(shù)項目成員滿意的命名規(guī)則，并在項目中貫徹實施。命名規(guī)范注釋代碼注釋量檢查注釋風(fēng)格文件注釋類注釋函數(shù)注釋變量注釋代碼實現(xiàn)注釋TODO注釋SourceMonitorJava注釋規(guī)范：/technetwork/java/javase/documentation/codeconventions-141999.html#385推薦閱讀《TheElementsofJavaStyle》100頁左右的關(guān)于Java編程風(fēng)格的書官方標(biāo)準(zhǔn)：/technetwork/java/codeconvtoc-136057.html

練習(xí)應(yīng)用CheckStyle、PMD等工具檢查代碼風(fēng)格CodeReview–程序理解程序理解工具能幫助我們搞懂代碼庫中的大量代碼，洞察程序運轉(zhuǎn)之道，評審代碼的設(shè)計架構(gòu)等內(nèi)容。集成開發(fā)環(huán)境（IDE）一般至少都包含某些程序理解功能，例如：“查找本方法的所有應(yīng)用”。常用工具代碼流程圖：CodeVisualtoFlowchartUML與源代碼雙向工程，例如Green、Fujaba、Understand、RationalRose代碼調(diào)用關(guān)系圖：Understand、JDepend、JArchitectPMD的數(shù)據(jù)流分析視圖Fujiaba能在UML視圖和源代碼之間來回轉(zhuǎn)換JDepend識別包依賴Understand的”蝴蝶圖”CodeReview-Bug查找BUG查找的目的不像風(fēng)格檢查那樣抱怨格式方面的問題，而是根據(jù)“BUG慣用法”（規(guī)則）來描述代碼中潛在的缺陷。常用工具：

PMD、FindBugs JTest、Coverity、Klocwork《MoreJavaPitfalls》EmptyCatchBlock: EmptyCatchBlockfindsinstanceswhereanexceptioniscaught,butnothingisdone.Inmostcircumstances,thisswallowsanexceptionwhichshouldeitherbeactedonorreported.Example: publicvoiddoSomething(){ try{ FileInputStreamfis=newFileInputStream("/tmp/bugger"); }catch(IOExceptionioe){ } }CodeReview-Bug查找PMD能檢查出上面Java代碼中“空的異常Catch塊”的問題Stringastr="abcdefghijklmn";astr.replace("abc","123");System.out.println(astr);PMD、FindBugsFindBugs能檢查出上述Java代碼的潛在錯誤

inta=0;switch(a){case0:return0;case1:a=1;}returna;PMD可以發(fā)現(xiàn)其中潛在的錯誤doublei=0.0;while(i<10){

i+=0.1;

System.out.println(String.valueOf(i));

if(i==6.0){

System.out.println("OK!");

}}《Java編程規(guī)范》（第三版）

voidmethod1(Vectorvector){

for(inti=0;i<vector.size();i++)//Violation;//...}

voidmethod3(Strings){

if(s.startsWith("a")){//violation//...}}代碼效率問題練習(xí)使用PMD、FindBugs檢查代碼錯誤推薦閱讀CodeReview-安全審查靜態(tài)的代碼安全測試：主要是通過對源代碼進行安全掃描，根據(jù)程序中數(shù)據(jù)流，控制流，語義等信息與軟件安全規(guī)則庫進行匹對，從中找出代碼中潛在的安全漏洞?？梢栽诰幋a階段找出大部分可能存在安全風(fēng)險的代碼，這樣開發(fā)人員可以在早期解決潛在的安全問題。工具CodeSecure、Yasca、FindBugs\

FindSecurityBugsFortify、AppScanSourcetry{Stringpwd=hashPassword(password);StringsqlString="SELECT*FROMdb_userWHEREusername='"+username+"'ANDpassword='"+pwd+"'";Statementstmt=connection.createStatement();ResultSetrs=stmt.executeQuery(sqlString);

if(!rs.next()){

throw

newSecurityException("Usernameorpasswordincorrect");}//Authenticated;proceed}finally{

try{connection.close();}catch(SQLExceptionx){//forwardtohandler}}importjava.io.FileReader;publicclassEightBall{ publicstaticvoidmain(Stringargs[])throwsException{ char[]buffer=newchar[1024]; Stringfilename=args[0]; try{ filename=""+(Integer.parseInt(filename)%3); }catch(Exceptione){ System.out.println("Invalidinput."); }

newFileReader(filename).read(buffer); System.out.println(buffer); }}FindSecurityBugs、FortifyFortify能找到上述代碼的“路徑操縱”問題Java安全編程標(biāo)準(zhǔn)TheCERTOracleSecureCodingStandardforJava/CodeReview-代碼質(zhì)量度量代碼精簡度繼承深度類間耦合度圈復(fù)雜度可測試性可維護性…常用工具：Metrics、JavaNCSS、Testability-explorer、SourceMonitor、SonarLogiscope代碼復(fù)雜度軟件復(fù)雜性度量-圈復(fù)雜度復(fù)雜度計算公式為：M=V(G)=e–n+2其中：V(G)路徑圖的環(huán)形數(shù)目e=邊的數(shù)目n=節(jié)點數(shù)目練習(xí)計算以下代碼的圈復(fù)雜度：voidSort(intiRecordNum,intiType)1{2intx=0;3inty=0;4while(iRecordNum-->0)5{6If(iType==0)7 x=y+2;8else9If(iType==1)10x=y+10;11else12x=y+20;13}14}討論如果檢查出圈復(fù)雜度很高應(yīng)該怎么辦？軟件復(fù)雜性度量--語法構(gòu)造法基本思路是根據(jù)程序中可執(zhí)行代碼行的操作符和操作數(shù)的數(shù)量來計算程序的復(fù)雜性。操作符和操作數(shù)的量越大，程序結(jié)構(gòu)就越復(fù)雜。語法構(gòu)造方法可以揭示程序中單獨的語法構(gòu)造和缺陷率之間的關(guān)系：缺陷率=0.15+0.23DOWHILE+0.22SELECT+0.07IF-THEN-ELSELogiscope軟件復(fù)雜性度量--結(jié)構(gòu)度量法Henry給出的結(jié)構(gòu)復(fù)雜性定義：Cp=(扇入×扇出)2其中：扇入–調(diào)用外部模塊的模塊數(shù)扇出–被外部模塊調(diào)用的次數(shù)JDepend、Understand、Metrics、Logiscope代碼審查輔助工具（1）CodeCollaborator、Jupiter代碼審查輔助工具（2）SourceMonitor、JavaNCSS…推薦閱讀主題1白盒測試知識體系2如何開展實施白盒測試項目3靜態(tài)白盒測試方法4動態(tài)白盒測試方法5持續(xù)集成四、動態(tài)白盒測試方法單元測試最佳實踐單元測試用例設(shè)計的方法與技巧單元測試工具與框架的應(yīng)用樁與驅(qū)動單元測試覆蓋率分析代碼性能測試代碼內(nèi)存泄漏測試WhyUnitTesting?Dynamicblack-boxtestingishighcost:1.It’sdifficultandsometimesimpossibletofigureoutexactlywhatcausedtheproblem.2.Somebugshideothers.立即測試vs單一測試TDD思想TDD把單元測試的地位提高到了史無前例的最高點，倡導(dǎo)測試先行、用測試驅(qū)動開發(fā)。測試是最好的設(shè)計，在編寫代碼之前就要把測試想好，這樣在編寫代碼時才胸有成竹。XP中一個很核心的實踐就是TDDTDD基本過程測試驅(qū)動開發(fā)的基本過程明確當(dāng)前要完成的功能?？梢杂涗洺梢粋€TODO列表?？焖偻瓿舍槍Υ斯δ艿臏y試用例編寫。測試代碼編譯不通過。編寫對應(yīng)的功能代碼。測試通過。對代碼進行重構(gòu)，并保證測試通過。循環(huán)完成所有功能的開發(fā)。測試驅(qū)動開發(fā)的好處不斷測試，提高軟件質(zhì)量不斷重構(gòu)，提高軟件處理變化的能力在EmpiricalSoftwareEngineering雜志上首次發(fā)表的一篇研究報告聲稱：“看來TDD可以應(yīng)用在多個領(lǐng)域中，并顯著降低軟件的缺陷密度，同時也不會明顯降低開發(fā)團隊的工作效率。”單元測試框架基于框架來編寫單元測試代碼會更方便、高效。常見的單元測試框架JUnit、TestNGJUnit單元測試建立JUnit單元測試JUnit3與JUnit4的區(qū)別斷言類的使用TestCase、TestSuiteJUnit框架的AnnotationAnnotation含義@Test定義一個要測試的方法@Before在每一個測試之前都會被執(zhí)行的方法，這個方法常常用來進行一些測試環(huán)境的準(zhǔn)備，比喻說讀入輸入數(shù)據(jù)，初始化類@After與@Before進行對應(yīng)，做一個清理工作@BeforeClass在所有的測試開始之前執(zhí)行，這個方法在類運行的時候運行，而且只會運行一次，所以常常用來做一些所有的方法都要依賴到工作，比喻說，數(shù)據(jù)庫的鏈接。@AfterClass與@BeforeClass進行對應(yīng)，做一些類級別的清理工作@Ignore表明方法是被忽略的，這個方法非常實用，比喻你的方法已經(jīng)修改，但是對應(yīng)的測試方法還沒有得到一致的修改的時候，可以忽略掉這個測試方法先。@Test(expected=IllegalArgumentException.class)檢查測試方法是不是拋出了對應(yīng)的異常@Test(timeout=100)如果方法的執(zhí)行操作所耗費的毫秒數(shù)>100MS，那么方法失敗。JUnit單元測試常見問題如何測試私有方法和字段？如何測試異常？如何測試代碼執(zhí)行效率？單元級別性能測試System.currentTimeMillis()、System.nanoTime()AOP編程實現(xiàn)方式代碼執(zhí)行效率度量TDD過程演練如何做到“Cleancodethatworks”？不可運行–可運行–重構(gòu)代碼覆蓋率度量你的測試用例沒有覆蓋軟件的哪些部分？哪些測試用例是冗余的？為了得到更好的覆蓋率，如要添加哪些新的測試用例？覆蓋率統(tǒng)計工具Emma、Cobertura、CoverlipseClover、PureCoverage正確看待覆蓋率數(shù)據(jù)！數(shù)據(jù)驅(qū)動的單元測試參數(shù)化測試、數(shù)據(jù)與代碼分離數(shù)據(jù)源Excel、XML、數(shù)據(jù)庫數(shù)據(jù)驅(qū)動框架DDTUnit、Feed4JUnitDBUnit的應(yīng)用DbUnit(/

)則是專門針對數(shù)據(jù)庫測試的對JUnit的一個擴展，它可以將測試對象數(shù)據(jù)庫置于一個測試輪回之間的狀態(tài)。模擬框架驅(qū)動和樁的概念Stub和Mock為什么要做Mock？模擬框架應(yīng)用EasyMock、Mockito、JMock驅(qū)動（driver）樁（stub）單元測試工具JTestRTRT工具與框架的區(qū)別我們需要這些工具嗎？開發(fā)者測試的難點什么是合適的被測單元？如何找到合適的被測單元？如何提高被測單元的可測試性？何時停止測試？挑選合適的單元模塊進行測試適合測試單元的標(biāo)準(zhǔn)： –高內(nèi)聚、低耦合 –由1-3個開發(fā)人員完成，最好是1個 –不直接訪問網(wǎng)絡(luò)、數(shù)據(jù)庫、文件系統(tǒng)單元測試用例設(shè)計單元測試既可以是白盒測試也可以是黑盒測試白盒（基于覆蓋率的用例設(shè)計）語句覆蓋、判定覆蓋、條件覆蓋、條件判定組合覆蓋、多條件覆蓋、基本路徑覆蓋等黑盒規(guī)格導(dǎo)出、等價類劃分、邊界值分析、錯誤推測、因果圖等Right-BICEP方法Right--結(jié)果是否正確？B--是否所有的邊界條件都是正確的？I--能查一下反向關(guān)聯(lián)嗎？C--能用其他手段交叉檢查一下結(jié)果嗎？E--是否可以強制錯誤條件發(fā)生？P--是否滿足性能要求？

如何實施單元測試挑選單元測試范圍分層的單元測試個人、組長、QA

“當(dāng)你試圖打印輸出一些信息或調(diào)試一個表達式時，寫一些測試代碼來替代那些傳統(tǒng)的方法?！?Martin

FowlerJava單元測試項目案例分析JPetStore單元測試代碼分析集成測試集成的類型函數(shù)集成、類集成、組件集成、子系統(tǒng)集成集成測試策略大爆炸集成自頂向下集成自底向上集成三明治集成…單元測試與集成測試內(nèi)存泄漏問題檢測內(nèi)存泄漏現(xiàn)象Java內(nèi)存泄漏檢測工具JconsoleJprofilerWASTPV監(jiān)控JVM發(fā)現(xiàn)內(nèi)存泄漏現(xiàn)象JConsole實時監(jiān)控JVMJprofiler-JAVA代碼執(zhí)行效率監(jiān)控分析Jprofiler–SQL性能TestMemJprofiler–內(nèi)存泄漏檢測案例主題1白盒測試知識體系2如何開展實施白盒測試項目3靜態(tài)白盒測試方法4動態(tài)白盒測試方法5持續(xù)集成持續(xù)集成持續(xù)集成是一項軟件開發(fā)實踐，它鼓勵團隊成員頻繁集成他們的工作，每次集成都通過自動化構(gòu)建來驗證。持續(xù)集成可用于確保你的軟件一直是可以工作的，并且在幾分鐘內(nèi)你就能夠得到關(guān)于“你的修改是否破壞了系統(tǒng)”的反饋。

持續(xù)集成過程持續(xù)編譯持續(xù)部署持續(xù)測試持續(xù)報告《持續(xù)集成:軟件質(zhì)量改進和風(fēng)險降低之道》第18屆Jolt震撼大獎圖書從一個Java項目的持續(xù)集成系統(tǒng)和腳本看持續(xù)集成的基本步驟所有最新代碼從配置管理工具中取出（checkout或者update）所有的代碼從干凈的狀態(tài)開始編譯將編譯結(jié)果鏈接并部署，以備執(zhí)行執(zhí)行部署的應(yīng)用并運行測試如果上述所有操作沒有任何錯誤，沒有人工干預(yù)，并通過了所有測試，我們認(rèn)為這才是一次成功的構(gòu)建MartinFowler持續(xù)集成標(biāo)準(zhǔn)流程持續(xù)編譯持續(xù)檢查持續(xù)驗證持續(xù)部署持續(xù)基礎(chǔ)設(shè)施持續(xù)報告持續(xù)編譯持續(xù)編譯是一個很樸素的想法，就是保證主線上的代碼始終處于可編譯的狀態(tài)。但是這對于很多大中型團隊來說卻并非想當(dāng)然的簡單。這是因為很多團隊并未采用集體代碼所有權(quán)策略，導(dǎo)致存在依賴的團隊的代碼無法編譯。針對這樣的問題，一方面我們建議采用集體代碼所有權(quán)；另一方面，對于確實因為安全原因需要隔離的代碼應(yīng)該明確邊界、接口，很少存在大部分代碼需要對大部分人保密的情況。持續(xù)檢查持續(xù)檢查的目的是保證代碼風(fēng)格一致，主要關(guān)注于代碼的靜態(tài)質(zhì)量和內(nèi)部質(zhì)量，比如變量命名方式、大括號位置等等。大部分的現(xiàn)代集成開發(fā)環(huán)境（IDE）都具備實時檢查代碼質(zhì)量的功能。為了保證主線上的代碼質(zhì)量能夠達到一致的標(biāo)準(zhǔn)，應(yīng)當(dāng)在持續(xù)集成腳本中加入靜態(tài)檢查階段。比如，Java的PMD、FindBugs等等。持續(xù)驗證持續(xù)驗證的目的是檢查主線上的代碼是否能夠?qū)崿F(xiàn)所要求的功能，或者已有的功能是否被破壞。在大部分的構(gòu)建中，驗證部分是耗時最長、成本最高的部分，但同時也是收益最大的部分。在這個階段，我們看到的主要問題是驗證不充分和驗證時間過長。針對這樣的問題，我們通常采用分層分級的持續(xù)集成策略。持續(xù)部署對于大型軟件應(yīng)用來說，部署往往是一個費時費力又容易出錯的步驟，因為這里面涉及到數(shù)據(jù)遷移、版本兼容等各種棘手的問題。持續(xù)部署的思想是將這些工作標(biāo)準(zhǔn)化自動化，使其能夠可靠地、自動地、快速地運行。持續(xù)基礎(chǔ)設(shè)施集成現(xiàn)代大型軟件開發(fā)，尤其是互聯(lián)網(wǎng)應(yīng)用開發(fā)中經(jīng)常依賴于一些常見的基礎(chǔ)設(shè)施——比如Spring、Tomcat、Database等等。這些基礎(chǔ)設(shè)施發(fā)生變化的時候，我們應(yīng)當(dāng)及時地觸發(fā)持續(xù)集成，以確保我們的系統(tǒng)是能夠與新的基礎(chǔ)設(shè)施一起工作的。持續(xù)報告報告是將持續(xù)集成的狀態(tài)以適當(dāng)?shù)男问秸宫F(xiàn)給干系人的基本手段。報告是持續(xù)集成的晴雨表，所以它必須直觀、易懂，而且對關(guān)注點不同的角色展現(xiàn)不同的內(nèi)容和粒度。比如，開發(fā)人員可能更關(guān)心錯誤的日志；項目經(jīng)理可能更關(guān)心測試覆蓋率；產(chǎn)品經(jīng)理可能更關(guān)心持續(xù)集成通過率的趨勢等等。持續(xù)集成的基本原則CreateaRepeatable,ReliableProcessforReleasingSoftware盡早集成、經(jīng)常集成任何人都可以找一臺干凈的機器，做一次checkout動作，然后對系統(tǒng)執(zhí)行一次完整的構(gòu)建持續(xù)集成的目的是為了溝通-每個人都能看到進度（EveryoneCanSeeWhat'sHappening）持續(xù)集成工具與框架CruiseControlHudson、JenkinsTeamCitySonar持續(xù)質(zhì)量度量平臺Sonar的架構(gòu)Sonar與持續(xù)集成框架的整合(SVN、Jenkins)Sonar的標(biāo)準(zhǔn)度量項基于Sonar構(gòu)建Java質(zhì)量度量平臺代碼分析與規(guī)則定制代碼測試覆蓋率度量評估質(zhì)量趨勢查看Sonar質(zhì)量報告Sonar插件與生態(tài)系統(tǒng)質(zhì)量的七個緯度IcdnuoltblveieetahtIcluodaculacltyuesdnatnrdwahtIwasrdgnieg.Thephaonmneal

pweorofthehmuanmnid.Itdeosn‘tmttaeri