恭喜楼主，已经看破了本质。
其实《A Tale of Two Cities》撑死了也就 26 个字母组成的，《红楼梦》都是拿一个一个汉字套出来的，毫无新意啊，用了几百年了还是这些东西

同样的内容，换个说法，点赞过千。
《在社区和 github 看了测试平台，总结下涉及的技术栈，为想做平台的人指个路 》

1 平台技术特点：flask django，springboot，前端 vue 居多。平台实现 curd。
2 数据驱动：数据库、yml、excel、json 几种常见格式。
3 一般使用开源权限管理系统追加各自特色的功能页面。
4 平台微服务多用 spring cloud 管理。
5 集成 ui 自动化核心在找元素，双向数据绑定，虚拟的 dom。效率稳定性方面期待更好的方案提高。
6 接口自动化目前处于简单阶段，建议引入 spring 的组件测试，dao，服务层，包装起来方便黑盒操作。
7 综上说述平台任重道远如何能善加利用人工智能，大数据等技术破局！@#￥%……&（）（&……&%￥@#！

编不下去了。

我也支持楼主，不过我有另一层理解：楼主似乎在说，这些技术都不是测试的核心技术
比如你做一个接口测试平台，拿个阿猫阿狗都会的 django/flask+vue+iview 啥的，除了学会构建一个 web 的 demo 根本不构成任何能力
关键的是如何打通关键的相干性技术：如何支持多种协议、如何支持多种格式的请求报文和返回，如何构建与之匹配的多层 mock 服务，等等……
这些东西很单薄，别人写个 httpclient 你就包一层，甚至连二次封装可能都没做过，也没考虑过是否基于 rest-assured 会更合适，流于 CRUD 的确很可悲。
我在别的帖子里也提过，github 上那么多开源的 XX 平台，9 成 9 我看了代码都没有 fork 的欲望……没有经过设计，没有扩展性，看起来比我的代码还烂，既然这样，还不如自己先凑合一下
总结一下：开源 XX 平台烂大街，没有形成合力，没有技术指导，不知道黄老板的学院有没有兴趣组织整合一下，搞两个在国际上能拿得出手的框架、工具、平台~

额外回复下楼主

1 平台技术特点，千篇一律。不是 flask django 就是 springboot，前端就是 vue。核心东西无非就是 curd。
2 数据驱动千篇一律，无非就是数据库、yml、excel、json 这种格式。
3 自研的平台都是网上权限管理系统然后加几个页面拼凑而成。
4 平台微服务毫无新意，无非就是用 spring cloud 管理。

对的，一两年开发经验的开发工程师就可以搞定，这块属于通用编程技能。有人做就可以了，不需要每个测试工程师都精通。测试部门也可以招聘研发去做。因为很多测试领导的确看不清测试平台和测试核心价值的区别，导致很多人重表面、轻内功。不过我相信随着时间的发展，各家公司肯定是可以认识到问题的，做一个 sdk+ 开源数据分析平台的价值是超越自己去搞 web 开发的。所以我们学院的测试开发课程并没有把 web 开发吸纳进正式课程。而且做平台的人，如果不及时转型提升测试内功，他们自己也会遇到瓶颈，我之前已经接到好几个专门做测试平台的测试开发工程师的咨询了，我也是建议他们不要把平台开发当成自己的核心价值。

在没有 Jenkins 的时候，很多公司都在搞，Jenkins 一出大多数的自建平台就被淘汰了，同样的道理现在各家公司都在搞，无非就是还没有标准平台，如果有了标准的开源平台，各种自建平台很快就会沉寂。但是目前没有，所以也就造就了一定的商业机会，很多公司、个人在打造测试平台、做测试平台开发培训甚至为这个出书的人都有。当然这些所谓的 “开源平台”，几乎都是千篇一律的，代码烂、维护差。而且随着开源项目的流行，很多商业机构也在打着开源的旗号去赚眼球，所以也有不少项目都是假开源。

虽然列举了上诉缺点和乱象，但我仍然支持这种行为，重复造轮子还是有必要的，他的价值体现在如下几点

• 在没有合适的开源平台可以用的时候，尤其是测试需要整合测试左移、测试右移的相关数据，自己去 DIY 平台仍然是有价值的。
• 如果认真做，有机会做成统一行业的标准开源项目。就像 STF、Jenkins 一样，用的技术也是老套的，但是的确有价值。
• 专业做测试平台的商业公司以后都会死掉的，因为开源会严重的冲击这类公司，除非他们能把售卖平台的模式转型到 SAAS 服务

