DevOps 时代，测试、开发、运维不需要有太明显的界限了，统一称为技术研发岗

说实话，会给人一种只会点点点的感觉，欠缺一些技术性。

讲真的，我不是想跟你较真，也不是说你写的这些东西没有价值。但是如果以当前的互联网发展节奏，按照这样的学习进度，迟早是要被淘汰的。 现在测试的职业定位早已不是点点点的时代了，从点点点 -> 自动化 -> devops -> 智能化测试 -> 未来？ ，如果这几个命令要画上 21 天 *3 遍去学习，那什么时候才能搞通 jdk8、spring、es6、docker、算法等等等不计其数的新技术。

另外，IT 行业不像传统行业（工作时间越久就一定越吃香），相反，企业招人看的不仅仅是你的知识和技术储备，更看重你的成长速度是否超过你当前的工作年限应有的平均水平。

希望所有人，多一点紧迫感！

感觉有点过于基础了。老实的讲，按照这个学习进度，是跟不上时代的发展速度的。

感同深受吧。但是想给楼主说些激励的话：一切提早到来的经历，只不过是帮助你更快的成长罢了。
我 14 年 4 月硕士毕业，第一份工作在外企，工作半年，遇到大裁员。从那一刻才知道，公司永远是靠不住的，能给自己增加安全感的只有自己的实力。14 年 11 月加入网易，当时是什么都不会，遇到我人生的贵人主管，没有嫌弃地接纳了我。所幸，我可以确信地说在网易的日子没有让他失望。三年半后，因为个人发展考虑，离开了网易，入职阿里拿到了 P7。

在内网写了些文章，但是不方便公开。http://www.cnblogs.com/znicy 我博客上有一些不涉密的文章，有兴趣可以看看，不过上面没有写算法效果测试探索的内容哈

我现在也是负责广告搜索推荐领域的算法测试，以后可以多多交流下

楼主自己也说了，高覆盖率的用例。 你怎么评估你的用例是不是高覆盖率呢，是不是还要懂得怎么看覆盖率，覆盖了哪些代码，是不是代码覆盖到了就不会出问题，没覆盖到的代码为什么没覆盖到，怎么去补充用例？ 另外，楼主热衷于发现 bug，就说个仅靠页面点点点验证不到的点：比如后台的一个需求，数据优先从 db 读取，如果读取异常，则从本地磁盘读取加载进内存。 你如何去构建读取异常。另外一些数据交互的过程，中间过程很短，普通测试是很难验证的。需要测试人员手动去开启远程代码调试，打断点，然后执行点点点操作。

大师手笔

深度好文

大佬，我搜到你了，哈哈哈。好文顶！

世界杯开幕夜，不看世界杯，看飞哥。花了一个半小时仔仔细细读了几遍。对于刚从大数据测试踏入算法测试领域的人来说，受益匪浅

飞哥，不知道有没有兴趣加个微信（我的微信:wz63650406）。 关注你也比较久了，我之前一直做大数据组件方面（azkaban、spark 等）的测试，可能马上要去阿里那边做数据算法方面的测试了，有机会想跟你多交流交流。感觉很多关于测试的观点、看法跟你都非常相似。

少 HTMLTestRunner 这个包呗 pip install 下试试

期待 spark 更多文章

厉害

楼主说的这个就是分布式计算的基本思路 推荐看看 MapReduce

我们其实也是这么做的

没考虑 mapreduce 么。。

额，原来是 16 年的帖子。。

selenide，我们 2017 年初就开始用了，并进行了封装，一年下来确实还不错。我跟楼主测的项目有点类似，也是大数据相关的。另外我现在负责的就是后端组件 spark 的测试

这倒是一个很好的建议！ 我之前没有想到，基于这组基础镜像写 dockerfile

谢谢。我也知道 dockerfile 绝对是更好的方式，但是我们这种好像没办法用 dockerfile 来搞。因为没办法去制作单独的容器镜像，只能通过 ambari 界面化的 ui 部署工具，一体化地部署一堆组件，让 ambari 去处理各个组件之间的依赖关系。。。也考虑到 commit 的方式会让容器的体积越发庞大，所以我们只能基于此制定了一套镜像升级规范来约束镜像升级操作

我最近也用 docker 将我们整个大数据环境迁移到了 docker 容器里。不过我不是将每个服务制作成一个镜像，然后去用 k8s 编排。主要是因为大数据的服务组件实在太多，而大数据有自身的部署工具 ambari，我是借助了 ambari，先启用一堆基础容器（debian），利用 ambari 在这些容器内部署各个大数据组件，然后将各个容器 commit 成镜像，出来一套容器镜像套件。然后用了 Swarm 去做容器跨主机的调度，监控用的是 Rancher。这些工作都是一个人在搞，不知道飞哥能不能给我这种方式一些点评和指导。

目前整个集群也是支持多环境的并行，利用的是 swarm 的 label 来区分不同环境。各个环境利用 docker 的跨主机通信机制，搭建自己的私有 overlay 网络。

支持李赫