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

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

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

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 文件插桩后每个桩有没有跑到的标记。如果类的内容有修改，插桩就会发生变化，变化后这些标记和桩的位置就对不上了，只能认定为无效。此时需要基于更新后的类重新进行操作，生成基于新的类的桩的覆盖率数据才可以。

可以找领导要更有挑战性的任务，或者直接换工作。

总是工作压力小，长期很容易变成温水煮青蛙。做点有挑战的事情，成长才快。

客气啦。我感谢你才对，你分享的这个多配置项目类型我也没接触过，才知道还可以这么操作。

你验证确认可行后，可以也发帖分享一下呗~

其实 7 个系统不一定多，每个系统做的事情并不一定很复杂，只是按领域设计，拆分了多个服务而已。

如果每个系统都功能很复杂且频繁迭代，那测试团队也不大可能一个团队直接 hold 这么多个系统。

从理论上来说，必须得 Mock 才能真的做到独立测试。至于 mock 的维护成本，有很多方法可以优化（比如由真实服务的提供团队来维护 mock，保障和真实服务版本内容一致；系统间契约改动保持着向下兼容，这样老的 mock 可以长期复用）

不过实际工作上，如果这 7 个系统的测试团队其实是同一个，甚至是同一个人，大概率还是会直接强依赖来测试，因为要花大精力保障的，是这 7 个系统集成起来的效果。只有这 7 个系统会分给不同团队或者小组来测试时，大家才会花成本投入到各个系统的独立测试中。

至于说这种场景下，想独立测试单个系统时会受限太多，这个信息比较有限，得具体问题具体分析。比如如果只是缺数据，可以考虑通过造数据解决；如果是要求返回异常以便触发某些异常处理机制，也可以考虑针对性构建少量的 mock。

不应该呀。一般刚入职 1-2 个月，应该是处于什么东西都是新的，得要快速学习适应的压力中，怎么会这么快就觉得焦虑？

可以分享下你的期望，以及与目前现实项目的差距是什么吗？

建议直接简历先投起来吧。

大三快大四，相比自己闭门学技术，接触一个实际的测试项目，你的收获会更大。

强者越强，我觉得其实也算是一种社会规律，毕竟强者领导会更希望去解决更难的问题，然后也会进一步变得更强。

所以这块我会看得比较开。由于社会规律，各个方面永远都会有比我强的人，所以我更多会想着怎么向他们学习取经，以及复盘自己有没有可以做得更好的地方，但会注意不要单纯去比较他的成就，毕竟有很多时候成就或者说成功是不可复制的。

知足者常乐。明确自己想要什么，努力去达成自己想要的，并做好持续的积累总结，个人觉得这样生活会简单舒服一些。