分层测试的演进和优劣对比

服务开发架构的演进：单体架构-》SOA架构-》微服务架构

单体架构容易理解，SOA将应用程序的不同功能单元进行拆分，不同服务间通过定义好的接口和契约进行联系，使用了一个叫做ESB的总线（想象成计算机中的总线，其他部件间通信都要通过总线），ESB与某种技术栈进行了强绑定，例如J2EE。 

微服务在SOA的基础上，将服务间的通信方式改为RPC或者HTTP Rest， 各个服务可以使用不同的技术实现，每个服务可以单独部署。

 

分层测试的演化：

冰激凌测试模型

特点如下：

- 单元测试投入很少

- 较少的接口测试

- 测试主要集中在UI测试中

在这个模式中，测试介入的比较晚，大量测试需要在集成测试阶段进行（UI测试）。 以手工测试为主，测试周期比较长。 

在这个模式下做UI自动化，测试开发、维护的成本较高，但适当的自动化是必须的（回归测试）

由于测试集中在集成阶段，问题修复成本很高，而且很难覆盖代码或者接口级别的异常场景，容易造成漏测，同时修复问题时引入新问题的概率比较高

这个模型已经渐渐退出历史舞台了，但是我们正在用的就是这个模型 ^)^

 

金字塔测试模型

这个模型特点如下：

- 测试主要集中在单元测试

- 有一定的接口测试

- 很少的UI测试

大家都知道，在单元测试中发现问题的修复成本是非常低的，但是单元测试对测试人员的开发人力要求很高，同时要维护大量代码级的用例，它的维护成本往往无法被接受。 同时，对于开发人员，考虑到进度因素，也变得不可接受

 

橄榄球测试模型

它的特定如下：

- 单元测试投入较少

- 接口测试占很大的比重

- UI测试投入较少

这个模型提倡高度自动化的接口测试，对测试人员代码能力有一定的要求。 它使得测试能够尽早的介入，而无需等到集成阶段。 相对于其他2中模式，这种模式在测试成本和修复成本取得了较好的平衡，既降低了测试技术门槛，也减少了开发人员的进度压力。

 

但是，在实际项目中，特别是使用敏捷的项目中，接口变的不是那么稳定。 例如，服务开发人员定义好接口并实现它，前端人员写完页面后需要和服务进行联调，这个过程中，接口可能需要进行调整以满足前端的要求。  这样的话，测试何时接入呢？ 等联调结束进入，岂不是还在集成阶段接入吗？

大家可能会说那是你接口定义的不好，是的，确实是这样。 但在实际项目中就是这样，服务端和前端各自按照需求开发，最终联调时，接口规格不会变化，但是输入输出的数据可能发生变化。 这种变化导致一定的额外的测试开发成本。

大家有什么好建议吗？