你可以看看我之前写的文章

恩。。是的。。我们这招人的时候也有这个问题。。 我们现在也是手动，自动化，工具开发，性能测试一把抓。 全都干

其实成长有两种方式，一种是进入一个好平台，在成熟的体系下学习。这种情况下学的快，视野宽，少走弯路，干的舒服，应届生首选路线。只是体系太成熟就会变成接触的都是人家封装好的东西，很多东西不需自己考虑，时间长了容易形成被动的思维惯性，没有自己的思维和技术体系，这是被动学习的一个缺点吧，很多大厂的螺丝钉都是这么形成的，所以在中期需要强烈的自驱力或者机遇跳出这种状况，但只要跳出来了，也是前途光明的。 另一种是开荒，从 0 到 1。自己从头开始面对一切困难。这种情况下跟第一种完全相反。学的慢，视野窄，走的弯路多，干的很不舒服。是需要打从一开始就要有强烈的自驱力才能坚持下去的路线，不少人都在前期被干掉了。但是一旦坚持下来，中后期成长飞速。由于一开始就选择了 hard 模式，所以接触的广，接触的深。也很容易形成自己的思维和技术体系。

以上两种方式各有各的好处，也各有各的缺点。前者的具体经验我给不了你。当初我基础和背景都很差， 好平台不收我。 所以我走的是后者的路线。 这是一开始就选择了 hard 模式的游戏体验。 该做什么没人告诉你， 该怎么做也没人告诉你。所以最好在工作中寻找突破口。 加入什么技术能让工作做的更快更好。 不建议脱离工作去学习，学习一项技术应该有目的性，一定要是你觉得能对之后的工作有很大帮助的才去学。 如果你们测试还是手动的，那就学学 UI 自动化，接口自动化。 如果你们的环境还要靠手动搭建，那就想办法学 linux，学 shell。 如果想要更好的维护多套环境，那就学 docker。如果你们的团队越拉越大，就学学 web 和底层技术去搭建测试平台， 一点点来，随着团队和业务的发展。 技术栈也就这么积累起来了。 我就是这么走过来的。

这个我也不知道

多谢指正~

直接开迅雷下几个电影，热的比起线程快 哈哈哈哈

最近有点忙，写到一半还没发出来。 这两天我把下一篇写完就发出来哈

啊？ 难道不需要写自动化脚本么，还能闲着？赶紧补脚本啊。 没脚本也得开发工具吧

刷屏了。。。。

就是多线程，testng 里能配置的

PC 端的浏览器，BS 的，不是 CS

额，那个啥。。。我不是想泼你冷水。。。但就我所知。。。docker 是没办法制作非 linux 镜像的。。 docker on windows 我知道。。那也是在 windows 上装个虚拟机跑 linux 然后装的 docker。。。你去看看我最新写的两篇文章就知道了。。docker 容器让你看到的操作系统是假的。。他们用的都是宿主机的内核。。 所以 linux 内核怎么跑 windows 的东西呢。。。

俺们做 B 端的，不做 C 端。所以你懂的~~~

那个我可是没试过

可以啊，grid 一开始出来的时候，大家都是拿它做兼容性测试的

1. 很少有薪资大幅降低的情况，我是没碰见过。 我入行的时候甚至还给我涨工资了。 做大数据的公司不是只有大数据的，人家也是有产品的，照样有 UI，有接口。 所以主要还是看你的以前的工作经验定级
2. 我再北京所以不清楚了~

我觉得我们公司的 UI 自动化做的还是不错的， 当然了我们只有 PC 端的，用 docker 把 grid 容器化后扔到 k8s 集群里去跑。 30 个浏览器并发的话 20 分钟就跑完了。目前覆盖了大部分的分支，只有一些不适合做 UI 自动化的和边边角角的功能手动做。稳定性也不错。 一轮下来误报的在 10 个以内，版本验收的时候有好几次是 100% 全通过的。 我们也并没有花大量的时间去维护 UI 自动化的东西，当然我们 TO B 的产品迭代慢，变化不是特别快，业务也相对稳定，前端过于复杂，bug 有一半集中在前端。所以我们的自动化测试以 UI 自动化为主。这也算是一个业务优势。 我说一下做 UI 自动化要注意的几个重点。

