經過自動化測試發現缺陷

[本文出自天外歸雲的博客園]

今天在tx內部作了一次關於自動化測試發現bug的分享，把ppt的內容總結下：

對於自動化測試沒法發現bug的緣由嘗試分析

1. 自動化模擬程度不夠高：自動化過程不能有效替代手工過程，從而致使沒法發現經過手工探索能夠發現的bug

2. 自動化發現問題見效晚：由於開發也寫單測，並且有code review，對於主要單元邏輯出錯的機率不大，這致使單測發現問題的階段後移，有效的單測在代碼重構之日就是見效之時，因此增量需求經過單測來發現問題難度較大，但做爲重構時的迴歸用例是合適的，可以彌補手工過程的細微不足之處

經過自動化測試發現bug的方法總結（終歸第一點）

1. 一元生態構建：構建自動化能力生態，確保每個手動行爲和肉眼驗證都有對應的自動化封裝和實現替代：好比音頻模塊，那麼針對minibar是否出現的判斷是必備的能力封裝，還有對音頻播放狀態的判斷封裝，獲取到音頻bar的能力封裝，操做切播的能力封裝，底層頁音頻入口的點擊能力封裝，音頻專輯頁的按鈕操做能力封裝等等，針對場景的自動化測試能力的強弱主要體如今將手工執行用例包含過程的還原度上，好比進入頁面是點一個按鈕進入的，可是你是經過直接構造一個頁面進入的，這是不等價的。省時的未必是好的，自動化測試的有效性必定程度反映在模擬用戶行爲的程度上

2. 二元代碼走查：可以對基本函數的輸出結果產生預期，從而在非運行時可以根據需求分析代碼邏輯是否符合預期，針對代碼的改動處開始進行串聯式邏輯走查

3. 三元運行調試：對客戶端代碼的運行與調試能力，可以經過代碼邏輯針對改動進行分析，順藤摸瓜式找到請求的接口和下發的控制字段，有經過打斷點、打log等方式搞清軟件運行過程，對問題的緣由作出判斷的能力

4. 三元歸一：擁有了第二和第三點的能力，就能夠知道一些控件具有哪些屬性，哪些方法，如何獲取，如何觸發。歸根結底是經過對原生函數作出合理的調用和封裝，來實現提高自動化生態構建能力的目的（第一點）