代碼質(zhì)量與評(píng)審

1、北美專業(yè)培訓(xùn)機(jī)構(gòu)AVTECH 簡介 AVTECH總部設(shè)在美國NEW JERSEY,是北美排行第一的專業(yè)培訓(xùn)機(jī)構(gòu)，設(shè)有4大分校，數(shù)十個(gè)培訓(xùn)點(diǎn)遍布北美、西歐和東亞;；2000年進(jìn)入中國，以培養(yǎng)國際化的中高端信息人才為己任,專注于國際前沿的新技術(shù)研發(fā)與信息科技新興行業(yè)的開拓教育。 AVTECH進(jìn)入中國13年，屬同行中歷史最久。 AVTECH是國內(nèi)最大的國際認(rèn)證考試中心，提供上千門國際認(rèn)證考試。 AVTECH的師資來自全球，在國內(nèi)培訓(xùn)機(jī)構(gòu)中獨(dú)一無二的。 學(xué)院開設(shè)課程超過500門，學(xué)習(xí)培訓(xùn)內(nèi)容涵蓋IT技術(shù)及使用IT技術(shù)的醫(yī)學(xué)、生物、財(cái)會(huì)、管理等相關(guān)行業(yè)所有高、中、低級(jí)知識(shí)和技能。其中一些技術(shù)課程來自于如

2、下廠家:微軟、微軟、IBM、Oracle、Cisco、SAS、ISTQB、SAP、 PMI、EXIN、IIBA、Open Group、APMG、ISACA、Vmware、EXIN、Peoplecart、EPI、BRMI、IAOP、ScrumAlliance等等 艾艾威最新推薦：威最新推薦： ITIL、ITIL Expert、CISSP、PMP、CISA、COBIT、Prince2、MSP、SCM、CSD、CBAP、TOGAF、CRISC、CGEIT、CISM、PGMP、PFMP、BRMP、CDCP、SGF、NPDP等等認(rèn)證培訓(xùn)認(rèn)證培訓(xùn)內(nèi)容 質(zhì)量管理的必要性 質(zhì)量管理實(shí)踐 看得見的改進(jìn) 總結(jié)互聯(lián)

3、網(wǎng)開發(fā)特點(diǎn) 市場競爭激烈，需求變化快 開發(fā)周期長時(shí)間/迭代代碼質(zhì)量的影響成本生產(chǎn)率質(zhì)量管理實(shí)踐代碼質(zhì)量封裝封裝內(nèi)聚內(nèi)聚耦合耦合冗余冗余可讀可讀性性可測可測試性試性質(zhì)量質(zhì)量角度：演化、維護(hù)角度：演化、維護(hù)高內(nèi)聚、低耦合是有限度的高內(nèi)聚、低耦合是有限度的目標(biāo)群體：開發(fā)人員目標(biāo)群體：開發(fā)人員代碼質(zhì)量保障步驟代碼評(píng)審持續(xù)集成對(duì)待變化的態(tài)度不只是擁抱變化，更要利用變化時(shí)間/迭代質(zhì)量重構(gòu)的時(shí)機(jī)某周一早上，你的老板要求編寫一個(gè)小程序，從鍵盤讀入字符，然后輸出到打印機(jī)上 void Copy() int c; while (c=Rdkbd()!= EOF) wrtPrt(c); CopyCharWriterPr

