白盒測(cè)試技術(shù)

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

測(cè)試用例執(zhí)行

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

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

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

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

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

XX評(píng)審CHECKLIST

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

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

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

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

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

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

分鐘后，評(píng)審者就會(huì)感到疲勞，于是就不會(huì)找到額外的缺陷了?；陲L(fēng)險(xiǎn)篩選審查重點(diǎn)系統(tǒng)關(guān)鍵模塊、業(yè)務(wù)較復(fù)雜的模塊從業(yè)務(wù)需求重要度、優(yōu)先級(jí)出發(fā)篩選缺陷率較高的模塊從歷史缺陷數(shù)據(jù)出發(fā)篩選代碼復(fù)雜度高的模塊從代碼實(shí)現(xiàn)的復(fù)雜度（圈復(fù)雜度）度量出發(fā)篩選把工具引入到代碼審查流程中把工具引入到代碼審查流程中編程規(guī)范編程規(guī)范通常包括：數(shù)據(jù)類型檢查代碼縮進(jìn)換行命名規(guī)范注釋規(guī)范…CodeReview-類型檢查 在Java中，下面的語句雖然符合類型檢查規(guī)則，但是會(huì)在運(yùn)行時(shí)失敗，拋出一個(gè)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)格檢查更加挑剔，也更加注重空格、縮進(jìn)、命名、注釋、程序結(jié)構(gòu)這些表面的東西。風(fēng)格檢查程序所展示的錯(cuò)誤往往都是影響代碼的可讀性和可維護(hù)性的問題。好的代碼編寫風(fēng)格能讓代碼變得“賞心悅目”增強(qiáng)代碼的可讀性和可維護(hù)性并且能促進(jìn)項(xià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;}縮進(jìn)的問題命名規(guī)范駱駝（Camel）帕斯卡（Pascal）匈牙利“匈牙利”法該命名規(guī)則的主要思想是“在變量和函數(shù)名中加入前綴以增進(jìn)人們對(duì)程序的理解”。例如所有的字符變量均以ch為前綴，若是指針變量則追加前綴p。如果一個(gè)變量由ppch開頭，則表明它是指向字符指針的指針?！靶傺览狈ǖ娜秉c(diǎn)“匈牙利”法最大的缺點(diǎn)是煩瑣，例如 inti,j,k; floatx,y,z;倘若采用“匈牙利”命名規(guī)則，則應(yīng)當(dāng)寫成 intiI,iJ,ik;//前綴i表示int類型 floatfX,fY,fZ;//前綴f表示float類型如此煩瑣的程序會(huì)讓絕大多數(shù)程序員無法忍受。駱駝式命名法正如它的名稱所表示的那樣，是指混合使用大小寫字母來構(gòu)成變量和函數(shù)的名字。例如，下面是分別用駱駝式命名法和下劃線法命名的同一個(gè)函數(shù)：

printEmployeePaychecks()；

print_employee_paychecks()；

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

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

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

stringUserName;

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

在C#和JAVA中，以帕斯卡命名法和駱駝命名法居多。據(jù)考察，沒有一種命名規(guī)則可以讓所有的程序員贊同，程序設(shè)計(jì)教科書一般都不指定命名規(guī)則。命名規(guī)則對(duì)軟件產(chǎn)品而言并不是“成敗悠關(guān)”的事，我們不要花太多精力試圖發(fā)明世界上最好的命名規(guī)則，而應(yīng)當(dāng)制定一種令大多數(shù)項(xiàng)目成員滿意的命名規(guī)則，并在項(xiàng)目中貫徹實(shí)施。命名規(guī)范注釋代碼注釋量檢查注釋風(fēng)格文件注釋類注釋函數(shù)注釋變量注釋代碼實(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–程序理解程序理解工具能幫助我們搞懂代碼庫中的大量代碼，洞察程序運(yùn)轉(zhuǎn)之道，評(píng)審代碼的設(shè)計(jì)架構(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識(shí)別包依賴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代碼的潛在錯(cuò)誤

