首页 » 脚本文章 » 是如何成功转岗自动化测试的?(测试自动化功能转岗接口)「转行自动化测试」

是如何成功转岗自动化测试的?(测试自动化功能转岗接口)「转行自动化测试」

南宫静远 2024-07-23 19:06:11 脚本文章 0

扫一扫用手机浏览

文章目录 [+]

不知同样作为测试的你,有没有思考过究竟问题出现在哪里呢?

我相信很多同学都看了市面上和测试相关的书籍,也看过很多测试大咖的博客,培训课程也多多少少参加过,就是发现在实际应用的过程中在大脑里提取不到,在这里我提出3点自己的见解:

一 、测试知识点零散,没有形成自己的架构

是如何成功转岗自动化测试的?(测试自动化功能转岗接口) 是如何成功转岗自动化测试的?(测试自动化功能转岗接口) 脚本文章
(图片来自网络侵删)

1、 从功能测试来讲,给你某个应用让你写 case,这里有个原则列举所有可能发生的"正确的、错误的、异常的"场景,下面我们来看看这一原则的架构:

功能测试架构:

是如何成功转岗自动化测试的?(测试自动化功能转岗接口) 是如何成功转岗自动化测试的?(测试自动化功能转岗接口) 脚本文章
(图片来自网络侵删)

2、 不会学习,形成"一看就会,一用就废"现象

何为学习,学习是在特定情境下由于练习和反复经验而产生的行为或行为潜能的相对持久的变化。
从上面的测试架构来说,读完后感想"哦,原来是这样啊" 然后就没有然后了 ,第二天回到单位继续按照原有的知识架构进行工作,头一天看的文章内容随云彩飘走了。

我们都知道学习是会遗忘的,德国心理学家有个著名的艾宾浩斯遗忘曲线大家都应该不陌生,大致的意思是学习的内容仅仅看过一遍 1 天后能记住一部分 50%,一周后、一个月后也就剩 20%了。

所以我在这里的建议是把核心知识架构进行背诵,这样无论什么样的功能拿到你面前你都知道要测试什么了。

三、我是如何从功能测试成功转岗测试开发的?

功能测试——>UI自动化

回想刚入行那会,功能测试都玩不溜。
所以花了很多时间在功能测试用例的设计上,随着项目越做越多,用例设计也变得手到擒来。
自己的内心也不满足于只做功能测试,觉得自动化测试很厉害的样子,就去学了代码基础。
但是有一个问题,学了代码基础还是不会做自动化测试,因为那时候还傻傻分不清自动化到底有哪几种。

随着学习的深入,知道软件测试中常见的自动化主要分为2种:一种是UI自动化,一种是接口自动化。
那么先学哪个呢?当时觉得UI自动化有点不明觉厉,因为可以代替手工点点点,非常酷炫。
后来又花小半年时间学习UI自动化。
到这里可能有点人会说,UI自动化要学这么久吗?对于我当时来说,是的。
虽然是计算机专业出身,但是大学学的东西基本都忘差不多了。
我们先来看UI自动化要学哪些内容(以selenium举例),下面用个思维导图简单列一下:

当然UI自动化需要学的内容远不止以上这些,这些东西算是比较核心的。
学习过程中所有的知识都是零散的,想要组合起来对一个小白来说却是很难。
后来有机会加入一个新的公司,需要用到UI自动化,然后去GitHub上找了很有优秀的代码以及看一些博客,终于实现了第一个自动化项目。
那种感觉是非常棒的,但是也被个大神说这有啥,不就是按键精灵吗(捂脸哭)。

UI自动化——>接口自动化

当然,也是被这个大神带上走接口自动化之路,有了UI自动化学习经验,学习接口自动化基本没有费什么功夫。
如果让我说UI自动化和接口自动化各有哪些优缺点,这是不好比较的,其目的都是为了软件质量。
但是如果让我选择,我会选择接口自动化,因为接口一般是不容易变得的,UI界面是经常变的,所以接口自动化的维护成本相对较低。

接口自动化——>性能测试

UI自动化,接口自动化学完了,学什么呢?我又去学了性能,为什么学性能,完全是工作需要,后来发现性能真的是个无底洞,需要了解开发知识、服务器架构、操作系统、测试监控工具、容器知识等等。
知识面太广,现在还在苦苦挣扎。

当然在性能测试过程中,也去学了一些开发知识,之前做UI/接口自动化或者功能测试时只能从黑盒/灰盒层面去判断BUG原因,学了开发知识后,大概就知道这个bug是如何产生了。
这对我自己的测试生涯也算是有了一个提高。

说了这么说,其实我们软件测试人员的知识体系常见的就以下几点:

如果要是从这5年中说出最宝贵的经验,我想应该是知识体系化。
那么什么是知识体系化,每个人都有不同,以上简单的谈了一下我的知识体系化,希望对你有所帮助。

我是谁?

我是一名从事了多年软件测试的老测试员,今年年初我花了一个月整理了一份最适合2020年学习的软件测试学习干货,可以送给每一位对软件测试(包括自动化测试)感兴趣的小伙伴,想要获取的可以关注我的头条号并在后台私信我:【测试】,即可免费获取。

相关文章