按梁士兴的说法，他们在设计统一开发范式的时候就设定了目标，他们希望对高级工程师的依赖能够降低，以及开发效率能够得到提升，提升的逻辑在于代码可以复用。对此他给出了以下案例：将2014年7月、2016年12月以及2017年夏天开发独立APP时做的需求进行对比，前两者比较，发现2016年效率提升了33%，而2017年独立APP只用了2倍的人力实现了8倍工作量，效率提升了400%，这种提升是非常值得开发人员自豪的。同时他们团队参与这些项目的高级工程师的比例也在持续降低，到最后做独立APP时，一个高工带着一群小弟就能把事情搞定了。
想实现统一开发范式也会存在一些困难，这里的困难和上文是一样的，主要有两点，第一，整体重构一遍成本极高，第二，业务永远不会等着技术，所以开发的同时要进行重构。他们只对新需求涉及的页面进行重构，客户端的代码总是很快地迭代到，借着产品迭代这样的时机把对应的架构重构做完。
做到这个程度，梁士兴认为他们已经进入了相对理想的状态，但有些事情是不受他们控制的。由于公司战略的原因，美团和点评进行了合并，众所周知，这两家公司一直以来是独立运营的，各自都有不一样的积累，合并会带来大量的不统一：两边的APP技术栈不统一，后端服务不统一，交互样式也不统一。对产品经理来说相当于多了一个APP，再加上大量的基础设施不统一，想把某功能整体从美团迁移到点评，这几乎比登天还难。但是技术人员就是解决问题的，所以针对这三个不统一，他们做了两层抽象。
首先，针对基础服务层的差异，他们做了一层抽象接口，这个接口不做具体功能的实现，它的具体实现是由两个平台真正的基础设施来实施的。第二个方案是针对差异进行了设计，在一套代码仓库里利用构建过程，把一些差异化的地方让它产生不同的构建产物。
通过这样的方式，可以在APP里写不一样的代码，同时去支持美团和点评两个APP的业务开发，这套方案其实是一个通用的方案，它并不仅限于对这两个APP的支持。美团在开发独立APP的时候，也是直接利用这样一套模式，就把美团的东西复用到美团独立的APP中，在三端之间实现了代码复用，而且这套模式本身对自动化测试也是极好的，可以直接利用二进制构建的结果接入到自动化测试的工程，这样自动化测试的构建效率是非常高的。
解决了多应用复用的问题，带来的收益更加明显。统一架构优化之后迁移成本整体控制在30%以下，其实平均是低于20%的，在这个阶段下，美团多应用同时支持需求迭代的情况就变得可行了，而且是一个常态化的过程，代码复用率也从一开始不复用，到后面整体复用率在95%以上。
5 自动化阶段
经过了这样几轮架构方面的迭代，还有没有办法进一步提升研发效率呢？在这里，美团用了一个方法论：既然已经实现了标准化，是否可以进行自动化了呢？因为有了自动化的工具做保障，反过来可以促成标准化的达成，杀掉非标准化的行为。
那我们应该针对什么事情做自动化？梁士兴表示，根据一个迭代周期的各个环节的实际人力投入，可以发现测试的成本很高，测试和开发的时间比例是4：5，同时把测试和开发的若干个环节再去做拆解，会发现测试里面有一个很可怕的东西叫做回归测试，占的比重非常大，而且回归测试还有一个特点：回归测试的规模只与APP的规模有关，并不与迭代的新功能有关，这也是一件很可怕的事情。某个版本做了很小的需求想快速上线，同时还要为了保证线上的质量进行完整的回归，回归的规模并不因为需求小而变小，应该优化回归测试的过程，从这个角度上来说，自动化测试就是解决回归测试最有效的手段。
从开发阶段上来讲，美团在这几个环节中的投入基本相当，他们希望通过代码脚手架的方式减少开发阶段的成本，如涉及网络的开发与后端进行API联调的工作，如果使用联合脚手架的话就会变得非常轻松。
如何进行自动化测试？
在自动化测试上，美团的思路是从业务特点出发，对美团的业务形态进行了分析，他们发现几乎所有业务线都可以落到一个套路中来：首先业务有它的入口，通过入口可以进入到业务线的主流程，如列表、详情、购买、售后等。配合主流程的各个环节会有大量的信息增值服务，比如攻略、地图、相册等增值服务。
通过这样的业务流程对各个页面进行分析，可以得到一个结论：现在只有两种类型的页面，信息展示页面和交互逻辑型页面，前者占比超过了80%，如果对这类页面进行测试，只关注它的展示行为，会发现它并没有很复杂的逻辑；后者的情况正好相反，它的占比很少，但是它的交互逻辑会变得非常复杂，同时它内部的各种细节都会对质量有至关重要的影响，对它的测试要做得比较重，而且它的测试更多关注的是程序逻辑的实现。
然后再针对这些页面去做测试技术的选型，上图中的三角是通用的模型，涉及测试的各个场景，中间是分界线，分成黑盒和白盒两种方式，美团选择了靠近分界线的这一块，从UI自动化测试和集成测试里选取一个子集，一个子集是UI的截屏测试，应用在信息展示型页面，一个子集是面向UI接口应用于交互逻辑型页面。
首先是UI截屏测试方案，一份截屏测试需要参考图、实际效果图、Diff分析，还包括后端返回的数据，即数据桩，还有模拟登录层出、设置时间等，同时需要把上下文的所有信息都设置成可控的，展示结果也是可控的。
面向UI接口的集成测试模拟了视图该有的结果，可以供开发者执行测试，套用到三部曲里，第一步，设置上下文环境，设置测试数据；第二步模拟用户操作，就是用测试用例调用VM上的命令；第三步校验结果，即监测VM上的数据状态。有些测试用例数据一直在端上，我们要把最终发起的请求拦截住，在请求那一层检查，比如选择了下单信息，最终去发出请求看这些是否正确。
自动化测试的挑战
实施自动化测试也有很大的挑战，主要有两点：一是实施测试的成本，二是自动化测试的执行效率。成本方面主要体现在开发测试用例的人力投入和测试用例本身失效带来的额外成本（也可以说是维护的成本）。
在执行效率方面，前面介绍过通过复用二进制构建方式，把构建+执行时间从30分钟优化到6分钟，然后另一个是执行成功率，因为有15%的概率会失败，所以需要引入重试的机制，把失败率降低到5%以下。
自动化测试的收益
自动化测试带来的收益，首先最明显是线上质量的提升。另一个是对研发效率有很大的提升，这主要体现在对迭代频率的影响，因为一旦对应的模块实施了自动化测试，就只需要抽查2%的测试用例。
6 未来之路
对于未来，梁士兴表示他们希望把前面测试用例通过平台化的方式统一管理起来，同时会在这些场景里面对日常开发有很大的效率提升。另一个是代码脚手架，从上文迭代周期可以看到这块也是值得去做的。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
