測試開發工作者日記：2020.9.28

    又開始這個系列。

最近半個月。忙的跟個monkey一樣。天天研究業務。隻能利用閑散時間維護下工具和平台。

    不過最近拒絕了一次業務測試。發了脾氣。甚至揚言大不了不幹了，有能耐開了我...這種“豪言壯語”。

    經過詢問得知，我們組之前好多同僚都受到了那個部門提測的不同程度的欺負。比如沒有測試環境，要求着急上線，線上測試。然後出了問題，測試背鍋。或者線上的測試因為沒有辦法利用各種工具/腳本，節省人力時間，導緻很多測試隻能持續很久，比如測試一個三天的優惠卷，你需要真的等3天，而且這個卷還要經過财務的層層審批，防止你套現。出點bug，還沒來得及提，财務那邊風控部門先找你了。

    最可怕的是經常有一些防打擾的測試需要半夜幾點測試。如果在測試環境我們可以輕松修改資料庫來實作替代。但是線上呵呵。你需要真的等半夜爬起來。

    更可怕的是，你一定在很多知名大軟體上見到tsest推送吧？然後sha個測試祭天？其實真實原因并不在測試。

    比如他們要線上測推送，然後說幫你寫個if過濾，隻給你一個人發推送。你忐忑不安的開始，結果發現，推送給了千萬的使用者.... 因為那個if寫錯了，或者剛寫完被其他人上線部署給覆寫回複原狀了.....

    這種情況壓根就不是正經的開發項目周期流程。為什麼還硬拉着測試人員呢？因為需要背鍋俠啊....

    不過最近我在支援各部門的時候，這種鍋砸在了我頭上，作為嗅覺靈敏的老油條立即開始反抗。不測就是不測，風險無法承擔。要麼别上線，要麼你自己自測去吧。反正你們沒過自測冒煙，流程上也不對。

    當然上司還是向着我，緊急開會給這事平息了，對方又是道歉又是退步的。但是我仍然沒有松口，要麼下成本搞測試環境要麼以後他們部門的東西别提測。不過聽組員說，以前就吃過很多次虧，敢怒不敢言，而且申請過測試環境，但是沒批。這次我鬧的這麼大，然後以一個最高p級去申請，結果..居然仍然失敗了。算了，帶不動。

    利用空閑，還是回來搞之前設計的ui自動化架構。其實說白了，就是一套關鍵字驅動核心的架構。隻是利用了很多很多的設計，和小技巧。能把我們各個測試同學寫的好幾千條用例，直接翻譯成緩存中的代碼來使手機app運作。

    看着很神奇，那邊漢語描述的各種用例，這邊手機就開始自動跑起來，斷言出報告了。中間環節的寫腳本的自動化測試人員消失了。 

    做這個之前，我分析了ui自動化的各種特點特性及适用場景，包括一些我們以前不考慮的問題。

    比如問題:

都說ui自動化不好，因為維護成本高，前端總變。 

    思考：

為什麼高？因為前端總變？那麼到底變了什麼？其實就三點，1是舊用例邏輯，2是舊用例元素定位語句 ， 3是新用例。

      如果解決了這三點，ui自動化是不是就穩了？當然我們不可能徹底解決，但是能解決多少算多少，當達到了一個可接受的維護成本内，是不是就可以搞起來了？而且如果能利用ai智能，不斷的糾錯提高準确度，是不是最終會達到一個不需要人維護的狀态呢？ 

    當然類似于上述的設想和分析到底的 節點，有很多。 

    而且在一開始，我也分析預測了各種開發風險，最可怕的就是一個沒思考過的突發問題，然後無法解決或繞過，導緻整個項目設計前功盡棄，然後引咎辭職吧～

    在經過了一個月的零散時間的開發中，真的如我所料，遇到了不少突發問題。好在運氣比較好，全部完美解決了。

    終于昨天晚上，第一個demo用例成功了。  直接對着我們用例平台上的一條用例，然後手機app開始運作，和人一樣的邏輯，和人一樣的判斷。

    這個demo打通，說明這個架構的設想是成功的，帶來的效果也非常非常震撼，我試着改了改用例，随便寫了點邏輯和斷言。果然app就像一個活的人一樣，開始按照你寫的漢字開始準确的運作和斷言。

    比如我寫的用例是：進入個人中心頁面，點選登入，然後登陸成功，然後去首頁看看歡迎語對不對，再去個人設定頁面看看昵稱。

    然後新架構的做法是先打開app，然後判斷要先去個人中心頁面，但是自己目前并不在這個頁面，發現自己在首頁，然後判斷出要怎麼做才能最短路徑進入個人中心，然後和人一樣進了去之後，判斷一下是不是進入成功了，然後開始找登陸按鈕，點選。然後進去之後，識别用例需要登陸成功，好的，自動找到使用者名/密碼/登陸按鈕，成功後，自己會判斷一下是不是真的登陸成功，之後覺得自己要去首頁了，但是自己并不在首頁，然後就找到一條路跳轉到首頁，看看歡迎語覺得沒問題，然後又同樣方法跑到個人設定頁面去看看昵稱。

    反正聽我說，可能覺得很平常的操作，但是實際上看到是很震撼的，仿佛有生命一樣。比如我改成登陸成功後，去聊天頁看看有沒有新通知小紅點。再次執行它會真的這麼做。

    以上，就是我如何解決用例邏輯變更 帶來的問題的方案和已經實作的技術。

    接下來就是如何應對元素定位變更的問題，好在我的wqrfnium_app 自動維護元素這個開源工具先研究出來了，直接套用，能應對不少前端變更元素定位的問題。

    接下來就是新用例的問題。這個更不用考慮了。因為每次執行，對于架構系統而言，都是新用例，都會重新按照邏輯去跑app。是以無所謂老舊。

    中間遇到不少意外問題：

比如同一個頁面，在不同登陸狀态下，裡面的内容完全不相同。

比如倆個頁面，在某種狀态下，裡面的東西一摸一樣，導緻系統都分不清自己目前處于什麼位置了。

比如一個輸入框元素的資料在用例上寫的太潦草 并沒有給出應該輸入的确切内容。

比如某個流程用例中缺少很多關鍵資訊，比如登陸，應該寫輸入使用者名/輸入密碼/點選登陸按鈕， 但是用例中我們往往看到就簡單四個字：登陸成功

很多很多這樣的意外問題，都被一一解決掉，添加新控制器的，添加新層級的，添加新過濾層，添加新元件，還有引入ai深度學習 和大資料識别等技術。

上面這些隻是定位執行操作的過程，另一個大過程是斷言。當然也被實作了。

    一個一開始聽起來很簡單的架構，真實達到穩定的能用的狀态，代碼量起碼翻番2次。任何一個小問題解決不了，都可能導緻最終全盤皆輸。

    在第一個用例被成功執行後，就說明線路通了。其他用例估計還會遇到一些意外風險，但是總數是固定的。疊代幾次後一定會解決掉全部用例。

    我覺得這個穩定運作之後，我可以寫成一個教程或者一本書。 當然還有很多系列教程等待我去寫完，真希望那時候這公衆号和部落格還有人看。