• UI 自动化要跟 CI 走，在迭代进入联调时期 (或者是开发自测时期) 的时候监控开发分支 (注意是开发分支)，这时候不是为了找 bug，而是要及时调整脚本，应对 UI 和业务变化。 我们要在提测一开始就输出一份提测质量报告，甚至是提供一份冒烟自动化脚本给开发人员作为提测标准输出。如果在提测之后还要花大量时间修改自动化脚本的话，意义就不是很大了。
• 做 UI 自动化的人要懂设计，懂业务。 UI 自动化不是一个简单的 page object 就完事的。可以说所有自动化测试类型中 UI 自动化是最考验工程师的业务能力和代码设计能力的。根据业务的特点去设计代码结构，抽象共性，封装复用。我们不是写 demo，我们是要支持成百上千的 case，所以设计很重要。这也是为什么我觉得相比 python，java 是更适合的测试语言的原因之一。 这也是为什么我之前写的帖子里就说过设计模式很重要的原因之一。拥有良好的设计才能做到最大程度的代码复用，才不会再需求变化的时候麻爪，才不会花大量时间跑去维护测试脚本。
• 为了维护稳定性，多用自旋等待，异常捕获和重试之类的功能。有的 UI 自动化框架有这些 api，如果没有就自己封装。 不能有太多的误报率，否则又是维护梦魔

额，感谢你对我的认可。 也说声抱歉由于生娃的问题之前大数据系列文章断更了，生娃这段时间我欠了好多债，最近在努力补 docker 和 k8s 的东西。之后会慢慢的把 spark 和 yarn 这些大数据的文章也续起来。 下面我来根据你的提问一个个的说一下我的想法把。这些是我的成长路线，可能不适合大多数人。

如何增加大数据方面的经验

• 首先获得这方面的工作机会：我这个人是主张工作驱动技术成长的类型。选定一个方向，然后拼命的学习这个方向的知识，之后不管是求是骗还是去忽悠都要进入做这个方向的公司去锻炼，任何一公司都需要初级人员来打杂的，我们争的就是这个机会。技能的增长不是一厢情愿的事，我再之前写的一篇文章中写到过。 没上过战场的士兵就算在训练中再优秀也是菜鸟。我们需要真正的战场磨炼我们的技能。 所以自学到一定程度以后一定要去实际去用，如果你的公司没有这种业务环境，那么就跳槽。这时候别犹豫，你必须要有一个环境来做你想做的事情，如果这个时候拖下去，自学而来的东西会很快的被忘掉，之后你面试的时候可能什么都答不上来了。这时候争的就是一个机会，一个跑到对方公司打杂的机会。
• 然后想尽所有办法找应用场景： 当有环境以后剩下的就是自我驱动。主动去挖掘我们学到的知识的运用场景。 测试应用这边咱们确实空白很多，我几乎找不到多少可以跟我一起聊分布式计算的测试同行。 所以自己要善于发现和思考。

大数据方面的实际测试是什么样子的

