史上最细，自动化测试框架落地-框架选型-分层设计（详细）

---

前言

1、自动化测试框架选型

其实关于测试框架选型，要考量的无非是如下几点：

个人技术基础如何，框架的学习难易曲线；
框架功能是否丰富，官方文档是否详细，框架生态是否成熟；
框架本身的扩展性如何，是否支持多语言，开源还是商业的；

如果个人技术基础比较薄弱，建议选择功能丰富开箱即用，且学习曲线比较平滑的。

有些框架入门简单，但是进阶和落地难度就会特别高；有些框架入门难度稍微高点，但整体的学习难易曲线比较平滑，适合不断打怪升级，这点需要看个人适配程度和喜好。

第二点，功能丰富意味着落地实践阶段二次开发封装的成本投入较低。详细的官方文档可以帮助新手更快的入门，且其中也会有不少的案例。

所谓的生态就是用这个框架的人多不多，用的多自然遇到的问题多，解决问题的方法也有更多人在前面趟坑。

至于第三点，就是选型后落地方面的考量。
支持多语言，意味着和研发团队的技术栈以及被测应用更为匹配；开源意味着更低的直接成本，扩展性则是是否支持团队级别的定制化选项。

2、自动化测试落地实践路径

自动化测试框架和工具都很成熟了，落地实践的案例也不少，但具体落地过程肯定会遇到各种各样的问题，解决问题的过程需要考量具体的业务特性，基础设施建设，项目迭代频次等很多因素，很难说有普适性的通用案例可以参考。

1）自动化测试是如何做的？

回答思路：从问题出发，要解决什么问题，采用了什么工具/框架，原因是什么？自动化测试的流程，重点是哪些方面，要面临哪些挑战，如何解决的，是否有更好的方式。

2）选择自研框架和开源框架？

回答思路：这个问题考察两方面，一方面是对开源/商用框架优缺点的了解程度，以及和自身团队及业务的匹配性；另一方面则是自研框架和团队及业务的是配性更强，但成本更高。

3）自动化测试主要投入和产出是什么？

回答思路：同样考察两方面，一方面是前期的产出和效果肯定是低于成本投入的，自动化需要长期持续建设且项目相对稳定，才能在大后期收益覆盖成本。

另一方面则要表达出自己对自动化测试的理解，比如自动化就是用来辅助测试，解决重复性高的执行工作，如果最开始奔着提升效率，那大概率最后会不了了之。

4）如何管理自动化测试数据？

回答思路：分阶段用不同的方法。单人或者刚开始落地，以简单易懂为主，比如Excel；规模稍微起来或者参与自动化测试工作的人多了，就要考虑配置文件或者函数生成方式；大规模覆盖阶段则要考虑造数工厂方式。

测试数据管理是自动化测试中特别重要的一环。特别是团队扩大，业务复杂度上升之后，如何高效合理管理测试数据，需要很深入的思考和大量的实践。 重要的是要有持续迭代和优化的做事方式，而不是从一开始就求大而全。

5）自动化测试如何融入CICD交付流水线？

回答思路：单纯的做自动化测试，产出和价值并不高，自动化测试如果不能持续集成，融入到持续交付流水线中，那只能说是测试用例自动化执行。更好的方式是让自动化测试成为整个研发交付流程的一部分，为研发交付提供辅助和支撑。

当然，CICD的交付流水线是整个技术团队要发力做的事情，需要解决很多前置问题，比如编码规范、代码分支命名规范、版本管理、完善监控，也需要技术团队内部各团队协同配合。

回答这个问题，可以从推动和参与CICD流水线建设来讲，解决了哪些问题，最终达成了什么效果。

6）如果让你来负责整体的质量保障工作，你会从哪些方面入手？

回答思路：这个问题看似和自动化测试没有直接关联，但实际上很考验测试工程师的全局思维和技术视野，以及对业务和技术关系的理解。

在质量保障体系中，流程建设、需求/风险/进度管理、质量门禁、团队赋能、工具提效、人员培养、知识库沉淀等多个方面都需要进行建设，自动化测试是质量门禁、工具提效辅助和团队赋能的重要抓手。

7）从零开始从零开始落地自动化测试，你会如何做？列举重要的几个方面。

前期摸底：业务情况、团队的技术基础设施、团队成员的技术能力等。
调研对比：商用&开源&自研框架的优劣势，做demo，拿到数据支撑结论，然后出落地方案。

分阶段落地：不同阶段的重点是什么，要解决什么问题，采用什么方法和手段，需要的资源和面临的挑战。

更进一步思考：能否为测试团队赋能，怎么做？能否推动整个研发交付流水线流程，有什么好的想法和思路。

3、自动化测试分层的落地前置条件

先聊聊不同的自动化测试各自的特点，再来列举它们的适用场景和前置条件。

1）UI自动化

UI自动化落地最大的挑战是需求和UI设计的频繁变化会导致大量的变更，如果需求和UI设计频繁变化，那测试框架、脚本甚至相关的测试数据都需要频繁的变更，环境和测试的维护成本大概率会高居不下，因此持续稳定的系统是UI自动化测试落地很需要的一个属性。

UI自动化落地较为适用的场景有：

稳定的系统版本迭代；
线上业务主流程巡检；

2）接口自动化

相比于UI自动化，接口自动化要解决的问题是验证数据的交互和逻辑的正确性，此时要考验的则是系统设计和研发编码规范。

因此接口自动化落地的前提或者说适用的场景有：

较为清晰的系统架构设计(单体架构或交互与逻辑分不清的系统，梳理逻辑就需要花费很多精力)；
有一定的研发规范且执行的比较好(如果接口命名和变更无法及时同步，同样需要投入很多精力去检查)；

环境的稳定性和相关的基础技术设施建设是前提条件；

3）单元自动化

单元测试要检查的对象一般是代码中的类、方法甚至某一个函数，一个系统或者服务本身就是由很多这种细小单元构成。因此要落地单元自动化测试，有几个前置条件：

对业务需求很熟悉(如果不熟悉业务和需求细节，单元测试就无从谈起)；
具备一定的技术底子(主要指编码能力，或者最起码的代码走读能力以及对技术方案的了解)；

迭代内有一定的时间来设计单元测试case(单元测试相对来说是更底层更细致的活儿，需要在每次变更迭代中一边实现业务代码一边实现测试代码)；

团队规模和上级支持是很重要的隐藏条件(如果是小团队且迭代较快，资源的投入势必会少很多，且如果没有上级支持，单元测试的落地大概率没有足够的时间证明其价值)；

接口自动化测试方向：Python+requests+pytest+yaml+alluer+Jenkins；
web自动化测试方向：Python+selenium4+pytest+POM+allure+Jenkins；
app自动化测试方向：Python+appium+POM+pytest+allure+Jenkins；

最全Python自动化测试进阶之路视频教学 (全集)

下面是我整理的2025年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

人生最动人的篇章，往往写在最艰难的转折之后。当你觉得力不从心时，请记住：每一个"不可能"的突破，都始于"再试一次"的勇气。你的坚持，正在为世界书写新的可能！

别让他人的质疑成为你的枷锁！你体内蕴藏着改变命运的力量，每个微小的进步都在为辉煌铺路。当别人停下脚步时，你的坚持就是最有力的回应。向前走，属于你的舞台正等待绽放！