勇敢的人先享受世界，加油

在国企本职工作能完成即可，主要在其他的活动比赛表现自己，否者就躺平好了

你需求中并发数 10 是怎么来的？我觉得你可以提供你们的数据场景给第三方，让他们给出执行方案。不然拍脑袋的指标测了意义也不大

手机市场尾部应该没有这么大，TOP51 还能占 1%。如果只是从这个角度考虑，可以分析下数据先，再考虑有没有必要为这些尾部数据付出这么高的成本。

10 公里跟半马还是有差距，楼主继续加油

几 M 的数据不算大吧，尤其现在动不动几 B、T 的数据量。你这是有什么存储或者传阅的具体困难吗

生产造数？还是领导的要求？没问题就是领导有魄力，出了问题就是你执行不力。

优化下报告样式 再加个钉钉/企微推送，提升自动化的档次

羽毛球爱好者，每周 2 场，压力、不爽全都一扫而空

现在哪有资格谈兴不兴趣，找到工作而且有前景，才是极好的

测试给开发打分，还跟绩效挂钩。。。这是什么脑袋想出来的主意

建议接 allure

永远叫不醒装睡的人

总结：多干活、少拿钱，进一步降低测试工作的价值

感谢楼主详细的回复，我也实战一下，多谢

最近也在考虑容器环境的问题，请教楼主几个问题：
1、被测服务部署在容器中，jacoco 监听的 port 是否要对外映射
2、被测服务部署容器 ip 重启部署后有可能会变，如何解决
3、编译部署与覆盖率获取时点不一致造成的代码差异，会有影响吗

我也是 Jenkins 配置的 allure 报告，正常生成的。楼主的情况应该不是 Jenkins 的问题，可以先手动 generate 试一下。

机会肯定是好的，看你有没有勇气走出舒适区，迎接挑战，患得患失是最大的阻碍。选择这个机会可能后悔 3、5 年，如果失去了这个机会，是不是会后悔 30、50 年。

点都很真实，解决方案也给的很靠谱，但有些问题还是无解。比如现在公司效益不好，研发都是以产品为导向。项目立项的时候就已经确定了上线的 deadline，过程中需求延期、开发延期、需求变更。。。，后期测试堆人能解决上线时间问题，但质量就堪忧了

“当前平台属于代码托管形式，在每次运行时会拉起一个 docker init 所有相关依赖后 再运行自动化脚本”
对于这个问题，是否可以拆成 2 步走：
step1：构建一个框架/平台级的基础镜像 image_base，包含所有基础依赖
step2：运行任务时基于用例 +image_base 构建可执行镜像

深有体会，目前的产品搞不清需求，只是个业务人员的传话筒，每次需求评审的时候就擅自定了上线日期。在开发测试阶段不停的修改需求，上线时间还不能变，头疼

祝好，努力做出改变的人，值得被命运奖励

我们接口自动化也是利用 swagger 获取接口信息、参数信息，然后根据参数必填和类型填写随机值。这样做的目的不是用来冒烟的，而是为后续编写自动化用例提供参考，不过效果也不是太明显。想要直接生成可用的冒烟用例太难了，目前还没有好的方案

有机会还是要走管理的路，在底层永远是被动的，可以舍弃的。还有任何技术都弥补不了的信息差，任何一点风吹草动都可能是致命性打击

产品就是业务的传话筒 + 搬运工，需求描述 20 个字，需要自己翻译成 1000 字的需求分析才能落地