inta=0;switch(a){case0:return0;case1:a=1;}returna;PMD可以發(fā)現(xiàn)其中潛在的錯(cuò)誤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檢查代碼錯(cuò)誤推薦閱讀CodeReview-安全審查靜態(tài)的代碼安全測(cè)試：主要是通過對(duì)源代碼進(jìn)行安全掃描，根據(jù)程序中數(shù)據(jù)流，控制流，語義等信息與軟件安全規(guī)則庫進(jìn)行匹對(duì)，從中找出代碼中潛在的安全漏洞?？梢栽诰幋a階段找出大部分可能存在安全風(fēng)險(xiǎn)的代碼，這樣開發(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ì)量度量代碼精簡(jiǎn)度繼承深度類間耦合度圈復(fù)雜度可測(cè)試性可維護(hù)性…常用工具：Metrics、JavaNCSS、Testability-explorer、SourceMonitor、SonarLogiscope代碼復(fù)雜度軟件復(fù)雜性度量-圈復(fù)雜度復(fù)雜度計(jì)算公式為：M=V(G)=e–n+2其中：V(G)路徑圖的環(huán)形數(shù)目e=邊的數(shù)目n=節(jié)點(diǎn)數(shù)目練習(xí)計(jì)算以下代碼的圈復(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ù)量來計(jì)算程序的復(fù)雜性。操作符和操作數(shù)的量越大，程序結(jié)構(gòu)就越復(fù)雜。語法構(gòu)造方法可以揭示程序中單獨(dú)的語法構(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白盒測(cè)試知識(shí)體系2如何開展實(shí)施白盒測(cè)試項(xiàng)目3靜態(tài)白盒測(cè)試方法4動(dòng)態(tài)白盒測(cè)試方法5持續(xù)集成四、動(dòng)態(tài)白盒測(cè)試方法單元測(cè)試最佳實(shí)踐單元測(cè)試用例設(shè)計(jì)的方法與技巧單元測(cè)試工具與框架的應(yīng)用樁與驅(qū)動(dòng)單元測(cè)試覆蓋率分析代碼性能測(cè)試代碼內(nèi)存泄漏測(cè)試WhyUnitTesting?Dynamicblack-boxtestingishighcost:1.It’sdifficultandsometimesimpossibletofigureoutexactlywhatcausedtheproblem.2.Somebugshideothers.立即測(cè)試vs單一測(cè)試TDD思想TDD把單元測(cè)試的地位提高到了史無前例的最高點(diǎn)，倡導(dǎo)測(cè)試先行、用測(cè)試驅(qū)動(dòng)開發(fā)。測(cè)試是最好的設(shè)計(jì)，在編寫代碼之前就要把測(cè)試想好，這樣在編寫代碼時(shí)才胸有成竹。XP中一個(gè)很核心的實(shí)踐就是TDDTDD基本過程測(cè)試驅(qū)動(dòng)開發(fā)的基本過程明確當(dāng)前要完成的功能?？梢杂涗洺梢粋€(gè)TODO列表?？焖偻瓿舍槍?duì)此功能的測(cè)試用例編寫。測(cè)試代碼編譯不通過。編寫對(duì)應(yīng)的功能代碼。測(cè)試通過。對(duì)代碼進(jìn)行重構(gòu)，并保證測(cè)試通過。循環(huán)完成所有功能的開發(fā)。測(cè)試驅(qū)動(dòng)開發(fā)的好處不斷測(cè)試，提高軟件質(zhì)量不斷重構(gòu)，提高軟件處理變化的能力在EmpiricalSoftwareEngineering雜志上首次發(fā)表的一篇研究報(bào)告聲稱：“看來TDD可以應(yīng)用在多個(gè)領(lǐng)域中，并顯著降低軟件的缺陷密度，同時(shí)也不會(huì)明顯降低開發(fā)團(tuán)隊(duì)的工作效率?！眴卧獪y(cè)試框架基于框架來編寫單元測(cè)試代碼會(huì)更方便、高效。常見的單元測(cè)試框架JUnit、TestNGJUnit單元測(cè)試建立JUnit單元測(cè)試JUnit3與JUnit4的區(qū)別斷言類的使用TestCase、TestSuiteJUnit框架的AnnotationAnnotation含義@Test定義一個(gè)要測(cè)試的方法@Before在每一個(gè)測(cè)試之前都會(huì)被執(zhí)行的方法，這個(gè)方法常常用來進(jìn)行一些測(cè)試環(huán)境的準(zhǔn)備，比喻說讀入輸入數(shù)據(jù)，初始化類@After與@Before進(jìn)行對(duì)應(yīng)，做一個(gè)清理工作@BeforeClass在所有的測(cè)試開始之前執(zhí)行，這個(gè)方法在類運(yùn)行的時(shí)候運(yùn)行，而且只會(huì)運(yùn)行一次，所以常常用來做一些所有的方法都要依賴到工作，比喻說，數(shù)據(jù)庫的鏈接。@AfterClass與@BeforeClass進(jìn)行對(duì)應(yīng)，做一些類級(jí)別的清理工作@Ignore表明方法是被忽略的，這個(gè)方法非常實(shí)用，比喻你的方法已經(jīng)修改，但是對(duì)應(yīng)的測(cè)試方法還沒有得到一致的修改的時(shí)候，可以忽略掉這個(gè)測(cè)試方法先。@Test(expected=IllegalArgumentException.class)檢查測(cè)試方法是不是拋出了對(duì)應(yīng)的異常@Test(timeout=100)如果方法的執(zhí)行操作所耗費(fèi)的毫秒數(shù)>100MS，那么方法失敗。JUnit單元測(cè)試常見問題如何測(cè)試私有方法和字段？如何測(cè)試異常？如何測(cè)試代碼執(zhí)行效率？單元級(jí)別性能測(cè)試System.currentTimeMillis()、System.nanoTime()AOP編程實(shí)現(xiàn)方式代碼執(zhí)行效率度量TDD過程演練如何做到“Cleancodethatworks”？不可運(yùn)行–可運(yùn)行–重構(gòu)代碼覆蓋率度量你的測(cè)試用例沒有覆蓋軟件的哪些部分？哪些測(cè)試用例是冗余的？為了得到更好的覆蓋率，如要添加哪些新的測(cè)試用例？覆蓋率統(tǒng)計(jì)工具Emma、Cobertura、CoverlipseClover、PureCoverage正確看待覆蓋率數(shù)據(jù)！數(shù)據(jù)驅(qū)動(dòng)的單元測(cè)試參數(shù)化測(cè)試、數(shù)據(jù)與代碼分離數(shù)據(jù)源Excel、XML、數(shù)據(jù)庫數(shù)據(jù)驅(qū)動(dòng)框架DDTUnit、Feed4JUnitDBUnit的應(yīng)用DbUnit(/

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

如何實(shí)施單元測(cè)試挑選單元測(cè)試范圍分層的單元測(cè)試個(gè)人、組長(zhǎng)、QA

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

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

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

pweorofthehmuanmnid.Itdeosn‘tmttaeri