• 先举个数据测试的例子，常出现在做 BI 和机器学习的公司。你可以参考我在测试大会上的演讲稿，这类型的业务每天都会有很大的数据被采集过来，我们需要测试这些数据，由于数据大，对测试速度要求高。所以也必然要使用 spark，mr，hbase 这些大数据处理框架去扫描数据。这个更详细内容你可以去看我的演讲稿。关于数据统计分析类的工作也跟这个差不多。
• 然后是造数， 大数据相关产品，尤其是 to b 业务的产品要给客户提供一个比较专业的性能测试报告。 在各种数据量，数据分布，数据类型下产品的计算性能是什么样的需要有一个量化指标。 而客户的数据是不会给你的， 所以我们要开发一个工具能够生成大数据量的，各种不同数据类型，各种不同数据分布的造数工具。 还是由于数据量大，同样需要用大数据处理技术去做。我再演讲稿里也有提到过。
• 再举一个 yarn 集群管理的例子。一切都始于我们的 UI 自动化，我们的产品是做机器学习的么，产品要把计算任务放到 hadoop 集群上运行，而集群是用 yarn 管理的。当我们 case 越来越多，我的 UI 自动化也就必须用分布式的方式来执行 (浏览器的分布式属于 docker+k8s 的范畴这里我不跟你说了，目前我们启动了 30 个浏览器)，当初我们发现在测试集群上 15 个小任务的并发能力就是极限了，多了就得排队，连 20 个浏览器的并发都支撑不起来，更不要说集群不只是给自动化测试用的，开发，产品，测试用的集群都是一个。 所以对集群的调参是必要的，只是大家都不熟悉，测试环境的事也不爱管，这事就没有人搞。所以我买了 hadoop 技术内幕中的 yarn 的那一本开始啃。之后在测试集群上各种折腾，更换公平调度器，重设 vcore，提高 AM 限制， 分队列，分用户，设定资源抢占，队列权重等等等等。 一套下来现在集群抗个百十个小任务并发是没问题的。所以这方面的工作又多了一个测试集群管理。
• 很多建立在大数据基础上的产品都跟 hadoop 深度耦合，尤其是 TO B 业务的产品，要测试到 hadoop 的各种情况。各种 hadoop 的版本与产品的兼容是不是好的 (很多客户有自己的 hadoop), 以及 hadoop 的各种配置是不是与产品兼容的。 例如我们曾经出现的问题是在 jdk1.8 下的 hadoop2.7.2 版本在我们的产品中会出现虚拟内存计算不正确的情况，而测试集群是开了虚拟内存 check 的，所以某一个算子运行失败。这是 jdk1.8 的一个 bug，需要我们在该算子的配置中增加内存参数绕过去。再比如 hadoop 集群的多租户实现，很多地方是用 yarn 的 fair 调度器或者 capacity 调度器中的 queue 的概念去做，那么产品如何跟 hadoop 的配置协调？ 假如产品提交到错的 queue 上去了？ 假如产品提交到了不存在的 queue？ 产品使用了 hadoop 不存在的 user？这些东西我们就会要测试到。 其实不仅仅是多租户，产品跟 hadoop 集群耦合的地方都要测试。因为我们是做产品，而不是自家公司自己用，任何与 hadoop 的配置冲突的地方产品都应该做出相应的处理
• 应该还有一些场景，只是我们的业务暂时没碰到，看看之后有没有同学补充一下

区别大数据测试和运维的角色

别再纠结纯运维和纯测试了，devops 流行的今天，开发，运维和测试这三个职位都互相渗透了。 互相都干了以前对方的活是很常见的。

总结

建议楼主去 TO B 的公司看看，现在做大数据的还是 TO B 的比较多。互联网里能接触到这些的公司不多。 对于投向这方面的学习我觉得也是不亏的。 不论是 BI 还是 现在非常火的人工智能。大数据都是基础。 这方面的平台和产品也越来越多。 而这些行业的测试门槛还都很高，所以如果你再这方面有经验，都不用多厉害，就可以找到一个不错的工作。

恩 那 明白

我看到了~ 感谢~~ wiki 里是什么都可以写么？ 还是必须写 docker 相关的主题？

不要在意这些细节哈哈哈

mark 一下，同样不清楚细节。 访问密集型业务的性能测试我是业余的。不过以前就听说过全链路的概念

我能干的事情，有多少人也能干，有多少能干的人跟我一样好甚至比我还好。让这些人越来越少就是提升核心竞争力的过程。

我发现了。。。。你拼错了
是 parallel

selenide 里的 remote 是这么设置的么