以下純屬聊聊過去三年在前公司做過的介面測試，沒啥特別的技術含量，可能寫的會有點亂 ，只是一些流程，測試方法上的簡單總結~~

           過去三年也是就職於某電商公司，前公司的測試架構簡單可分為 前端和後端 ，測試呢，大概有幾百人，前後端測試的比例基本大概為1:3 ；後端基本是純介面測試，基本不用涉及任何的前端介面操作， 然後前端呢，基本上因為這幾年來PC,WAP 端的使用者量其實很少的，基本都不怎麼維護了，所以真正算起來是APP 前端和底層測試了。本人主要是做交易服務底層介面的測試，三年轉了三個組， 涉及到了庫存，商品，購物車，訂單售前售後等 ， 感覺應該算是公司業務最複雜的一個組了；公司底層也分了好多模組： 活動，價格系統，物流等，綜合起來，最複雜的業務組應該就是訂單組了，訂單售後各種狀態的流轉，和下游各個系統 的互動特別容易出問題~~

          在過去的三年裡，也是經歷了公司的一次大的程式碼重構， 直接將後端php寫的工程轉為java 工程了，介面的入參，出參等都變化了 ； 重構的過程也是歷經了一年，不過重構後代碼的結構變的清晰了好多，效能經過實踐確實也是比前php工程程式碼的效能 有所提升 ；介面的協議是公司自己開發的一套框架，其實也是類似和dubbo介面一樣通過將服務註冊到zk ，然後通過proxy 去zk找到相關介面的服務 或者是通過伺服器+加埠直接去訪問 。

         然後說回之前的一個測試的流程  （專案需求，提測前， 測試，上線）         

          1 、專案需求階段：

          大專案一般都有專門的專案經理去跟進前端後端的排期，然後我們後端的產品經理會跟前端的產品經理確定需求點，然後跟開發（有時候也會拉上測試）討論技術方案， 後端的產品寫的需求基本上都是維護在一個wiki上，產品經理或者開發也會寫清楚後端要涉及那幾個工程要改，改了那幾個工程的介面，需要後端的介面給到什麼欄位前端，這些都會提前商量好，所以很多情況下，基本都是後端功能測試完成其實上線很久了，然後前端才會來接入我們的介面 ；

         第二：專案提測階段：

         確定好需求後， 開發提測前也會找測試簡單過一下設計方案，類似要輸出什麼欄位給前端呀，邏輯裡面要怎麼改呀，調了什麼外部介面來拿值呀，需要和哪個外部系統聯調呀等等這些都會說清楚 ~~然後~~~ 開發就又開始寫bug了   ~ O(∩_∩)O~   ， 之前做的比較不好的地方開發的單測其實沒有比較統一的規範，導致其實寫的單測覆蓋點不一定全，所以基本上感覺介面的質量最主要靠測試來把關的，一不小心測試，開發隨時就埋了個大坑，至今深有印象的一個bug是一個加日誌的專案， 開發在底層每個介面入口的地方打了一個日誌，剛好另外一個計劃任務的工程需要呼叫這個工程的一個清空購物車的介面，日誌那一行卡住了，然後導致購物車連續兩個小時釋放不了庫存，然後來了一個P1 故障，然後各種檢討~~~~所以，當開發說，我只是加了一行日誌，不用測試的時候，總是感覺瑟瑟發抖~~~~~

       第三 :專案測試:

        然後就是輪到我們測試的工作了 ，一直說強調質量前移，不要把所有的上線壓力都放在測試，但是這塊一直做的不夠好，不過也在慢慢的推進 ；之前都是一週釋出一次版本，每週三固定釋出日期 ，（有時候也會處理一些線上緊急問題啥的，有時候一週五天都在釋出，也是蠻坑的~~不過釋出從驗證到上線基本有一個值班的同學在跟就可以了，值班的同學當週一般專案會安排少一點） 所以專案排期的時候，一般是下週三要上線的專案，我們一般都會預估這週五前能不能完成，（預估的時間因為一起開始做介面測試寫自動化指令碼不太熟練，可以多加上這部分耗費的時間，排查倒排期的專案）如果不能完成，基本上都是不讓上了，這點還是做的挺規範的，然後每週一，二 是迴歸時間（不過自從我們在測介面功能測試的時候就寫自動化指令碼去做的時候，基本上回歸的時候跑指令碼就可以了，迴歸基本不用怎麼做~~） 

     因為每週都有版本要釋出，專案排期也比較緊，只有少部分的專案能夠在開發提測前就把自動化指令碼寫好，一般都是開發提測完後， 首先我們會去看開發的程式碼具體的邏輯改動點 ，然後結合產品的需求文件，結合開發給的提測wiki ,然後開始寫介面自動化用例， 目前的介面測試方法都是在自動化框架裡面 寫指令碼來進行介面的功能測試， 每個介面的用例單獨維護在一個excel 裡面，用例都是直接寫在excel 裡面（突然發現每個公司的用例管理平臺都有點卡，有點不好用~~O(∩_∩)O~ ） ，寫完後迴歸 的時候直接跑這些用例就可以了，這個專案的迴歸基本不用做了~~

     然後就是介面測試，手工測試方式有幾種，第一 ，基於公司的協議框架，每個工程的啟動的時候，都可以啟動一個網頁版的介面測試介面，自動去載入這個工程的程式碼的sdk包識別出來介面的每個方法，輸入介面引數去呼叫就可以了； 第二種方法就是用jemeter 來測試介面，這個jemeter的外掛是我組的一個測試大神弄出來的，然後被我組的開發老大挖去做資深開發去了，然後就輪到大家要測試他寫的需求了~~O(∩_∩)O ~~說好的一起吐槽開發呢~~jemeter 外掛 網上也有很多介紹，例如：https://www.cnblogs.com/yulia/p/6825027.html 這個 ；也看過這個大神寫的外掛原始碼，好像程式碼量不大，現在都想研究下也找不到原始碼了~~囧~~~ ，用jemeter來測試介面主要是方便平常有些除錯，排查問題免不了要手工去呼叫，這需要在jemeter 目錄的lib檔案裡面把工程的sdk包放進去，每個人本地都有一個jemeter，自己想放什麼版本都可以，不會互相沖突， 然後上線的時候， 我們需要通過跳板機去 驗收介面 ，也是可以通過jemeter去呼叫 ；做介面效能測試的時候也會有用到jemeter ,不過需要另外寫指令碼 ； 之前工程程式碼還是php的時候，是http的介面，也用過postman ,soapUI 來測試，公司也有測試介面的平臺，但是一般都不怎麼用公司的平臺，也不知道為啥之前，，可能覺得不好用~~哈哈哈~後來公司的介面測試平臺也沒人維護了，然後之前做介面平臺的人專門來搞一個自動化框架了，算是做的比較完善了，然後之後我們的介面測試一直都是在框架中來做了 ~~   

     
      第三 :上線 ，迴歸完成之後，週三會上預釋出，預釋出產品，測試，開發都會去驗收， 介面的驗收可以通過跳板機連線線上伺服器ip來驗收，上線是灰度釋出的過程，一般釋出第一批的時候測試會去看日誌， 日誌裡面有沒有報錯資訊這些， 看監控，訂單呀，購物車的流量有沒有下跌呀這些類似~~一般發現有問題幾分鐘內無法排查的必須馬上把程式碼回滾了~~這些好像區別不大~~

       然後來聊聊日常的介面自動化測試~~ 在前公司三年，做了三年的介面測試，業務驅動，需求很多，商品，購物車，訂單，總是有做不完的需求，並且屬於比較核心的域，容易出問題，很多時候，出故障往往是底層介面比較多 ，介面上一般不會有太大的問題 ； 從介面底層開始測試其實也可以避免在介面測試的時候遇到的一些奇奇怪怪的問題；以前做的介面自動化測試也分了幾個階段：

      1、端到端測試 ： 從一開始，基於php寫的程式碼的介面或者一開始java工程 的介面， 我們都是自己搭的框架，就簡單的testng+jsonAssert  來做， jsonAssert 這個jar包也是挺好用的，可以對json 進行寬鬆匹配，嚴謹匹配 ，有序無序匹配等， 然後我們會把介面的入參，預期出參整一個json 都放到excel裡面， 預期的資料庫的表其實也可以轉成一個json串 填到excel裡一列，腳本里面 把資料庫表的值讀出來和excel校驗就可以了，也可以使用mybatis 來寫資料庫語句， 但是好像之前都不怎麼用mybatis ； 寫表這塊對於介面測試 比較重要，所以之前的用例基本涉及到讀表或者寫表的都會有相關的校驗點 ；或者把介面的返回欄位和資料庫表的欄位進行對比 ；做的比較多的校驗是返回結果和寫表讀表 ，  後來不直接讀表讀es了，就通過mock ES 的返回來做了，但是es 的資料庫源其實還是來源於我們自己的表 ，redise 用的是 jedis-2.9.0.jar 包的一些方法 ,  快取讀取用的是Memcache 的XMemcached 客戶端讀取的（see:https://blog.csdn.net/heiyueya/article/details/64441901?utm_source=blogxgwz9）

           當時自己是在下單組，下單這個工程比較特殊，它裡面的介面 竟然沒有一個是要寫表的，都是讀取的外部介面，例如掉商品的，價格系統的，活動的，錢包的，訂單的，反正它就是不寫表， 當時 做端到端測試都是直接造好了商品資料，活動資料這些，然後自動化的資料都是用這些維護好的資料，然後直接在公司的唯一一套迴歸環境來跑，資料庫全公司各個系統的人都可以看到，這樣就會導致資料經常會被改，即使標註了不能改~~ 做端到端的自動化比較簡單，因為資料都是造好的，寫起來比較省事，有一個好處是在迴歸的時候跑的時候能夠發現其他系統的問題，但是不好的地方是維護起來不方便，老是要維護資料，不穩定~~

       2、然後就有了用線上資料的方案 ，剛好是因為這個工程比較特殊，不用讀表寫表， 開發做了一個從線上撈日誌的平臺，批量把每一次介面的請求入參和出參 ，還有介面呼叫外部介面的傳參和外部介面的返回都拿到 ，然後按介面維度護放到csv檔案，這個日誌平臺也可以根據不同的條件，例如各種不同活動型別，不同商品資料等，做這個平臺其實開發當初的初衷只是為了方便排查線上問題 ；  然後後來主要的功能就是用來撈日誌匯出csv 檔案來做自動化了， 一次一般可以匯出 幾千條請求，這些請求免不了有重複的 ， 我們拿到日誌的介面入參作為自動化case 的入參，拿到 介面的出參作為預期返回 ；拿到這次請求呼叫的外部介面 返回的json串 作為mock 的返回資料，  每一次請求都有一個唯一的traceId 標識 ，這樣就完成了一次完整的請求 （前提是這個介面不用讀表，有快取，佇列那些）。因為我們的指令碼都是寫好的了，只要業務邏輯不變，case一般都沒有多大問題，每個介面都可以匯出幾千條請求，剛好可以用來做迴歸測試，沒有了造資料的麻煩 ，也沒有了資料 被改的困擾 ；  不過缺點是 ：適用不用讀表的工程，讀表的因為沒有測試環境的資料庫和線上的不一樣， 比較難做到同步，  還有其實用線上撈資料應該要脫敏的，當時沒有去做~~

 這個方案的一個大概的流程圖是這樣的：

         3、本地啟動服務測試， 其實這個方案就是目前還在用的方案， 用了公司平臺組的一個比較完善的自動化框架（據說準備開源~~），支援UI 自動化，介面自動化等 ，支援多種協議，其實每個組還是要搭建自己的工程目錄，然後匯入框架的一些jar包 用到裡面的一些公共方法 ， 其實我所在的組也算是這個框架的最開始的使用者，他們給與了很多的技術上的支援，無條件支援業務組的需求~~~O(∩_∩)O哈哈~  ， 這個自動化方案有點類似開發做單測，但是不用在開發的程式碼裡面來做測試， 將工程的程式碼打service的jar  包，然後在本地pc機器啟動工程的服務 （這樣不用將部署到linux機器上）,  然後debug的時候匯入原始碼包就可以以直接本地debug了，寫自動化指令碼遇到問題debug十分方便， 也不用遠端連線到linux機器 ，  然後例如buy工程需要呼叫 活動系統的介面，我們會將活動系統的介面mock掉 ，配置中心也是直接mock掉的， 這些服務的啟動是框架實現的，不過用起來還是需要每個組自己配置，這裡就不展開了 ；  

             由於之前php 轉java 測試後，好多工程幾百個介面場景都沒有做自動化，然後我們都是把開發的程式碼拉下來，一個介面一個介面去看程式碼的實現邏輯，要呼叫的哪些外部介面，每種場景需要mock 什麼資料，這個介面讀了什麼表，寫了什麼表，基本上一個介面寫下來，對業務也是很瞭解了，當時是一邊做需求，一邊抽空把之前重構後的每一個介面涉及到的場景都用自動化去實現了，不用特地去整理用例，寫的時候看程式碼的過程就知道要設計哪些場景了，畢竟關於介面的業務文件其實很多都是沒有的，程式碼就是最接近線上的真實業務的體現 ，當我們把組內涉及到的每個介面涉及到的場景都用指令碼寫完了之後，大概用了三個月左右的時間， 6個工程大概 5000個左右的case，  這樣給後續的介面測試帶來了很大的方便，當有涉及到介面優化的時候，直接跑之前已經寫好的case就可以了；或者需求有改動的時候，其實只需要在介面上加場景就可以了， 效率會有一定的提升 ； 這種方式的好處就是 把外部介面的返回都mock了，不用擔心資料被改，服務返回不穩定導致case 出錯， 還是可以發現一些問題 ；不好的地方就是因為調外部介面都是mock調的，有時候呼叫外部介面傳參傳少了如果不去校驗其實不好發現，（這個其實可以通過Mockito的包裡面有個ArgumentCaptor 方法可以捕獲 入參，see:  https://yanbin.blog/mockito-capture-method-paramters/#more-7737）不方便聯聯調 。但是因為我們是底層，只要我們確認我們的欄位返回符合需求，一般不會有太大的問題。

          4、之後想要做到介面精準測試 ，目前還沒怎麼開始做，有一個大概的方案，可以寫一個介面去讀取開發 每個分支和另外一個分支，例如master的不同點 ,其實就是我們平常用的git diff 命令，但是可以寫程式碼匯入git 的jar包來實現（org.eclipse.jgit-4.10.0.201712302008-r.jar ， <groupId>org.eclipse.jgit</groupId>，<artifactId>org.eclipse.jgit</artifactId>） ，裡面 的類 org.eclipse.jgit.api.Git 下面 的多個方法 就是平常用的git 命令的一些方法，  將拿到的git diff 的資訊儲存下來，每一個改動點都追溯到上一層呼叫方法， 直到最上一層方法不被其他方法呼叫 ； 拿到的涉及到改動的所有介面 和方法，自動去匹配觸發呼叫我們已經寫好的介面自動化用例 ，這樣可以用來開發的冒煙，  我們可以根據程式識別出來的開發改動到的介面和方法，有針對性的去測試，也能預防開發改動到公共方法 的時候，有介面是漏掉要測試的~~

        介面測試還有很多可以做好的地方，目前我也是處於一知半解，只是把之前做過東西大概寫一下，可能寫的有不對的地方，歡迎指出一起討論啦~~~~

        文字好像有點多 ~~endning~~~~~