Ⅰ 如何利用jenkins來做android自動化
如何利用jenkins來做android自動化
概述
持續集成是一種軟體開發實踐，即團隊開發成員經常集成他們的工作，通常每個成員每天至少集成一次，也就意味著每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發布，自動化測試)來驗證，從而盡快地發現集成錯誤。許多團隊發現這個過程可以大大減少集成的問題，讓團隊能夠更快的開發內聚的軟體。其中包含一些代碼靜態檢查工具，自動打包和自動測試功能。
持續集成流程
環境配置
啟動Jenkins
1、 安裝jdk
從略，建議1.6或以上版本，配置好環境變數。
2、 安裝tomcat
http://tomcat.apache.org/download-70.cgi
從略，安裝完調試下tomcat是否正常。
3、 安裝ant
http://ant.apache.org/bindownload.cgi
下載zip包，解壓後配置好環境變數。
4、 安裝jenkins
http://java.net/projects/hudson/downloads/directory/war
下載war包，命名為Jenkins，拷貝到tomcat/webapps目錄下。
5、 安裝Android SDK
http://developer.android.com/sdk/index.html
下載安裝,完成後配置好Android_SDK_HOME環境變數。此步驟主要用於進行android自動化測試，若不進行此項可略過。
安裝完成後啟動tomcat/bin/startup.bat文件(linux下是startup.sh)，在瀏覽器輸入http://localhost:8080/jenkins，8080為tomcat埠，即可訪問jenkins伺服器。
配置Jenkins
1、 JDK配置
新增JDK，指定JDK名字和JAVA_HOME
2、 ANT配置
新增ANT，指定ANT名字和ANT_HOME
3、 Maven配置
從略，本文未使用到Maven，具體配置方法參考Google。
4、 Subversion
選擇1.6版本SVN，勾選Update default Subversion credentials cache after successful authentication
5、 郵件通知
填寫SMTP server、Default user E-mail suffix、System Admin E-mail Address、Jenkins URL、勾選Use SMTP Authentication，填寫User Name、Password、Use SSL、SMTP port、Chareset(UTF-8) 、Default Content Type(默認)、Default Recipients(默認收件人)，配置完成後可進行測試郵件。
6、 Jenkins URL
配置該URL，用於別人訪問。
插件管理
1、 Hudson Subversion Plug-in，jenkins的svn插件。
2、 Android Emulator Plugin，android模擬器插件。
3、 JUnit Attachments Plugin，junit測試報告附件插件。
4、 Email-ext plugin，郵件擴展插件。此處說明下，默認Jenkins只會發送構建失敗的郵件，我們需安裝此插件才能自定義不同場景。
5、 Deploy to container Plugin遠程發布插件。
自動化測試
打包源工程
Android程序
本小節講訴如何打包一個Android工程，當前使用的是ant進行編譯源碼。
1、 首先構建一個自由風格的Job。
2、 添加源碼路徑，選擇所使用的版本控制器，輸入源碼路徑。
3、 構建觸發器可根據需要選擇是否定時構建。
4、 構建環境，此處Jenkins安裝了Android Emulator Plugin插件，可以啟動已有模擬器或添加新的模擬器，本文案例中使用真機調試。
5、 構建，卸載手機中原程序 adb –s uninstall com.XXXXXX
6、 生成bulid.xml文件，-p後面跟工程所在的本地jenkins下路徑
android update project -n *** c:\被測工程Job路徑\workspace
7、 Ant進行編譯程序，並安裝到當前手機中
ant debug install -f c:\被測工程Job路徑\workspace\build.xml
8、 構建後操作，本案例中構建完成後自動啟動構建下一個測試Job
Bulid other projects，選擇測試工程的Job.
打包測試工程
Android程序
本小節講訴如何構建一個Android測試工程，包括郵件發送和測試報告展示。
1、 構建步驟1-7和Android程序章節一樣，從略。
2、 本文案例中測試程序是通過命令行啟動運行的，所以在此處增加一個批處理運行。P.S. adb shell am instrument -w -e class com.megafon.test.MegafonTest#testDeleteContact com.megafon.test/android.test.InstrumentationTestRunner ，此處是通過批處理來單獨運行一個個的測試用例。避免了Junit3的無序執行的問題。
3、 刪除Workspace中原來存在的測試報告文件，一般不刪除也會覆蓋。
如何讓測試程序生成xml格式的測試報告，其他文章會重點介紹。
4、 從手機中拷貝測試報告，最終測試是在手機上運行，所以報告也生成在手機中，使用adb pull命令把測試報告全部拷貝到workspace下制定目錄。
5、 構建後操作，發布測試報告，如果報告中包含附件，此處使用到JUnit Attachments Plugin插件。
6、 郵件通知，此處使用到Email-ext plugin插件，前面的默認，直接使用我們在系統管理裡面設置的默認值。
7、 點擊右下角高級按鈕，可選擇不同場景下發送郵件。
8、 測試結果展示，在本次構建的控制台可以顯示當前所有的構建日誌。
9、測試報告點擊Test Result可以顯示所有測試記錄。
z轉載，僅供參考，祝你愉快，滿意請採納。
Ⅱ 什麼是DevOps
DevOps 是一套實踐、工具和文化理念，可以實現軟體開發團隊和 IT 團隊之間的流程自動化和集成。它強調團隊賦能、跨團隊溝通和協作以及技術自動化。
DevOps 運動始於 2007 年左右，當時軟體開發和 IT 運營社區開始擔憂傳統的軟體開發模式。在此模式下，編寫代碼的開發人員與部署和支持代碼的運營人員會獨立工作。DevOps 這一術語由「開發」和「運營」兩個詞構成，它反映了將這些領域整合為一個持續流程的過程。
DevOps 團隊包括開發人員和 IT 運營人員，他們在整個產品生命周期中進行協作，以提高軟體部署的速度和質量。這是一種全新的工作方式，也是一種文化轉型，對團隊及其工作的組織具有重大影響。
在 DevOps 模式下，開發和運營團隊不再是「孤立」的。有時，這兩個團隊會合並為一個團隊，合並後工程師會參與整個應用生命周期中的工作（從開發和測試到部署和運營），並具備多學科的技能。
DevOps 團隊使用工具實現流程自動化，並加速流程，這有助於提高可靠性。DevOps 工具鏈可幫助團隊處理重要的 DevOps 基礎事項，包括持續集成、持續交付、自動化和協作。
DevOps 的價值有時也會應用於開發團隊以外的團隊。當安全團隊採用 DevOps 方法時，安全性則成為開發過程中一個活躍的組成部分。這就是所謂的 DevSecOps。
由於 DevOps 的連續性，從業人員使用無限循環來展示 DevOps 生命周期各個階段之間的相互關系。盡管看似是按順序進行的，但此循環實際表示需要在整個生命周期進行持續協作和迭代改進。
DevOps 生命周期由六個階段組成，它們分別代表開發（循環的左半部分）和運營（循環的右半部分）所需的流程、功能和工具。團隊會在每個階段進行協作和溝通，以保持一致性、速度和質量。
DevOps 團隊應採用敏捷開發實踐來提高速度和質量。敏捷開發是一種用於項目管理和軟體開發的迭代方法，可幫助團隊將工作分解成更小的部分，從而提供增量價值。
Git 是一個免費的開源版本控制系統。Git 可為分支、合並和重寫存儲庫歷史記錄提供出色的支持，而這已為開發構建流程帶來了眾多極具創新且功能強大的工作流和工具。
CI/CD可讓團隊頻繁且可預測地發布高品質產品，其范圍涵蓋從源代碼存儲庫到使用自動化工作流的生產環節。團隊可以頻繁地合並代碼變更、部署功能標記以及集成端到端測試。
快速識別並解決影響產品正常運行時間、速度和功能的事務。自動通知您團隊有關變更、高風險操作或故障的信息，以便保持服務的運行。
管理面向客戶的端到端 IT 服務交付。這包括設計、實施、配置、部署和維護支持組織服務的所有 IT 基礎架構過程中涉及的實踐。
DevOps 團隊應對每個版本進行評估，並生成報告以改進未來版本。通過收集持續反饋，團隊可以改進其流程，並採納客戶反饋以改進下一個版本。
DevOps 工具可應對 DevOps 生命周期的關鍵階段。它們通過幫助改進協作、減少上下文切換、引入自動化以及實現可觀察性和監控功能來支持 DevOps 實踐。
DevOps 工具鏈通常遵循兩種方法：一體化或開放式工具鏈。一體化工具鏈提供完整的解決方案，通常不會與其他第三方工具集成。開放式工具鏈則允許使用不同工具進行自定義。這兩種方法各有優缺點。
有「2020 年 DevOps 趨勢調查」表明，99％ 的調查對象表示 DevOps 對他們的組織產生了積極影響。DevOps 的優勢包括更快且更輕松的發布、團隊效率、更高的安全性、更高品質的產品，以及更高的團隊和客戶滿意度。
更頻繁地實踐 DevOps 發布可交付成果的團隊具有更高的品質和穩定性。事實上，DORA 2019 年 DevOps 狀況報告發現，精英團隊的部署頻率和速度分別比表現不佳的團隊高出 208 倍和 106 倍。持續交付使得團隊可以使用自動化工具來構建、測試和交付軟體。
DevOps 的基礎是開發人員和運營團隊之間的協作文化，他們會分擔責任，協調工作。此舉可以提高團隊的效率，並省去工作交接和編寫專為其運行環境而設計的代碼的時間。
通過提高發布的頻率和速度，DevOps 團隊可以快速地改進產品。快速發布新功能和修復缺陷有助於獲得競爭優勢。
持續集成和持續交付等實踐可確保變更正常運行且安全無誤，從而提高軟體產品的質量。監控則有助於團隊實時了解性能。
通過將安全性集成到持續集成、持續交付和持續部署管道中，DevSecOps 成為開發過程中一個活躍的組成部分。通過將主動安全審計和安全測試集成到敏捷開發和 DevOps 工作流中，可將安全性植入產品內。
原有的習慣很難改變。深陷孤立工作方式的團隊可能會難以應對，甚至抗拒徹底改變團隊結構以採用 DevOps 實踐。某些團隊可能會錯誤地認為有了新工具就足以採用 DevOps。但是，DevOps 是人員、工具和文化的結合。DevOps 團隊的每一個人都必須了解整個價值流，從構思、開發到最終用戶體驗。它要求打破孤島，以便在整個產品生命周期中進行協作。
從傳統的基礎架構轉向使用基礎架構即代碼 (IaC) 和微服務可以加快開發和創新速度，但增加的運營工作量可能極具挑戰性。最好為自動化、配置管理和持續交付實踐奠定堅實的基礎，以幫助減負。
過度依賴工具會使團隊偏離 DevOps 的必要基礎：團隊和組織結構。一旦建立了結構，就應該建立流程和團隊，然後確定工具。
首先，採用 DevOps 需要致力於評估且可能更改或刪除組織當前所用的所有團隊、工具或流程。這表示需要構建必要的基礎架構，以便團隊能夠自主構建、部署和管理其產品，而不必過分依賴於外部團隊。
DevOps 文化是指團隊採用新工作方式（包括加強合作和溝通）的環境。這是人員、流程和工具的協調一致，以實現更加統一的客戶導向服務。多學科團隊負責產品的整個生命周期。
在 DevOps 方面表現良好的組織鼓勵進行實驗和一定程度的冒險。在這些組織中，跳出固有思維模式是常態，而失敗則被理解為學習和進步的自然組成部分。
敏捷開發方法在軟體行業中非常受歡迎，因為它們賦予了團隊內在的靈活性、出色的有序性以及響應變化的能力。DevOps 是一種文化轉型，可促進軟體構建和維護人員之間的協作。搭配使用敏捷開發和 DevOps 時，可提高效率和可靠性。
持續集成
持續集成是將代碼更改自動集成到軟體項目中的實踐。它允許開發人員頻繁地將代碼更改合並到執行構建和測試的中央存儲庫中。這有助於 DevOps 團隊更快速地修復缺陷、提高軟體質量以及縮短驗證和發布新軟體更新所需的時間。
持續交付
持續交付通過自動將代碼更改部署到測試/生產環境中來擴展持續集成。它會沿著持續交付管道推進。而在此管道內，自動化構建、測試和部署會被編排為一個發布工作流。
情境意識
對於組織中的每個成員來說，能夠訪問他們需要的數據以盡可能高效和快速地完成他們的工作可謂至關重要。團隊成員需收到部署管道中的故障警報（無論是系統性故障還是由於測試失敗引起的故障），並及時收到在生產中所運行應用的運行狀況和性能的最新信息。指標、日誌、跟蹤、監控和警報都是團隊了解其工作進展所需的重要反饋來源。
自動化
自動化是其中一個最重要的 DevOps 實踐，因為它能讓團隊更快速地完成高品質軟體的開發和部署流程。利用自動化，將代碼變更推送到源代碼存儲庫的一個簡單操作便可觸發構建、測試和部署流程，從而大大減少這些步驟所花的時間。
基礎架構即代碼
無論您的組織是擁有本地數據中心，還是完全託管在雲中，能快速、一致地調配、配置和管理基礎架構是成功採用 DevOps 的關鍵。基礎架構即代碼 (IaC) 不僅僅是編寫基礎架構配置腳本，它還將基礎架構定義視為實際代碼：使用源控制、代碼審查、測試等。
微服務
微服務是一種架構技術。在此技術中，應用被構建為一系列可以相互獨立部署和運行的小型服務。每個服務都有其自己的流程，並通過介面與其他服務通信。這種關注點分離和剝離的獨立功能支持 DevOps 實踐，例如：持續交付和持續集成。
監控
DevOps 團隊監控從規劃、開發、集成和測試、部署到運營的整個開發生命周期。如此一來，團隊就能迅速、自動地對客戶體驗中的任何降級做出響應。更重要的是，它允許團隊「左移」至開發的早期階段，並最大程度地減少具有破壞性的生產變更。
開始使用 DevOps
開始使用 DevOps 的最簡方法就是識別小型價值流（例如：小型支持應用或服務），然後開始嘗試一些 DevOps 實踐。與軟體開發一樣，與一小群利益相關者一起轉換單個數據流比嘗試在組織內一次性過渡至全新的工作方式要容易得多。
Ⅲ 如何做自動化測試
什麼叫做自動化測試工程師
首先，會使用自動化測試工具的測試人員不能夠稱之為完全的自動化測試人員，這類測試人員被稱為『工具小子』(Script Kid)。這個階段還是處於自動化測試的一個比較低級的階段，因為這些工具都不是測試人員開發的。
對於高手來說，要能寫一些獨立的測試腳本甚至測試工具。
更高的高手則是能腳本和工具和實際工作緊密結合起來，解決工作中遇到的問題。
自動化測試工程師應該具有開發能力嗎
通過上述內容，應該可以看得出來，自動化測試人員一定要有開發能力，而這恰恰是測試人員目前所欠缺的。沒有開發能力的測試人員雖然也可以做一些所謂的自動化，但是僅僅是一些皮毛，沒有辦法做到活學活用。根據某機構的調查數據，目前所有從事測試工作的人中，90%的人都沒有任何開發能力。根據目前的市場行情，如果在精通一門開發語言，能夠從純手工測試轉型為自動化測試工程師，月薪至少增加3~5k。
Ⅳ 要怎麼做辦公自動化軟體
企業定製辦公OA軟體步驟：
1、在企業進行定製oa辦公軟體立項之初，公司需要對多家oa辦公軟體開發商進行了嚴格的篩選，最終確定一家技術實力強，辦公軟體研發經歷豐富的企業進行開發。
2、在確定辦公軟體開發商後，開發商需要派出相關技術人員入駐公司後廣泛徵求各方意見，在充分進行需求調研、分析的基礎上制定了項目實施方案和進度規劃。
3、根據一般公司實際需要，定製oa辦公軟體需要涵蓋協同工作、表單應用、公文管理、計劃日程、會議管理、文檔中心、文化建設等模塊，具有催辦、逐級審批、文件會審會簽、信息採集等功能。這套辦公自動化軟體具有穩定實用的軟體公文流程、信息發布平台，流程可根據用戶的實際情況經審批認可後進行定製、調整等特點，更貼切地滿足用戶移動辦公的需要。
4、進行企業定製oa辦公軟體是對公司各項工作流程的明確與規范，每項工作的各個節點都能得到及時反饋和跟進，有效避免了職責不清、流程不暢、遇事不了了之等弊病。隨著軟體使用過程中遇到的各類問題，公司還會根據需要隨時對流程進行增減和修改。
5、在公司對OA辦公軟體定製到一定階段時，需要組織辦公自動化軟體操作與使用的關鍵用戶分兩批進行了培訓，詳細講解了軟體各模塊的使用方法。為了消除各用戶在軟體試運行過程中面臨的陌生感和困難，軟體管理員又根據培訓內容制定了軟體使用規范，將軟體使用要求、操作規范等內容再一次進行了梳理。
企業定製OA辦公軟體不是一朝一夕就能完成的工作，需要長期、循序漸進的磨合；辦公自動化的開展也不僅僅是某個部門或者某幾個人去進行的事情，它需要各部門的積極配合、每位員工的共同參與，形成一個整體的軟體。
Ⅳ 怎麼學習自動化測試
首先，想從事自動化測試，必須先了解What/Why/How，也就是常說的去了解什麼是自動化測試、為什麼要進行自動化測試、該如何進行自動化測試，這類的資料在網上有很多，這里就不做重復了； 其次，需要根據項目的特點，選擇合適的自動化測試工具，並了解工具的特性。以QTP為例，該如何去掌握它呢？對於初學者，大多數都是通過錄制的方式來生成腳本，這個階段應該掌握的基礎知識有：1) QTP是如何去識別對象的，對於新手經常會出現錄制的腳本回放的時候報錯的現象，這個時候就應該考慮為什麼呢？如果很了解QTP識別對象的原理啊，我想就能很快定位到原因了2) 去掌握一些QTP對象的方法，如GetROPreperty、GetTOPreperty、ChildObjects等等，對於相似的方法應該去搞清楚到底區別在哪？像GetROPreperty、GetTOPreperty有什麼區別等3) 什麼是Action參數、什麼又是Test參數？兩者有什麼區別，又有什麼聯系，在同一Test和不同Test間這些參數如何工作4) 什麼是環境變數？環境變數是如何建立和使用的，環境變數在參數傳遞中和action參數、test參數有什麼不同5) 了解檢查點的知識，明白什麼是內置檢查點，什麼又是自定義檢查點。並搞清楚在什麼時候該如何使用檢查點6) 掌握對象庫的操作，了解對象庫對於測試的意義，象是否啟用智能識別對測試腳本有何影響、為什麼同一對象識別起來會有_1、_2之類的後綴等都是需要去研究清楚的問題這幾個問題都搞清楚的話，那基本就能夠利用QTP生成正確的腳本了，當然以上只是部分必須掌握的內容，其實還是很多細節的設置，就需要在實際運用中去掌握了。接下來，就可以進一步提升自己的QTP運用水平了，這個階段就需要去學習vbs知識和如何運用描述性編程實現腳本了，同時在這個過程中還需要去學習html知識、DOM、XML、以及像excel、word等的API知識了，總的來說，這個階段應該掌握的內容大體上包括：1) VBscrīpt的基礎知識，熟悉常用的方法和函數，掌握文件對象的操作等2) 熟練掌握XML技術；excel、word等API對象，可以根據需要創建日誌等3) 熟練掌握DOM和HTML知識，能夠結合這些技術對Web頁面進行解析4) 掌握資料庫的基本操作語句，能夠利用ADO對象進行數據操縱5) 熟練掌握正則表達式，很多時候處理對象問題相當方便6) 掌握如何調用dll進行工作7) 能夠利用QTP的自動化對象模型創建出需要的運行模式8) 掌握WMI知識以上只是我考慮到的部分，並不全面，呵呵，供大家參考，當然這些技術主要是針對Web系統運行，因為我們的系統就是B/S的，呵呵。如果這些知識都能夠扎實的掌握的話，個人認為，基本上能夠處理自動化過程中的絕大多數問題了，這個時候你對自動化測試的技術應該是有一定積累了。接下來就需要考慮自動化測試框架問題了。當腳本規模到了一定的程度，就會面臨一些問題，如：1) 如何有效的管理並調度腳本2) 如何實現腳本運行的無人值守，測試過程中能夠自動進行錯誤處理並進行日誌記錄3) 如何生成簡介明確的測試報告4) 如何能夠更加高效的維護測試腳本5) 實現框架代碼和業務代碼的分層、業務腳本和業務數據的分離這個階段主要體現的是測試人員的測試思想，是可以脫離工具獨立存在的過程。當然各個公司項目的實際情況不同，導致設計出來的思想不同，但總體上來說一般包括數據驅動和關鍵字驅動兩種模式。後者實現的技術難度大於前者，大多數公司目前都採用的數據驅動模式。這個階段不應局限於技術運用上，而需要從測試全局考慮，進行分層設計、模塊化實現，減少代碼之間的耦合。如果以上三個方面都能夠做的很好的話，那麼恭喜你，你已經可以獨立負責項目的自動化測試建立工作了，呵呵！總之，學習自動化測試需要在實際項目中進行，這樣提高的會比較快，項目中運用了很多種技術，自動化實施過程會碰見各種各樣的問題，是很好的學習機會，關鍵要善於總結、積累經驗，只要能夠把各個細節做好，那麼你一定能夠成為一名優秀的自動化測試工程師。
Ⅵ 如何才能做好測試自動化
1.測試自動化類似於軟體開發的過程
錄制/回放腳本的開發方式是不可能應付所有自動化測試的需求的，因此，需要測試人員掌握必要的開發知識和編碼知識。
2.測試自動化是一個長期的過程
首先，不能期望自動化測試在短期內找到很多Bug，自動化測試只有在長期的多次運行後磁能體現它的價值。其次，不要認為只要購買了工具，錄制一些腳本，然後就可以安枕無憂的看著自動化測試實現想要的效果，需要考慮自動化測試腳本維護成本，隨著被測試應用程序功能的增加和修改，測試腳本的維護工具量會急劇的增加。
3.確保測試自動化的資源，包括人員和技能
最好有專門的自動化測試工程師來保證測試自動化持續，順利的進行下去，自動化測試工程師需要對項目測試自動化負責，設計測試框架和腳本結構，解決各種測試腳本的開發問題，確保自動化測試得以計劃，設計和有序的開發，維護。
4.循序漸進的開展自動化測試
不要一開始就把自動化設想的很大，這往往是不可實現的，應該從小開始，先熟悉工具和自動化測試的基本技能，然後，整合資源開始實現一些基本的自動化測試用例，例如：冒煙測試類型的自動化測試腳本，先實現那些容易實現的，且相對穩定的功能模塊的自動化測試，然後再考慮逐步擴展和補充其他相對難實現，或者是比較不穩定的功能模塊。
5.確保測試過程的成熟度
如果軟體企業的測試過程和項目管理過程的能力成熟度比較低，則實現自動化測試的成功率也比較低，在開展自動化測試之前，先考察一下軟體企業各方面的管理能力，；例如：測試是否獨立進行？有無配置管理？進度控制能力如何？如果各方面的能力成熟度都比較差的話，則不要盲目的引入測試自動化。
自動化測試應該是這樣的：
自動化應該是一種Service（Automation As A Service)，所有的測試人員和開發人員都應該可以自己很方便的去跑自動化
自動化測試的運行結果應該是可以自動分析的，佔用很少的時間
自動化測試的成功率應該是要很高的（比如95%以上）
自動化應該是寫一次，運行很多次，為什麼你們花那麼多時間還要去改自動化代碼？