⑴ 自動化測試腳本開發的主要步驟
1、通過某些方式定位到我們要執行的對象、目標( Target)
2、對這個對象進行什麼操作(command)
3、通過操作對定位到的元素賦值(value)
4、添加斷言操作
⑵ 自動化測試實例二：腳本開發(上)
完成測試用例後就可以開發測試腳本，一般包括自動化測試框架的開發和功能腳本的開發。在本節中不介紹如何開發自動化測試框架，有興趣的讀者可以參考《 QTP 自動化測試與框架模型設計 》一書中第 19 章和第 20 章的自動化測試框架的內容。本章介紹該實例中需要調用到的函數。
(1)公用函數封裝。
在本實例中需要封裝的函數主要包括： 讀取測試用例、輸入每個測試用例的測試結果。
通過獲取單元格中數據的行數，可以確定測試用例文檔中有多少條測試用例， 代碼如下：
讀取單元格中的數據，即獲得測試用例值， 代碼如下：
在該實例中還需要記錄每個測試用例執行的結果， 封裝的代碼如下：
由於在本實例中需要連接資料庫，檢查資料庫中的數據是否正確，所以將連接資料庫的代碼進行封裝， 代碼如下：
(2)單一模式腳本開發。
自動化測試腳本開發完成後，開始錄制腳本，這個階段主要是將自動化測試的需求轉換為一個簡單的腳本。
1)錄制登錄過程的腳本如下：
2)錄制訂票流程的腳本如下：
3)錄制航班信息的腳本如下：
4)錄制查詢訂票信息的腳本如下：
(3)腳本增強。
錄制好的單一模式腳本的功能很弱，只完成了一個簡單的功能，不具備可擴展性，無法兼容不同的測試數據，所以需要對上面的腳本進行增強。在錄制單一模式的腳本時，其實有一個功能是通用的，就是登錄功能，每個操作的功能都需要先登錄系統，所以可將一個正確登錄的腳本封裝成一個過程，這樣可以節約腳本量，也便於維護腳本。在封裝登錄過程時，需要使用到描述性編程， 封裝的代碼如下：
接著對登錄的腳本進行增強操作，增強的原因是腳本需要能正確處理當輸入用戶名或密碼出錯的情況。 主要需要處理的情況有： 輸入的用戶名為空、輸入的用戶名少於 4 個字元、輸入的密碼為空、輸入的密碼少於 4 個字元。 登錄功能增強後的腳本如下：
訂票流程腳本的增強主要需要處理訂票日期未輸入和輸入錯誤的情況， 訂票流程功能增強後的腳本如下：
航班信息查詢腳本的增強主要是需要檢查當選擇出發城市和到達城市後，顯示出來的航班信息是否正確，腳本增強時需要獲取所有航班信息。 增強後的腳本如下：
查詢訂票信息腳本增強主要是需要檢查該航班號是否存在，如果航班號不存在，會彈出相應的對應信息;如果查詢的訂單號存在，就會顯示出該訂單的相關信息。 增強後的腳本如下：
⑶ 自動化測試實例三：腳本開發(下)
僅僅通過上面對腳本增強還不夠，不能做到真正的自動化測試，還必須讓腳本正確地執行所有用例，並且同時判斷每個測試用例執行的結果。
對於登錄功能調用測試用例後的腳本如下：
訂票流程功能腳本不但需要調用測試用例，並且在選擇出發城市和到達城市時需要隨機選擇，選擇好出發城市和到達城市後，在選擇航班時也需要做到隨機選擇，這樣能更好地模擬真實的情況。
訂票完成後需要檢查訂票信息是否已經寫入資料庫，即需要檢查 Orders 表中是否添加了相關的訂單信息，增強後的腳本如下：
航班信息功能不需要讀取數據，但需要隨機選擇出發城市和到達城市，當輸入出發城市和到達城市後，應該檢查彈出的航班信息對話框中的所有航班信息是否成功，即是否與 Flights 表中的記錄對應， 增強後的腳本如下：
查詢訂票信息功能增強，即隨機輸入一個訂單號，當該訂單號存在時，需要進一步判斷相關的信息是否正確，如果正確，說明該測試通過，否則測試失敗。 增強後的腳本如下：
腳本開發完成後，即可開始執行腳本，這些腳本主要是功能方面的驗證測試。功能驗證測試也可以理解為每日構建測試，主要是對系統每日新增或修改的代碼進行測試，以保證新增或修改的代碼不會對關鍵功能產生影響。
在執行腳本過程中，需要記錄每一輪測試用例執行的情況，即測試用例記錄，當整個項目的自動化測試完成後，需要提交相關的測試報告。
【自動化測試小結】
本章主要介紹了自動化測試相關的知識， 自動化測試的目的、范圍，測試的程度和測試對象;自動化測試的優缺點和當前自動化測試普遍存在的問題;當前主流的自動化測試工具、自動化測試框架和自動化測試的過程。 通過本章的學習，重點了解什麼是自動化測試、自動化測試框架和自動化測試過程。最後通過介紹一個自動化測試實例，使讀者更好地學習自動化測試的相關知識，但要進一步了解自動化測試，還必須閱讀相關的自動化測試資料。
⑷ 測試中如何使用自動化腳本
從畢業到現在，經歷了軟體開發，
軟體測試，
1）QTP工具。QTP是一個快速測試專業工具。它的優點是可以快速建立企業自動化框架，但不是一個全能的工具，因為利用QTP並不能幫助用戶找出更多的 BUG，只能提高執行測試用例的效率。 QTP的價格也較貴。 QTP主要應用於較穩定的測試項目的回歸測試，UI的變化不明顯，功能較穩定的項目。它可以節省回歸測試的成本，但相對手工測試來說，QTP對測試人員的要求較高，比如要掌握VB腳本，掌握函數調用等技術；另外，建立QTP框架前期需要投入較大的人力寫測試用例，加上調試的時間，是一筆不小的開銷，所以企業在選用QTP測試工具時一定要三思而後行。
2）Loadrunner是一個企業級性能測試工具，應用十分廣泛。對於WEB應用，Loadrunner的優勢十分明顯。但與QTP一樣，lr的 License十分昂貴，所以很多企業都使用破解版。並且真正掌握LR精髓的人員並不多，很多人都會使用這個工具，但能用這個工具找出系統瓶頸的人並不多，所以，會使用Loadrunner和會性能測試是兩碼事。懂腳本語言的性能測試人員當然最好。
3）Python和Tcl/tk腳本語言。在我之前的經驗中，我用到過PYTHON和TCL。他們都是腳本語言，不需要編譯。兩種語言的特點如下：Python開發JAVA方面的http介面比較方便；tcl/tk開發C++方面的介面更容易一些。PYTHON寫的程序可讀性強，TCL寫的程序的可讀性不好。
4）在需要產生一些大批量數據時，如一個表需要插入100萬條數據，然後這100萬條數據屬於100個不同的類別，如果是手工輸入的話，估計10個人一個月都輸不完，但如果利用腳本，如PB，VB或者Tcl/tk，可以通過產生批量SQL腳本的方式，來產生SQL腳本，這樣不到半小時就可以搞定全部的數據。看來腳本的威力不小！
5）另外，就是Linuxshell腳本了，我們通常說「事半功倍」，shell腳本的確可以幫助你實現這個目的。我們平時在LINUX部署一個應用會用到很多的命令如 Checkout，ps，vi，kill等等，如果能把這個操作流程寫成一個SHELL腳本讓機器自動執行，那該是省了多少事？另外，作為 UNIX/LINUX管理員，平時可以要監控較多的PC終端，他完全可以在UNIX/LINUX上定製各種任務（如備份，刪除臨時文件，檢查磁碟空間等等），所以，掌握Shell腳本（如Sed，awk，grep等）對一個測試人員來講是十分必要的！
6）另外一個就SQL腳本了，要能寫存儲過程（SP）和觸發器（Trigger），還有游標（Cursor）的使用，掌握這些的話對於測試資料庫方面的用例是相當有幫助的。SQL腳本對系統性能和功能都起著十分重要的作用。
作為一名有6年測試經驗的工程師，我堅定地認為腳本測試技術是以後的發展方向，包括白盒測試，也是將來的一個發展方向，對於測試人員來講，核心競爭力是能完整的測試開發人員的程序，盡可能找出更多的BUG。黑盒測試只能從系統的角度去完成功能測試，但作為軟體本身，應該作更深層次的測試。
⑸ 自動化測試腳本的基本功能有哪些
自動化測試腳本的基本功能有腳本語言，對象識別，自動執行和結果判斷。
1、測試需求分析階段。測試需求分析階段主要工作是獲得測試項目的測試需求（測試規格）。輸出產物：《可測試性需求說明書》和《測試規格》。
2、測試計劃階段。以測試需求為基礎，分析產品的總體測試策略。輸出產物：《產品總體測試策略》。
Test Partner：
它使測試人員和開發人員都可以使用可視的腳本編制和自動向導來生成可重復的測試，用戶可以調用VBA的所有功能，並進行任何水平層次和細節的測試。TestPartner的腳本開發採用通用的、分層的方式來進行。
沒有編程知識的測試人員也可以通過TestPartner的可視化導航器來快速創建測試並執行。通過可視的導航器錄制並回放測試，每一個測試都將被展示為樹狀結構，以清楚地顯現測試通過應用的路徑。
⑹ 程序員6年只幹了50個小時工作，被開後稱是編寫了自動化工作腳本
很久之前，Reddit上出現了一則匿名的自白帖子：「 大概六年前到現在，我在公司什麼活都沒干 。」
這個化名為FiletOFish1066的程序員稱自己供職於一家知名的 科技 公司，實際上無所事事。
他寫道，謀得這份質量保證工作的八個月後，他使自己的全部工作完全自動化。「我可不是開玩笑。每周40個小時，我去上班，在辦公室玩《英雄聯盟》，瀏覽Reddit，想幹啥就幹啥。 在過去這六年，正兒八經的工作我可能也就幹了50個小時 。」
上司意識到他在六年內所做的工作比大多數矽谷程序員在一周內所做的工作還少後，就把他開除了。
這個故事在網上的技術圈子迅速傳播開來，最終促使這位主人公不僅刪除了帖子，還刪除了整個帳戶。
我發現歪果仁也跟中國人一樣愛看熱鬧，不嫌事大！
大概一年後，一個自稱是Etherable的用戶向互聯網上最重要的程序員論壇之一Stack Exchange上的Workplace版塊發了一個問詢帖：
「我沒有告訴僱主我的工作已自動化，這是否不道德？」這位內心矛盾的程序員說，他接受了一份美其名曰是「數據錄入」的編程活；六個月前，他編寫了使整份工作自動化的腳本。此後，「 上一個人過去常花一個月才能完成的工作現在只要10分鍾就能完成。 」這份工作是專職性質的，帶來的好處是Etherable可以在家辦公。
這個程序取得了近乎完美的效果。
後來這個帖子引起了分歧，評論鋪天蓋地。（現在瀏覽量將近50萬人次。）意見分成兩大派，一派覺得Etherable在欺騙僱主，至少在蒙蔽僱主；另一派認為這個程序員只是找到了一種巧妙的方法來完成手頭的工作。Etherable從未回應隨至而來的討論。也許是被受到的關注程度（世界各地的媒體都在競相報道此事）嚇壞了，這個用戶銷聲匿跡，只留下了那則帖子，關於誰可以使工作自動化、在什麼樣的條件下這么做的討論越來越備受關注。
可以稱之為自發自動化（self-automation）或自行自動化（auto-automation）。在大規模自動化這個幽靈困擾一線員工的那一刻，自行其事的程序員表明這個威脅到了程序員的手裡，如何變成天賜之物，不管僱主是不是知情。由於FiletOFish1066和Etherable都匿名發布帖子，隨後很快消失，因此兩人都聯系不上，無法請他們發表評論。但他們的故事表明，職場自動化會有多種形式，並由高管以外的人來主導。
生性樂觀的經濟學家和未來學家吹噓， 自動化的好處在於，將工作交給機器有望消除無須動腦子的重復性工作 ，讓人們可以一心撲在有趣又有創造性的工作上，或者更要緊的工作上。
磚家你確定現在程序員乾的都是不動腦子的工作？
你還確定，時間多出來之後，
程序員會干有創造性的工作？！
幾十年來程序員們一直在編寫使工作自動化的代碼。編程通常需要用到在不同的層面（從代碼格式化到合並至不同的代碼庫）添加自動化的工具，大多數人根本沒有走到使工作完全自動化或幾乎完全自動化這個極端。
我通過Reddit和電子郵件的私聊信息與十來個聲稱有類似經歷的程序員聊天。這些自發自動化人士處理過庫存管理、報表編制、圖形渲染、資料庫管理和各種各樣的數據輸入。
有個人還使他妻子的全部工作自動化。大多數人要求匿名，以保全工作和聲譽。
一位很早是自發自動化人士的名為Gary的程序員告訴我：「一開始，我的工作每天實際上要干8個小時。」他在一家大型企業連鎖酒店工作，這家連鎖酒店在90年代開始實現計算機化工作流程。Gary很快意識到在花大量時間重復同樣的任務，於是他開始 下班後學習編程 。他說：「大概 花了三個月的時間，我用Lotus 1-2-3（當時一款很流行的PC電子表格軟體）編寫了一段代碼，不僅使個別的重復性任務自動化，實際上還使整份工作自動化 。」他沒有一五一十地告訴上司，其職場生活的質量大大提高了。
他告訴我：「一整天很空閑感覺怪怪的，於是我趁空了解酒店的其他系統。」後來他幫助管理層消除了那些系統中的瓶頸。自行自動化消除了瑣碎的工作，減輕了他的壓力，並讓他可以撲在真正感興趣的事情上。他說：「實際上，我將這份崗位變成了自己喜愛的崗位，即排查故障。」在離開公司前兩周，他交給老闆一張軟盤，裡面裝有這個程序和解釋如何運行的說明文檔。Gary說，老闆對他辭職頗為不安，直到他交出了軟盤，介紹程序如何運行，並告訴老闆萬一有問題可以打電話給他，老闆才放下心來。 後來電話沒來過一個。
在大多數領域，一線員工對於他們的工作是否自動化，或者如何實時、何時實施自動化很少有任何正式的意見。自發自動化人士明白，自由化由勢必從中收益的一線員工、而不是由自上而下的公司命令來安排自動化會什麼樣。一些人欣然享受多出來的閑暇時間，另一些人利用多出來的時間來學習新技能，應對新的編程挑戰。
ps：你確定不是玩手機？
不過，許多自發自動化人士害怕與辦公室外面的人分享代碼。即使一個程序無可挑剔地完成了工作，許多人還是覺得為牟私利而搞的自動化是錯誤的。人力勞動本質上是善良的（以及員工應始終最大限度地為僱主提高生產力），這比任何自動化腳本更深深地融入到美國的職場文化中。而大多數僱用合同明文規定，工作時間開發的知識產權屬於僱主。因此，員工可能所做的任何效率提升或自動化改進都往往歸僱主所有。
一位程序員沒有把他使其工作完全自動化的真相告訴公司，因為擔心公司到時聲稱知識產權歸公司，並拒絕補償他。另一位只肯自稱是Jordan的人告訴我，他曾無意中使整個部門的工作自動化。現在他用自動化腳本每年省下「好幾周」的時間。Jordan表示，他和同事們保持緘默，絕不透露自動化技術，以便控制使用自動化技術的方式：「我們通常不對外透露這些工具。」
另一位程序員竭力向老闆隱瞞使其年薪5萬美元的工作完全自動化的概況。管理層可能通過網路查看其電腦屏幕上的內容， 於是他運行預先錄制的視頻，掩蓋他實際上沒在工作的事實。 Etherable在尋求建議的帖子中寫道：「我覺得這么做不對。」
一些程序員表示，就因為使工作自動化，自己已被公司炒魷魚。2011年，一個名為AcceptableLosses的用戶寫道：「 公司拿去了我開發的軟體，派一個白痴頂替我，並立即以「不服從」為由解僱了我 。我開發了一款每年讓這家公司獲利100萬美元的軟體，對方卻僅僅為了省下每年約3萬美元的工資而開除了我。我真是自掘墳墓啊。」
正因為如此，自發自動化人士擔心的倒不是道德問題，而是不想被僱主開除或盤剝，正如伍德科克特別指出的那樣，僱主「不僅要求我們的所有時間歸他，我們開發的所有東西也歸他。」他推測，謹慎的自發自動化人士「不信任我們的工作場所。上司會說『謝謝你，幹得漂亮。現在再做一次。』」
很少有員工渴望完全自我自動化，但似乎越來越多的員工對於使用腳本來處理繁忙工作感興趣。網路上有眾多這方面的博文和實用文章，比如《我如何用Node JS使我的工作實現自動化？》，也有眾多播客介紹每一種想像得到的自動化：小公司、營銷和智能手機。這簡直就是一個蓬勃發展的家庭手工業。
照目前情況來看，自發自動化大有助益。但隨著自動化技術變得更廣為人知，它們可能完全成為管理層期望員工擁有或學會的另一種技能，並最終讓企業受益，並以另外某種方式使這些人成為有用的員工。
《哈佛商業評論》雜志寫道：「員工將越來越需要使自己的工作自動化，否則就滾蛋。放眼全球，我們會看到更多自上而下的管理層命令，要求搞自下而上的自動化項目。」而老闆及員工開發的機器人軟體會再次品嘗勝果。
在此之前，任何使用代碼的人都可能應該考慮自發自動化帶來的好處。可以以此來測試自動化如何為普通員工帶來更高的生活質量，盡管談不上完美。伍德科克告訴我：「問題在於自動化要有效，自動化要民主化。不是公司企業在提供自動化，這向前邁出了一步。它仍然不是民主化過程。」自發自動化人士在單獨行動，決定何時、如何把自己的工作換成代碼。而理想情況下，自動化決策將在同事和同行給出意見的情況下共同做出，以便可以均勻分攤好處。
自發自動化人士表示，程序員有獨特的條件，可以與僱主就員工應該保留哪些自動化帶來的效益展開談判，比如時間更短的工作周以及更靈活地從事自己感興趣的工作。從理論上來講，自發自動化人士可以在屬於中產階級和工薪階級的程序員當中組織和分配自動化技術，從而打造有望實際上獲得15小時工作周的一個行業。這似乎是千載難逢的機會，可以努力為把人放在首位的自動化模式創造條件。
你如何看到互聯網蓬勃發展，越來越多產業自動化發展，今後人們能做什麼呢？
歡迎評論
點擊【右上角，關注 子瑜說IT 】持續更新IT資訊以及web前端開發教學
⑺ 自動化腳本怎麼寫
引流腳本，其實簡單的來說，就是模擬人的自然行為，實現各種點擊，發送文字，打字等等功能。
即不需要人工去干擾，也不需要什麼控制器去控制，每天24小時，根據事先設計的指令，完成指定的任務。
一個成熟的腳本 ，可以幾十 ，幾百台手機同步運行 。
自動化腳本穩定性如何，如果涉及到一些比較敏感的業務，會不會封號呢？？那麼應該如何正確的使用腳本。
目前比較好的腳本設計語言要數 按鍵精靈，分PC版和手機版本，當然也有其他的好的 自動化腳本語言。
比如 autoJS ，nodeJS等等 ，
目前基本所有的 腳本設計語言，都可以免ROOT執行 ，這個也是為了避免大型APP檢測。很多APP
都會檢測，手機是否已經被ROOT，如果已經Root ，則直接封號 ，或是限制流量等等，這樣就失去了 自動化的意義了 。
一：自動化腳本穩定不穩定？
其實設計 一個 自動化腳本 ，隨便一個 入門級程序員都可以 ，甚至不會開發的，都可以見到的開發一些腳本。
特別是按鍵精靈，支持中文 開發 ，太給力了 。
而且一般通過按鍵精靈編寫的 ，都是非常穩定的 ，因為這個開發團隊經歷了 十多年的改進，完善 ，已經非常的值得讓人信賴，
少有的良心軟體之一，不過最近也開始收費，適當收費，個人覺得也是合理的 ，因為別人也是花費大量的人力，財力 。
二：正確使用自動化腳本的方法是什麼？
不管任何一個腳本，他的最終的目標就是可以讓一些復雜的操作，可以根據事先設計的軌跡進行運行 ，至於是否封號，
這個並不屬於腳本需要實現的范圍，所以很多人使用腳本 ，導致封號，或是效果差，
就怪罪腳本不行，這個是完全不合理的 。
大多封號，都是有些用戶24小時發送廣告，生怕成本賺不回來，而且大部分都是採用模擬器的方式，
當用戶被大量騷擾，平台檢測出來你使用同樣的一個硬體環境，大量刷 ，
所以很多時候 ，我們還是得老實點 ，不停更換賬號 ，適量發送，多從平台，從用戶角度出發，才能減低封號率。
如何解決問題，讓工具為我們服務？
既然清楚，分析了真實原因 ，自然就要開始著手解決問題 ，相信解決問題的方法總比問題多。
每天我們不是在解決問題就是在解決問題的路上。
既然腳本無法解決一機一號問題 ，就得著手從其他的途徑解決這個問題 。
這里介紹一款工具 ，可以完美解決一機一號問題 。
廢話就不多說 ，可以詳細參考下面的視頻
https://www.bilibili.com/video/BV1fK411A7DD
看完這個文章介紹，我們就可以實現，將手機根據自己的需要 ，模擬出一個獨一無二的手機
功能非常的齊全 ，可以進行虛擬的GPS定位 ，隨機mac IME編碼等等 ，內置大量主流手機 。
然後配合自動化腳本 ，就可以實現批量的自動化操作，同時也可以很好的避免封號 ，
比如批量轉發視頻，或是自動點贊，評論 ，回復等等 ，
通過加大自己作品曝光量，自然對你感興趣的就會關注你，粉絲會慢慢積累，
在運營中，要做好方向規劃，利用好腳本 ，自然不管你做什麼事，都會得心應手 。
⑻ 求自動化測試腳本編寫教程，別就說讓我去學各式語言，詳細點。
你好
我是從事自動化測試方面的
1、自動化測試腳本，包括下面幾個方面
1）CLI自動化測試，其應用腳本技術，包括tcl、phython、ruby，你學好一門自動化測試腳本即可，因為CLI的自動化測試就是應用腳本去模擬人工輸入命令行，建議學習一下phython，因為其強大的社區，還有不亞於高級語言的編程思想。
2）工具方面，自動化測試工具例如：RFT的腳本包括java與.net；QPT的腳本為VB等。你有一定的編程基礎的話，就不要停留在工具試用方面，而是要去重點學習一下其工具思想。你沒有基礎的話，你就從其RFT與QTP的幫助文檔看起，裡面都有關於這些功能的API的。
3）自動化測試框架，這個方面不是單存的自動化測試腳本了，而是利用編程技巧，結合各種自動化測試理念去構建適合自己的自動化測試框架，則就要求一定高度的編程技巧和各種知識了。
你需要自動化測試腳本編寫教程，這先要看你去掌握什麼方面的的自動化測試腳本了，我可以提供你教程，但關鍵先看你的需求
這樣，推薦你一個博客， 是專注自動化測試的博客。你先看看，我覺得你對自動化測試認識不深，你先把自動化測試弄得有點小明白，再去看看。你需要什麼，你的方向是什麼：
51tesing上的「散步的SUN」的博客，這是我的博客，你可以在網路裡面直接輸入「散步的SUN」就是其博客了。上面有各種關於自動化測試方面的知識，希望對你又幫助吧。
或者對自動化測試有興趣的，可以發短消息或者郵件我吧（[email protected])，有機會一起學習探討下
⑼ 測試開發之自動化篇-使用Selenium Driver實現腳本
本文使用到了Selenium的Java版WebDriver、Chrome瀏覽器驅動。前者為一個Java類庫，提供了測試有關的各種API，項目中使用了Maven來導入其Jar包；後者是一個二進制的可執行文件，用於完成對瀏覽器的操控，在代碼中指定了其文件路徑。
閱讀和嘗試運行本文中的例子，需要一些Java基礎，如搭建基礎開發環境、使用Maven下載Java依賴包、JUnit單元測試框架等，這些我們可在後續的編程語言的課程中給大家介紹。
這里給出完整的Java代碼文件，其他語言的例子，請參照Selenium官方示例。
⑽ iOS開發知識體系之《腳本自動化打包--xcodebuild》
iOS腳本自動化打包方案--xcodebuild
本文主要xcodebuild腳本自動化打包並上傳到蒲公英或者AppStore，廢話不多說，直接上干貨！
先了解一下xcodebuild打包需要的一些指令
-workspace XXX.xcworkspace
XXX.xcworkspace需要編譯工程的工作空間名稱，如果工程不是.xcworkspace的，可以不需要-workspace XXX.xcworkspace這段話
-scheme XXX
XXX是工程名稱，-scheme XXX是指定構建工程的名稱
-configuration Release
填入打包的方式是Debug或Release，就跟在Xcode中編譯前需要在Edit scheme的Build configuration中選擇打出來的包是Debug還是Release包一樣，-configuration就是配置編譯的Build configuration
-archivePath ./myArchivePath
配置生成.xcarchive的路徑， ./表示生成在當前目錄下，myArchivePath是生成的.Archive文件名稱
ODE_SIGN_IDENTITY=證書
配置打包的指定證書，如果該工程的Xcode已經配置好了證書，那麼不加入這段話也可以，打包出來的證書就是Xcode中配置好的。
PROVISIONING_PROFILE=描述文件UUID
配置打包的描述文件，同上，Xcode已經配置好了就不用在填入這段話了
CONFIGURATION_BUILD_DIR
配置編譯文件的輸出路徑，如果需要用到.xcarchive文件內部的dSYM等文件，可以使用改欄位指定輸出路徑。
如果工程是勾選了Automatically manage signing，那麼就不用在配置ODE_SIGN_IDENTITY和PROVISIONING_PROFILE,今天這里講到的Automatically manage signing自動配置證書，手動配置的就不多說了，有興趣的話可以自己研究。
xcode工程配置自動獲取證書，如下圖：
打包所需要文件
配置打包的ExportOptions.plist文件，可以在任意一個Xcode工程中新建一個ExportOptions.plist文件。dev和adHoc和AppStore的配置文件內容不一樣，可以先手動打包後看下plist文件的樣式，這里提供一個樣例：
這里method對應的value為打包對應的環境，有development、ad-hoc、app-store、enterprise根據打包環境來配置不同的值
編譯腳本命令
xcodebuild archive -workspace XXX.xcworkspace -scheme XXX -configuration Release -archivePath ./myArchivePath CONFIGURATION_BUILD_DIR ./dir ODE_SIGN_IDENTITY=證書 PROVISIONING_PROFILE=描述文件UUID
導出ipa包命令
xcodebuild -exportArchive -archivePath ./myArchivePath.xcarchive -exportOptionsPlist ./ExportOptions.plist -exportPath ./out
-archivePath ./myArchivePath.xcarchive指定需要打包的.xcarchive路徑，./myArchivePath.xcarchive表示在當前終端路徑下的myArchivePath.xcarchive文件
-exportOptionsPlist ./ExportOptions.plist指定打包需要的ExportOptions.plist配置文件路徑
-exportPath ./out指定打包輸出的路徑， ./out表示打包結果輸出在終端的當前路徑下的out文件家中。如果沒有out文件夾會自動創建一個
腳本操作
首先：cd到需要自動打包的工程下
然後：在終端中輸入touch xcodebuild.sh創建xcodebuild.sh腳本文件
然後：雙擊打開腳本寫入下面 腳本內容（請確保所有版本的plist配置文件都寫好了）
最後：在終端中輸入./xcodebuild.sh運行腳本，按照步驟完成打包選擇(如果運行的時候出現Permission denied，請先在終端中執行chmod a+x *.文件的後綴名後，在運行，相當於提高腳本文件的許可權)
腳本內容
此腳本包含了自動上傳蒲公英的選擇操作，根據輸入指令來執行具體操作
腳本實現
具體詳細腳本見GitHub地址： https://github.com/Luck-666/xcodebuild.sh.git 如果好用記得給star，謝謝！
如腳本打包執行遇到問題可留言溝通!