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

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

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

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

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

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

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

  • atest 版本发布 v0.0.12 at June 19, 2023

    不错,手动点赞~

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 2023.6 at June 02, 2023

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

  • 安卓端自动化求助! at May 31, 2023

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

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

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

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

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

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

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

  • 越来越强大了,点赞!

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

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

  • 这几个工具不错,学习了

  • 个人觉得,可以用测 api 的思路来测吧。比如针对每个函数,校验入参值合法时效果是否匹配,不合法时是否可以正确抛异常。

    如果是自动化的手段,可以参考 5 楼的答案,用一些 js 框架来调用。

  • 登录页有找回密码的入口

  • 坚持不易,做 CEO 仍然心系 bug 排查定位,点赞!

  • 预计会后会有视频回放。是否有直播这个,目前在内部讨论,暂时还不确定。

  • 目前没有直播的计划哦,欢迎来现场交流学习

  • 第一次知道这么高效的管理后台界面生成工具 https://www.erupt.xyz/#!/ ,受教了。以后快速开发新程序可以用起来😉