标签:yaml 收获 pru 支持 rem 编辑器 个人观点 man ppi
在TesterHome看到的一个话题,当我们选择做自动化时是否需要code 或者codeless。
用code去做自动化,实现过程就是拿个IDE撸代码。
python + pytest/unittest + appium/selenium/requests + ...
Java + Junit/testNG + appium/selenium/requests + ...
用codeless的方式做自动化,就是各种测试工具/框架方案,几乎可以不碰代码。
在实际情况下,可能会出现很多混搭的方案。
比如,你写好了一个脚本用于解析excel中的自动化用例,如果脚本做的足够强大,那么编写用例的过程是面向excel的。Sweetest就是提供了这种方案。
比如,实现用例的过程主要通过code编写,偶尔需要读取excel实现参数化,脚本中实现了excel的解析,可以很方便的解析excel中的数据并用于用例的参数化,Seldom就提供了这种能力。
Robot framework编写用例不需要写代码,但要学一套DSL(领域特定语言),当需要为Robot Fremework封装个Library时,需要用到Python。
HttpRunner2.x以JSON/YAML编写用例为主,偶尔用python写辅助函数,HttpRunner3.x 支持完全code。
当然,混搭技术/框架还有很多。
我下个人观点,鼓励code,但不反对codeless。
鼓励code
为什么鼓励code,因为我是code的收益者。我真正开始学习编程并做自动化是在工作的第三年,很多同学刚做测试就开始code了,这一点比我厉害。那么,code带来什么好处呢?
直接好处就这么一条,接下说说间接好处。
写写自动化只是入了code门而已,真正的好处是为你打开了编程的大门。
更大的好处是涨工资。
如果在编程的世界遨游,你会收获更多。
不反对codeless
既然code好处多多,为什么不反对codeless?
某些场景工具更好用,比如,在日常调试接口过程中,复制浏览器的cURL,导入postman非常方便,再比如,压测接口的时候,JMeter真香啊~!
在一个code能力不强的测试团队,强推人人code是不现实,不是每个公司都BAT/TMD,我面过很多公司测试,他们待的测试团队只有几个人,甚至一两个人,就因为不会code,难道就不配碰自动化?既然有codeless工具,干嘛不先拿来直接用。总比什么都不做,什么都不会强太多了吧!
标签:yaml 收获 pru 支持 rem 编辑器 个人观点 man ppi
原文地址:https://www.cnblogs.com/fnng/p/14882974.html