看到这样一个话题:当我们选择做自动化时是否需要code或者codeless。
code方案
用code去做自动化,实现过程就是拿个IDE撸代码。
·python+pytest/unittest+appium/selenium/requests+...
· Java+Junit/testNG+appium/selenium/requests+...
codeless工具
用codeless的方式做自动化,就是各种测试工具/框架方案,几乎可以不碰代码。
· JMeter
· postman
· UFT
· 基于各种开源/自研的测试平台
混搭框架/库
在实际情况下,可能会出现很多混搭的方案。
· Sweetest
比如,你写好了一个脚本用于解析excel中的自动化用例,如果脚本做的足够强大,那么编写用例的过程是面向excel的。Sweetest就是提供了这种方案。
· seldom
比如,实现用例的过程主要通过code编写,偶尔需要读取excel实现参数化,脚本中实现了excel的解析,可以很方便的解析excel中的数据并用于用例的参数化,Seldom就提供了这种能力。
· Robotframework
Robotframework编写用例不需要写代码,但要学一套DSL(领域特定语言),当需要为RobotFremework封装个Library时,需要用到Python。
· HttpRunner
HttpRunner2.x以JSON/YAML编写用例为主,偶尔用python写辅助函数,HttpRunner3.x支持完全code。
当然,混搭技术/框架还有很多。
观点
我下个人观点,鼓励code,但不反对codeless。
鼓励code
为什么鼓励code,因为我是code的收益者。我真正开始学习编程并做自动化是在工作的第三年,很多同学刚做测试就开始code了,这一点比我厉害。那么,code带来什么好处呢?
1. 编写的自动化用例更加灵活,想想写自动化的时候需要循环的执行一些操作,或根据某个条件判断执行,或者想随机的生成一些测试数据,工具要么不能满足,要么需要扩展,要么需要用更加繁杂的操作才能满足。对于coder者来说,只要你编程能力OK,一切需求都不是问题。
直接好处就这么一条,接下说说间接好处。
2. 变得更加自信。有同学要说了,不就写个代码嘛,还写出优越感了。整个IT圈子还是崇尚技术的(说是我粉丝的人难道是因为我长的帅?哈哈),虽然,最终效率一样,因为你用了更难的方式做自动化测试,确实看上去更厉害一点儿。我有一个做了十几年开发的朋友,他一直觉得我会做自化是很厉害的技能。如果你做的是有一些门槛的工作,那么,你的自信就是在别人的不断肯定中建立起来的。
写写自动化只是入了code门而已,真正的好处是为你打开了编程的大门。
3. 随着自动化用例越写越多,会给你带两个提升,一个是编程水平的提升,封装、设计模式,多线程,越写越高级。二是学会了很多库,ddt库、发邮件库、allure库。会的更多之后,你会尝试在工作中用编程提升自己的测试效率。我以前在测业务需求的时候也会开一个编辑器,时不时的要用Python计算一下数据或者批量的跑一下脚本。
更大的好处是涨工资。
4. 谈钱就俗了,那你要不是交房租,要不要还房贷,要不要养老人和小孩。我们总有生活压力,那面试的时候,肯定技术好同学更能要到高薪,为什么要技术好的?code能力强的,招进来又不一定做自动化。你要知道,技术好其实代表了你学习能力更强。说明你可以承担更多有挑战的工作。谁不喜欢优秀的人呢?
如果在编程的世界遨游,你会收获更多。
比如,当我略懂Android/Flutter、Web开发之后,在测试这类应用时,我会对被测系统有更深的理解,在日常的测试过程中具备更强的debug能力,和开发交流更顺畅,能够推测出更多潜在bug。
不反对codeless
既然code好处多多,为什么不反对codeless?
1. 某些场景工具更好用,比如,在日常调试接口过程中,复制浏览器的cURL,导入postman非常方便,再比如,压测接口的时候,JMeter真香啊~!
2. 在一个code能力不强的测试团队,强推人人code是不现实,不是每个公司都BAT/TMD,我面过很多公司测试,他们待的测试团队只有几个人,甚至一两个人,就因为不会code,难道就不配碰自动化?既然有codeless工具,干嘛不先拿来直接用。总比什么都不做,什么都不会强太多了吧!
感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取