目录:导读
- 前言
- 一、Python编程入门到精通
- 二、接口自动化项目实战
- 三、Web自动化项目实战
- 四、App自动化项目实战
- 五、一线大厂简历
- 六、测试开发DevOps体系
- 七、常用自动化测试工具
- 八、JMeter性能测试
- 九、总结(尾部小惊喜)
前言
Python自动化测试:https://www.bilibili.com/video/BV16G411x76E/
我们先来说一下现在自动化测试主要的几个方向(以python语言为主):
接口自动化测试方向:Python+requests+pytest+yaml+alluer+Jenkins;
web自动化测试方向:Python+selenium4+pytest+POM+allure+Jenkins;
app自动化测试方向:Python+appium+POM+pytest+allure+Jenkins;
测试环境选择和搭建
自动化测试运行环境,不外乎测试环境(SIT)、验收环境(UAT)、灰度环境(PRE)和生产环境(PROD)。
在不同的环境运行的目的、效果、优势和不足也各不相同。
下面是不同环境的区分对比结果:
环境名称 | 优势 | 不足 |
---|---|---|
测试环境(SIT) | 节省环境资源,代码版本比较新,可及时验证,复用性强 | 服务不稳定,测试数据容易混淆,测试结果准确性不高,需要人工二次校验 |
验收环境(UAT) | 服务相对稳定,环境复用性强,代码版本相对较新 | 测试数据容易混淆 |
灰度环境(PRE) | 环境稳定,服务齐全,可以更好的进行业务流程的自动化测试 | 测试数据容易混淆,需要单独的维护和管理测试数据 |
生产环境(PROD) | 环境稳定,服务齐全,主要用来做线上主流程巡检,防资损 | 需要单独维护测试数据和账号,且需要配置白名单过滤,防止污染生产数据 |
不同环境对自动化测试开展的便利性和制约性不同,建议根据自动化测试的成熟度、要解决的问题来选择不同的环境。
当然,如果选择搭建单独的自动化测试环境,就要考虑环境资源申请、域名、代码仓库权限、维护成本等因素。
还有个很容易忽视的点就是服务器操作系统类型和版本,举个我当时遇到的例子:
要做web的UI自动化测试,工具选择了selenium,我们常用的浏览器是chrome,用户使用环境是windows,自动化测试要求快速无感执行,
就需要考虑Linux环境下基于chrome浏览器的case执行(chromium),还要考虑Linux操作系统对chrome的适配问题(centos和uhuntu,以及centos的版本选择),甚至还要考虑浏览器驱动的适配问题。
测试框架选型和设计
近几年成熟稳定的开源自动化测试工具和框架可选择的比较多了,但具体问题具体分析,测试框架的选型和设计同样是很重要的事情。
在选择测试框架或者工具时,一般需要考虑如下几方面:
自动化测试类型:UI/API/UNIT,UI自动化要考虑web和移动端的区别,单元测试要考虑被测系统的开发语言;
框架自身的生态:框架支持的编程语言、社区活跃度、文档是否齐全、业内落地案例、测试同学自身的技术栈;
框架的学习成本:不能只考虑选择个人熟悉的,还要考虑后续的多人协同,团队其他同学的学习上手难度;
框架的维护成本:后期case多了或业务场景变更后,case的维护成本以及框架本身是否提供了更好的封装模块;
测试脚本和数据管理
测试脚本和测试数据管理,需要结合自动化测试的执行环境一起来看。
一般来说,测试脚本为了便于统一管理和多人协作维护,现在都是采用Git+gitlab的方式,做好版本管理和分支规范即可。
而测试数据的管理,相对来说比较复杂,可选的方式也不同。
下面是常见的几种测试数据管理方式对比:
测试数据管理方式 | 优势 | 不足 |
---|---|---|
Excel参数文件形式 | 数据维护方便,简单快捷 | 不利于多人协作,数据量大了之后数据维护更新成本高 |
配置文件形式 | 适合热点数据/通用信息管理,如账号密码等 | 无法适用于复杂场景和大规模的数据管理 |
数据库统一管理 | 便于数据隔离,统一管理 | 一般是配合单独的自动化环境一起维护,需要专业的DBA团队来进行数据库的管理和维护,成本较高 |
测试范围和校验粒度
标题所述的两点,其实是同一种问题。
测试范围的筛选,需要结合投入的资源,项目紧急程度来综合评估,一般测试范围的覆盖优先级,可以遵循这个顺序:核心业务——高频业务——问题较多的业务。
覆盖率的考量,可以遵循这个顺序:核心场景——核心业务流程——异常场景,如此覆盖后,再考虑逆向流程。
测试用例的粒度,可以参照功能测试用例的区分,从 P0 &冒烟case到 P1 再到 P2,以此类推。
当然,如果遇到比较复杂和亢长的流程,可以考虑拆分为多个测试用例,在同一个任务里按上下游关系去执行。
粒度的设定和拆分,在不同阶段有不同的划分。刚开始落地时,可以由粗到细,先实现再考虑不断优化。
持续集成和测试报告
自动化测试,如果无法做到持续集成快速验证,那就不能称之为自动化。
要做到将自动化测试,我个人认为有如下几个标识来判断:
执行的频次和效率:比如1天可以执行100个功能case,那自动化最起码要在10分钟甚至1分钟内完成;
执行结果自动校验:功能测试可以人工来判断测试是否通过,自动化测试的通过率&成功率需要达到一定的成功率(比如90%以上),且失败的case可以重试验证,或者失败的结果和日志及时通知给相关人员;
无人值守自动运行:这点其实很多方法可以实现,比如定时任务,条件触发。当然做到这点还算不上自动化,必须考虑到如果出现重大问题还需要及时的发现和告警通知;
是否融入交付流水线:交付流水线即我们今天常说的CICD或者devops流水线,常见的场景有服务打包编译后的自动化单元测试,服务自动发布后的接口自动化和UI自动化测试,以及服务上线前和上线后的自动化冒烟和回归测试,甚至还可以加入线上的日常自动化巡检。
下面是我整理的2023年最全的软件测试工程师学习知识架构体系图 |
一、Python编程入门到精通
二、接口自动化项目实战
三、Web自动化项目实战
四、App自动化项目实战
五、一线大厂简历
六、测试开发DevOps体系
七、常用自动化测试工具
八、JMeter性能测试
九、总结(尾部小惊喜)
每天醒来,我们都要以积极的心态面对新的一天。无论前方道路如何崎岖,我们都要勇往直前,在奋斗中不断成长。相信自己,坚持不懈,追逐成功的脚步!
成功路上,最大的敌人永远是自己。要战胜内心的懒惰和贪婪,不断超越自我,做最好的自己。只有持之以恒,才能开创属于自己的辉煌未来!
人生没有彩排,每一次都是现场直播。要勇敢面对生活的挑战,不畏困难和失败,坚韧不拔地追求自己的梦想,只有这样,才能创造更加美好的明天!