持續(xù)集成中的自動化實踐

1、持續(xù)集成中的自動化實踐技術創(chuàng)新，變革未來目錄為什么做持續(xù)集成，痛點在哪里？1自動化實踐，為了自動化而自動化？2持續(xù)集成實踐，僅僅為了效率？ No3CI到CD, 突破科技，啟迪未來4QA5 為什么做持續(xù)集成，痛點在哪里？面臨的問題1. 手動打包，費時費力易出錯；2. 各個開發(fā)手動出包環(huán)境不統(tǒng)一，出包內(nèi)容有差別開發(fā)3. Build記錄無法追溯，問題定位困難 為什么做持續(xù)集成，痛點在哪里？面臨的問題我可能用了個假的測試包為什么只有我的測試有問題3. 誰有xxx tag的包，我想驗證一個問題4. 這些工具用起來好麻煩測試 為什么做持續(xù)集成，痛點在哪里？面臨的問題1. 灰度期間這些問題都是什么類型2.

2、集成測試階段與灰度階段的測試數(shù)據(jù)對比QA3. 現(xiàn)在的流程真的完美無缺，無法改進么？ 為什么做持續(xù)集成，總結一下提升開發(fā)效率節(jié)省人力資源統(tǒng)一了測試入口標準并規(guī)范化 降低工具上手難度增加測試維度覆蓋使測試介入開發(fā)流程階段 提前降低BUG修復成本自動化部署，流程更透明 自動化實踐，為了自動化而自動化？單元測代碼靜接口自UI自動試態(tài)掃描動化化 自動化實踐，為了自動化而自動化？單元測試AndroidRobolectric/Junit4+Mockito + PowerMockiOSXCTestSOAJunit4 + Mockito +PowerMock 自動化實踐，為了自動化而自動化？單元測試Androi

3、d 單元測試案例： Junit4 + Mockito + PowerMock1. 痛點：JVM上運行純JUnit單元測試時沒有 androidcontext, 里面只定義了一些接口,所有方法的實現(xiàn)都 是 throw new runtimeException(“stub”)，因此需 要使用Android提供的Instrumentation系統(tǒng)，將單元 測試代碼運行到模擬器或真機上, 執(zhí)行效率有所折扣2. 為什么使用PowerMock: Mockito是通過創(chuàng)建proxy的方 式來實現(xiàn)mock, 因此對于static,final,private方法 都是不能mock的，而PowerMock是通過使

4、用CGLib來操 縱字節(jié)碼的方式實現(xiàn)mock, 所以可以彌補Mockito的不 足自動化實踐，為了自動化而自動化？單元測試Demo Script 自動化實踐，為了自動化而自動化？單元測試iOS 單元測試： XCTest：XCode自帶單測工具, 在XCode5時引入，XCode6時增加了對性能測試，異步測試的支持每個配置的Unit Test Class均是繼承于XCTestCase 最重要的三個方法：(void)setUp:準備測試環(huán)境；(void)tearDown:腳本結束后執(zhí)行，清理測試影響；measureBlock: 性能測試方法，用來計算測試block中方法 執(zhí)行時間，通過與期望性能值

5、對比可以判斷是否能夠通過 性能測試自動化實踐，為了自動化而自動化？單元測試Demo Script 自動化實踐，為了自動化而自動化？代碼靜 態(tài)掃描Infer / FindbugsInfer / Xcode Analyze InferFacebook開源的一款代碼靜態(tài)分析工具 Java/Objective-C中均捕捉的BUG類型如下：資源泄露問題(Resource Leak)空指針/引用問題(Null Dereference)Objective-C中捕捉的BUG類型如下：內(nèi)存泄露問題(Memory Leak)內(nèi)存死鎖問題(Retain cycle)參數(shù)非空檢查(Parameter Not Null

6、 Checked)本地變量非空檢查(Ivar Not Null Checked)自動化實踐，為了自動化而自動化？代碼靜 態(tài)掃描Infer Tips: 初次運行時，確保項目是清理過的?？梢酝ㄟ^ (make clean，gradle clean etc)兩次運行之間，需清理項目，否則-incremental選項會因 為增量編譯而無結果輸出，如使用的是非增量編譯方式， 則無需如此，比如：infer - javac Hello.java，編譯 Java 文件。3. 成功運行之后，在同一目錄下，你可以通過inferTraceBugs命令瀏覽更加詳細的報告自動化實踐，為了自動化而自動化？代碼靜 態(tài)掃描In

