在正式讲自动化测试之前，我们不妨来先聊聊目前测试团队一般存在的几种模式。
1.1 冰淇淋模式(ice cream cone)
这个冰淇淋模式是2012年被提出来的，从图我们可以非常明显看到，测试团队在自动化测试投入主要在GUI界面，而在集成测试和单元测试的投入则非常少，更可怕的是在图顶端还有一大堆的手工测试，相信看到这个我们的感受是一样，这个测试团队一定处于较低水平，大量的手工测试的存在，必然也就造成了这是一个难吃的冰淇淋。
出现这种情况的团队很多是因为测试团队为了尽快产出效果，获得收益就从最容易上手的用户界面测试开始。还一个原因就是团队成员自动化测试技能较弱，不得不采用更多的手工测试。
这种模式在传统软件公司非常常见，甚至会出现底下三种测试的投入几乎为零。 这是一种非常典型的依赖手工测试完成业务的测试，通过手工测试来测评产品的质量。这样系统随着时间而越来越庞大，业务逻辑越来越复杂，代码耦合性越来越高，系统公共部分越来越多，最后可能出现牵一发而动全身，到那时测试工作就变得极其困难。经常遇到A功能之前测试是正常，等发布几个周期后，因为测试时间紧，就没有再去回归A功能，结果上线后往往A功能就处于一个不可工作状态。
1.2 金字塔模式
这是现在非常流行的一种自动化测试分层理念，这个是由Mike Cohn提出的，所以这个模型其实也是敏捷测试模型。 这个模型上，我们看一看到金字塔的底部是 Unit 而且占了绝大多数位置，中间这层是 Service 有时我们也叫接口层API层，而金字塔的顶部是 UI 层，占有空间最小 。
这个自动化测试金字塔提出后，几乎被奉为主旨，甚至一度出现配合敏捷转型，很多公司出现拆撤独立的测试部分，将测试人员大散并入到各个Scrum 团队的风潮。当然其实现实中真正长期执行这种模型的团队很少，因为难度非常大。
为啥呢？
我们再看看这个图，图中自动化测试中 Unit 的自动化占比非常大，大概在80% ， Service 占比大概10% ~ 15% ，而最顶端的 UI 自动化占比最少，大概 1% ~ 5%。1% ~ 5% 其实也基本跟我们编写 TestCase 中的冒烟级别的Case数量差不多，这也就说，UI 自动化测试建议做到冒烟回归级别便可，通过UI自动化测试来保证系统不会出现大的问题。
当然从实际工作中往往我们可以把这个比例提高到10%左右，也就是UI自动化测试主要去覆盖系统的重要功能。
当然提个醒UI自动化测试，不要一味去追求覆盖率，也不要去定一些不切实际的UI自动化覆盖率。真正对覆盖率要求高的应该是 Unit层，假设真的做到了80%以上的 UnitTest 覆盖率，是不是觉得这种团队已经偏向TDD团队了。TDD团队对全员要求水平都很高，所以这也就是为啥很少团队真正执行这种模型。
1.3 另一种的金字塔模型
这个跟上面的金字塔模型没有太大的区别，随着敏捷测试的不断演进，又有个敏捷大师在金字塔上加了顶帽子 —- 探索性测试。 团队有了自动化测试，是不是手工测试团队就解散了？当然不是，还有无穷无尽的探索性测试等着你去做。
1.4 橄榄模式（不倒翁模式）
刚上说的几种模型要嘛不符合现在的敏捷团队，要嘛难度大。那从个人经验上和测试效果上看，这个橄榄模式更为推荐。
它相比冰淇淋模式它更符合现在的敏捷团队，因为他重视自动化测试。 相比金字塔模式它相对更容易实操。
再来细看这个图，图中占最大比例的是中间部分的接口API层，其次是Unit层，UI 层依旧占比最少。
为啥大力推荐多做接口自动化测试呢？
接口自动化测试与UI自动化测试或单元测试对比，有很多的优势。 单元测试通常针对代码进行测试，系统往往还处于一个还未部署状态，而接口测试则是系统部署完成后才进行的测试，另外一个接口测试TestCase往往会比一个单元测试的TestCase覆盖到的代码更多，而且接口测试通常是面向业务的测试。
这时你们可能就会问那一个UI测试的TestCase不是会覆盖更多代码，更贴近业务，更贴近用户实际操作？
这话没毛病。 但为啥图中反应出来的UI 测试占比还是最少。 原因是接口自动化测试相对UI自动化测试更加简单直接，容易见成效，执行效率也更高。而且根据经验随着自动化测试用例个数的增长，接口自动化测试整体的维护难易度会比UI自动化测试低，因为接口自动化测试更简单直接。
所以，按照以往经验看，我个人认为一个团队如果不是走TDD模式，测试还处在自动化测试的初级阶段，橄榄模式更适合这一团队。平时我也经常喜欢说：重接口，轻UI。
最后如果我们在这橄榄模型上再加一部分的手工测试或者探索性测试，那这样是不是就像一个不倒翁啦。
按照这个模式，将大部分自动化投资用于接口测试，可以获得最高的投资回报。再结合持续测试与持续集成等最佳实践，在团队中通过接口测试这一承上启下的测试类型，可以自下而上地逐步翻越过冰淇淋模式中的那堵墙。
若有收获，就点个赞吧
0 人点赞