4、tCharReadKbd重構(gòu)的時(shí)機(jī)boolean ptFlag=false;boolean punchFlag=false;void copy()int c;while(c=(ptFlag?Rdpt():Rdkbd()!=EOF)punchFlag?wrtPunch():wrtPrt(c); 幾個(gè)月后，老板來找你，說有時(shí)希望Copy程序能從手寫板讀入信息幾個(gè)月后，老板又來找你，有時(shí)希望Copy程序可以輸出到U盤上ReadWriterCopyKbdPtCharCharPrtPuh質(zhì)量管理平臺(tái) Sonar Maven Jenkins 插件體系結(jié)構(gòu)看得見的度量指標(biāo)A&D重復(fù)代碼單元測試復(fù)雜度

5、潛在Bug編碼規(guī)則注釋代碼代碼重復(fù)代碼單元測試復(fù)雜度 圈復(fù)雜度 度量代碼分支情況 If for while case catch throw return & | ? 復(fù)雜性越高，測試成本越高復(fù)雜度編碼規(guī)則檢查注釋架構(gòu)依賴結(jié)構(gòu)矩陣（DSM）設(shè)計(jì)度量指標(biāo)NOC 派生類的數(shù)目DIT 繼承樹的深度RFC 類的外部響應(yīng)LCOM4 方法的內(nèi)聚LCOM4 Lack of cohesion of methods 說明類內(nèi)部方法和變量之間的關(guān)系 指標(biāo) LCOM4=0/Bad LCOM4=1 /高 LCOM4=2/低 SRP原則RFC Response For Class 通過檢查方法被調(diào)用的情況來反映

6、一個(gè)類的復(fù)雜程度 可以簡單的理解為一個(gè)類所包含的方法多寡 復(fù)雜度從類的內(nèi)部描述，RFC從類的外部來描述 RFC = M + R RFC = M + R M = number of methods in the class R = number of remote methods directly called by methods of the class R = number of remote methods called, recursively through the entire call tree設(shè)計(jì)設(shè)計(jì)高級(jí)度量Sonar插件附加維附加維度度治理治理可視化可視化集成集成IDE本地化

7、本地化多語言多語言/display/SONAR/Sonar+Plugin+Library/插件插件改進(jìn)效果改進(jìn)架構(gòu)-模塊劃分原則 采用Maven多Project結(jié)構(gòu)，先根據(jù)職能分Project，再根據(jù)功能模塊分Package REP(重用發(fā)布等價(jià)原則) 重用的粒度就是發(fā)布的粒度 CCP(共同封閉原則) 包中所有類對(duì)于同一類性質(zhì)的變化應(yīng)該是共同封閉的 ADP(無環(huán)依賴原則) 在包的依賴關(guān)系圖中不允許存在環(huán)設(shè)計(jì)-變化應(yīng)對(duì)之道視角視角描述描述關(guān)注點(diǎn)關(guān)注點(diǎn)概念對(duì)象是一組責(zé)任軟件要負(fù)責(zé)什么？規(guī)約對(duì)象是一組可以被其他對(duì)象或?qū)ο笞约赫{(diào)用的方法（也稱行為）怎么使用

8、軟件？實(shí)現(xiàn)對(duì)象是代碼和數(shù)據(jù)，以及它們之間的計(jì)算交互軟件怎樣履行自己的責(zé)任？Martin Fowler的建議:對(duì)象的三個(gè)視角設(shè)計(jì)-變化應(yīng)對(duì)之道 在概念上層次上交流，在實(shí)現(xiàn)層次上執(zhí)行，客戶端無需準(zhǔn)確知道具體操作細(xì)節(jié)，只需一般性（概念性）知道即可 只要概念不變，客戶端就可以與實(shí)現(xiàn)細(xì)節(jié)的變化隔離開來 案例：下一節(jié)分享去哪里聽設(shè)計(jì)-變化應(yīng)對(duì)之道 Programming to an Interface, not an Implementation 客戶對(duì)象和服務(wù)對(duì)象之間的職責(zé)分配 使用抽象類隱藏具體的實(shí)現(xiàn) 創(chuàng)建和使用分離 案例：評(píng)價(jià)、資料設(shè)計(jì)-變化應(yīng)對(duì)之道 Favor object composition

9、 over class inheritance 但是設(shè)計(jì)模式中為什么繼承無處不在？ 不要按照傳統(tǒng)的方式來使用繼承 用新的行為來特化現(xiàn)有的具體對(duì)象 案例：講師分類講師講師男男女女主題主題A男男主題主題B男男主題主題A女女主題主題B女女性別性別講師講師主題主題女女男男主題主題A主題主題B設(shè)計(jì)-變化應(yīng)對(duì)之道 Designing for Change 在設(shè)計(jì)中思考什么應(yīng)該變化，并封裝會(huì)發(fā)生變化的概念 封裝不只是隱藏?cái)?shù)據(jù)，也可以是封裝類型 變化不只是算法和行為，可以是任何事情 案例：委托評(píng)價(jià)講師講師聽眾聽眾公司公司A公司公司B主辦方主辦方usesusescreatecreate公司公司C設(shè)計(jì)-變化應(yīng)對(duì)之

10、道Single Responsibility PrincipleOpen Closed PrincipleLiskov Substitution PrincipleInterface Segregation PrincipleDependency Inversion Principle注釋 能用代碼來闡述的，盡量不用注釋 好的注釋應(yīng)該解釋意圖，而不是解釋操作 什么也比不上放置良好的注釋來得有用 什么也不會(huì)比陳舊、提供錯(cuò)誤信息的注釋更有破壞性目錄（一） 除了編碼，開發(fā)還可以做什么除了編碼，開發(fā)還可以做什么 編碼規(guī)范 單元測試 代碼評(píng)審 靜態(tài)檢查 持續(xù)集成目錄（二） 補(bǔ)充補(bǔ)充 動(dòng)態(tài)檢查 缺陷管理

11、性能測試 WEB前端分析 自動(dòng)化測試除了編碼，開發(fā)還可以做什么 現(xiàn)狀項(xiàng)目開發(fā)過程中，由于開發(fā)人員的經(jīng)驗(yàn)、代碼風(fēng)格各不相同，以及缺乏統(tǒng)一的標(biāo)準(zhǔn)和管理流程，往往導(dǎo)致整個(gè)項(xiàng)目的代碼質(zhì)量較差，難于維護(hù)，需要較大的測試投入和周期等問題。 措施 可以采用以下五個(gè)步驟來保證和提高整個(gè)項(xiàng)目的代碼質(zhì)量：統(tǒng)一編碼規(guī)范、代碼樣式；靜態(tài)代碼分析（static code review）；單元測試；持續(xù)集成；代碼評(píng)審和重構(gòu)（Review & Refactor）。下面將針對(duì)每個(gè)步驟和其所使用的工具、方法進(jìn)行詳細(xì)描述。編碼規(guī)范規(guī)范統(tǒng)一的編碼能提高項(xiàng)目代碼的可讀性和可維護(hù)性，編碼規(guī)范主規(guī)范統(tǒng)一的編碼能提高項(xiàng)目代碼的可讀

