这种代码分享有风险吧，毕竟一般都算公司财产，不能随便公开的。一般最多就公开整个平台大概啥样 + 部分关键代码，完整代码不大可能直接给到。

如果想看完整代码，甚至直接搭建起来做二次开发，待建议上 github 或者在社区开源项目板块里找找。

https://github.com/bytedance/Fastbot_iOS/commit/cf58560f0439bb1be4759dbb031d1332d269e7b8

你用的是最新版本的代码吗？这个问题官方 22 年年底已经修了呀

没怎么用过 phpmyadmin ，不确定这个平台有没有定时备份数据库的功能。

备份数据库命令不复杂，一个 mysql 命令行命令就可以 dump 出指定数据库的所有内容到 sql 文件了，然后你可以用操作系统自带定时任务，或者 jenkins 服务之类的来让它定时执行。这里面最核心的是数据库的连接地址、账号、密码。phpmyadmin 你能连上，我理解这三个信息你应该都知道了。

具体命令你可以百度或者 google 一下，问一下 chatgpt 也可以。

保持用例独立是可以做到的，把造数据和你用例核心要测的部分分开就可以了。

首先要区分两个概念，你这里提到的其实是数据依赖，并不是用例依赖。

“2 模块需要依赖 1 模块主要流程执行成功” ，完整地说应该是 “2 模块需要依赖 1 模块主要流程执行成功后得到的数据” 。这里的数据可以通过实时调用 1 模块的主流程生成，也可以通过在数据库里捞取符合条件的数据，甚至通过定时任务提前造好数据，使用时直接获取。

所以针对长流程的业务，完善的造数据，或者说测试数据管理能力非常重要。这不仅自动化用到，对于平时的业务测试也可以起到很明显的提效效果。你可以搜一下数据工厂、造数据平台、数据银行等关键字找一下相关资料。

印象中之前陆金所也曾经在 MTSC 有分享过相关议题，你可以去看看。

不知道你说的这个结合具体是怎么结合，不过看了下 testlink 一些官方文档，升级过程有提及数据库备份，所以应该是可行的。

如果你不知道怎么弄，找个身边的开发或者运维和你一起看看？

你单独发一个贴，把你完整的启动过程和报错日志发一下吧。光靠现在的信息没法给到有效的意见。

看你学习计划已经有比较丰富的安排了，不过偏通用技能多一些。

建议你可以自己尝试整理下自己的简历，选一些公司投一下练练手，同时也在过程中调整优化下自己项目经验或者测试技能方面的内容。

理解。那就先写着，主管问起就说自己想尝试一下咯。只要不影响你本职工作，我觉得你主管不会为难你的。

建议你可以自己直接测试下？

这里绑定的值，有可能是 input 标签的，也可能是 select 标签的，要深究得看 js 代码。建议你直接测试下，看哪个有效。

fastbot 的 xcode 14 兼容问题官方已经解决了，我们内部有在用。

然后 fastmonkey 因为基于 swift ，每年 xcode 升级带来 swift 升级，会导致一堆兼容问题，处理起来太费劲，我们已经放弃。

现在随机事件型 monkey，我们是直接自己写了一个，直接调用 xctest 的 api 发滑动、点击等随机事件。

没怎么用过，目前看到的 sonic 应该算发展比较不错的一个，推荐试试。

二楼 +1，大大方方说就好。

主管说业务复杂没写只是找点理由，我觉得没有哪个主管会拒绝一个积极主动写自动化提效的人。如果真的不让你写自动化，那你准备跑路吧，做下去很难突破。

我们用 xmind 形式写用例，平台是基于滴滴开源的 agiletc 进行二次开发。

PS：自动定时备份 db 这个，弄个定时 dump 数据库 DDL+DML 的备份脚本就行了吧。担心服务器磁盘坏的话，可以传到另外的位置多存一份。

2 个小时有点夸张呀，我们以前信贷业务，流程比较长，通过调脚本也基本可以做到 1-2 分钟就造一个账号数据（按正常业务顺序调接口）。建议可以做个耗时分析，看这 2 小时时间都消耗在哪里？

然后楼上也提到了，流程多，要造的数据复杂且耗时的话，比较适合把造数据独立出来一个服务。接口测试时直接找这个造数据服务取就好。然后这个服务里面，可以根据需要的数据情况实时造，或者提前造好内部自己存下来。

极客时间测试 52 讲里也有提到类似的服务能力，有兴趣可以去看看。

楼主这个模型感觉有点过于简单了，实际项目情况会更复杂。

比如因为会议多或者人员并行任务多，导致效率低，此时加人分担一部分任务，提高关键人员的专注度，是可以提效的。
另外，系统模块或者需求拆分足够合理，情况会接近场景 3-少量沟通，此时加人也可以提效。
还有一种情况，就是人员能力问题。可能本身项目里人员能力不足导致的进度不及预期，此时如果加一个能力强的，也可以提效。

单纯堆人大部分情况确实对项目进度没有帮助，但至少增加了解决问题可以选择的方法，合理利用还是有办法提效的。

PS：如楼上所说，加人是最常见和最容易实施的解决项目进度落后的手段。在领导看来，不加人会被理解为你没有尽最大的努力，此时最合适的解决方法，还是要加人。

我倒没太多看法，最终还是看能力吧。

