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

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

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

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

其实 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 或者其衍生产品，辅助自己更好地完成工作，也是一个很不错的方向。

比较幸运，遇到这类型的人比较少。更多也就是可能看到某篇文章觉得我们可以借鉴，顺手转发分享过来，也不会指挥啥的。

反正不是直接上下级关系，倒也不用太在意这个。不过如果很明显在质疑测试的能力的话，那就把内部测试平台和以前的测试成果啥的甩他，让他先了解学习下，然后有什么质疑的点，再面对面反驳回去。

PS：建议标题改改，不要直接就用 “架构师” 这类角色名，容易误伤和造成大家对架构师的错误认知。我接触到的大部分架构师还是比较有技术范和友好的。

"超市面上现有方案一个数量级"，这个厉害。

建议可以看看 https://github.com/yanglikai0806/testool 或者 solopi 这类直接在设备上单机运行自动化的方案，只有触发和上报需要和设备，其它时候独立运行。

这个问题有点大。可能的原因很多，比如发布程序被意外中断了、资源不够了、服务器断联了、服务器配置有差异导致启动失败等，这么猜测没法接近真相。

直接去查发布日志，不是应该可以直接看出来未发布成功的原因么？

预计会放在大咖说，往届的视频回放也是放在那里。到时候会通过微信公众号等途径发出这方面的具体信息。

还有一种方法，趁这个机会把你的知识体系梳理一下，像楼上说的搞个系列来讲。

分享这个事情，一旦强制频率，确实会很难受。而且固定每个人每个月 1 次，这频率确实有点高。。。

制度无法改变，就只能适应。如果实在没啥好分享的，直接分享这个月的日常工作和背后自己的一些思路呗。

越来越强大了，点赞！

我一般关注具体实现逻辑是否有漏洞（比如写法上是否有空指针风险），是否和测试对需求的理解一致。

说实话能提出问题或者建议的情况不多，毕竟有信心给大家 cr 的开发，基本代码也不会太差。更多是通过了解代码实际逻辑，帮助自己补充一些需求上不一定能体现，但技术实现上会存在的异常场景用例，以及提高自己的一些代码知识水平。