从来不去宣传，做的真的好，人家自然就过来找你

#30 楼 @sixleaves 额，我们并没有移动端产品，我们是 TO B 业务，给企业级用户做产品的。所以前端只有 PC 端。 我们持续集成是对整个产品做的。所以也包括 UI 自动化。

#23 楼 @tigerge000 额~ 见笑了。。。。当初确实是为了学习点 java 并发包的东西才用这种方式的。。。。

#6 楼 @cobbxia 木有~ 还是用 yarn 管理的

#1 楼 @Lihuazhang 精辟

#24 楼 @li_hugo 多谢智哥的鼓励

#90 楼 @A_tester 这种技术暂时还是比较坑的，你想用的话得等了。 暂时我们都还是写 sql 或者做数据库 diff 等方式维护测试数据。自动生成 case 首先没有业务逻辑性。bug 优先级比较低。再一个用例数量太多了。 一出 bug 好几百的失败，分析不过来。 同时运行时间也是个挑战

#87 楼 @A_tester 你说的可能是自动生成 case 的机制。有一定规则下把参数做多种组合，会生成非常多的 case。

#85 楼 @A_tester 预期结果和请求数据是没办法自动生成的。 除非你调用其他产品接口做这些

#11 楼 @safe 俺们刚毕业的时候~~ 外企很强势的~~ 外包都是抱外企大腿的~~

#10 楼 @seveniruby 现在积极的跟在开发和运维沟通。他们也有意做这些。希望今年能作出点成绩出来~~

#13 楼 @cesc 谢谢哈~~ 感觉跟拜年一样~~

#5 楼 @0x88 看来我暴露年龄了~~

#38 楼 @seveniruby 恩 ，对的，所以我说跟业务种类相关么。 不管产品架构如何，回归自动化这种一般都是搞的出来的。分层自动化在 UI 层和接口层也不难搞。 专项测试方面我不太清楚移动端怎么定义的。如果意思是更深入的测试，找出 bug 的原因等。那么是需要了解产品架构的。想自动化就需要能够操控各个组件 fake 一些状况。例如我们公司用 etcd 作为服务发现和负载均衡。那测试的时候就自己去 etcd 上 hack 一些操作。或者故意 kill 掉摸个某块的核心进程等等。不知道理解的对不对。 总的来讲，感觉只要不是产品业务上因素的制衡。总是能找到办法去自动化的。

#36 楼 @michael_wang 我们 bug 也多，但很多跟我们没啥关系。提测准入标准是跑过自动化测试。 测试失败了开发自己去修了。不需要我们 QA 管

#30 楼 @safe
#31 楼 @seveniruby
我感觉自动化做不起来跟公司大小好像没有决定性的联系。我见过一些公司，包括我现在的公司，虽然公司小，QA 人数少，例如我们只有 4 个 QA。但自动化依然有声有色的。应该是跟业务种类，公司的重视程度和 QA 人的技术水平有关系更大

啥也不说了，先点个赞

#2 楼 @Lihuazhang 额，目前还在调研中，没有实际用在公司的项目中。 之后比较一下 mesos 和 k8s，最后跟同事商量一下到底用哪种方案。 没准真正落地是很久之后的事了

#3 楼 @seveniruby 正在尝试 QA 涉足 devops 的路线是否可行，希望能以 QA 之身在公司内部打通开发 - 测试 - 运维的界限。做出更好的工程化实践。

#3 楼 @seveniruby docker 在生产环境确实不尽人意，没人用。我也只是想在公司内部看看 swarm 是否可行，之后也会去调研一下 mesos 和 k8s。 我们的产品之后要涉及到多租户，资源隔离。所以大家都在调研各种集群部署方式。 多了解一些以后测试也方便，之前跟一些人沟通，发现涉及到这些的东西都是开发和运维自测，很少有 QA 介入，都觉得 QA hold 不住，我也是有野心想搞一搞。 我们公司的情况也比较特殊。暂时没有专职的运维，但是有一票做过运维的开发。所以运维的工作都是我们平分了。 公司内的所有产品环境都是用我的那套机制去维护。所以好多东西也就逼得我去了解了。另外对 devops 的东西非常感兴趣，有意思往这方面发展一下，所以最近也是积极的学习一些运维的知识。

加油吧。我们都是在不停的踩坑中成长起来的

思寒又要删好多帖子了

#5 楼 @sakura 这个我没有碰到过啊~~

人往高处走，水往低处流. 多往上面看看就好了。

#12 楼 @595233872 其实也不是我写的。 我们的开发写了个 config server。我们的配置都动态的去读