外包其实也有分很多种的，有的外包除了劳动合同不同外，公司内基本当普通正职用，这种情况下外包得到的能力成长和正职差距不太大。有的则纯粹人力外包，各种权限限制和区别对待，基本只能做纯执行，能力很难提升，这种确实不建议久呆。

什么程度算完成，取决于你希望接口自动化能帮你解决什么问题。

从你上面的描述看，你应该是把整体框架基本搭了起来，并且确认可以满足单接口自动化的需要，而多接口流程型自动化还没有做起来。我按照你的问题一个一个来回答吧。

以下纯个人观点，仅供参考：

1.因为没有接触大公司自动化测试系统的训练,对于自动化需要产出什么结果很懵?

一般自动化测试的目标，是可以更高效地保障某一方面的质量。常见的有确认各接口是通的且返回结果符合预期（线上巡检常用）、各接口针对不同类型入参都可以正确处理（单接口自动化常用）、主流程是通的且返回结果符合预期（多接口流程型自动化，或者 UI 自动化常用）。
能把一部分本来人要重复做的事情改为自动化，把这部分人释放出来做其它更需要人去做的事情，我觉得就是有产出了。

2.跑通接口输出结果到报表做到这一步算不算完成了?

有用例、有断言，个人觉得基本架子算是搭起来了。

3.我个人感觉这套代码能跑冒烟???

这个要看你们冒烟的定义是啥。我接触的冒烟一般定义是至少主流程可以跑通，而你这里只是各种独立的单接口调用，还不能当做冒烟吧。

4.求大佬解惑我这个产出结果算好还是很差???

个人觉得算是零的突破吧。现有成果有用，但用处不算特别大，因为用例场景比较单一，而且断言啥的做得还是比较浅。

有一些方向建议，你后续根据团队情况，选一些来持续进行：

1、新增接口的接口测试，直接通过自动化完成。这样用例的量和覆盖度会更高。
2、结合业务主流程，补充一些流程型用例，可以部分达到冒烟的效果
3、结合 CI 流程/线上发布/线上巡检，提高自动执行的频率，进而降低问题发现时效，这样效果会更明显。

重构后可读性提高不少，点个赞。

和我第一家公司时状态差不多，本质上就是现在的能力应付工作绰绰有余，工作上没有什么新的有挑战性的东西去促进自己提升。

最有效的手段是换环境，换到一个工作有挑战性的环境里，这样这种焦虑会快速得到消除。不过现在大环境下，也不大推荐直接换环境，风险比较高。

自己自学提升的话，有几个事情建议你可以做一下：

1、先弄个脑图，梳理一下自己的知识体系。明确一下自己什么地方是薄弱且心里很没底，需要巩固提升的
2、明确后，选一个你觉得最需要快速补充起来的，做起来。
3、给自己划分出一个每天固定的学习时间（半小时或一小时都行），到了这个时间就放下手机，专注学习，让身体逐渐适应形成习惯。
4、按照上面这个时间，评估一些学习的耗时，定一个阶段性的行动计划，比如 xx 月 xx 日学习到什么程度，输出什么内容。最好是每天学习完有一些文档总结或者代码输出，一到两周有一些阶段性成果，让自己持续有成就感。

最后，要给自己设一个限制，手上这个学习没达成目标前，不要轻易换方向。

这个使用率是每个 cpu 占用率的总和，会超过 100 的。想要一个不超过 100 的，需要自己除以 cpu 核数。

非常坎坷的经历，不过现在带团队 +965，应该还是挺不错的。

祝楼主未来越过越好，有好东西欢迎来社区分享交流~

想获取外部引用 jar 包的覆盖率数据并生成报告，需要满足两个要求：

1、覆盖率数据有包含这部分代码的覆盖数据。用 agent 方式进行动态插桩，作用域是 java 虚拟机内运行的所有 class，应该没有问题。但如果是编译时插桩，只有当时编译的代码有增加覆盖率的桩，那没办法。

2、生成报告时，提供的 class 文件以及 java 文件有包含对应的内容。本质上覆盖率数据（ec 文件）只带有类名、类标识（类似于 md5 的东西，用于确认覆盖率数据和 class 文件匹配得上）以及各个覆盖率桩的覆盖情况标记，需要结合 class 文件才能生成覆盖率报表，还需要进一步结合 java 文件才能出现每一行的覆盖情况数据。

这两者都具备的话，就可以得到对应的覆盖率数据了。

学习了

如果是我，我会写在同一个类，因为都是属于购物流程的用例。

不过这个没有统一标准的，主要看大家对于每个类的职责划分情况。一个用例一个类也没太大问题，而且找起来文件列表一目了然，缺点是得增加文件夹，否则都堆在一起，不大好看。而且两个用例要相互独立，也没啥可以复用的地方，所以怎么放都问题不大吧。

倒是用例里登录、添加商品、进入购物车结算三个步骤，有一定的复用性，这块要单独抽离到一个动作层，方便用例复用。

如果是公司真的想确认自己安全达到某些标准要求（如等保要求），或者真的从业务出发要保障没有明显安全漏洞，还是找专业公司做吧。

如果只是个人自己学习，可以看看白帽子之类的入个门，有个概念，也基本了解最简单的检测方法就好。
安全还是挺深的，特别如果想挖漏洞，深度要求更高。