12、性和可維護(hù)性，編碼規(guī)范主要應(yīng)包含以下幾個(gè)方面：要應(yīng)包含以下幾個(gè)方面： 一般規(guī)則和格式規(guī)范。例如代碼縮進(jìn)、程序塊規(guī)范、每行最大代碼長度等。 命名規(guī)則。例如包名、類名、變量、方法、接口、參數(shù)等命名規(guī)范 文檔規(guī)范。例如類文件頭聲明、類注釋、成員變量和方法注釋等規(guī)范。 編程規(guī)范。例如異常、并發(fā)、多線程等方面的處理方式。 其他規(guī)范。例如日志格式、屬性文件格式，返回值和消息格式。用eclipse控制代碼樣式（一）一旦編碼規(guī)范確定，就可以利用一旦編碼規(guī)范確定，就可以利用 Eclipse 來控制代碼樣式和格式。來控制代碼樣式和格式。點(diǎn)擊 Eclipse 的 Windows - Preference 菜單項(xiàng)，在

13、打開的Preferences 對(duì)話框的左側(cè)欄中找到 Java 節(jié)點(diǎn)下的子項(xiàng) Code Style，該項(xiàng)和它的子項(xiàng)允許您對(duì) Java 代碼的樣式進(jìn)行控制：用eclipse控制代碼樣式（二）可以在 Eclipse 提供的默認(rèn)代碼格式配置的基礎(chǔ)上建立自定義的格式。在 Formatter 面板中，點(diǎn)擊 New，輸入新的名字并選擇一個(gè)默認(rèn)的配置作為初始化格式，如圖所示：用eclipse控制代碼樣式（三）設(shè)置風(fēng)格如圖所示：代碼靜態(tài)檢查_CheckStyle CheckStyle用來檢查代碼格式、規(guī)范、風(fēng)格用來檢查代碼格式、規(guī)范、風(fēng)格。 檢查并強(qiáng)制執(zhí)行統(tǒng)一的代碼風(fēng)格；檢查并強(qiáng)制執(zhí)行統(tǒng)一的代碼風(fēng)格； 檢查檢查

14、Javadoc； 檢查類、變量、方法的命名；檢查類、變量、方法的命名； 檢查類和方法的大小；檢查類和方法的大??； 檢查編碼錯(cuò)誤，例如檢查編碼錯(cuò)誤，例如magic number； 代碼常見問題舉例：代碼常見問題舉例： 代碼中的代碼中的magic-number和和magic-string ： String s = “0000” + Integer.toString(ch, 16); 0000、16的含義，作者幾周后就忘記了。CheckStyle的安裝配置（一） CheckStyle插件地址。插件地址。 自動(dòng)安裝地址：http:/eclipse- 下載地址： http:/ 安裝后出現(xiàn)：安裝后出現(xiàn)：C

15、heckStyle的安裝配置（二） 配置項(xiàng)說明：配置項(xiàng)說明： CheckStyle的安裝配置（三） CheckStyle檢查結(jié)果：檢查結(jié)果： 其它工具 用于用于javascript靜態(tài)檢查的工具：靜態(tài)檢查的工具：Jslint -The JavaScript Code Quality Tool 代碼靜態(tài)檢查_FindBugs FindBugs是一個(gè)是一個(gè)java代碼的靜態(tài)代碼分析工具，用來發(fā)代碼的靜態(tài)代碼分析工具，用來發(fā)現(xiàn)那些潛在的、常見的、很難被發(fā)現(xiàn)的現(xiàn)那些潛在的、常見的、很難被發(fā)現(xiàn)的bug。與其他靜態(tài)。與其他靜態(tài)分析工具不同，分析工具不同，F(xiàn)indBugs 不注重樣式或者格式，它試圖不注重樣

16、式或者格式，它試圖只尋找真正的缺陷或者潛在的性能問題。如只尋找真正的缺陷或者潛在的性能問題。如NullPoint空空指針檢查、沒有合理管理資源等。指針檢查、沒有合理管理資源等。 Findbugs插件地址。插件地址。 自動(dòng)安裝地址：/eclipse 下載地址：http:/ 配置配置選項(xiàng)選項(xiàng)： Findbugs的使用運(yùn)行，右鍵項(xiàng)目執(zhí)行運(yùn)行，右鍵項(xiàng)目執(zhí)行“Find Bugs”操作：操作： 檢查結(jié)果：檢查結(jié)果： 單元測試單元測試單元測試單元測試是最小粒度的測試，以測試某個(gè)功能或代碼塊，一般由程序員來做。用例設(shè)計(jì)和評(píng)審用例設(shè)計(jì)和評(píng)審 設(shè)計(jì)階段需要具體考慮

