自动化测试之争：code vs codeless

在TesterHome看到的一个话题，当我们选择做自动化时是否需要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就提供了这种能力。

• Robot framework

Robot framework编写用例不需要写代码，但要学一套DSL(领域特定语言)，当需要为Robot Fremework封装个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能力强的，招进来又不一定做自动化。你要知道，技术好其实代表了你学习能力更强。说明你可以承担更多有挑战的工作。谁不喜欢优秀的人呢？

如果在编程的世界遨游，你会收获更多。

5. 比如，当我略懂Android/Flutter、Web开发之后，在测试这类应用时，我会对被测系统有更深的理解，在日常的测试过程中具备更强的debug能力，和开发交流更顺畅，能够推测出更多潜在bug。

不反对codeless

既然code好处多多，为什么不反对codeless？

1. 某些场景工具更好用，比如，在日常调试接口过程中，复制浏览器的cURL，导入postman非常方便，再比如，压测接口的时候，JMeter真香啊~！

2. 在一个code能力不强的测试团队，强推人人code是不现实，不是每个公司都BAT/TMD，我面过很多公司测试，他们待的测试团队只有几个人，甚至一两个人，就因为不会code，难道就不配碰自动化？既然有codeless工具，干嘛不先拿来直接用。总比什么都不做，什么都不会强太多了吧！