所以行业乱象值得吐槽，但是这是发展必经阶段，如果遇到好的开源平台，我还是建议社区收录到 TTF 进行孵化支持。我给个人的建议就是，别人折腾就让他折腾，你要预判到下一个阶段，提前布局提升自己的价值。随着测试开发的业务越来越多，很多有挑战的事情都可以搞的，让别人走走弯路也是可以的，这本身也是给你提供一个超越别人的好窗口机会。

5 集成 ui 自动化核心就是找元素，现在都双向数据绑定，虚拟的 dom。再怎么找都不能提高效率，还不稳定。
6 接口自动化毫无技术含量，spring 可以测试组件，dao，服务层。颗粒度比你细，你无非就是没界面的黑盒。
7 综上说述平台已经落伍，拿大数据，人工智能，docker，开发和运维的技术套在测试头上。

这块就有问题了，你对测试理解的还是太少，比如
虚拟 dom 如何提高可测性，有没有办法脱离已有的体系增加新的定位符，比如根据数据定位，而不是传统的定位符？不要被 webdriver 的那套标准限制你的想象力和执行力。接口自动化本来就是黑盒测试，与 ui 一样只不过是驱动业务执行的一个层面而已，组件级别、方法级别的确有更多的办法，抛开这些表象，既然这些体系都是黑盒测试，是否可以用统一的业务用例形态去描述，你的接口自动化测试用例是否可以不用写，直接利用已有的监控和建模数据生成，根据研发的行为和代码直接生成接口测试用例? 你的接口测试用例断言是否可以用更智能的验证方式，比如基于机器学习与新老版本的 diff。你是否把函数级别的入参、返回值做了存储分析建立 bug 规则档案等等，改进的方向还是很多的。

大数据、人工智能、docker 是通用知识不假，你可以理解这些都不过是类似编程语言的升级，既然有了新版本的技术，自然是想办法把技术用于生产力了，虽然用老版本也可以工作，但是新版本用起来就是生产力提升，新的生产力必然就可以淘汰落后生产力了。测试行业从人工升级到了自动化、智能化，这是一个标准的不可逆的行业演进过程，这就相当于是人类从冷兵器进入到了热兵器，为什么中国最早发明了火药，却被全世界那些后发现的民族用火药按在地上摩擦，就是因为当时的人们觉得这个东西不重要只适合用来做鞭炮。

大数据很重要，最近好多家公司都在招聘大数据测试工程师，随着 AI、大数据的崛起，很多算法会被引入，很多公司的营收，比如电商推荐广告、外卖物流的路径规划和销售数据预测，如果准确度能提高几个百分点，公司的营收就可以提高很多的，这营收随便就是百亿的规模，而大数据处理的正确性，目前为止一直是难题，所以这块是有机遇的。

人工智能也很重要，只是目前的人工智能都被用于图像识别了，导致很多人认为这玩意不就是类似鞭炮一样的小用途嘛，其实这只不过是测试圈把人工智能用错了，等正确的用途被发明后，人工智能就是大炮了。正确的人工智能用法是什么，就需要大家去探索了，至少我就发现有一类人工智能技术是可以很好的解决测试建模问题的。

再说 docker，这玩意直接推动了持续交付、devops 的进度，把原来还可以苟延残喘的瀑布流模式直接秒成渣了，因为持续集成 devops 的发展，又催生了测试开发的发展，为了流水线交付，自动化测试、测试左移、测试右移都变的更迫切，精准化测试、质量监控等体系也应运而生。而这一切加速的推手其实就源自这小小的 docker，这就是一个很典型的蝴蝶响应。2013 年的 docker 诞生，促进了持续交付与 devops 的发展，又促进了测试开发的发展，并导致了如今数十万不懂技术的测试工程师被外包、被淘汰。我最近跟拉勾合作，他们告诉我一个数据，测试行业的职位需求下降、投递不通过率在飙升，企业招聘成本也在增加。

所以很多技术的应用，不是简单的用 “把技术套在测试上” 就可以总结的，这里面的确有很大的价值，也有很大的坑。用对还是用错，还是看人。不要被错误的乱象干扰自己，从自己的公司出发，做好最务实的改进就可以。至于那些乱象，他们碰到头破血流之后，应该也能找到正确的路，磨练对他们来说也是一种好事。

总结

保持正能量，测试大有可为，从乱象中吸收好的经验，提升自己就好。