目录：导读
前言
企业自动化测试流程
自动化测试流程包括测试分析及计划、测试设计及开发、测试执行和测试总结四个阶段
1、测试分析及计划
自动化可行性分析：
在进行需求自动化测试之前，先要确认是否可以实行测试自动化，必要时进行抽样demo分析（如涉及第三方系统等）。
自动化测试应该遵循以下几个前提条件：
需求变动不频繁：
项目周期为足够长的时间段；
自动化测试脚本后期可重复使用；
抽样demo分析是将实体案例进行更深层次的可行性分析，demo的选取，一般直接选择冒烟用例写成测试脚本后执行，检查脚本是否能运行通过，设计的测试点是否全部覆盖；
测试需求分析：
确认需求自动化测试可行后，对需求进行梳理，划分出可以进行自动化测试的功能点，划分的标准一般是重复性高、业务不过于复杂的功能点，便于快速脚本实现，如果选择功能点过于复杂，会花费大量的时间在脚本编写上，这样就丧失了做自动化的初衷；
在这个阶段，要确定自动化测试覆盖率以及自动化测试颗粒度，原则是在项目周期内尽可能提高自动化测试覆盖率；
2、制定测试计划
测试计划主要包括以下内容：
准入准出：自动化测试介入时间点，达到什么标准后，自动化测试结束
测试范围：确定测试需求的优先级与业务范围
进度安排：在什么时间点输出什么成果
风险评估：对项目过程中的风险进行预估并给出应对的方案
所需资源：测试所需要的人员、软件、硬件与文档等资源
工作安排：具体人员的分工
3、测试设计及开发
测试用例设计：
先进行测试用例的设计，测试用例编写完成之后，进行用例评审，评审通过后再进行测试脚本的开发。
设计自动化测试用例过程需要遵循的原则：
一个用例为一个完整的场景，覆盖核心的业务流程；
优先考虑实现正向的测试用例，辅以个别重要的反向用例；
数据计算类的用例需要在数据驱动中提供预期结果进行比对；
新增类与修改类的用例需要在新增与修改成功后重新查询比对查询结果；
用例和用例之间尽量避免产生依赖；
用例完成测试之后需要对测试场景进行还原（数据清除等），以免影响其它用例的执行；
4、脚本开发与版本控制
根据写好的测试用例，编写对应的自动化测试脚本，测试脚本的编写遵循脚本开发规范，编写过程中应考虑脚本的可维护性、可重用性、简单性与健壮性。
同时要注意确保自动化项目的结构化和一致性，脚本开发完毕后，至少运行成功3次以上，才能认为脚本已经没有问题
当日进行脚本编写前，在本地拉取Master分支代码，保证本地代码为最新版本，当日脚本编写与调式完成后，上传到自己的分支，后期统一Merge到主分支
5、测试执行
在迭代需求系统测试已经完成的情况下（如迭代需求线上发布后），采用Jenkins工具任务触发方式进行脚本的无人值守执行
执行过程中发现的有效BUG记录在华为云上并提交给对应的开发人员修复，标题前缀加上【自动化测试】，以便后期跟踪处理
开发人员修复BUG后，需要对BUG进行回归测试，如果问题的修改方案与原来的需求有偏离，那么在回归测试前，还需要对用例与脚本进行的修改
6、测试总结
对自动化测试的结果进行总结，统计发现的BUG与产生原因，提交测试报告文档
7、自动化测试报告
版本运行总结：每次新功能上线的自动化测试覆盖率，通过率，缺陷率，与上版本相比的质量数据
每日运行总结：发布后的自动化测试质量追踪，问题分析，确定缺陷的原因
包含：
所有的自动化统计报表，囊括所有的脚本运行的历史数据和近 7 天的脚本成功率趋势；
单次自动化统计报表，统计了单次运行脚本的详细信息，分为失败统计和全部统计和日志复盘信息；
单条自动化统计报表，单条用例的详细信息，包括检查点，执行步骤；
最后针对测试报告进行脚本与测试用例的维护与优化，归档；
自动化测试分类
1、Unit-单元测试
单元测试需要做DAO层和Service层的测试，数据驱动层的单元测试主要保障SQL脚本的正确性与合理性，Service层的单元测试主要保障单个功能函数逻辑的正确性
单元测试的外部依赖可以通过Mock框架 (Mockito等) 模拟返回，使得自动化测试尽量做到可以随时随地运行，某种意思上来说这一层自动化测试的投入产出比是最高的
2、Service-接口测试（集成测试）
在服务层接口测试关注的是某个接口的输入输出功能是否正确，以及业务流程的逻辑测试，初期测试自动化起步较晚，代码覆盖率不高，所以初期接口自动化策略是增加业务场景的覆盖
优先覆盖核心业务的场景：
接口所依赖的数据选择使用接口返回值的方式；
暂时不做系统间的Mock，更多的考虑系统之间的依赖；
优先做场景覆盖，之后再考虑代码覆盖；
这样做可以快速增加业务场景的覆盖，同时写好的API接口就算后期产品业务流程发生变化一样可以使用(对UI层的接口逻辑不变)，以这种方式编写的脚本，后期维护成本较低。
接口测试由测试人员完成，接口测试时测试人员不需要非常详细的了解内部接口代码的实现，编写的脚本中体现了对不同接口、模块之间关系的梳理，后期在核心业务流程覆盖率较高的情况下，可以增加对单个接口的覆盖
进行接口依赖的解耦，比如数据从调用接口变为直接往数据库插入数据；
逐渐细化拆分业务场景；
由系统级的自动化测试逐渐转为灰盒与白盒自动化测试；
3、UI–页面测试
这一层主要是页面展示逻辑及界面前端与服务的集成验证，适当的UI自动化测试是有必要的，因为UI自动化可以在版本迭代回归时替测试人员进行重复的工作，实实在在的解放劳动力。
只做核心的功能的自动化覆盖，脚本可维护性尽可能提高
UI自动化测试脚本遵循Page Object设计模式；
通过数据mock的方式减少对后台数据的依赖；
UI测试由测试人员完成，在覆盖了核心场景之后，没有必要在UI层投入太多的精力和资源，因为UI界面是变化频率最高的一层，后期的维护成本太高
持续集成
有了各层的自动化测试，需要建立起持续集成体系
流程自动化，提高自动化效率
定时定量重复执行，最大化自动化测试脚本的价值
目的：
代码提交自动执行单元测试；
单元测试通过后自动部署整体的环境；
自动执行集成自动化测试 (Service/UI)；
自动生成构建的详细测试报告，同时自动通知相关人员；
可以推动开发进行单元测试的覆盖，制定接口自动化脚本编写规范，增加代码的可读性、有效性与可复用性，脚本设计时尽可能脱离测试、预发布和线上三个环境数据的依赖，在时间可控的情况下增加核心业务流程UI自动化测试的覆盖
在各层自动化测试都比较成熟的情况下，后期可以加入代码覆盖率自动收集、代码静态检查等测试左移的活动以及线上数据与BUG的收集与监控（接口性能、crash率、用户行为分析等）等测试右移的活动，搭建符合公司风格测试平台等
| 下面是我整理的2023年最全的软件测试工程师学习知识架构体系图 |
一、Python编程入门到精通
二、接口自动化项目实战
三、Web自动化项目实战
四、App自动化项目实战
五、一线大厂简历
六、测试开发DevOps体系
七、常用自动化测试工具
八、JMeter性能测试
九、总结（尾部小惊喜）
每一次努力都是前行的力量，每一份拼搏都是成长的养料。坚持不懈，追逐梦想，奋斗是我们的座舵之船，扬帆起航向未来。
心怀梦想，步履坚定。不论前路崎岖与挑战，奋斗的火焰永不熄灭。用汗水浇灌成长，用努力书写辉煌。相信自己的力量，勇往直前，你将开创属于自己的壮丽篇章，成就人生的伟大航程。
风雨兼程，奋斗不止。每一次努力都是人生的投资，付出总有回报，坚持总有收获。在追逐梦想的道路上，不要畏惧困难，勇往直前，相信自己的力量，你将创造属于自己的辉煌人生。