#1 楼 @gz19891020 这个是比较看团队的。不同的团队的发展方式是不同的。有些团队的方向是工程自动化 devops 方向,各个职位界限没那么清楚,崇尚极限编程,不喜欢条条框框的死规定扼杀团队的创造力,如我们团队是这样的。 有些团队的方向是流程严谨化,管理规范化,崇尚把所有事都规定一套流程进行把控,如一些传统金融公司。 我个人觉得现阶段互联网还是倾向于前者发展的
#2 楼 @Lihuazhang 可能文档都是英文的,在国内测试圈子火不起来?
#80 楼 @phicomm123 可以自己造啊。。。。或者找 DBA 把线上数据脱敏后 dump 下来。。。。
#78 楼 @phicomm123 恩,那不一定非要到线上搞数据下来。。。
#76 楼 @phicomm123 为啥要搞线上数据库。。。
#22 楼 @hustar0102 这个木有啊~ 前端的我就搞过 UI 自动化
#24 楼 @sanlengjingvv 这是我们之前在 Facebook 工作的个同事说的,据他描述,当初整个公司只有 8 个专职的 QA。他们把 CI,CD 做的非常好。 同时开发人员的 UT 也做的很好。我们公司已经停止招 QA 了,盲目的加人并不能解决问题。
#11 楼 @hu_qingen 恩恩,哪方面不清楚,我再解释解释
#10 楼 @caikaibai 恩恩 恭喜哈
#8 楼 @caikaibai 我没有在树莓派下搞过,不过我看到过很多人都分享了树莓派下的 docker 实践,你可以查查资料
#6 楼 @caikaibai 恩恩,互相交流哈,里面有个专业运维,他 docker 很厉害
#4 楼 @caikaibai 叫 QA 之道,你看看能不能搜到
#30 楼 @seveniruby 恩,有一个不足的是验证方式仍然不够智能。例如返回的 json 很大,但是只有一个字段是随机字段。 这时候应该有一个像 assertJ 的递归验证对象一样的实现。可以选择不验证某个或某几个字段。 但现在只能一个字段一个字段的验证了。 我之前是自己写了一个责任链来达到这个目的。 再配上 assertJ-db 的数据库断言,我觉得可以满足大部分的业务场景了
#24 楼 @seveniruby 这个框架的对返回的 json 的验证也挺好的。例如有如下的 json
{
"lotto":{
"lottoId":5,
"winning-numbers":[2,45,34,23,7,5,3],
"winners":[{
"winnerId":23,
"numbers":[2,45,34,23,3,5]
},{
"winnerId":54,
"numbers":[52,3,12,11,18,22]
}]
}
}
可以使用以下的验证方式:
get("/lotto").then().body("lotto.lottoId", equalTo(5));
get("/lotto").then().body("lotto.winners.winnerId", hasItems(23, 54));
理论上基层 json 应该是都可以的。我现在没有公司的电脑。我 copy 了一段 github 上的 wiki。也可以从 response 里获取 jsonpath,jsonpath 的语法也能取出字段来。
额,艾特错人了,请无视吧
除了刚毕业那会。。我是真没碰见有要做笔试题的地方。。。笔试题能考什么呢?一些算法和黑盒测试的理论方法?或者是一些语言的基本语法? 作为一个老 QA,你觉得如果你去面试,人家问你黑盒测试用例设计方法或者面向对象语言的 4 个特性这种问题。。你会不会感觉是在浪费你时间。这不是招聘一个有经验的工程师的方式。 只会让对方觉得公司招聘的职位等级太低。现在大家都很忙,没人愿意跑来浪费时间。