測試金字塔新解之移動無線應用測試(2)

控件顯示 現在往往很多測試說測UI了就是拿過來看看界面顯示對不對，所謂UI Automation也就是模擬用戶的操作，但是真的僅僅只是如此嗎?Android的應用界面一切都是以View來構成：

　　請問有多少工程師關心過這些所謂的界面上的控件顯示的到底對不對呢?像素值和比例與需求一致嗎?我們一般可以通過三步來解決這個的問題。

　　A. 先驗證每個界面顯示之后控件是否存在

　　B. 再驗證這些控件具體的位置、大是否正確

　　C. 最后驗證整體顯示是否正確

　　其中B可以使用如下所示的這個類來驗證：

　　而C的話我更偏向于自己去寫，而不是用MonkeyRunner自帶的圖片對比方法，其精準度不高，很難判斷圖片是否真的有細小的差異性，我自己更偏愛用PIL庫。iOS的話Xcode也自帶了Inspector可做相關驗證。

　　功能交互

　　手動測試，自動化的話可用框架太多。Robotium，Instrumentation，Appium，這里不多做解釋。

　　代碼接口

　　某些應用往往邏輯很復雜，但界面卻很簡單明了。其復雜程度體現在它的邏輯和數據場景。這類情況對于測試工程師而言尤其的痛苦，那么自然我們就可以跳過界面層來做功能代碼的接口測試。

　　接著我們來說下Service層。與傳統金字塔描述的Service不同的是，移動互聯網的應用同時存在“Service”和“Inner Service”(感謝晉恒溫提供這樣一個我覺得很不錯的新詞)這里的Inner Service主要指的是Android基礎組建里面也有一個叫Service

　　這里提到Inner Service這個概念就是為了和服務器端的Service區別開來。在這個金字塔中Service被虛線所區分開，原因有兩個：

　　Service不再單純的指后臺服務器的Service

　　不是所有應用都有Inner Service或者Service

　　其中后臺的服務Service測試方法已經相對成熟，參考的資料也相對多，而Inner Service的測試相比困難很多，除了監聽Service是否正確啟動以及反饋之外，還有很多測試細節可挖掘。

　　最后就是共同的Unit了。其實我們撥開金字塔的上面幾層，到Unit test的時候就已經和應用所在的平臺的特性關系不大了。Android使用Junit Test，iOS使用Xcode自帶的OCunit，WP使用Windows Phone Toolkit Test Framework等。除了編寫測試用例的語言不同以外，其用例的設計方法等已經不再去考慮Android、iOS、WP等系統架構或其他特性上的區別了。

　　我個人是認為移動無線應用的金字塔理念不僅僅適用于功能測試，更多的也適用于壓力、性能、自動化甚至安全等測試中。當我們需要加大測試顆粒度的時候，那么借助分層的理念往往能夠讓我們豁然開朗，找到新的突破口。

原文轉自：http://www.testwo.com/article/89