很抱歉这个系列没有保持住更新频率。不过
接口测试平台最近几天也耽搁了一小下下，明天恢复正常。
原因是最近几天在忙一个比较大的生死存亡的技术问题。
是什么呢，这里可以给大家透漏下，因公司要求，要对app端 数以千计的用例全部实行自动化运行。要支持非常不稳定的测试环境 和 各种分支环境自由选择，各个模块/服务 要像积木一样可自由组合，使用时可以直接在平台上指定/上传apk，并且执行的过程中要实现运行状态可视化，测试报告有繁有简，有word标准报告。而且要实现多台设备的并行/支持多任务的执行。还有支持埋点自动化断言等一系列需求。
我用了大概一周时间，搞定了这个平台，实现了全部功能。但是当我真正开始写用例的时候，我发现了一个致命的问题，一个让之前努力全都前功尽弃的问题：
就是用例数量实在是过大。
如果只是核心用例还好，几十条，一百条，二百条的。维护起来也没太大问题。
可当用例达到了几千条时候，我突然发现我草率了。
一个真正的 量变引起 质变的问题：
我要全部写完这上千条用例脚本需要多久？？几个月，一年？而按照我们每天都有很多迭代上线更新的现况来说，这全部用例也就是每天都会有一大堆要重新改变逻辑来维护。也就是说，我可能还没写完1/10 ，前面的用例就几乎有一大堆报废了。 按照这个速度，永远都不可能出现 全用例都准确的运行起来的时刻。甚至后期的维护成本 需要按月来计算，更严重的说，整个巨大的几万行的脚本代码 ，几乎完全失去作用。
这种情况下，ios 和android 居然还是俩套代码脚本，后期维护也要双倍成本。以我们公司目前的体量来说，这是不可能办得到的事情，尤其是当下ui自动化的不稳定背景来说，即使我的用例逻辑非常优秀非常智能，恐怕都是螳臂当车，杯水车薪。
不过我仍然没有放弃，看着身边做ios自动化的小伙已濒临跑路的状态，我也给他打了个定心丸：别说上千条用例，就是上万条，十万条，我也要有办法搞定。只不过我这个办法，恐怕会一石激起千层浪。是成是败，后果恐怕都不是我们能承受的了的。
为何这么说呢？
因为我在搞一套，可以自动把我们那上千条用例来直接执行自动化的架构。 后续成熟后，应该再也无需我去维护了，当然首次写这些脚本也完全不用我去写了，全部自动临时生成，自动维护更新。
听上去很强很可怕。没错，这个架构的链路之长，层级之深，所要消耗的资源之大，都是在警告我：
如果失败了，那么最好引咎辞职，不然也难逃被开的命运。
如果运气好成功了，那么这将会淘汰掉数以万计的ui自动化测试工程师，就算不进行推广，恐怕我司的自动化同学也会尴尬了。
不过我考虑到很多很远，人类的思想，终归不会一直浪费在搬砖重复工作的事上，你无数次的调试脚本，定位元素，find_element_by_id，在我看来都是对人类智慧的浪费，人类的智慧仅仅应该放在设计类的工作上，在测试领域来说也就是去写测试点和测试用例，而翻译成脚本写成代码定位元素维护脚本这种重复工作早晚会被电脑取代。即使我不迈出这一步，仍然挡不住历史的车轮。
然后我便开始了这个巨大架构的设计，首先是分析当前我们的自动化脚本的背景和痛点和冲突。
然后是思考成本究竟为何物，为什么会产生，中间到底浪费在哪了，要如何避免，或者说转移成本，让新的少量成本替代老旧的巨大重复成本。
然后是这个架构的分层和各个模块及技术分析，提出需求。不过其中应用的技术很多，层层相扣，任何一环如果无法攻关成功，都会前功尽弃，导致全盘失败。其中好几项技术如果要从0开始搞那需要搞很久很久，幸运的是，我自己这6年来已经全部搞定了这些关键节点的技术，比如自动维护元素定位，抓包自动，完全自动断言，11池矩阵解析法，关键字驱动，闭包动态生成临时脚本，平台搭建，python和django,自动监控，ui自动化底层原理，并发的进程线程，page-object，多人协作开发和使用设计,元素自动录入，智能匹配,复杂脚本组件化，实体解析，仿生测试法，11种黑盒用例设计，leetcode上少数能用到的算法，数据库服务器接口的链接使用技术，shell命令，adb快速操作封装，智能异步断言，用例平台破解，报告生成,python自愈算法，自动报警 等等等等( 部分技术为自创,所以换一个和我同水平的人来单枪匹马的做恐怕要多浪费大量时间成本了)。 按照目前的水平来看，应该是颤颤巍巍的差不多能打通整个设计链路了。
当然还少不了风险的预估，人员风险，排期风险，成本风险，技术风险,最终效果准确度风险等等。这些都需要进行可行性评估时候考虑。
最后就是整个架构的优点和未来预期了。
预期和优点很nice:
1 成本：随着不断的提高准确度，磨合。几千条用例都可以实现自动维护，无论是新用例变成自动化的成本，还是旧用例的自动化维护几乎都毫无成本，无需浪费精力关心 。其实也可以说，从来就没有实际的脚本保存住，更何谈维护呢？因为每次都是根据很多测试同学手写的中文用例 直接去生成自动化代码。并不会一直保存。以前的成本是线性到指数的，而这个架构的成本是常数级，并且逐渐缩小。
2 回归：这个状态可以彻底改变ui自动化的尴尬现状，从前完全回归一次需要好多人好多天，这次只需要一点点时间即可，也不浪费占用任何人力。就会变成哪怕一个小需求迭代，都可以享受到超级全面的完全回归测试。线上的bug数将几乎大大减少！
3 精力解放：功能测试同学可以把每次回归的执行时间省下来做更有意义的事，比如完善用例和测试点，自由测试，学习新技术等。自动化测试同学也可以不用在辛苦调试写千篇一律的脚本了，也不用后期好不容易维护了几十条，没几天又要重新维护这样的浪费精力事情，可以把精力省下来，去完善这个架构让其更智能更精准。
4 技术生态：很多同学的奇思妙想的技术设计往往因为没有用武之地而夭折，不过这个架构非常底层和庞大，任何新的点子几乎都能在上面找到合适的用地。而且带来的反馈也会比较大，比如流行的ai神经网络 深度学习，就可以大幅度提高精准度。它会成为很多同学晋升加薪绩效的 基石。
5 符合未来主流： 其实大家可以预见，未来几年内，自动化肯定会越来越傻瓜式的简单，我们现在写的脚本，定位元素的这些简单技术，很可能会因为开源框架的某次更新或某些新技术的出现而稀释掉。而这个架构很可能是未来的主流之一。
6 健壮：这个架构的特点就是我们的成本不会被浪费，而是会叠加，当其足够成熟的时候，或者引入ai后，自动越来越成熟的时候，它会慢慢不需要我们人类工程师的干预，各种因人员的风险就会降低，比如回归的时候不需要功能测试同学，那么即便有人请假也不会耽误排期，比如作为主要开发者的我，哪怕我就算离职了，这套架构也会自己不断的进化 ，完全不需要我本人去更新它和维护它。而不是像之前的很多自动化项目一旦主程离职，那么这套基本没人可以维护起来。
7 符合开始的预期：支持各种测试环境自选。各种模块/服务的用例组合。各用户使用。多人开发更新。各种安装包指定。设备可增删改查。http(s)的请求头/体断言。
8 项目容量小：考虑到最终支持的代码量超大，日志也超多，所以采用动态生成技术，就算上万脚本一台电脑也轻松运转
9 多端复用 ：这个比较重要，因为整个架构的底层是可拆卸的，可自由拼接其他语言/框架/ 也就是说，ios和android是公用一套用例的情况下，不必像之前那样写两套代码脚本和维护了，这个架构可以支持一切，所有端一套架构完全没问题。
10 解决用例冲突 ： 我们之前的背景是，用例中比较重要的 是核心用例，这些用例的特点是稳定，但是非常重要，数量很少。 其他用例呢，不太重要，数量极其庞大，且经常频繁的变动。 而核心用例最好通过人的肉眼确认才可以，所以其他用例最好由自动化来执行。
而自动化组的情况是，ui自动化的适用场景是，用例稳定，数量少。所以结论是自动化只能实现核心用例，所以只做来核心用例的脚本。。
这就是冲突和矛盾点。而解决这的根本办法就是这个新架构。新架构一视同仁，全部自动生成并执行。然后各组各取所需即可。
最后因为篇幅限制，没法跟大家说更多，所以再说俩个地方给大家来点遐想空间：
1：何为ui脚本的维护成本？
有俩点：一是用例逻辑变更，比如操作顺序。这部分成本新架构可以避免。二是元素定位变更，比如id name变动，这部分成本新架构更可以避免。
2 ：如何解析汉字自然语言成脚本？
试着理解一下为什么你能看懂如下这句话：
输入用名户然后点击按钮登录
你到底是怎么看懂这段话的？ 其中很多词语颠倒顺序你为什么也能看懂？ 为什么你知道点击的是登录按钮 而不是点击一下用户名输入框？其实因为人的大脑反应太快了，你一瞬间就理解来这句话，以至于完全不明白自己到底是怎么一步一步的解析并理解的，试着放慢自己的思维。然后就会知道我这套新架构当中的这里的算法到底是怎么回事了。这和我们业界已有的深度学习ai不完全相同，后者是不断的纠错调整，前者是仿生学范畴，甚至可能是真正的人工智能的路线也说不定。不过我的新架构里，是多种方法混合互补的，所以比较可靠。
最后希望小伙伴们点个赞点在看和分享，因为这篇文章很可能会成为测试领域的历史性时刻。
