聊聊自動化測試有效性(2)

　　我們可以期望用自動化測試來暴露所有的問題供使用者抉擇，而非用來精確定位每一個問題。即便我們不期望自動化測試發現所有的BUG，但是我們必須要用發現每一個BUG的標準去分析設計和利用我們的自動化測試用例。

　　方法之一：善用手動測試用例庫

　　如果有完整或近乎完整的手動測試用例庫，在做自動化測試的時候用它來甄別自動化測試范圍、做自動化測試需求分析和設計是非常棒的，可達事半功倍之效。因為除了SLA簽訂的關鍵功能清單，我們可以分析測試用例庫中最近X 個月、Y個版本中被執行的測試用例的頻率和比例等等數字，從而很容易得出最有價值做自動化測試的范圍，而如有其他因素也可以加入綜合評估。這時候，關聯或映射手動測試用例和自動化測試腳本可以很容易地衡量自動化測試的覆蓋率等相關指標。

　　除此之外，手動測試用例之于自動化測試開發的意義還在于一種特定模式下的自動化測試開發：測試人員按照一種特定的規約編寫產品或項目的手動測試用例，隨后用一種模型化的轉換規則去生成自動化測試腳本，繼而再去修改和優化。這種模式的好處是，自動化測試腳本的開發者不需要懂業務知識，只需要按照業務測試人員編寫的詳盡的測試用例去實施。而不足之處卻也十分明顯，由于思維方式上的差異，編寫測試腳本過程中的溝通成本不會太低，而且對建模水平要求很高。

　　方法之二：搭建適應性強的框架

　　開源測試工具，我們組先后用過Selenium RC、WebDriver、WatiJ這幾種工具模式，框架采用JUnit和TestNG，測試調度和CI使用Jenkins管理。做起來最大的感受就是，像WebDriver這種工具，它本質上是為互聯網而生;如果要用于我們的企業ERP應用的自動化測試，如果沒有做一系列適應性的API和組件封裝，測試腳本開發對于大部分同事來說都是件頭疼的事情。

　　經過摸索，我們結合PAFA(PingAn Foundation Architecture)架構的前端頁面特征做了對象識別、頁面加載和處理緩沖、運行監聽、數據處理、斷言和運行容錯、報告、日志以及第三方組件(如 Autoit、Cmd等)兼容的封裝操作。這種封裝屬于Bot-Style，適用于我們基于業務操作驅動的自動化測試用例編寫，能夠大大地降低我們測試腳本開發的技術成本。雖然它們看起來運行起來效率并不是十分高，但是對于被測應用的響應速度來說已經是數十倍的效率勝出了。至于使用Page Object還是Bot-Style，還請大師們不要吐我的槽，這沒什么可爭論的，因為這只是面向前端業務操作的頁面測試，二者的表現毫無優劣之分，完全在于隊員的測試腳本編寫風格偏好。

　　附圖1：測試中的TestCase樣例

　　附圖2：測試中的TestApi樣例

　　我們正在從瀑布開發模式下逐漸開展持續集成和敏捷轉型，不難預見，達到一定成熟度之后我們大部分團隊會使用ATDD模式。這種快速開發的基于前端的自動化驗證測試雖然在驗證測試中所占的比例會越來越小，但它們將依然有用武之地，同時對當下的系統前端的回歸測試也可以完全支持。

　　自動化測試框架強大與否主要在于其適應性，所以與其說自動化測試框架是選擇出來的，不如說它是被改造出來的。產品比較單一的小公司或者開發框架比較成熟的公司用一個工具、一個框架在一個測試平臺下就可以解決一個公司的自動化測試實施的絕大多數問題，而大型企業的應用繁多復雜，很難由一個簡單工具或者框架來解決。

　　自動化測試框架，沒有自己DIY過的永遠都不要相信不造輪子這種說法，因為只有在你做的時候，你才能夠更深入地理解你的工具、框架和你的被測應用及其所依賴的開發框架的特征，才會產出更具適應性的測試框架和特征庫。

　　方法之三：善用設計與重構

　　無論是前端自動化測試還是單元測試，腳本代碼結構的重要性是個老生長談，因為這關乎測試腳本代碼的可讀性、維護經濟性等問題。由于我們的業務系統的測試案例主要是基于操作流程的業務場景，所以我簡單說一下我們在這方面的做法與經驗，而單個功能點特性的測試分析也基本與此類同，不再獨占篇幅。

　　測試范圍與設計

　　大型企業，尤其是金融行業的ERP應用，很多系統實際上都是規則零散、流程復雜，規則引擎應用得并不是很充分。這便是前文所提及的自動化測試分析設計時對輸入條件分支和狀態機組合的窮舉和選擇困難的問題的產生原因了。對于這種情況，我們可以借鑒兩個基礎的測試設計方法：正交覆蓋和Pairwise/All-Pairs，其基本原理和用法這里不再贅述。

原文轉自：http://www.uml.org.cn/Test/201307094.asp