[自動化測試][單元測試]自動化及單元測試裨益淺析

“自動化測試”淺析
     
對于“自動化測試”的誤解
 
很多人認為“自動化測試”就是自動執行并自動分析程序正確與否的測試方法，那讓我們看看事實是否如此
吧。
 
 以百度(www.baidu.com)搜索界面為例，測試頁面Layout的正確性：
 1.    頁面元素（元素是否齊全、位置是否正確、文字是否正確、超鏈接是否正確、多媒體是否正確）
 2.    頁面展示（樣式是否正確、縮放窗體自適應、瀏覽器自適應）
 3.    腳本兼容
 一個如此簡單的設計，倘若為了實現全“自動化測試”，僅實現以上檢查點各元素枚舉所需的（用例設計、
腳本開發、代碼審核的）工作量就相當可觀，對這個龐大腳本的維護成本更是難以估算。
     
既然實現“自動化測試”如此復雜，還有必要推廣嗎？
 
答案是肯定的。因為導致上述困境的唯一原因是我們忽略了“自動化測試”成立的前提：
 1.    工具的支持
 2.    人力、時間成本的投入
 3.    投入人員的技術能力
 4.    測試用例、測試數據的完備性
 5.    環境部署的獨立性與正確性
 6.    測試代碼的可維護性、重用性及正確性
 所以當
 1.    程序更新頻繁
 2.    程序耦合度高
 3.    程序優先級高
 時，可將不同模塊不同場景不同優先級的功能抽離出基本業務邏輯，構成所謂的通用用例進行自動化。
 除了日常對系統的例行檢測外，還可根據具體場景排列出各種組合，滿足大項目所需的首輪smoke test
，識別功能性block。
 
 另，“自動化測試”還存在許多附加收益，比如：
 1.    測試數據構建
 2.    測試數據積累
      （不同場景下的數據積累可在日常手工測試中得到復用和維護）
 3.    基本功能展示
      （對于員工熟悉產品起到直觀的展示作用）
 4.    等等
 
 常用的測試輔助工具除了“自動化測試工具”QTP和Selenium外還有：
 1.    Excel: 滿足一定規律的數據統計
 2.    SQL:   數據驗證、還原
 3.    LoadTest: Web Test（簡單業務的檢查點校驗）、Load Test（并發處理正確性）
 4.    UnitTest: 白盒測試（含覆蓋率統計）

“單元測試”淺析

 同樣，也有人認為實現了單元測試就等于實現了該單位功能所有業務場景的校驗，這也是沒有根據的。因
為1行代碼需要多少句進行驗證是無法估算的。
 即便有人寫出了所謂的單元測試代碼，那他的測試代碼的正確性又該有誰來保證？這就構成了死循環。
 
 所以常見的Unit Test真正起到的作用，是保證在data contract一定時，功能不被block且輸出結果
滿足約定，僅此而已。