[本文出自天外歸雲的博客園]
今天在tx內部做了一次關於自動化測試發現bug的分享，把ppt的內容總結下：
對於自動化測試無法發現bug的原因嘗試分析
1. 自動化模擬程度不夠高：自動化過程不能有效替代手工過程，從而導致無法發現通過手工探索可以發現的bug
2. 自動化發現問題見效晚：因為開發也寫單測，而且有code review，對於主要單元邏輯出錯的概率不大，這導致單測發現問題的階段后移，有效的單測在代碼重構之日就是見效之時，所以增量需求通過單測來發現問題難度較大，但作為重構時的回歸用例是合適的，能夠彌補手工過程的細微不足之處
通過自動化測試發現bug的方法總結（終歸第一點）
1. 一元生態構建：構建自動化能力生態，確保每一個手動行為和肉眼驗證都有對應的自動化封裝和實現替代：比如音頻模塊，那么針對minibar是否出現的判斷是必備的能力封裝，還有對音頻播放狀態的判斷封裝，獲取到音頻bar的能力封裝，操作切播的能力封裝，底層頁音頻入口的點擊能力封裝，音頻專輯頁的按鈕操作能力封裝等等，針對場景的自動化測試能力的強弱主要體現在將手工執行用例包含過程的還原度上，比如進入頁面是點一個按鈕進入的，但是你是通過直接構造一個頁面進入的，這是不等價的。省時的未必是好的，自動化測試的有效性一定程度反映在模擬用戶行為的程度上
2. 二元代碼走查：能夠對基本函數的輸出結果產生預期，從而在非運行時能夠根據需求分析代碼邏輯是否符合預期，針對代碼的改動處開始進行串聯式邏輯走查
3. 三元運行調試：對客戶端代碼的運行與調試能力，能夠通過代碼邏輯針對改動進行分析，順藤摸瓜式找到請求的接口和下發的控制字段，有通過打斷點、打log等方式搞清軟件運行過程，對問題的原因做出判斷的能力
4. 三元歸一：擁有了第二和第三點的能力，就可以知道一些控件具備哪些屬性，哪些方法，如何獲取，如何觸發。歸根結底是通過對原生函數做出合理的調用和封裝，來實現提升自動化生態構建能力的目的（第一點）