当前位置:首页 » 网页前端 » 开发人员自动化脚本
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

开发人员自动化脚本

发布时间: 2022-11-30 02:57:40

⑴ 自动化测试脚本开发的主要步骤

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,谢谢!

如脚本打包执行遇到问题可留言沟通!