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 文件才能出现每一行的覆盖情况数据。

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

学习了

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

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

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

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

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

chatgpt 的回答：

这个报错通常出现在切换到 Webview 后的 Appium 测试中。它意味着 Chromedriver 无法创建会话。有几个可能的原因和解决方法：


Chromedriver 版本不兼容：确保你使用的 Chromedriver 版本与你的 Chrome 浏览器版本匹配。可以尝试升级或降级 Chromedriver 来解决版本不兼容的问题。



Chromedriver 未正确配置：在切换到 Webview 前，确认已正确设置 Chromedriver 的路径。你可以通过设置环境变量 PATH 来指向正确的 Chromedriver 所在文件夹。



Webview 未准备就绪：有时候在切换到 Webview 前，需要等待一段时间，直到 Webview 完全加载并准备好。你可以增加一个等待步骤，确保 Webview 完全加载后再切换。



设备不支持：某些设备可能不支持使用 Chromedriver 进行 Webview 测试。你可以尝试使用其他的 Driver 来处理 Webview，如 Selendroid 或 UiAutomator。



希望以上解决方法能帮助到你！如果问题仍然存在，请提供更多的细节，以便我给出更具体的建议。

基于个人经验补充 1 个检查点：

android 很多应用用的不是系统 webview ，而是自定义内核的 webview（如腾讯 x5 内核，uc 的内核等）。这些 webview 不一定有开放外部接入的 debug 入口，也不一定兼容 chromedriver。如果是自家应用，建议和开发确认下这方面信息。

赞同。

对于单接口来说，tps 可以用来表示系统最大处理能力的指标。当 tps 已经达到系统极限后，增大压力只会引起内部请求排队等待，进而增大响应时间，系统性能并没有什么变化。

这种是一本正经地胡说八道的答案，可以用下面两个点推敲下：

1、没有用上 3500 个请求这个条件，公式考虑不够周全
2、MTR 已经是 200ms 了，而 TPS 是每秒处理数数，毫秒转秒应该是乘以 1000，不是除以 1000

看起来 chatgpt 对于八股文类问题很擅长，也可以作为加深自己擅长语言或者领域的基本知识的手段。

我们现在要开始做这种场景，浏览器端的录音音频需要实时发给设备，目前正在调研中。不知道你目前有没有找到相关的方案或者思路，可以一起交流下？

chatgpt 的回答：

作为公司内部的应答类 AI，您可以从以下几个方面入手测试和调试：

功能测试：主要关注您的 AI 是否能够正确地回应用户的提问或需求。测试时可以模拟常见的使用场景或者构建各种测试案例，确保 AI 能够正常工作并给出准确的答复。

语义理解和意图识别：测试您的 AI 在理解用户输入时的准确性。验证 AI 是否能够正确地理解用户的意图，并能准确地识别关键信息。

对话流程测试：测试 AI 在长对话或多轮对话中的表现。您可以构建一系列连续的问题和答案，验证 AI 的对话流程是否顺畅，是否能够正确地记住上下文，以及能否提供一致性的回应。

异常情况处理：测试边缘情况和异常输入。例如，模拟用户提供错误、模糊或不完整的信息时，AI 是否能够给出合理的提示或处理方式。

性能和稳定性测试：测试您的 AI 在高并发、大数据量或长时间运行时的性能和稳定性。确保 AI 能够在繁忙的环境中稳定运行，并能够快速响应用户的查询。

此外，您还可以根据具体需求和使用场景，考虑测试可用性、安全性、多语言支持、声音合成/识别等方面。总之，全面的测试能够帮助您发现和修复潜在问题，提升应答类 AI 的质量和用户体验。

这个问题有点大，而且你在里面没提到过自己做过什么尝试，有点伸手直接拿答案的感觉。我基于自己知道的，尽量快问快答一下吧。

想了解大家做自动化测试的技术选型，能顺便讲讲各种框架有哪些优点，解决问题时有哪些方便的轮子也很好。

java 的可以看看 rest-assured ，或者 okhttp；python 的可以看 httprunner

所以有任何能帮助我了解学习客户端测试，服务端测试的经验，历史上的帖子，github 上的项目，书目希望能给我推荐一下

服务端测试可以看看社区出过的一个接口测试白皮书；客户端测试范围很大，建议你找个培训课程的大纲先了解下具体的一些方向，然后再一个一个方向去找对应的帖子、项目啥的。社区有搜索功能的。

PS：你说的这些整理后的知识，刚好也是 chatgpt 擅长的点。建议你可以找 chatgpt 问一问，得到的回答可能更好。

可以做做副业，自己给自己找事情做；或者多花点时间去照顾家庭。

反正有时间，是用来刷视频划水，还是拿来研究 chatgpt，都是可以自己选择的。

楼上正解。

jacoco 的报告生成主要基于覆盖率数据（dump 出来的 exec 文件）、class 文件及 java 文件。其中覆盖率数据是可以通过调用 jacoco agent 的接口来获取的。

所以这块的设计要把覆盖率数据的获取，和报告的生成进行抽离。覆盖率数据获取用一个定时任务之类的来做，定时获取或者主动上报。报告生成时则把指定时间内获取到的覆盖率数据进行合并，再结合 class 和 Java 文件进行生成。

至于楼上提到的类覆盖有修改，据我了解，jacoco 内部是会自动识别到类有变化，进而认为这段覆盖率数据无效，不标记到类中的。
因为覆盖率数据本质上就是 class 文件插桩后每个桩有没有跑到的标记。如果类的内容有修改，插桩就会发生变化，变化后这些标记和桩的位置就对不上了，只能认定为无效。此时需要基于更新后的类重新进行操作，生成基于新的类的桩的覆盖率数据才可以。