#17 楼 @lingdu 都是帮运维和开发做点事，没做多深入的。

#13 楼 @xuxtc 分布式执行向来不是问题，问题是执行结束后把测试结果归集起来并生成 report

#1 楼 @jamesparagon 谢谢

#11 楼 @hu_qingen 恩恩，哪方面不清楚，我再解释解释

#10 楼 @caikaibai 恩恩 恭喜哈

#8 楼 @cobbxia 有一个队列，排队等待机器的空闲。就像是一个生产着消费者模式一样。所以多个任务是可以运行在一台机器上的。但是没办法在一台机器上同时执行

#7 楼 @lose 搞完了分享一下哈

#8 楼 @caikaibai 我没有在树莓派下搞过，不过我看到过很多人都分享了树莓派下的 docker 实践，你可以查查资料

#6 楼 @caikaibai 恩恩，互相交流哈，里面有个专业运维，他 docker 很厉害

#4 楼 @caikaibai 叫 QA 之道，你看看能不能搜到

#3 楼 @lose 你做的那个主要是解决兼容性测试么？

#1 楼 @lose 我主要的目的就是增加执行速度么。分布式中的每台机器运行的 case 都是不一样的。我做 PC 端的 web UI 自动化没办法在一台机器上起多个浏览器进行测试。以前尝试过多个浏览器并发运行会出问题。你的多进程启动多个 appium，也是在不同的手机上吧？

#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 个特性这种问题。。你会不会感觉是在浪费你时间。这不是招聘一个有经验的工程师的方式。 只会让对方觉得公司招聘的职位等级太低。现在大家都很忙，没人愿意跑来浪费时间。

#34 楼 @18663049557 https://testerhome.com/topics/4767
https://testerhome.com/topics/4784
看看这两个帖子吧

在模型生产出来之前有什么有效的测试方式呢？ 还是只看模型出来后的 AUC？ 很想知道百度的 QA 同学是怎么做的？我们目前都是自己在研究

不知道外卖的数据处理和特征工程是专门的数据科学家在做么？ 还是 RD 自己评经验？ 自学习部分又是怎么实施的？

#12 楼 @wanxi3 恩 对的

#10 楼 @wanxi3 有时候截图判断不了，避免不了去环境里看看的

#7 楼 @wanxi3 写脚本的思想，我建议还是跟着业务逻辑走。配合数据库和文件系统的检查，你也可以调用一些开发的接口来避免某些不稳定的页面的操作

#5 楼 @wanxi3 如果是单纯的空间的定位方式都不一样了，例如 xpath，id，name 这些东西都不一样了那就是很糟糕了。不过我没碰见过。 这时候需要在代码里做不同的控件定位处理。 我见过的做法是，在 page object 里定义一个控件。然后使用不同的注解 (java 特性) 定义这个控件。IE 就找 IE 的注解， chrome 就找 chrome 的

#5 楼 @wanxi3 有些地方是需要些特化的。我们之前会给 IE 做特化处理。 判断如果是 IE 浏览器，就做怎样的操作。不过这种地方不会多的。极少的部分

#3 楼 @wanxi3 你说的问题是什么问题。

#49 楼 @lingcizhisheng 新的需求是不建议立刻做自动化的，因为不稳定。 如果做了，也是你有自信能立刻应变的。例如变了某些东西你有自信在很短的时间内作出改变。 你看在需求变动的时候受影响最大的肯定是开发而不是测试。为什么开发人员能快速变化，测试人员不能呢，很多时候是因为设计问题，开发人员在写代码前都会设计很多东西来应对未来的变化。 而测试人员就我所知基本没什么设计，上来就写。 所以这就是问题所在了。