技术群里，有同学聊起了各自在实践自动化测试时遇到的各种问题，最典型的就是落地难度和投入产出比。毕竟在当前这个时间节点，单纯的技术实践如果不能带来实际可见的业务价值，确实很影响个人绩效和团队产出。
这篇文章，结合自己的经验，聊聊关于自动化测试的分层和落地实践场景以及前置条件。
自动化测试的分层模型
自动化测试的分层模型，测试同学都应该很熟悉了，按照分层测试理念，自动化测试的投入产出应该是一个金字塔模型。越是向下，投入/产出比就越高，但开展的难易程度/成本和技术要求就越高。如下图：
从控制质量的角度来说，单元测试自动化是最应该投入资源去提升覆盖率的。因为代码的质量风险越早发现，修复的成本越低，对最终交付质量的影响也越小。
从性价比的角度来说，接口自动化测试最应该在实际的工作实践中去推动落地。按照现在流行的前后端分离架构理念来说，接口是交互和逻辑的处理层，只要对数据的处理逻辑没问题，纯技术层面，测试效率就能得到明显的提升。
从产品和用户体验的角度来说，UI层的自动化测试也是必不可少的。必经用户的使用体验会很直接影响用户的转化留存和商业价值变现(当然这个观点对于To C业务更为适用)。
回到质量保障的初衷，影响质量的因素有成本、范围和时间。在技术落地实践过程中，技术实践固然重要，但成本和产出依然是需要抉择和平衡的。因此，根据业务场景选择合适的自动化测试方式，就很重要。
自动化测试分层的落地前置条件
先聊聊不同的自动化测试各自的特点，再来列举它们的适用场景和前置条件。
UI自动化
UI自动化落地最大的挑战是需求和UI设计的频繁变化会导致大量的变更，如果需求和UI设计频繁变化，那测试框架、脚本甚至相关的测试数据都需要频繁的变更，环境和测试的维护成本大概率会高居不下，因此持续稳定的系统是UI自动化测试落地很需要的一个属性。UI自动化落地较为适用的场景有：
稳定的系统版本迭代；
线上业务主流程巡检；
接口自动化
相比于UI自动化，接口自动化要解决的问题是验证数据的交互和逻辑的正确性，此时要考验的则是系统设计和研发编码规范。因此接口自动化落地的前提或者说适用的场景有：
较为清晰的系统架构设计(单体架构或交互与逻辑分不清的系统，梳理逻辑就需要花费很多精力)；
有一定的研发规范且执行的比较好(如果接口命名和变更无法及时同步，同样需要投入很多精力去检查)；
环境的稳定性和相关的基础技术设施建设是前提条件；
单元自动化
单元测试要检查的对象一般是代码中的类、方法甚至某一个函数，一个系统或者服务本身就是由很多这种细小单元构成。因此要落地单元自动化测试，有几个前置条件：
对业务需求很熟悉(如果不熟悉业务和需求细节，单元测试就无从谈起)；
具备一定的技术底子(主要指编码能力，或者最起码的代码走读能力以及对技术方案的了解)；
迭代内有一定的时间来设计单元测试case(单元测试相对来说是更底层更细致的活儿，需要在每次变更迭代中一边实现业务代码一边实现测试代码)；
团队规模和上级支持是很重要的隐藏条件(如果是小团队且迭代较快，资源的投入势必会少很多，且如果没有上级支持，单元测试的落地大概率没有足够的时间证明其价值)；
在当前的工作场景中，自动化测试只是质量保障的一个技术手段。是否分层，哪种测试手段投入多少资源，更多的是取决于面临什么问题，这些问题对质量的影响程度大小，然后才是根据具体的情况选择合适的测试手段去解决问题。成本、范围、时间依然是影响我们做技术选型和落地的最大影响因素。
总结：
感谢每一个认真阅读我文章的人！！！
作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。
软件测试面试文档
我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。
视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。
