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 的，这个和我认知有比较大的出入。

不错，手动点赞~

可以同步测试这边的解决办法建议，但还是以开发为准。

我这里表达的解决问题，或者更准确说应该是推动解决问题。测试不是万能的，不可能啥问题都由测试解决，测试的核心职责也不在这。但为了让发现的问题能最终得到解决进而产生价值，测试需要去找产品、开发推动问题的解决，不能说提了问题后就不管后续结果。

结果上，肯定是需要解决问题的，只发现问题不解决，没啥意义和价值。

但解决问题是不是由测试来做，这个看情况。比如 bug 修复，开发修复效率更高，那就开发来（少量测试修复效率更高的，比如文案类的，也可以测试直接修）。

模拟测试 app 兼容是什么意思？没太明白。

给一个建议，别管他说什么，关注他做什么。做得好的学习，不好的就忽略。如果他自己找上来，确实项目需要配合的就配合，不需要的就嗯嗯推脱过去就好。

他是聪明人的话，也不会和你纠结很多，毕竟你又不是他出成绩的关键。他最后出不了成绩，也呆不久的，不用在这上面太费神，专注做好自己的事情就好，别让他占据你太多精力。

可以做一下复盘，让重复的项目测试每次都有做一些小改进，持续变好。

还可以偶尔换换测试内容，比如做一下专项测试啥的，接触点新东西。

另外，学习下怎么用 chatgpt 或者其衍生产品，辅助自己更好地完成工作，也是一个很不错的方向。