17、要對(duì)哪些代碼單元進(jìn)行測試，被測單元之間的關(guān)系，測試策略，以及單元測試用例設(shè)計(jì)等，并最終輸出單元測試用例設(shè)計(jì)文檔，用來指導(dǎo)具體的單元測試執(zhí)行。 在用例設(shè)計(jì)完成之后，下一步的工作就是進(jìn)行測試用例的評(píng)審。個(gè)人的理解和經(jīng)驗(yàn)始終是有限的，用例評(píng)審可以借集體之力，對(duì)用例設(shè)計(jì)進(jìn)入查漏補(bǔ)缺，進(jìn)一步保證測試用例的有效性。 單元測試_JUnitJUnitJUnit 是一個(gè)開發(fā)源代碼的Java測試框架，用于編寫和運(yùn)行可重復(fù)的測試。它是用于單元測試框架體系xUnit的一個(gè)實(shí)例（用于java語言）。主要用于白盒測試，回歸測試。下載地址下載地址 eclipse自帶了JUnit，完整安裝包的下載地址： http:/ Jun

18、it核心結(jié)構(gòu)JunitJUnit測試開發(fā)（一）下面舉例描述怎樣對(duì)一個(gè)類編寫單元測試代碼，待測試的類：JUnit測試開發(fā)（二）JUnit3.8測試類：JUnit測試開發(fā)（三）JUnit4.0測試類：JUnit測試開發(fā)（四）setUp和tearDown方法：Junit斷言（一）斷言Assert方法：Junit斷言（二）斷言Assert方法：在Eclipse上執(zhí)行Junit（一） 下面說明怎樣在eclipse上執(zhí)行Junit單元測試添加一個(gè)需要測試的類Hello：在Eclipse上執(zhí)行Junit（二）選中需要測試的類，右鍵點(diǎn)擊，選擇New-JUnit Test Case，如圖：在Eclipse上執(zhí)行

19、Junit（三）新建測試類：在Eclipse上執(zhí)行Junit（四）下一步選擇要測試的方法：在Eclipse上執(zhí)行Junit（五）完成HelloTest的Abs方法：在Eclipse上執(zhí)行Junit（六）執(zhí)行測試程序，右鍵，Run As-JUnit Test，就可以看到JUnit測試結(jié)果： 綠色表示測試通過，只要有1個(gè)測試未通過，就會(huì)顯示紅色并列出未通過測試的方法。單元測試_EasyMock模擬對(duì)象技術(shù)模擬對(duì)象技術(shù)在實(shí)際項(xiàng)目中，開發(fā)人員自己的代碼往往需要和其他的代碼模塊或系統(tǒng)進(jìn)行交互，但在測試的過程中，這些需要被調(diào)用的真實(shí)對(duì)象常常很難被實(shí)例化，利用一個(gè)模擬對(duì)象來模擬我們的代碼所依賴的真實(shí)對(duì)象，來

20、幫助完成測試，提高測試覆蓋率。常見的模擬技術(shù)常見的模擬技術(shù) 模擬技術(shù)有很多種，如 jMock，EasyMock，Mockito，PowerMock 等等，下面用EasyMock舉例說明如何模擬對(duì)象。EasyMock（一） 下載地址：/ 使用樣例： 看一個(gè)用戶驗(yàn)證的servlet： public class LoginServlet extends HttpServlet protected void doPost(HttpServletRequest request, HttpServletResponse response)throws Servl

