qileilove

          blog已經轉移至github,大家請訪問 http://qaseven.github.io/

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

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

          posted on 2014-04-08 10:37 順其自然EVO 閱讀(151) 評論(0)  編輯  收藏 所屬分類: android

          <2014年4月>
          303112345
          6789101112
          13141516171819
          20212223242526
          27282930123
          45678910

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 五常市| 贺州市| 卫辉市| 新兴县| 荣昌县| 奎屯市| 天门市| 宜兰县| 万载县| 宜丰县| 修文县| 清镇市| 南华县| 留坝县| 东阳市| 南阳市| 仁寿县| 临清市| 阿城市| 松阳县| 林甸县| 都安| 金昌市| 汶上县| 上虞市| 玉龙| 罗田县| 西盟| 沈丘县| 镇宁| 静安区| 小金县| 长白| 远安县| 山阳县| 朝阳区| 禄劝| 吴桥县| 绥滨县| 凤凰县| 大新县|