注：本文來自@ Monkey陳曄曄 的投稿。如果其他朋友也有投稿，請看這裡。
在看過吳穹對2014年測試的展望之後，真的對於移動無線測試的未來大有信心。在文章中再次看到了熟悉的“測試金字塔”，該金字塔是分層測試思想的重要鑰匙。我自己是移動網際網路出身的測試，所以突發奇想從移動無線應用的測試角度重新來審視了下該金字塔並做了擴充套件，希望對於大家有一定的幫助。
首先我們先來看下經典金字塔，如下圖所示：
這對於傳統網際網路的測試而言非常清晰的一個層次結構，但我相信對於很多移動網際網路的同學們而言也許就多少有些迷茫，這不單單是因為技術上的實現不同於以前，也有些是名詞定義問題。經過我思考之後，發現發現移動網際網路的應用測試角度出發可以從該圖上拆分出很多的東西，並且圖還有些小小的變化，如下圖所示：
單從這個圖上來看的話的確是比較迷惑的，那麼我們接下來就一層一層來剝，以下內容很黃很暴力，大家做好準備了嗎？
我們先來說第一層：UI層。UI層顧名思義就是使用者看到產品時候所長的樣子，從技術實現角度而言，那就是產品的一層皮。那麼UI層在移動無線應用的測試中分成哪些主要的部分呢？
1. 使用者體驗
2. 控制元件顯示
3. 功能互動
4. 程式碼介面
1. 使用者體驗
移動網際網路應用是一款產品，相對其他型別的產品而言，其使用者體驗已經到達了舉足輕重的地步，在我的新書《大話測試——移動網際網路應用測試指南》中有單獨闡述使用者體驗的一個章節，有興趣的朋友可以等出版之後仔細閱讀。
現在各個公司也出現了大量的和使用者體驗相關的崗位，比如“產品體驗師”、“產品設計師”、“互動設計師”等，也越來越說明著使用者體驗對於移動無線應用的重要性。
很多人覺得使用者體驗好就是一定要畫面優美，互動酷炫，介面上沒有出現明顯的瑕疵就可以了，雖然沒有錯，但這些僅僅是使用者體驗的表面一層。我們來看下以下的幾個例子。還是那句老話，也許你覺得他們的成功或失敗與使用者體驗關係不大，但其實從移動無線應用能夠成功的情況來看，使用者量、使用者黏性才是最主要的，這些歸根結底還是使用者體驗。在我的書中著實已經吐槽了非常多的應用了，在這裡就再吐兩個大家都認識的、知名度很高的應用。我們使用無線應用的時候難免碰見網路不好的情況，這也是現在大量測試工程師正頭疼的事情（幸好fiddler和Charles能夠為我們解決這個問題），但我相信如果我們在網路不太好，卻看到以下介面顯示的時候，肯定恨不得想摔手機。
也許我不說，大家也能夠猜得出來是哪家的應用了吧。我幾乎每次在餐館想要使用一些優惠券的時候就會看到這個介面，恨之入骨。難道網路慢彈出個提示就那麼難嗎？難道為使用者考慮一下就那麼難嗎？你能夠告訴我“createorderxxx”這串外星文使用者真的認識是什麼嗎？所謂使用者體驗好，就是要讓使用者覺得應用在說“人話”，而不是“火星語”。你採取如下方法都比現在的做法好：
- 可以選擇在使用者點選的時候就向伺服器做請求，此時並不跳轉介面，短時間超時之後給出一個“網路差”的提示
- 可以選擇進入這個介面，但不要給使用者看到“火星文”，短期超時之後再給出一個“網路差”的提示，並自動返回上一頁
說著說著我的火氣就上來了，不過還有更可氣的了。我們來看下面這個應用的行為。
碩大的logo，這個是什麼場景呢？現在支付寶和“喜士多”、“7-11”等多家便利店合作了，不但方便了大家的購物，同時也減少了零錢和假幣的流通，的確是個大好事。便利店網路不好的情況也尤其多，當我選擇好了很多商品，最後拿出支付寶，看到這個鳥樣，我心裡真的千萬只草泥馬奔過。但此時想想沒有關係阿，我作為iOS高大上的使用者可以殺程式，於是我熟練的殺掉支付寶的程式再次開啟，事實證明我無法改變這個鳥樣。我真的很焦慮，我知道支付寶要聯網，但它不是一個網遊吧，為什麼沒有網你就不能讓我開啟呢？我真的覺得讓我看到一個進入的介面或者設定一個短時間就超時都比我看著一坨黑色上面有個“菊花”強數百倍吧，於是，我的手機真的被我摔壞了。
2. 控制元件顯示
現在往往很多測試說測UI了就是拿過來看看介面顯示對不對，所謂UI Automation也就是模擬使用者的操作，但是真的僅僅只是如此嗎？Android的應用介面一切都是以View來構成：
請問有多少工程師關心過這些所謂的介面上的控制元件顯示的到底對不對呢？畫素值和比例與需求一致嗎？我們一般可以通過三步來解決這個的問題。
A． 先驗證每個介面顯示之後控制元件是否存在
B． 再驗證這些控制元件具體的位置、大是否正確
C． 最後驗證整體顯示是否正確
其中B可以使用如下所示的這個類來驗證：
而C的話我更偏向於自己去寫，而不是用MonkeyRunner自帶的圖片對比方法，其精準度不高，很難判斷圖片是否真的有細小的差異性，我自己更偏愛用PIL庫。iOS的話Xcode也自帶了Inspector可做相關驗證。
3. 功能互動
手動測試，自動化的話可用框架太多。Robotium，Instrumentation，Appium，這裡不多做解釋。
4. 程式碼介面
某些應用往往邏輯很複雜，但介面卻很簡單明瞭。其複雜程度體現在它的邏輯和資料場景。這類情況對於測試工程師而言尤其的痛苦，那麼自然我們就可以跳過介面層來做功能程式碼的介面測試。
接著我們來說下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等系統架構或其他特性上的區別了。
我個人是認為移動無線應用的金字塔理念不僅僅適用於功能測試，更多的也適用於壓力、效能、自動化甚至安全等測試中。當我們需要加大測試顆粒度的時候，那麼藉助分層的理念往往能夠讓我們豁然開朗，找到新的突破口。