自動化測試的三兩事兒 (下)

寫在前面

請允許我以一句“大連加油”開始自動化測試的三兩事兒的下半篇。雖然有些生硬以及格格不入，但是還請在座各位優秀的測試攻城獅們稍微體諒一下此刻疫情下大連人焦慮複雜的心情。特此宣告：本篇文章雖產自大連，但是決對安全，請放心閱讀~

關於自動化測試的另外三兩事兒

上半篇我們討論了什麼是自動化測試以及我們對自動化測試的誤解。下半篇主要討論一下自動化測試的優勢及實踐策略。
自動化測的優勢主要體現在以下幾點：

• 減少失誤率，提高準確性
• 節省時間和執行成本
• 提升測試覆蓋率
• 做手工無法完成的測試
• 為開發人員提高質量反饋速度

但是傳統自動化測試存在一些困境，測試用例執行成本高；執行頻率低，通常只在軟體開發完成後進行；質量反饋滯後；測試環境準備成本高；測試結果可信度低；人員依賴性強。因此在持續整合實踐對自動化建設有了以下基本衡量維度：

• 快速：最好再10分鐘內，不要超過15分鐘
• 便捷：每個人都可以隨時方便地執行自動化用例，不需要別人幫忙也不影響別人
• 及時：功能一旦改變，就能通過自動化測試用例告知對軟體質量的影響
• 可信：不存在隨機失敗的情況，有失敗立即修改

自動化測試的實施策略

在實施自動化測試時應該增加自動化測試用例的今天今天著手點，針對程式碼熱區補充用例，隨時跟進新功能的開發進度，從測試金字塔的中間層開始，向兩端擴充套件，測試用例的質量比數量更重要，在保證質量的前提下用例數量越少越好。團隊應該共享自動化測試的維護職責，用例程式碼也需要設計並且很好的維護，當有人對測試失敗結果視而不見的時候就出現“破窗效應”。關於程式碼覆蓋率，谷歌給出的建議是85%，非常重要，但也非常不重要。程式碼覆蓋率是一個實實在在可衡量的指標，但是至於具體的數值，也要因專案情況而異。而良好的自動化測試應該滿足以下特徵：

• 用例之間必須相互獨立
• 執行結果必須穩定
• 執行速度必須夠快：sleep少用，可以分解用例或用輪詢替代
• 測試環境統一，不要只能在個人機器上執行

關於自動化測試的一些心得：

• 自動化測試用例執行次數越多，平均成本越低，收益就越大；
• 自動化測試用例之間應該儘可能相互獨立，互不影響；
• 在質量有保障的前提下，自動化測試用例的數量越少越好；
• 遺留程式碼的自動化測試編寫應該從程式碼熱區開始；
• 自動化測試用例從測試金字塔的中間層開始補充，投入產出比最高。

最後，今天你測試了麼？