python的我就不太熟悉了

利用testng的并发能力就可以了。 如下：

它会把不同的case分发到不同的浏览器上去

我觉得不发表意见对自己不好。 因为会太没存在感， 很难让人认可你，现在的人都喜欢能提出有价值的观点的人。 可能很多人都是没有自信吧。

其实你这样的想法是满正常的， 现在的人很多都背着房贷, 我也背着房贷， 而且因为要带孩子我媳妇辞去了工作。 所以家里只有我一个人挣钱。 年轻的时候跳跳曹来涨工资也是挺普遍的想法， 我觉得挺好的，也是挺现实的做法。 如果是为了钱跳槽，我个人觉得是无可厚非的。 只不过我到不会选择隐忍， 团队有不好的地方我就会指出来， 其实我再58的时候就是这么跟我老大闹翻后来导致离职的。 来到现在这个公司我也没改了这个脾气， 只不过这里的团队很好， 老大人也不错。 不会我因为我冒犯他就给我穿小鞋， 而我也确实比较争气， 做出了一些比较让他满意的成果，所以虽然我怼过他很多次，但是他反而更器重我了。 所以有时候我再这边还真是怼天怼地怼空气的架势，当然被怼的次数也不少。 这个看所处的团队吧和个人性格吧。我们这边是非常喜欢能提出自己意见的人，并且愿意给他们机会是实践自己的想法。

其实我没觉得他们浮躁， 他们走我也觉得也没啥问题，我们团队里也确实在那个时期出现了这样那样的问题，这些问题本身可能就足够导致人选择离开。

恩，大型企业软件的自动化体量和复杂度都跟是很高的。 那么多优秀的工程师都选择了自己写代码来完成自动化而不是录制回放是有原因的。 其实ariba在06年的时候就由美国的工程师2次开发了selenium IDE来完成UI自动化，类似楼主这样的思路的，录制回放加调优， 但是一段时间以后大部分时候daily run都是一两百的失败(不稳定)，每天我们team的人都要专门去一条一条的查看是为什么失败的，但发现绝大部分失败的case都不是bug引起的，而每天我们都得用好几个人来花起码半天的时间来一个个的查看， 实在太浪费人力，后来为了维持稳定性删除了1000个左右的不稳定case，跑了一段时间后还是觉得不行。 而且录制回放生成的代码冗余度太高。有时候只是更改UI上的一个小需求，比如在访问较多的页面上加了一个小输入框。 就又是一两百case的失败，又得一个个的去改脚本，要是碰见前端重构，那就是灾难了，后来产品的前端玩起了响应式设计，后端应用了异步调用和异构的系统，一下子就更难玩了。 最后无奈之下我们放弃了这些自动化的case， 老老实实的写代码了。 诚然录制回放可以很快的堆积起大量的case数量， 像是ariba在比较短的时间内靠着录制回放让case达到了数千， 但自动化从来都是创建容易维护难。 起码以目前的自动化录制工具而言，是无法应用在大型企业级产品上的。但在移动互联网玩玩小型APP还是可以的。 很多人是没有见过这样的复杂度所以才认为录制回放可以解决一切问题，就像很多没见过TB级数据量的人很难理解使用hadoop有啥好的，我以前一个客户都会问你们这分布式计算有什么优势么， 我问你们有多少数据量， 他说一百来万左右， 我说那没啥优势了， 可能比你跑在mysql里还慢呢。 其实在自动化上国外的很多企业都是领先于国内的， 他们有大量优秀的测试工程师，甚至是有多年开发经验的工程师来写自动化工具，有些场景他们没有选择使用录制回放自然是有原因的，尤其是在TO B的外企里，有些时候再我们眼里他们使用的技术是过时老旧的， 觉得他们都是low b， 但就是这些low b搞出来的软件质量好的让咱们所有人羞愧。不是他们玩不转新技术，也不是他们故步自封。 这帮子principle员工里动辄就是麻省理工学院或者斯坦福出来的人， 没什么技术是他们学不会的，他们只是选择了更安全和更稳定的做法。 稳定性是大型TO B企业最重要的质量指标， 因为体量太大，即便是自动化测试，一个不稳定就带来很大成本。 在这里做自动化， 写那些什么登陆页面，首页等等这些基础页面的page object的人都必须起码是principle的测试开发人员。 因为这些页面太常用了，被大部分case使用。 如果不稳定会出现巨大的问题， 所以都由实力最强的人来写。 有些时候我们必须承认他人比我们优秀， 他们的做法比我们优秀， 不要以为他们都是傻子。

多谢支持~~ 这久的文章了还有人继续留言~

嗯嗯。你觉得对就行。 我们谁也说服不了谁。就此打住吧。 各自做自己觉得正确的事就好了

算了不跟你犟了，你先去大型to b企业里见见像样的UI自动化是怎么做的吧。去看看ibm，微软这些公司怎么搞的。 就是我在一家叫ariba的这种小型的to b企业里， UI自动化也不是你这么做的。等你理解了自动化是怎么回事以后再聊吧

楼主可以了解一下to b企业中动辄数百甚至数千的UI自动化的case体量下， 你这套理论还管用不管用。 UI自动化的难点从来都不在工具上。而是代码设计能力，在to b企业中，面对复杂的业务逻辑，海量的测试用例，大量的异步调用和异构系统中。 如何能使用代码把业务逻辑组织起来，稳定，高效，简洁的运行下去才是难点。 并且to b企业中产品维护多个版本。我以前的公司同时维护50个版本。 50个UI自动化的daily run，并且还要对一些重要环境进行UI自动化的巡检。 试问构建这个级别的UI自动化测试，谁敢用录制回放。 都是自己哭哈哈的写代码，一个case的不稳定都会带来巨大的人力成本。海量的case下， 如果代码设计的不好，一个需求变动对测试来说都是灾难级的影响。 大量的异步调用和异构系统。需要写代码轮询数据库，中间件，各种集群来判断任务执行状态和结果。所以楼主有机会去大的to b企业做做看，就会有不同的收获的