21、etException, IOException String username = request.getParameter(username); String password = request.getParameter(password); EasyMock（二） / 校驗(yàn)用戶名和密碼 if(admin.equals(username) & 123456.equals(password) ServletContext context = getServletContext(); RequestDispatcher dispatcher = context.getNamedDis

22、patcher(dispatcher); dispatcher.forward(request, response); else throw new RuntimeException(Login failed.); EasyMock（三）為測試doPost()方法，需要模擬HttpServletRequest等對(duì)象，以便脫離J2EE 容器來測試這個(gè)Servlet。建立TestCase，名為LoginServletTest： public class LoginServletTest extends TestCase 測試當(dāng)用戶名和口令驗(yàn)證失敗的情形： public void testLogin

23、Failed() throws Exception /創(chuàng)建mock對(duì)象 MockControl mc = MockControl.createControl(HttpServletRequest.class); HttpServletRequest request =(HttpServletRequest)mc.getMock();EasyMock（四） /設(shè)置mock參數(shù) request.getParameter(username); / 期望下面的測試將調(diào)用此 方法，參數(shù)為username mc.setReturnValue(admin, 1); / 期望返回值為admin，僅調(diào)用 1 次

24、 request.getParameter(password); / 期望下面的測試將調(diào)用此方 法，參數(shù)為 password mc.setReturnValue(1234, 1); / 期望返回值為1234，僅調(diào)用1 次 / 表示錄制完畢 mc.replay();EasyMock（五） try servlet.doPost(request, null); fail(Not caught exception!); catch(RuntimeException re) assertEquals(Login failed., re.getMessage(); / verify: mc.verify(

25、);運(yùn)行JUnit，測試通過！表示我們的Mock 對(duì)象正確工作了！單元測試_測試覆蓋率分析 為了衡量單元測試的質(zhì)量和覆蓋的范圍，需要對(duì)單元測試的代碼進(jìn)行測試覆蓋分析。 具體采用哪些指標(biāo)可以根據(jù)項(xiàng)目的實(shí)際情況來定，以避免因過高的指標(biāo)增加了代碼開發(fā)人員的工作量而影響了項(xiàng)目整體的進(jìn)度。 。 業(yè)內(nèi)比較常用的工具有： 1、 Cobertura，對(duì)應(yīng)的eclipse插件： eCobertura。 2、 EclEmma是一款基于 EMMA 的 Eclipse 插件，方 便在 Eclipse IDE 中進(jìn)行測試覆蓋率分析。 插件下載地址：/ Eclipse測試覆

26、蓋率分析（一）下面說怎樣在eclipse上執(zhí)行測試覆蓋率分析： 先安裝插件EclEmma, 然后在測試用例寫好后，可以在右鍵點(diǎn)擊測試類，選擇 Coverage As - JUnit Test.Eclipse測試覆蓋率分析（二）單元測試執(zhí)行完后，Coverage視圖中會(huì)顯示所選擇的測試的覆蓋率。雙擊打開某一具體的類后，可以看到高亮顯示的覆蓋分析結(jié)果，如圖 所示。紅色代表測試沒有覆蓋到該行，黃色表示部分覆蓋，綠色的行表示該行在本次測試中被覆蓋到。Eclipse測試覆蓋率分析（三）在 Coverage 視圖中可以通過點(diǎn)擊鼠標(biāo)右鍵將測試覆蓋分析的結(jié)果導(dǎo)出成需要的格式，例如 HTML。單元測試-FIRS

27、T原則Fast（快速）Independent（獨(dú)立）Repeatable（可重復(fù)）Self-Validating（自足驗(yàn)證）Timely（及時(shí)）持續(xù)集成 持續(xù)集成（Continuous Integration）是利用一系列的工具、方法和規(guī)則，做到快速的構(gòu)建開發(fā)代碼，自動(dòng)的測試化，來提高開發(fā)代碼的效率和質(zhì)量 。 持續(xù)集成的提出 如果項(xiàng)目開發(fā)的規(guī)模比較小，比如一個(gè)人的項(xiàng)目，如果它對(duì)外部 系統(tǒng)的依賴很小，那么軟件集成不是問題，但是隨著軟件項(xiàng)目復(fù)雜度的增加（即使增加一個(gè)人），就會(huì)對(duì)集成和確保軟件組件能夠在一 起工作提出了更多的要求-要早集成，常集成。早集成，頻繁的集成 幫助項(xiàng)目在早期發(fā)現(xiàn)項(xiàng)目風(fēng)險(xiǎn)和質(zhì)量

28、問題，如果到后期才發(fā)現(xiàn)這 些問題，解決問題代價(jià)很大，很有可能導(dǎo)致項(xiàng)目延期或者項(xiàng)目失敗。持續(xù)集成 持續(xù)集成的常見做法是：持續(xù)集成框架持續(xù)集成的常見做法是：持續(xù)集成框架+ 版本管理器版本管理器+ 構(gòu)建工具。構(gòu)建工具。 1、持續(xù)集成框架常用的有：Jenkins、Continuum、 CruiseControl等。 2、版本管理器常用的有：ClearCase、Wincvs、SVN等。 3、構(gòu)建工具常用的有：Ant、Maven。 后面主要以 SVN + Jenkins + Ant 實(shí)現(xiàn)方式舉例說明。 持續(xù)集成_版本管理器 SVN(subversion)是近年來崛起的版本管理工具，是是近年來崛起的版本管理

29、工具，是cvs的接班人。的接班人。目前，絕大多數(shù)開源軟件都使用目前，絕大多數(shù)開源軟件都使用svn作為代碼版本管理軟件。作為代碼版本管理軟件。 服務(wù)端下載地址： http:/ 客戶端下載地址：http:/ 持續(xù)集成_自動(dòng)構(gòu)建 Ant 在構(gòu)建過程方面十分優(yōu)秀，它是一個(gè)基于任務(wù)和依賴的構(gòu)建工具。下載地址： /bindownload.cgiMaven不單是構(gòu)建工具，也是個(gè)項(xiàng)目管理平臺(tái)。下載地址： /download.html Maven與Ant對(duì)比，一些使用上的區(qū)別： 1、 Maven是基于中央倉庫的編譯，即把編譯所需

30、要的資源放在一個(gè)中央倉庫里，如jar，tld等。當(dāng)編譯的時(shí)候，maven會(huì)自動(dòng)在倉庫中找到相應(yīng)的包,而ant需要自己定義了。用maven編譯的項(xiàng)目在發(fā)布的時(shí)候只需要發(fā)布源碼，小得很，而反之，ant的發(fā)布則要把所有的包一起發(fā)布。 2、 Maven有大量的重用腳本可以利用，如生成網(wǎng)站，生成javadoc，sourcecode reference，等。而ant都需要自己去寫。 3、 Maven目前不足的地方就是沒有象ant那樣成熟的GUI界面。 持續(xù)集成_持續(xù)集成框架有了自動(dòng)構(gòu)建后，我們就可以通過Jenkins每天定時(shí)用Ant腳本或Maven，加上JUnit、Cobertura/EMMA等的ANT

31、腳本調(diào)用，每一次的構(gòu)建都可以把這些檢查工作自動(dòng)的進(jìn)行一遍測試。然后生成測試報(bào)告進(jìn)行查閱。Jenkins（Jenkins的前身）可以說在安裝和配置上最簡單的CI產(chǎn)品。 Jenkins是基于java開發(fā)的，但它不僅限于構(gòu)建基于Java的軟件，還能構(gòu)建.net、Python、Ruby等。 Jenkins提供了一組很明確和可擴(kuò)展API的Jenkins組件。這批組成一個(gè)大的類庫的Jenkins組件反過來又豐富了Jenkins的功能；它們都是開源的，而且它們可以直接通過Jenkins的控制臺(tái)來進(jìn)行安裝。 安裝軟件下載地址：/ Jenkins安裝要點(diǎn)將jenkins.

32、war拷貝到tomcat的webapps目錄下；修改Tomcat-7.0.8confserver.xml文件，設(shè)置UTF-8編碼：通過以下方式修改Jenkins_HOME的位置：在Jenkins的web.xml中找到Jenkins_HOME，默認(rèn)value為空值，將其設(shè)置 為你希望的路徑，然后重啟。 Jenkins首頁Jenkins管理界面Jenkins插件安裝（一）Jenkins插件安裝（二）Jenkins Job（一）Jenkins Job（二）Jenkins Job（三）Jenkins Job（四）Jenkins 質(zhì)量度量（一）Jenkins 質(zhì)量度量（二）openEAP應(yīng)用的實(shí)踐（一）

33、 以下演示在實(shí)際的openEAP項(xiàng)目中，怎樣自動(dòng)化完成以上活動(dòng)。 演示的是一個(gè)web項(xiàng)目，目錄結(jié)構(gòu)如下圖所示： openEAP應(yīng)用的實(shí)踐（二） 因?yàn)橄嚓P(guān)依賴資源都已經(jīng)在quality目錄下了（運(yùn)行只依賴數(shù)據(jù)庫環(huán)境，沒有對(duì)數(shù)據(jù)庫操作進(jìn)行模擬），所以可以直接通過ant執(zhí)行quality目錄下的build.xml，腳本執(zhí)行完畢后，生成的報(bào)告在quality目錄下，如下圖所示： openEAP應(yīng)用的實(shí)踐（三）也可以發(fā)布到Jenkins上執(zhí)行構(gòu)建： openEAP應(yīng)用的實(shí)踐（四）在Jenkins上查看報(bào)告： 代碼評(píng)審 代碼評(píng)審（Code Review）是 Java 項(xiàng)目開發(fā)過程中的一個(gè)重要步驟，代碼評(píng)審

34、可以幫助發(fā)現(xiàn)靜態(tài)代碼分析過程中無法發(fā)現(xiàn)的一些問題，例如代碼在邏輯上或者功能上是否存在錯(cuò)誤，代碼在執(zhí)行效率和性能上是否有需要改進(jìn)的地方等。代碼評(píng)審還可以幫助新進(jìn)入項(xiàng)目組的成員快速學(xué)習(xí)和了解項(xiàng)目，促進(jìn)經(jīng)驗(yàn)分享。代碼評(píng)審主要包括兩種形式，同級(jí)評(píng)審（Peer Review）和小組評(píng)審（Group Review）。同級(jí)評(píng)審主要指項(xiàng)目成員間的互相評(píng)審，小組評(píng)審是指通過召開評(píng)審會(huì)議，項(xiàng)目成員一起對(duì)項(xiàng)目代碼進(jìn)行評(píng)審。 為了提高代碼評(píng)審的有效性和效率，可以借助一些外部工具，比較常用的代碼評(píng)審工具有 Jupiter 和 Code Striker。Jupiter 是一款開源的 Eclipse 插件，允許成員將評(píng)審意

35、見定位到真實(shí)代碼的具體行，由于代碼評(píng)審的結(jié)果以 XML 文件的形式保存。Jupiter使用Eclipse插件下載地址：http:/ review)分為4個(gè)流程 ： 1.Configuration(配置)：review發(fā)起者設(shè)置“Review ID”，指定要 評(píng)審的代碼，參與代碼評(píng)審的人員，要討論的問題等等。 2.Individual review(個(gè)人評(píng)審)：每個(gè)人獨(dú)自審查代碼，把可能出現(xiàn) 問題的代碼加入checklist。 3.Team review(團(tuán)隊(duì)評(píng)審)：大家在一起討論之前檢查出的問題代 碼，并決定如何處理。 4.Rework：開發(fā)人員根據(jù)之前評(píng)審的結(jié)果，對(duì)代碼進(jìn)行修復(fù)。 具體操作請

