在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帶來什么好處呢？
- 編寫的自動化用例更加靈活，想想寫自動化的時候需要循環的執行一些操作，或根據某個條件判斷執行，或者想隨機的生成一些測試數據，工具要么不能滿足，要么需要擴展，要么需要用更加繁雜的操作才能滿足。對於coder者來說，只要你編程能力OK，一切需求都不是問題。
直接好處就這么一條，接下說說間接好處。
- 變得更加自信。有同學要說了，不就寫個代碼嘛，還寫出優越感了。整個IT圈子還是崇尚技術的（說是我粉絲的人難道是因為我長的帥？哈哈），雖然，最終效率一樣，因為你用了更難的方式做自動化測試，確實看上去更厲害一點兒。我有一個做了十幾年開發的朋友，他一直覺得我會做自化是很厲害的技能。如果你做的是有一些門檻的工作，那么，你的自信就是在別人的不斷肯定中建立起來的。
寫寫自動化只是入了code門而已，真正的好處是為你打開了編程的大門。
- 隨着自動化用例越寫越多，會給你帶兩個提升，一個是編程水平的提升，封裝、設計模式，多線程，越寫越高級。二是學會了很多庫，ddt庫、發郵件庫、allure庫。會的更多之后，你會嘗試在工作中用編程提升自己的測試效率。我以前在測業務需求的時候也會開一個編輯器，時不時的要用Python計算一下數據或者批量的跑一下腳本。
更大的好處是漲工資。
- 談錢就俗了，那你要不是交房租，要不要還房貸，要不要養老人和小孩。我們總有生活壓力，那面試的時候，肯定技術好同學更能要到高薪，為什么要技術好的？code能力強的，招進來又不一定做自動化。你要知道，技術好其實代表了你學習能力更強。說明你可以承擔更多有挑戰的工作。誰不喜歡優秀的人呢？
如果在編程的世界遨游，你會收獲更多。
- 比如，當我略懂Android/Flutter、Web開發之后，在測試這類應用時，我會對被測系統有更深的理解，在日常的測試過程中具備更強的debug能力，和開發交流更順暢，能夠推測出更多潛在bug。
不反對codeless
既然code好處多多，為什么不反對codeless？
-
某些場景工具更好用，比如，在日常調試接口過程中，復制瀏覽器的cURL，導入postman非常方便，再比如，壓測接口的時候，JMeter真香啊~！
-
在一個code能力不強的測試團隊，強推人人code是不現實，不是每個公司都BAT/TMD，我面過很多公司測試，他們待的測試團隊只有幾個人，甚至一兩個人，就因為不會code，難道就不配碰自動化？既然有codeless工具，干嘛不先拿來直接用。總比什么都不做，什么都不會強太多了吧！