先把参数节点标出来,然后用有向图连起来
然后 DFS 和 BFS 算法撸起来……然后再裁剪冗余结果
或者如果对自己的业务理解能力足够有自信,用 6 楼的法子,pairwise 也很优秀,但是涉费业务慎用,pairwise 不能保证全部覆盖到所有分支
招行那个司文吗?
还要区分历史遗留和当前版本……你这个指标是为了产品质量负责还是为了测试工程师的绩效负责?
另外,线上缺陷上报是有标准的,而且这个数量指标运维也要背,如果一个团队的目标都不一致那还不如团伙呢……
你表达的方式会让人觉得的确如此,无论对争论的哪一方看起来应该都是
我很同意你的观点,蛋糕做不大,就算做大也是短期、有限的做大,根本解决不了他们说的那个 “内卷” 的问题
原匿名吐槽帖的观点到处都是漏洞,估计孙总辩论的时候发现可攻击点实在太多,自己的观点也被带散了
在我看来,供需平衡——失衡这个轮回从来没变过,只是当前这个阶段还没有到质变或者说生产力革命的时候,那些被原帖吐槽的 “拔高了行业标准” 的人还需要继续努力,越过这个阶段就是另一番风景……那时候,TOP 将依然是 TOP,至于 BOTTOM 将来更加轻松愉悦还是落入更深的地狱就不得而知了。反正从历次工业革命的历史来看,总会有一大波人沦为牺牲品。生产力进步是必然的,幻想着公平或者靠民众/从业者的相互体谅来拖慢生产力的进步,那是绝无可能滴,上过中学的政治课就应该明白的,除非质子已经来到地球。
目前在做产品需求和部分 CRUD 工作,只不过还是过不去自己心里 “测试出身” 那道坎,所以一直有在关注质量技术相关的信息
我没准备评判哪个是对的哪个是错的,只是想知道大家到底是怎么想怎么做的,确保一下自己搜索出来的信息是准确的。
感觉楼主是个指望社会生产力不进步来保住自身利益的人,可惜历史的车轮从没停止过前进。你们在上下左右前后移的问题上争论可能说出来所有行业都要面临的现状,而且是维持了上万年从未间断过的现状……可惜我们谁都改变不了。知道改变不了就做出自己的选择就好,可以奋斗也可以佛系,不同的选择会有不同的收获,明白了就不纠结了。
注意:随便偷吃
打个招呼,说:高 P 总,我饿了,我去拿个好基友派吃没问题的吧,这个情况,我觉得再傻比的领导也不会计较这个。
我们以前零食大部分都是加班临时充饥用的……随意拿自己员工一样会说两句的,归结起来都是沟通和制度/共识问题,上升到外包内包的问题上,估计当事人火气大了,所以措辞不当,才把话说得这么难听~
偶尔漏测无所谓,经验积累,多总结复盘分析,缺陷根因分析持续做下去,还有记得主动扛锅别甩
如果同类型的问题反复出,那可以考虑转行了,别说 Testing King,就是 Testing Gold 也不好使
我觉得菊厂应该弄一些板子,低价甚至免费放送一批,像树莓派一样
可玩性搞好一点,让大家玩起来,让大家能够体验、练习,建立粘性
同一个用户在同一个帖子下,重复的确没有意义
DFS
如果配色和布局也算内容的话,那内容质量也差劲
主要还是使用的体验差,欺负我手机性能不行,卡我手机~
咸鱼是阿里旗下质量最差 app
飞书?
因为你不需要服务治理
搞算法、AI 用 python,python 在一个线程里面的运算效率是刚刚的
搞后端服务用 java,其他的都是垃圾,服务治理没有任何语言有能够匹敌 spring 全家桶的东西存在
搞中间件用 go 或者 c
至于写测试脚本……你想用 basic、pascal 都没人拦着你,反正你也不会考虑跟其他工具链集成,我就见过为了避免写 java 而放弃用 Jenkins,自己开发一套的情况,666……
测试 23 而立,24 不惑,25 知天命,26 花甲,27 古稀,28+ 耄耋
看到标题里面条件放宽,我就想进来看看是不是年龄放宽到 40 以内了,结果……
容我翻译一下可好:
头 20 年在职场努力地被资本家收割,攒了一些钱供后 20 年在资本市场被资本家收割用
另外一拨人的需求:站点的链接,可不可以不要在新标签页打开。。。
拆分 project……
GPL2.0,二次开发自用没啥问题,但是公开发布和商用就需要谨慎处理了
转载还不排版?这么懒吗~
面试官的点好像在:是不是红色的取决于什么颜色的光照在纸上。
红光照白纸、白光照红纸……或者其他混色都有可能,所以你说对就对,你说不对就不对,我没意见的,你是面试官、你是领导,你开心就好
如果你问的是已经在执行了咋办,拿提交代码是本来就不会影响当次的运行的,workspace 在 client 端只会在运行之前拉一次
如果你想要的效果是,代码提交之后,还要用上次执行之前 fetch 的代码运行,那就通过分支管理来做
Jenkins build 的时候可以加参数,你在 pipeline 或者 job 里面加个参数,指定要运行的分支,git merge 代码的时候不要删除源分支便可