36、參考Code Review工具Jupiter的使用.mht補(bǔ)充 除了以上提到的在開發(fā)過程中我們可以采取的措施外，我除了以上提到的在開發(fā)過程中我們可以采取的措施外，我們還可以通過其它手段從不同方面提升我們的系統(tǒng)質(zhì)量。們還可以通過其它手段從不同方面提升我們的系統(tǒng)質(zhì)量。 下面將簡要介紹動(dòng)態(tài)檢查、下面將簡要介紹動(dòng)態(tài)檢查、WEB前端分析、缺陷管理、前端分析、缺陷管理、自動(dòng)化測試、性能測試的操作和相關(guān)工具自動(dòng)化測試、性能測試的操作和相關(guān)工具。動(dòng)態(tài)檢查 動(dòng)態(tài)檢查是指當(dāng)應(yīng)用在運(yùn)行時(shí)，檢查當(dāng)前應(yīng)用的對(duì)象、對(duì)象引用、內(nèi)存、CPU使用情況、線程、線程運(yùn)行情況（阻塞、等待等），同時(shí)可以查找應(yīng)用內(nèi)存使用得熱點(diǎn)，即：哪個(gè)

37、對(duì)象占用的內(nèi)存比較多；或者CPU熱點(diǎn)，即：哪兒方法占用的較大得CPU資源。 常用的檢測工具有：JProfiler、JConsole。 動(dòng)態(tài)檢查_JProfiler（一） Jprofiler功能強(qiáng)大，是款付費(fèi)軟件，官方網(wǎng)站：http:/www.ej- 。 JProfiler監(jiān)控比較消耗系統(tǒng)資源的，所以性能測試的一般情況下不要運(yùn)行。 如果要用于相對(duì)大壓力情況下，可以有選擇的打開監(jiān)控項(xiàng)，不用所有都打開。主要有兩個(gè)，一個(gè)是內(nèi)存監(jiān)控，打開的情況下可以查找內(nèi)存分配熱點(diǎn)。一個(gè)是CPU監(jiān)控，打開的情況下可以查看CPU使用熱點(diǎn) 。動(dòng)態(tài)檢查_JProfiler（二）監(jiān)控界面如下圖所示： 動(dòng)態(tài)檢查_JConsole

