专栏文章 测试陷阱 3-自动化测试就是测试的技术

simonpatrick · 2019年11月28日 · 最后由 married577 回复于 2019年11月28日 · 2179 次阅读

随着自动化测试的风靡,测试同学们越来越觉得自动化就是全部,自动化就是自己的方向。
这些本身没有太大问题,但是如果认为自动化测试就是终极技术,那么我觉得这是一个很大的陷阱。
为什么?个人觉得大部分的测试把自动化和技术都定义的太狭小了,技术和自动化都是非常宽泛的定义,下面是我自己问自己的两个问题:

  • 什么是自动化?测试讨论的自动化难道就是接口自动化,UI 自动化测试吗?
  • 什么是技术?技术难道就是写代码吗?把测试用例代码化吗?

什么是自动化?测试讨论的自动化难道就是接口自动化,UI 自动化测试吗?

为什么先问这个问题,因为很多同学一开始没有接触过自动化,后来写了一些自动化用例之后,要么觉得高人一等,要么觉得一会就觉得没意思了,原因何在?因为写过自动化测试用例之后,要么觉得我技术很厉害了,基本可以把所有问题都解决了;要么马上一个疑问是这有技术含量吗? 大量重复的代码,差不多的验证点,没有比设计测试用例和执行用例高级到多少,然后就有一种深深的幻灭的感觉?路在何方的问题又来了.

其实什么都可以是自动化,把原来重复做的事情用代码实现是自动化的一种;把类似的事情用代码实现也是自动化的一种;把
日常工作用代码实现也是自动化;这些自动化都是在做了一次之后再用代码去实现,如果用时髦一点的时候 machine learning/ai 去把
没做过的事情自动实现了,也是自动化. 我甚至可以说,社会生产力的进步都是每一个自动化的结果。
如果从这个角度看的,那么自动化能做的事情太多了,自动化测试也好,测试自动化也好,你可以做的事情有很多很多,多到你无法想像,问题是你有
能力做吗? 那些写接口自动化,web ui 自动化的技能足够你去做更多的自动化吗?

自动化的目的大致就是为了不让人去做差不多的事情,减少重复劳动。用一样的方法做一样的事情是重复劳动,用不一样的方法重新再做一遍一样的事情也是重复劳动;如果目标是减少重复劳动,那么自动化测试就不能停在把测试自动化这一步,还有很多很多的事情可以做。但是坦白说,有哪些事情,我也说不出来,但是我觉得用代码再去实现一遍测试过用例,也是一种重复劳动,只是还没有能力把这件事情不重复做,但是相信一定有一些办法,有一些方面是可以解决的。

如果从上面的角度说,自动化的范围太广了,能做的事情太多了,会了接口自动化,UI 自动化算什么呢?

什么是技术?技术难道就是写代码吗?把测试用例代码化吗?

个人觉得技术包括的范围也很广,不止是写代码,不仅仅是测试用例代码化,这些都只是技术的一块。讨论起代码来兴致很高,觉得技术含量很高,讨论起业务来,没有一点情绪。但是如果仔细想想,像一个会计问题,一个交易问题,一个合规问题,这些是业务,但是不也是技术吗?这些只要是专业问题,这些就也是技术的一种,就像你专业写代码,这些不能理解为计算机科学的业务吗?如果是这样的话,那有什么非要区分业务和技术的?放在现实中来说,业务就是处理实际问题的技术,代码就是解决计算机如何运行的技术,不是吗?既然是这样的化,那么问问自己业务了解的透彻了,各个流程节点了解透彻了吗?技术实现和业务的匹配对应关系了解透彻了?代码说到底只是一个产品成功的一部分,还有很多很多其他问题需要解决,如果非要说代码能占到产品上线或者成功的多少比例?或许 50% 都不到. 代码本身不是目的,实际业务问题才是。不用非要拘泥与代码,各种方式解决了业务问题,也是很有技术含量的。

自动化测试就是测试的技术?

自动化测试只是测试的一种技术, 决定你有没有价值的不是你用了什么技术手段,是你解决了什么问题。代码,自动化测试也只是测试的一个侧面,想想日常工作中有多少事情要处理,如果眼里只有自动化测试,那么是不是失去了很多其他方面的锻炼和成长。问问自己把问题说清楚了吗,问问自己
做到了有效沟通吗,问问自己了解业务吗,问问自己能快速了解需求吗?自动化测试只是那么一小块,需要做的事情还有很多。

不过自动化测试如果你完全不会,那么现在的行情你肯定是不容易拿到高工资的;但是如果认为只有自动化测试,那么天花板也放在那边,也算给自己的一个提醒吧。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 2 条回复 时间 点赞

说到底,自动化测试也还是测试,目的是相同的

支撑核心还是要回归业务

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册