目录：导读
前言
1、什么是框架
框架（framework）是一个框子------指其约束性，也是一个架子------指其支撑性。是一个基本概念上的结构，用于去解决或者处理复杂的问题。
1）框架本身一般不完整到可以解决特定问题；
2）框架天生就是为扩展而设计的；
3）框架里面可以为后续扩展的组件提供很多辅助性、支撑性的方便易用的工具，也就是说框架是配套了一些帮助解决某类问题的库（libraries）或工具（tools）。
约束性：针对解决特定问题的软件框架会首先定义问题的边界，进而将相关的软件组件约束在这个边界内，保持框架在解决问题方面上的内聚性。
支撑性：框架本身不解决什么问题，但给了解决问题的相关组件一个组合底子，这个底子的科学性和易用性直接影响在此之上进一步开发的科学性和方便性。
2、自动化测试
1）为什么要进行自动化测试？
①黑盒测试回归效率低
②手动测试的偶然性和不确定性
③回归的覆盖率不足
④交付的产品质量无法保证，全靠评估
⑤系统越复杂，问题越多
⑥上线时间长、构件失败率高导致的蝴蝶效应（迭代快，加班多）
2）自动化测试能解决什么问题？
①提高出现问题后的响应速率
②降低回归成本
③提高回归覆盖率
④提高回归效率
⑤提高回归的稳定性
3）自动化测试的不足有哪些？
①无法减少成本投入，而是为了加快测试结果反馈，提升测试质量
②自动化适用于回归和冒烟，而不是发现BUG
③录制回放功能是鸡肋，可视化并不是一个很好的做法
④不是所有所有系统所有功能都适合做自动化测试
3、自动化测试框架
构成框架的组件，最起码应该具备以下的功能：
Log：日志记录和管理功能，针对不同的情况，设置不同的日志级别，方便定位问题；
Report：测试报告生成和管理以及即时通知，测试结果快速响应；
Source：配置文件、静态资源的管理，遵循高内聚低耦合原则；
Common：公共函数、方法以及通用操作的管理，遵循高内聚低耦合原则；
TestCase：测试用例管理功能，一个功能点对应一个或者多个case，尽可能的提高覆盖率；
TestData：测试数据管理功能，数据与脚本分离，降低维护成本，提高可移植性；
TestSuite：测试组件管理功能，针对不同场景不同需求，组装构建不同的测试框架，遵循框架的灵活性和扩展性；
Statistics：测试结果统计管理功能，每次执行测试的结果统计、分析、对比以及反馈，数据驱动，为软件优化和流程改进，提供参考；
Continuous：持续集成环境，即CI环境，包括测试文件提交、扫描编译、执行测试、生成报告及时通知等功能，持续集成是自动化测试的核心！
4、常见的自动化测试框架
1）接口自动化框架
①、java+testNG/Junit+Maven/Ant/Gradle+Jenkins+MySQL+testlink/redmine
②、python+unittest/pytest+Git+Jenkins+MySQL+testlink/redmine
③、python+rebot framework+unittest/pytest+Git+Jenkins+MySQL+testlink/redmine
④、jmeter+Maven/Ant+Jenkins+MySQL+testlink/redmine
2）UI自动化测试框架
①、java+selenium/appium+testNG/Junit+Maven/Ant/Gradle+Jenkins+MySQL+testlink/redmine
②、python+selenium/appium+unittest/pytest+Git+Jenkins+MySQL+testlink/redmine
③、python+rebot framework+unittest/pytest+Git+Jenkins+MySQL+testlink/redmine
它们都拥有共同特性：编程语言+单元测试框架+扫描编译工具+持续集成工具+数据库+项目管理工具。
编程语言：编写测试脚本、日志记录和输出；
单元测试框架：提供测试脚本运行、异常校验等一些列的配置；
扫描编译工具：测试文件扫描编译，一般配合持续集成工具使用效果更佳；
持续集成工具：Jenkins，经典的持续集成工具；
数据库：测试数据管理；
项目管理工具：测试结果统计管理；
PS：自动化测试工具太多，上面只是列举了使用率较高以及我个人还算了解的一些开源工具，具体的框架选型，需要根据具体项目特点和团队、个人技术特点来决定！
5、做自动化测试的目的
在聊自动化测试度量指标前，有必要回到做自动化的初衷上，就是为什么要做自动化测试，要解决什么问题。
在不同公司，对不同的团队和技术同学来讲，做自动化的目的各有不同。常见的目的有下面几点：
测试数据准备耗时长，为了提升造数据的效率而做自动化测试；
项目上线之前的核心业务链路回归，为了提升回归测试效率，这也是一种上线前的check手段；
提测前为了快速验证提测质量，作为一种冒烟测试手段提升效率，同时这也是一种测试左移的实践；
团队大业务线多，通过统一框架和协作规范来提升测试团队协作效率，减少造轮子，避免资源内耗浪费；
当然还有其他目的，总结一下，做自动化测试的目的主要是降本增效。即通过技术手段，提升测试过程效率和团队协作效率，新增测试回归验证手段，降低重复性工作投入成本。
6、基于目的制定度量指标
如上文所述，关于自动化测试的度量指标，我个人的观点是基于实际的目的出发来制定度量指标。举例：
| 自动化测试目的 | 细分类型 | 度量指标 | 如何度量 |
|---|---|---|---|
| 效率 | 造数据效率 | 每周造数条数 平均造数耗时 造数任务调用量 | 和手动造数耗时对比 |
| 效率 | 冒烟测试效率 | 冒烟执行耗时 | 和手动冒烟测试耗时对比 |
| 效率 | 线上回归效率 | 回归执行耗时 | 和手动回归测试耗时对比 |
| 覆盖率 | 接口覆盖率 | P0/P1接口覆盖率 总体接口覆盖率 | 梳理核心接口，投入最多资源精力 |
| 覆盖率 | 用例覆盖率 | P0case覆盖率 P1case覆盖率 | 梳理核心case，投入最多资源精力 |
| 覆盖率 | 业务场景覆盖率 | 正向场景覆盖率 逆向场景覆盖率 核心场景覆盖率 | 根据业务场景，case by case度量 |
| 过程质量 | 构建执行成功率 | 自动化任务执行成功率 | 低于某个阈值判定脚本质量不通过 |
| 过程质量 | 用例执行通过率 | 自动化case执行成功率 | 低于某个阈值判定提测质量不通过 |
7、制定度量指标要注意的
制定度量指标时，建议遵循和考量如下几点：
切忌面向指标/面向KPI做度量；
考虑到冗余成本，指标不宜过多；
制定指标是为了提升质量，而非做数据；
根据做自动化测试的目的来制定度量指标；
度量指标对比应该以是否解决了痛点为依据；
度量指标是辅助评估依据，并不是唯一正确的结果；
制定指标应考虑到哪些指标更实际有效，从解决问题角度出发；
度量指标不要单一的评估，应结合多个维度来综合评估开展质量度量；
最新最全花1W买的Python+Selenium全栈Web自动化测试
|-------------------------------------|
| 下面是我整理的2025年最全的软件测试工程师学习知识架构体系图 |
一、Python编程入门到精通
二、接口自动化项目实战
三、Web自动化项目实战
四、App自动化项目实战
五、一线大厂简历
六、测试开发DevOps体系
七、常用自动化测试工具
八、JMeter性能测试
九、总结（尾部小惊喜）
人生最耀眼的不是站在领奖台的瞬间，而是黑暗中依然前行的勇气。当你觉得疲惫不堪时，请记住：每个伟大的转折都藏在"再坚持一下"的决定里。你的脚步，正在丈量属于自己的传奇！
别被眼前的迷雾困住脚步！那些看似徒劳的努力，都在为惊喜的绽放积蓄力量。当世界说"到此为止"时，你的坚持就是最响亮的回答。向前奔跑吧，生命的精彩正在下一站等你！