38、（一）JConsole是一個(gè)基于JMX的GUI工具，用于監(jiān)控正在運(yùn)行的JVM 。JConsole是 jdk5.0自帶的工具，所以如果安裝的的jdk5以上版本，那么就不用去另外安裝。JConsole 畢竟是JDK 自帶的東西，功能雖然沒有一些商業(yè)軟件那么強(qiáng)大，但是穩(wěn)定性好，在大壓力情況下也不會(huì)發(fā)生什么問題。而且，提供了相對(duì)全面的系統(tǒng)監(jiān)控功能。在待監(jiān)控的JVM啟動(dòng)命令上增加以下參數(shù)，JConsole就可以遠(yuǎn)程連接并監(jiān)控了。 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=fal

39、se -Dcom.sun.management.jmxremote.port=7080 其中7080是Jconsole連接的端口。 動(dòng)態(tài)檢查_JConsole（二） 在本機(jī)運(yùn)行jdkbinjconsole.exe，輸入遠(yuǎn)端機(jī)器的IP、JMX端口就可以連接上去了。如下圖所示： 動(dòng)態(tài)檢查_JConsole（三） 在本機(jī)運(yùn)行jdkbinjconsole.exe，輸入遠(yuǎn)端機(jī)器的IP、JMX端口就可以連接上去了。如下圖所示：動(dòng)態(tài)檢查_JMX（一）JMX（Java Management Extensions，即Java管理擴(kuò)展）是一個(gè)為應(yīng)用程序、設(shè)備、系統(tǒng)等植入管理功能的框架。通常使用JMX來監(jiān)控系統(tǒng)的運(yùn)

40、行狀態(tài)或管理系統(tǒng)的某些方面，比如清空緩存、重新加載配置文件等 。下面舉例說明怎樣通過JMX監(jiān)控自己的程序： 1、Hello是一個(gè)需要被管理的類： 動(dòng)態(tài)檢查_JMX（二）2、要管理Hello則必須創(chuàng)建一個(gè)相應(yīng)Mbean： 說明：包含在MBean中方法都將是可以被管理的。MBean起名是有規(guī)范的，就是原類名后加上MBean字樣。 動(dòng)態(tài)檢查_JMX（三）3、創(chuàng)建Agent類注冊服務(wù)MBean： 動(dòng)態(tài)檢查_JMX（四）4、運(yùn)行后通過JConsole監(jiān)控的情況如下圖： WEB前端分析（一）為什么關(guān)注前端性能分析？為什么關(guān)注前端性能分析？ “系統(tǒng)響應(yīng)時(shí)間”指應(yīng)用系統(tǒng)從請求發(fā)出開始到客戶端接收到所有數(shù)據(jù)所消

