airtest 潛水

前提：各類環境的配置你們就本身搞定了~

1.selenium 原理

 

 

 

2.appium 原理

 

3.adb 原理

當啓動 adb 客戶端時，客戶端首先檢查 adb 服務端進程是否運行，若是沒有運行，則啓動服務端。當服務端啓動時，它會綁定到本地的 TCP5037 端口，而且監遵從 adb 客戶端發來的命令——全部 adb 客戶端都使用 5037 端口與 adb 服務端通訊，以後經過命令實現各類操做

 4.airtest 

三者的結合++維護成本高+思想的拓展=airtest 的誕生

 

airtest 能作什麼？

1.作過移動端或者web端自動化的同窗都知道，版本的迭代與代碼塊的規範，對於自動化來講是多麼重要，但是在實際工做中，永遠都是項目緊，時間少，尤爲對於qa來講，真實一個巨大的坎兒，越是到最後，應用 的穩定和邏輯正確已然是必須產品，但誰也不能保證，沒有任何修改，尤爲是哪些沒有開發經驗的pm來講，更是呵呵啦，在加上不少人都有個誤區，理解自動化很高級，能夠快速找出bug，真實難以言表的解釋，幹過的小夥伴 都應該曉得的 哈哈哈，說到這裏你們可能會感受到，其實這種狀況並非很適合自動化有沒有？  答案 是確定的 ，可是呢，對應這主快速回歸的需求又愈來愈強，全部處處問詢大牛，終於找到你啦

2.所裏那麼多，到底 這個工具能作啥呢 ？

目前全部的用戶場景無非就是pc+h5+小程序+Android+ios 仍是啥 ，應該差很少了吧  ，其實這些場景均可以徹底在airtest中實現，那麼問題來了 ，我沒有自動化經驗，能學會使用嗎，這個須要什麼基礎嗎，維護起來負責不？能夠批量運行case？能夠截圖發郵件？......    其實均可以的  ，有些功能還在探索中~~

3.好久之前有個著名的工具叫我selenium ide  ，後來按鍵精靈也曾大火過，固然還有個死貴 的qtp，沒辦法，誰讓遊戲迷那麼多，隨着這幾年  國內的猿類愈來愈多，

你們在樂於破解各類收費工具的同時，也在腦補爲啥不開發個nb的東西，讓業界happy下，這這樣慢慢的  有些大牛好比思寒 ，閒不住 在加上各位開源愛好者和超強的github 資源庫，不靈不靈 就誕生了 

 

官網地址：

http://airtest.netease.com/docs/cn/6_poco_framework/poco_quick_start.html

1.經過這裏你們能夠快速小白上手

2.也能夠學習下poco api，固然最好仍是要 懂些自動化的東西如xpah，css定位，測試框架等，有助於快速掌握

3.另外呢，說下優勢吧

1.維護成本低，可使用歷史case，也能夠從新建立，分分鐘高訂

2.支持多平臺ios ，andorid  ，linux ，windows 均可以 

3.支持腳本導入導出，能夠手寫自動化腳本（python），也能夠錄製，回放，設置檢查點（固然自動化是不建議設置的）

4.盲點補充，自動化一次只適合一個場景，不要妄想一次走完全部流程（流程取正向便可）

5.最後一個，不要錢，不要錢，不要錢

 

 

4.任何一個工具都有缺點，這個也不例外：

1.由於是gui 節目，對內存影響較大，卡頓比較嚴重

2.錄製場景不建議過長，容易致使回放失敗 

3.不自動導入包（雖不是必線），新手剛使用的時候仍是有些頭疼的 

4.數據依賴（這是個老大難的問題），不管是接口仍是gui  都是存在的 （如：ops的一個增刪操做，若是經過接口，使用參數就能夠搞的定，可是在可視化界面上能夠以主流程爲主，其餘異常和數據關係仍是要人爲進行干預的）

5.還有其餘的，暫時想不起來了...

 

囉嗦下：

任何工具的使用，必定要在理解原理的基礎上進行

不要期望工具能夠替代一切，那樣，有一天你也會被替代

工具帶給咱們的只有方便，不會給你思考，你的思想以爲你的價值

做爲qa 找bug 是平常，更要肯定bug 是咋來的，如何阻止一連串的bug，甚至你可否解決bug，是時候看看你的level啦

最後我的觀點：自動化工做之後被替代率會愈來愈高，但願全部qa小夥伴居安思危，勤勉好學，早日實現CK ，LV 平常化

對了：對於這個工具本人也處於小鳥階段，若有哪裏解釋不清或誤導，煩請指教　~