此文已由作者王婷英授權網易雲社群釋出。

歡迎訪問網易雲社群，瞭解更多網易技術產品運營經驗。

為了儘可能多的釋放手工測試，提高測試效率，我們都會想到使用自動化測試，如http介面自動化測試、doubbo介面自動化測試、UI自動化測試等一系列的自動化測試。讓我們覺得原來自動化測試的種類也是多彩多姿的。

當前自動化測試在行業中投入的比例如下圖：

           圖1 網際網路行業自動化投入黃金角

當前考拉這邊投入比較多的是單元測試和介面測試，比較符合當前測試行業的投入自動化的比例情況。目前，我們在http介面執行持續整合CI的時候，經常會出現測試用例執行失敗了。詳細的失敗呼叫情況資料（資料來源於考拉質量平臺）如下：

              圖2 http介面執行失敗的資料統計表

從圖2中，我們可以看出，當前考拉的介面自動化不穩定的比例如下：環境問題佔57%，資料問題佔25%，測試用例問題佔4.5%，其他問題佔10.5%，發現bug數佔3%。前三名分別是環境問題、資料問題和其他。

1. 環境問題：這個問題是存在多元因素導致，整個考拉的工程之間的關係鏈比較長且有一定的複雜性，需要在環境迭代中找到平衡的方法。

2. 資料問題：這個目前有很多種情況會發生資料問題，如下：

    (a)測試用例裡的測試資料，在測試環境被別人動了，改變了這條資料的屬性狀態，或者是資料已經別刪除了
    (b)測試用例裡的測試資料對應的測試用例比較一次性，只能跑一次，每次跑之前，都需要把資料提前準備好
    (c)資料庫連結變更後，測試用例的測試資料檢驗不通過，需要重新調整測試資料的獲取源

    3. 基本上資料問題就上面說的幾點，不過應該還存在一些遺漏，主要是結合自己在跑介面自動化的時候出現的一些問題。

其他：這個暫時沒有進行調研   

上述過渡說了當前考拉介面不穩定的原因進行了簡單的分析。

那麼接下來，我們一起聊一聊如何避免介面測試用例資料的不穩定。

下面我們來簡單的看下一個簡單的介面測試用例的迭代優化，以達到一定的穩定性。

例如：delete操作的介面

該介面只要是刪除長文裡許可權列表裡的使用者（只要在這個列表裡的permissionid始終為10001，而openId會發生變化

               圖3 delete介面的V1.0

圖3中，直接將openId直接賦值，這樣就會導致一個問題，只能刪除這個指定的使用者，且自動化跑了一次之後，這個介面再次重新跑就會直接失敗。這種介面測試用例非常的不穩定，當然初次寫的時候，很多人會先這麼寫，寫完之後，再進行優化。

                   圖4 delete介面的V2.0

圖4是對圖3的V1.0進行的一次迭代，使用了list介面來協助delete介面，同時使用了TestNG裡的dependsOnMethods依賴執行的方法將兩個介面合在一個接口裡，並將openId這個欄位進行引數化。一般這種情況下，delete介面是相對於V1.0是非常穩定的。但是這個有一個弊端就是萬一這個list的size==0，那麼此時delete介面已經會跑不通過。那麼這個介面就需要我們再一次對其穩定性進行迭代。

                     圖5 delete介面的V3.0

圖5和圖3長得很相似，但是V3.0的迭代版本是將V1.0和V2.0進行結合在一起。具體操作如下：

                    圖6 delete介面V3.0的流程圖

如果delete介面按照V3.0進行，那麼類似這種資料穩定性基本上是可以解決。

當然測試用例資料的穩定性還有其他型別的。後續我們遇到了類似的場景繼續進行研究分析,有更好的建議可以pop私信我，再好好交流。本次就先聊這麼多哈^_^

網易雲免費體驗館，0成本體驗20+款雲產品！ 

更多網易技術、產品、運營經驗分享請點選。

相關文章：
【推薦】 談談資料庫的跨機房容災-網易雲
【推薦】  360°透視：雲原生架構及設計原則
【推薦】 SpringBoot入門（三）——入口類解析