7、fer Report: 自動化實踐，為了自動化而自動化？代碼靜 態(tài)掃描FindBugs檢查class文件，將字節(jié)碼與自帶或用戶自定義的bug pattern進 行對比以發(fā)現(xiàn)可能的問題, problem example below: 自動化實踐，為了自動化而自動化？代碼靜 態(tài)掃描自定義掃描規(guī)則： 自動化實踐，為了自動化而自動化？接口自動化SwaggerUIJMeter 自動化實踐，為了自動化而自動化？接口自動化SwaggerUI + Spring-boot 接口測試管理：添加依賴到gradle腳本添加SwaggerUI配置來激活對應服務 自動化實踐，為了自動化而自動化？接口自動化SwaggerU

8、I + Spring-boot 接口測試管理：Demo Api 自動化實踐，為了自動化而自動化？接口自動化SwaggerUI + Spring-boot 接口測試管理： 自動化實踐，為了自動化而自動化？接口自動化JMeterTestPlanCreate Thread GroupDevelop Test ScriptsExecute Test PlanAnalyze Test Result基本介紹：Jmeter是一款非常優(yōu)秀開源的接口/性能測試工具 常用控件：測試計劃、線程組、控制器、配置元件、定時器、 前置處理器、后置處理器、斷言、監(jiān)聽器基本的測試流程如下：自動化實踐，為了自動化而自動化？接口

9、自動化Jmeter的使用： 測試計劃是使用 JMeter 進行測試的起點，它是其它 JMeter 測試元件的容器。線程組代表一定數(shù)量的并發(fā)用戶，它可以用來模擬并發(fā)用戶發(fā)送請求。實際的請求內(nèi)容在 Sampler中定義，它被線程組包含。監(jiān)聽器負責收集測試結果，同時也被告知了結果顯示的方式。邏輯控制器可以自定義JMeter發(fā)送請求的行為邏輯，它與Sampler結合使用可以模擬復雜的請求序列。斷言可以用來判斷請求響應的結果是否如用戶所期望的。它可以用來隔離問題域，即在確保功 能正確的前提下執(zhí)行壓力測試。配置元件維護Sampler需要的配置信息，并根據(jù)實際的需要會修改請求的內(nèi)容。前置處理器和后置處理器負

10、責在生成請求之前和之后完成工作。前置處理器常常用來修改請求的設置，后置處理器則常常用來處理響應的數(shù)據(jù)。定時器負責定義請求之間的延遲間隔。自動化實踐，為了自動化而自動化？接口自動化Jmeter的使用 自動化實踐，為了自動化而自動化？UI自動化Appium 自動化實踐，為了自動化而自動化？UI自動化Why Appium跨平臺跨開發(fā)語言兼容其他工具非侵入式設計 自動化實踐，為了自動化而自動化？UI自動化Appium + TestNG控件層操作層驅動層PageObject層用例層配置層xml,yaml 自定義測 試套件自動化實踐，為了自動化而自動化？UI自動化UI自動化策略覆蓋率產(chǎn)出效率 持續(xù)集成實踐

11、，僅僅是為了效率？No代碼拉取靜態(tài)掃描編譯檢查單元測試接口測試UI自動化測試提測 持續(xù)集成實踐，CI-Service Framework 單測工具UI自動化測試工 具Monkey代碼掃描工具接口自動化工具測試數(shù)據(jù)搜集基礎分析自定義展示提交觸發(fā)手動觸發(fā)DailyBuild研發(fā)自測，通 過構建測試實時合并主干代碼管理構建方式工具數(shù)據(jù)持續(xù)集成實踐，僅僅是為了效率？NoCI實踐的主要價值體現(xiàn)測試提早介入項目代碼靜態(tài)掃描&代 碼編譯檢查，使得 測試介入編碼階段；盡早發(fā)現(xiàn)代碼問題， 降低bug修復成本；統(tǒng)一測試入口標準統(tǒng)一出包避免出包 不一致引起的bug；統(tǒng)一出包提高了測 試包的復用性，降 低重復操作和溝通 成本；提升測試效率引入不同的自動化 工具，增加產(chǎn)品開 發(fā)過程的透明度， 降低溝通成本，效 率更高；積累開發(fā)、測試過 程中的數(shù)據(jù)，測試 結果定期分析（定 期報告） 未來展望，CI-CD技術效率質量 未來展望，CI-CD 未來展望，持續(xù)集成到持續(xù)交付快速發(fā)布。能夠應對業(yè)務需求，并更快地實現(xiàn)軟件價值。編碼