这个使用率是每个 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 个月，应该是处于什么东西都是新的，得要快速学习适应的压力中，怎么会这么快就觉得焦虑？

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

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

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

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

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

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

标签表达式我理解只是表明这几个节点都可以执行这个标签类型的任务而已，并不是支持同时下发多台执行。比如有 3 台机器都有 android app 打包环境，就可以标记为同一个标签，给 android app 打包这类型任务使用。

同时下发两个服务器执行，需要先想好是一样的任务多节点执行，相互校验结果；还是要把任务内容中没有相互依赖的部分拆分到多个节点，同时执行，缩短执行时间。两种是不同的 “同时下发”，而且据我了解，jenkins 应该不具备这方面能力。

个人感觉行情这个事情嘛，我们无力改变，知道一下就好了。

至于说新技术学习，chatgpt 挺好玩的呀，而且这个个人觉得比自动化啥的更有趣，想象空间也更大。

这个计算公式感觉怪怪的，不能基于请求数 +MRT，计算 TPS 吧。TPS 计算公式，我了解只有 总事务数/总时间（单位秒）这个公式。

TPS 是每秒事务完成数，在系统配置不变的情况下，当请求压力达到让各个线程达到满负荷运行时，一般是一个相对稳定的值。此时再增大压力，TPS 不变，响应时间增大，所以 TPS 其实和响应时间没什么关系。响应时间的增大背后，是系统内部处理不过来，导致新的请求得放到队列里等待，造成额外的等待时间。

而你这个计算公式里，是把响应时间纳入进去来计算 TPS 的，这个和我认知有比较大的出入。