叫兽就是我了~

  • 内部公共包/二方库这些,需要使用 nexus 之类的内部 maven 仓库来管理,基础模块预先发布好,业务模块才可以编译、发布

    TO 楼主:不要妄图自动化一切,除非你们的 cmdb 做到了高度实时有效,即便是这样,也要花费很多精力:维护组件目录映射关系,通过变更文件清单找到所属组件,从 cmdb 查找、解析所涉组件所有的依赖组件……并且递归查找到 root,然后自上而下去发布基础组件,最后再发布你当前变更所涉及到的组件~

  • 首先你的登录服务必须是一个独立的仓库,或者是一个大 project 里面的一个独立的 module,以 spring 为例,可以参考https://www.cnblogs.com/toutou/p/project_module.html
    maven build 的时候可以这样做:https://www.cnblogs.com/wenbozhou123/p/7885905.html

    都是一个百度就能解决的问题

  • 我们抛开开发自己背不背锅的问题,只说测试工程师,归根结底这是个卷不卷自己的问题

    • 如果对自己、对自己的职业有所要求,那么一切 “Bug 藏的太深”、“测试环境无法复现” 的理由都不是借口,因为如果你愿意卷一下自己和自己所从事的这个职业,你一定会想到、找到办法规避这个问题,不然那些单测、静态分析、渗透攻击、埋点、监控、生产流量导入乃至混沌工程之类的解决方案要来干吗的?—— 如果愿意承认这个世界上有至少一种手段来规避这种漏测问题,那这个锅就背的心安理得了。

    • 如果说将自己和测试这个职业定义为仅仅是点一下、看一下、验一下的角色,那么遇到比较复杂难以测到的问题,出现漏测自然觉得无所谓,因为我能力有限啊,发现不了还能怎么办?要么你牛逼你来?再说你也不看看我拿几毛钱工资?凡此种种,肯定不会觉得自己应该背这个锅的。

    当然,那种用户一眼就能看出来的问题,无论你对自己是什么要求,只要没测出来,那就认了锅吧,不然就真的不要脸了。

  • 卤煮的观点高度赞同,速成也速失,或者经不起推敲、拷问,做完事情自己的能力没有得到多大提高

  • 酒吧不好,来我们玉兰四期吧,我请客😂

  • 关于功能测试人的价值 at 2021年12月07日

    好吧,实话说,我前面回复的时候说『预设了很多背景条件』,然后想说就像某些沙雕面试官的出题套路一样,结果觉得太那啥了,又憋回去了,不成想还真是……

  • 关于功能测试人的价值 at 2021年12月06日

    信用卡额度这么明显的因素不用考虑吗
    另外,也赞成拒绝这种垃圾需求,连用户场景都没交代……大约是预设了很多背景条件,但是都没说出来,觉得所有人都默认明白

  • 你发到活动区,应该就不会有人跟你较这个芝麻真了

  • 想当然了吧,工业 App 范围太大了,有些可能涉及自动控制的,不重视测试?
    反正我不信,不然每年因为这个要死多少一线工人呢

  • 记得:广度是深度的副产品,如果你觉得你自动化测试做得很好了,但是只会自动化测试等很容易被替代,说明你的深度根本不够,没找到解决问题的核心方法套路。
    举个例子:做 GUI 的自动化测试,面临分布式、兼容性问题的时候你要解决的就会有测试实验室/云测服务的构建,市面上的现有解决方案无论多优秀,在你具体的场景落地的时候都会有这样那样的问题,你要解决下去就势必需要掌握这些周遭的技能,比如自己加特性、改 BUG,了解开源协议背后的知识,学习采购和设备管理,保不准还要掌握 docker、k8s、openstf 等等之类的技能,然后保不齐又要辐射出 dockerhub、helm 等等等等……所以你所说的广度这就已经很可观了,关键是:你真的做到了追求深度了吗?

叫兽就是我了~