换个思路,自己拿树莓派控制几个无人机、气球炸弹啥的,对于本地没有事先 CI 搞通直接 push 上去的,CI 一旦跑红了,开飞机去炸丫的,然后通过度量数据公示出来……
预拦截 commint、push 只能通过项目下发本地的 hook 来实现,比较复杂,而且比较容易在本地被篡改。
你没有代码仓库权限吗?进去看一眼立刻就明白了……
可以配置多个 hook,MR 的配置 MR 的 CI 启动接口,Push 的(可以指定分支)URL 配置 Push 对应的 CI 启动接口
恒温大佬是个文艺青年,不过我还是比较愁……
这样一级一级的就到义务的某家小作坊,比方是个 500 万的螺丝钉的单子。小作坊是又开心又惆,开心的是有单子了,惆的是没有那么多钱去买螺丝钉的原材料啊。
面试题:请问这句话里面有几个错别字
另外,一楼说的那 4 条是真的,你要尽量托关系打听清楚,切不可草率
平台应该具备的最基本能力之一:在既定兼容范围内的框架下,手写的脚本,可以随意接入平台管理,这样就可以统一方便地场景组合、管理数据、调度任务,等等等等~~~
那种单纯做成在线写脚本的测试平台,想想就垃圾~
我之前装 tuleap 也花了一周……各种依赖是真心恶心,关键服务器还连不上外网,逐个手工下载上传上去,后来完成发现 bitnami 上有完整的一键安装包,深感幸福 & 沙雕~
拼写错误啊哥,是 fudax/vue-mindeditor
apollo 实在太重太繁琐了,nacos 开箱即用很方便,不过有一个缺点,那就是它是阿里开源
用配置中心的好处是可以把自动化测试接入到 CI/CD 的 pipeline 里面,一组配置端到端管到底,而不是中间断一下
对框架的应用很合理,对注解的使用也很 6
如果不嫌烦,上一套 nacos 来切分管理环境配置也不错
1MB 以下的图片对比,也就几十到几百 ms,很快的
import javax.imageio.ImageIO;
import java.awt.image.BufferedImage;
import java.awt.image.DataBuffer;
import java.io.File;
public class ImageUtils {
public static boolean sameImage(File fileA, File fileB) {
try {
BufferedImage bufferedImageA = ImageIO.read(fileA);
DataBuffer dataBufferA = bufferedImageA.getData().getDataBuffer();
int sizeA = dataBufferA.getSize();
BufferedImage bufferedImageB = ImageIO.read(fileB);
DataBuffer dataBufferB = bufferedImageB.getData().getDataBuffer();
int sizeB = dataBufferB.getSize();
if (sizeA != sizeB) {
return false;
}
for (int i = 0; i < sizeA; i++) {
if (dataBufferA.getElem(i) != dataBufferB.getElem(i)) {
return false;
}
}
return true;
} catch (Exception e) {
System.out.println("Failed to compare image files ...");
return false;
}
}
public static float compareImage(File fileA, File fileB) {
try {
BufferedImage bufferedImageA = ImageIO.read(fileA);
DataBuffer dataBufferA = bufferedImageA.getData().getDataBuffer();
int sizeA = dataBufferA.getSize();
BufferedImage bufferedImageB = ImageIO.read(fileB);
DataBuffer dataBufferB = bufferedImageB.getData().getDataBuffer();
int sizeB = dataBufferB.getSize();
int count = 0;
if (sizeA != sizeB) {
return 0;
}
for (int i = 0; i < sizeA; i++) {
if (dataBufferA.getElem(i) == dataBufferB.getElem(i)) {
count = count + 1;
}
}
return (count * 100) / sizeA;
} catch (Exception e) {
System.out.println("Failed to compare image files ...");
return 0;
}
}
}
我劝你耗子尾汁
我虽然老但不是大佬
没有鉴别照搬也是能力问题
我们说的潜在前提是选好了自己想要的却没法落地,这也是能力问题,基本上都不是技术水平问题,大多是吹水、忽悠、推动、向上管理能力不足导致的,很多人都遇到过这个阶段,没所谓,这是必经之路,躲不掉的,看到技术好就一门心思去搞那是不行的……我到现在就没碰过流量回放、混沌、k8s(用而不专)这些,学不过来也用不到啊
人家说 能力 不够,你非要扯 技术 不够,强行加戏吗
在我看来,去参加分享,无论听到什么,只要是自己不知道的,没实践过的,无论人家讲的对不对、虚不虚,能把人家的思路理解了,并且自己去实践一把,总会有收获的,楼主可能只是没理解人家的路和痛点而已
再说一个这么大的会搞成自动化测试基础培训,分享一些框架代码就完事了……你愿意买票吗~
瞧你这吐槽的劲头……我到现在还是可以下载~
如果不离职:帮所有人擦屁股,把所有脚本统一规范化,测试流程整理明白,然后大概率转正并且管理团队,高福利;
有一说一,有些 XDJM 听了可能会很不舒服:国企给一个大专转内且转管理的机会吗?即便是二线城市,这种希望也是极其渺茫的~
暂时还没找到可替代之人?
找到了将会是啥境遇?
先把参数节点标出来,然后用有向图连起来
然后 DFS 和 BFS 算法撸起来……然后再裁剪冗余结果
或者如果对自己的业务理解能力足够有自信,用 6 楼的法子,pairwise 也很优秀,但是涉费业务慎用,pairwise 不能保证全部覆盖到所有分支
招行那个司文吗?
还要区分历史遗留和当前版本……你这个指标是为了产品质量负责还是为了测试工程师的绩效负责?
另外,线上缺陷上报是有标准的,而且这个数量指标运维也要背,如果一个团队的目标都不一致那还不如团伙呢……