可以啊，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 是这么设置的么

你这配置的就是顺序执行啊， 不是并发。 一个 test 一个线程，你那 3 个 test 里没 case 吧

而且 testng 的配置文件要这么写

这两个参数都设置为 5 了么？

你去 hub 上看一下是不是有 5 个浏览器准备着

我已经不用 qq 了~~ 加我微信吧，微信还偶尔上一下。 我再社区的用户名就是我微信号

你是说进场 crash 的问题么？ 如果是这个问题确实是要在 docker-compose 里设置一下。下面是我之前写的 docker-compose，好久没用了，你可以试试。 主要是就是多个 node 和浏览器一起跑的时候内存利用不当的问题。 挂载并共享宿主机的/dev/shm 能有效解决这个问题

这个容器用的镜像不还是原生的么。 不是你做的那个 chinese 的。

有点乱，你到底连的哪个容器？

顺便一提， 启动的时候千万别忘了设置环境变量来控制 hub 和 node 的参数。 尤其是要挂载/dev/shm。 否则会 crash 到你怀疑人生的。 如下：

自己写一个 dockerfile， 继承它的镜像，然后安装字体就行了。 我是这么写的：

1. 你连接的 5903 好像不是你设置了字体的那个镜像把。还是原生的那个。
2. 连接不上的问题，先用 netstate 查看一下容器是否开启了 5900 端口， 再去宿主机看看 iptables 的规则，NAT 那张表里是不是已经做了 5900 的地址转换了。

首先是目的，你们公司要数据做什么？ 有什么业务需要？是提供数据分析给客户做 BI， 还是采集日志做行为分析和监控，还是需要业务数据用来给机器学习建模。 这个要搞清楚。 如果根本没有业务需要，那就没必要研究这些了。 知道了目的，你自然也就知道怎么去采集，分析，测试了

你这是网管大法，直接重启。 好歹贴个 docker 的 log，分析一下到底是什么错误。

1. 胖子不是一口吃出来的， 接口按优先级，慢慢加测试就行了。
2. 其实大部分业务情况并不是接口依赖，而是数据依赖。 接口依赖指的是接口内部会调用另外一个接口。 这种情况是很少见的，从设计上将对外暴露的接口很少会这么干。 你的情况应该是想要测试这个接口，就需要调用另几个接口来创建需要的测试数据。 例如想测试查看订单，就需要先调用创建订单的接口。 所以实际上，应该是这种数据依赖的场景比较多。 这种情况解决方法挺多的， 产品逻辑简单的可以直接在数据库中插入数据的方式做，前提是你对你们的数据库设计很了解。 产品逻辑复杂的数据库表关系就很难梳理出来了。 这时候可以在所有测试运行前实现创造好一批数据，所有 case 来用就可以了。 当然了每个 case 执行后要把数据恢复过来， 这方面我是通过 java 的 assertJ 写了个数据恢复的工具。 python 的我暂时没找到什么方法做这个事。
3. 没文档可以直接看代码，或者在浏览器抓包，根据对业务的理解一般是可以写用例的。

你好歹给点文字啊。