恩，大型企业软件的自动化体量和复杂度都跟是很高的。 那么多优秀的工程师都选择了自己写代码来完成自动化而不是录制回放是有原因的。 其实 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 企业做做看，就会有不同的收获的

什么情况？

负责用户的模块会提供 API 对用户进行 CURD 的， 其他模块是不准许直接访问其他模块的数据库的

我们使用 mysql，一个服务一个数据库。 微服务么， 应该都这么玩把

怎么说呢， 每个人成长的方式不太一样， 也可以说每个阶段的成长方式可能都是不一样的。但是土壤这个东西是在每个阶段都需要的， 即便是大牛，也需要一个土壤来发挥自己的价值。 只是对于每个人来说，土壤是不太一样的，有的人需要好的平台好的师傅来带自己，有的人需要完善流程，架构，业务来让自己专心的攻坚技术和业务。有的人则相反需要什么都不完善的情况下，为自己争取到更多了机会，因为什么都完善了，机会就相应的变少了，所以你给他特别完善的平台他反而不开心。 所以有些时候是不是好的土壤，可能在不同的人眼里看法是不一样的。

如我来说，正因为当初没有运维和研发做 k8s 的事情， 我才争取到了这个机会，虽然我之前没玩过 k8s，但是从 0 开始自学我坚持下来了。 而且自己从头一步一个坑的学来的东西和在有一个完善的体制下从别人学来的东西是不一样的。 相同的还有深度学习方向的测试 owner， 也是我花了数个月的学习后才拿到了这个机会，当初只是看到 tensorflow 的一个 roudmap 我就跑去开始学习了，但是直到提测的时候我也只是能写一个简单的 DNN 而已，是又花了近一个礼拜的时间才写出来 CNN。 如果之前就有这方面成熟的测试体系和人才的话，还轮的到我么？ 如我来说，虽然当初来这的时候这里一穷二白的，没人教没人带，连 QA 也只有两个 (包括我)。但这里就是我比较好的土壤。而我也习惯了没人教没人带，靠自己学习的环境了。

在没有实际应用的前提下， 深度掌握 是不太可能的。 技术的深度取决于遇到问题的复杂度。 如果连问题都没有遇到过~~ 那就没什么深度造诣了

这个是 selenide 的方法， 就是个以 $ 命名的方法，然后用 static import 引入过来的而已

我们公司自己机房，自己搭建的服务

这是什么梗，有电影要上映还是？

我在第四范式工作， 有兴趣加我微信 ycwdaaaa

暂时没有这种强需求，但是正在调研中

个人准备加机会吧。 我当初也是没机会碰整个 CI 系统的。 但是我来公司早， 我是 28 号原来。我来的时候还没有运维呢。 然后我自己学习了一段时间以后就把活接了。 对于 QA 来说， 有些时候真的是个人努力加机遇。

就是避免环境冲突的。 有产品给客户用来演示的 demo 环境， 有给公司内部试用的环境， 有培训用的环境。 有给不同的研发团队搭建的环境。有给技术支持用来复现问题和做验证的环境。 在测试组内部也会针对不同的目的搭建不同的环境。 有做性能测试的， 有做兼容性测试的，有做功能测试的， 也有针对不同的产品版本搭建不同的环境。

加我微信，ycwdaaaa。或者 qq 号 446051551

现在大部分都是用开源的。哪有几家公司像我们一样还自研算法的。就算我司现在不也是开始集成像 tensorflow 这种来源框架来满足客户对开源算法的需求么。 针对于开源的机器学习库，他们只是给你提供一个可以训练模型的框架。远远达不到商用的程度，机器学习要商用首先要有数据闭环，为算法提供数据流，时序特征，流式计算等。有了这些能力然后才是模型训练，同时为了达到在大数据下的训练性能。才会扩展出了了类似 mllib on Hadoop， tensorflow on k8s 的各种技术站。要依托于各种分布式集群来扩展机器学习能力，然后上线之后还要保证高可用，负载均衡等等，所以各种云技术或者 open stack 也是要用到的。 这些都不是原声开源框架能做的，但都是商用机器学习场景必须要用到的。 当然如果我只是个学生在实验室搞搞实验。 随便单机跑跑怎么地都行

30 而立。爱发火算性格缺陷吧。平时其实也容易暴躁。只不过一般我都能压下去。 但是面临高压的时候就控制不住自己

我尽量多更更

其实没必要总结一个职位的技能树，因为每个行业的测试开发应用的技能是不一样的。 我们也只是总结出自己所处环境的技能树。 代表不了所有人

有一句话叫：广度是深度的副产品。 我们都为此而努力吧

主要就看你要外派去的公司是什么，项目是什么。 工作内容是什么。

恩，项目组很重要。 碰见好的项目就能学到东西。