41、耗的時(shí)間。這樣，“系統(tǒng)響應(yīng)時(shí)間”加上“呈現(xiàn)時(shí)間”，才是完整的用戶感受到的響應(yīng)時(shí)間。 響應(yīng)時(shí)間 = 網(wǎng)絡(luò)響應(yīng)時(shí)間 + 應(yīng)用程序響應(yīng)時(shí)間 + 瀏覽器處理時(shí)間響應(yīng)時(shí)間 = （N1+N2+N3+N4）+ (A1+A2+A3) + TbWEB前端分析（二）為什么關(guān)注前端性能分析？為什么關(guān)注前端性能分析？ WEB前端分析（三）Yahoo!的的Exceptional Performance團(tuán)隊(duì)為改善團(tuán)隊(duì)為改善Web性能帶來最佳性能帶來最佳實(shí)踐。他們?yōu)榇诉M(jìn)行了一系列的實(shí)驗(yàn)、開發(fā)了各種工具、寫了大量的實(shí)踐。他們?yōu)榇诉M(jìn)行了一系列的實(shí)驗(yàn)、開發(fā)了各種工具、寫了大量的文章和博客并在各種會(huì)議上參與探討。最佳實(shí)踐的核心就是

42、旨在提高文章和博客并在各種會(huì)議上參與探討。最佳實(shí)踐的核心就是旨在提高網(wǎng)站性能。網(wǎng)站性能。 Excetional Performance團(tuán)隊(duì)總結(jié)出了一系列可以提高網(wǎng)站速度的團(tuán)隊(duì)總結(jié)出了一系列可以提高網(wǎng)站速度的方法?？梢苑譃榉椒??？梢苑譃?大類大類34條。包括內(nèi)容、服務(wù)器、條。包括內(nèi)容、服務(wù)器、 cookie、CSS、JavaScript、圖片、移動(dòng)應(yīng)用等七部分。、圖片、移動(dòng)應(yīng)用等七部分。 詳情請參考附件：詳情請參考附件：雅虎團(tuán)隊(duì)經(jīng)驗(yàn)雅虎團(tuán)隊(duì)經(jīng)驗(yàn)-網(wǎng)站頁面性能優(yōu)化的網(wǎng)站頁面性能優(yōu)化的34條黃金守條黃金守則則.pdf WEB前端分析（四）Yahoo!的的Exceptional Performance

43、團(tuán)隊(duì)為改善團(tuán)隊(duì)為改善Web性能帶來最佳性能帶來最佳實(shí)踐。他們?yōu)榇诉M(jìn)行了一系列的實(shí)驗(yàn)、開發(fā)了各種工具、寫了大量的實(shí)踐。他們?yōu)榇诉M(jìn)行了一系列的實(shí)驗(yàn)、開發(fā)了各種工具、寫了大量的文章和博客并在各種會(huì)議上參與探討。最佳實(shí)踐的核心就是旨在提高文章和博客并在各種會(huì)議上參與探討。最佳實(shí)踐的核心就是旨在提高網(wǎng)站性能。網(wǎng)站性能。 Excetional Performance團(tuán)隊(duì)總結(jié)出了一系列可以提高網(wǎng)站速度的團(tuán)隊(duì)總結(jié)出了一系列可以提高網(wǎng)站速度的方法。可以分為方法。可以分為7大類大類34條。包括內(nèi)容、服務(wù)器、條。包括內(nèi)容、服務(wù)器、 cookie、CSS、JavaScript、圖片、移動(dòng)應(yīng)用等七部分。、圖片、移動(dòng)應(yīng)用

44、等七部分。 詳情請參考附件：詳情請參考附件：雅虎團(tuán)隊(duì)經(jīng)驗(yàn)雅虎團(tuán)隊(duì)經(jīng)驗(yàn)-網(wǎng)站頁面性能優(yōu)化的網(wǎng)站頁面性能優(yōu)化的34條黃金守條黃金守則則.pdf WEB前端分析（五）常用的前端性能分析工具有：常用的前端性能分析工具有： Fiddler IBM Page Detailer （商用）（商用） FireBug Yahoo YSlow HTTP Analyzer （商用）（商用） AOL PageTest 建議采用建議采用IBM Page Detailer、 Yahoo YSlow。 缺陷管理缺陷管理缺陷管理/軟件缺陷管理（軟件缺陷管理（Defect Management）是在軟件生命周）是在軟件生命周期中獲取、管理、溝通任何變更請求的過程（從變更的建議到變更的期中獲取、管理、溝通任何變更請求的過程（從變更的建議到變更