为什么自动化测试要分层

前段时间写过一篇文章:《聊聊自动化测试的分层实践》。文中介绍了分层自动化测试的出发点，每个层级开展自动化测试的前置条件以及落地的注意事项，这些内容都偏向方法和实践。业内无论是技术大会还是各种技术课程，大多讲述的也是分层自动化测试的优势以及最佳实践，但很少看到为什么要开展分层自动化测试的文章或内容。

前几天知识星球有同学问了一个关于自动化测试的技术问题，然后沿着这个问题大家拓展性聊了很多，有技术实践也有方法论，最后聊到测试分层和自动化测试方案的抽象设计，出现了一些歧义。鉴于一两句也无法表述清楚我个人对自动化测试的理解，索性写篇文章，聊聊我对于自动化测试的理解，以及为什么要开展分层的思考。

软件测试的最终目的

计算机或者软件工程专业的同学，大学里主要课程内容为编程语言、编译原理、操作系统、计算机网络、数据库原理、数据结构和算法、软件工程、系统分析和设计。其中：

• 软件工程+系统分析和设计作为顶层方法，指导我们开展软件设计和研发，实现一个可用的软件系统；

• 操作系统+计算机网络+数据库原理作为基础知识，让我们明白软件系统运行的基础环境和数据交互逻辑；

• 编程语言+编译原理+数据结构与算法则是作为实践手段，帮助我们理解如何从零到一的实现一个软件系统；

从软件工程的角度来说，其作为顶层的指导方法，核心就是聚焦于软件质量不可控，利用工程化的方法去规范软件开发，让软件开发项目可以按时保质完成的同时且成本可控。

由于设计(需求阶段)、编码(开发阶段)都可能存在遗漏或意料之外的影响软件质量的因素，因此才有了软件测试这一环节。由于软件测试这一环节的出现，后面才有了软件测试的工作内容和对应的岗位，即软件测试工程师。

那么测试的最终目的是什么呢？就是通过种种方法和手段来验证编码实现的软件系统符合预期设计标准。软件产品的研发本身就是一个技术工程，从项目管理的角度出发要考虑按时交付，因此测试阶段，为了尽可能覆盖需求设计的场景，就必须考虑测试过程效率。在规定时间内有效的完成需求范围内的测试覆盖和验证，也是软件测试的核心之一。

自动化测试方法的提出和各种自动化工具的不断涌现，本身就是软件工程理念和技术实践不断完善和改进的必然结果。每一次技术改进优化，都是用更快更好的方法工具替代原有方式的过程。

软件测试的对象形态

从计算机诞生到软件系统开始参与到人类工作生活的各个方面，软件系统本身的架构也经过了多次的迭代。从最开始的单体架构，到垂直架构、分布式架构以及现在很成熟的微服务架构。软件系统架构的迭代演进，背后则是需求变得越发复杂以及需求对迭代交付速度的不断提高。

为了应对不断上涨的访问流量，系统需要具备弹性水平扩容的能力；为了应对需求对交付速度的要求，系统拆分的模块越来越多以便于各自的开发进度不受影响。因为系统的组成模块越来越多，系统的复杂度在不断提升，测试 case 的数量在不断增加；因为需求实现和交付速率要求的提高，因此测试验证的效率也需要不断提高，所以自动化测试在测试活动中的占比越来越高。

系统越来越复杂，意味着导致测试用例执行失败的因素越来越多，为了降低排查测试用例失败原因的耗时和难度，测试用例的设计应该变得越来越具体和细化，即一个测试用例只用来验证一个最小最具体的场景。

自动化测试目前大部分的执行场景依然是针对许多不同的最小最具体的业务场景，如果要验证复杂的业务场景(比如电商业务的下单场景，背后的业务逻辑涉及到库存扣减，三单匹配，购物车数据更新以及缓存数据的更新同步)，则势必会导致失败后的排查耗时和难度增加。

有过排查问题经验的同学都知道，越是复杂的系统，排查的难度和耗时往往是指数增长的。为了保障自动化测试的执行效率，降低失败后的排查根因耗时，才有了自动化测试的分层理念和实践，即测试同学很熟悉的三层模型。

自动化测试用例的设计方法

当然，单纯的测试分层并没有彻底解决问题，还需要在设计测试用例时，考虑到最小场景。即：测试用例只需要关注自己最直接的预期结果，它的下游依赖或者调用，用对应的测试用例去覆盖即可。如果是复杂的长链路业务场景自动化测试，可以通过测试用例集合的方式来开展。

我在前面的文章《自动化测试如何区分用例集合》中对测试用例集合已做过详细介绍，即只负责执行自己所需要验证模块的 case，考虑好正向逆向流程的校验点，然后调用依赖模块对应的场景和数据，双方约定好，遵循互信原则即可。设计组合测试用例集合的注意事项，主要有如下几点：

1. 业务团队按照一定的原则划分，而不是混乱；

2. 每个团队之间要明确好业务边界和职责边界；

3. 调用依赖和边界遵循统一的调用方式(如 Restful)；

4. 测试数据的存储校验建议统一维护而非各自独立；

5. 测试用例要按照不同条件做区分(类似打标签形式)；

6. 持续集成任务要按照前后依赖做好执行时序的区分；