《移動App測試實戰》讀書筆記

第一章 概述

什麼是移動產品？ 移動產品是一個能夠在移動設備上安裝的App，或者一個能夠在移動設備上訪問的定製頁面。

 

1.1 研發流程

互聯網產品的研發過程主要涉及如下職位分工。

產品經理：負責產品方向或需求規劃，需求可能來自於產品經理本人或者由其代理的第三方客戶

項目經理：負責項目實施安排，資源、進度、變動、風險等

設計師：產出設計原型

開發：產出可運行的實際產品，也可細分爲架構師、後臺開發、web前端開發、Android開發、IOS開發

測試：質量把關，負責產品的功能、性能、穩定性的測試

運維：負責產品服務端運行環境的維護，平常的配置管理、容量規劃、網絡和設備故障燈，也包括監控平臺的建設

運營：負責產品的推廣

研發流程通常爲：需求規劃—>開發實現—>產品體驗（主要由產品經理進行，產出體驗反饋郵件）—>測試—>發佈—>運營

測試人員在該流程中的主要職責有：參與需求評審—>測試用例設計/測試用例評審（產出測試用例）—>協助準備產品體驗環境—>測試執行（產出bug）—>發佈情況關注—>上線後（線上問題彙總）

從測試人員的角度，現場會議式的需求評審的價值主要在如下幾個方面：

1）理解需求，爲編寫測試用例打基礎

2）基於對需求細節的瞭解，能夠更準確地評估測試的要點和工做量

3）發現需求中模糊不清的地方，從質量管理的角度進行

另外對於實現複雜的功能，還須要進行技術方案的評審，不瞭解技術細節，不少測試場景都沒法覆蓋

1.2 測試用例的設計和評審

不編寫測試用例的缺點：

1）測試會很盲目

2）體現了測試的系統性、深度和效率

3）不便於知識的積累和傳遞

編寫方法：通常先編寫測試設計文檔，再編寫正式的測試用例，本書做者給出的測試用例示例也是使用思惟導圖形式

Android名詞：增量升級（Smart App Updates）

最快速提升測試設計能力的實踐是參加測試用例評審，能夠很快打開測試思路；另外就是用例設計的workshop，由所有的測試人員參加，各抒已見，能夠看出每一個人對測試的維度、深度、全面性

 

1.3 測試進度管理

 

第二章 功能自動化

主要包括基於接口的自動化和基於App UI的自動化

2.1 輕量接口自動化測試

web產品和移動產品都必須依賴大量的後臺接口提供的服務，能夠經過模擬UI操做，從界面上發起請求來測試，可是效率不高且穩定性很差。最好的辦法是從接口層面發起請求。

一些比較穩定的基礎性組件，如底層平臺、API、SDK等；或者功能通用性高的產品，能夠作到比較高的自動化率，偏重應用層業務的，則相對困難。

2.1.1 特性介紹

選用開源測試工具Jmeter的優勢以下：

1）支持多種不一樣類型的協議

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2）對HTTP協議的支持比較全面，還提供了cookie管理、cache管理、消息頭和受權管理等

3）其餘非直接支持的協議能夠經過擴展方式實現，能夠經過Jmeter的OS Process Sampler來進行橋接和測試

4）支持豐富的斷言

5）支持內嵌自定義腳本，可使用Javasript和Java等語言

6）能夠直連DB檢查數據

7）能夠嵌入執行第三方命令行

8）文本的輸入和輸出

9）圖形界面和命令行啓動執行

10）工具自己很是穩定，有用戶基礎

2.1.2 實踐

一些名詞：

CGI—單個業務接口

Function—一個對外有邏輯意義的請求組合

TestCase—一個成品

TestSuite—一個用例的集合

大體講解了如何組織自動化測試，未具體實踐，所以未截圖，先略過這裏

2.2 UI層面的自動化

對於一個在快速發展中的App，UI自動化可能更適合一些基礎功能的迴歸，而不是替代手工的功能測試，特別是對於新的功能點。

2.2.1 Android的UI自動化

.... 移動App的自動化測試暫未用到，這裏直接略事後面關於Android和IOS App的自動化測試，跳到第三章

 

第三章  性能測試

性能測試的開展和被測系統特色相關，針對移動互聯網產品的構成，性能能夠分爲前端性能和後臺接口性能，進一步，前端又分爲web頁面和原生的App代碼。

3.1 web前端性能測試

移動互聯網產品，前端性能涉及web的主要有兩部分：

① M站，即觸屏版（使用手機瀏覽器訪問）

咱們在PC瀏覽器和手機瀏覽器上輸入同一個網站的同一個URL，返回的內容徹底不一樣。這是考慮了手機屏幕的大小和流量等狀況，返回了專門的M版本。

② 混合App的存在，既有原生代碼，也有內嵌的網頁（使用App內嵌的瀏覽器組件，如WebView實現）

原生模板有限，開發新模板又須要時間，使用html頁面會更加靈活和便利

HTTP藉助下層的TCP協議來運做，HTTP請求由：請求行、消息報頭、請求正文（可選）組成；HTTP響應由：狀態行、消息報頭、響應正文組成

能夠經過網絡抓包工具（如WireShark）從TCP協議層面來了解HTTP的交互過程，TCP鏈接創建（3次握手）—發出HTTP請求—響應返回—TCP鏈接斷開（4次揮手）

* TCP鏈接是能夠複用的，能夠用一個TCP鏈接來發起多個HTTP請求，鏈接的複用對於性能的提高是很重要的，瀏覽器和不少HTTP請求模擬測試工具都提供了一個參數，能夠對這個並行鏈接數進行設置。

* 瀏覽器並非獲取了整個頁面完整的html文件後再進行解析，併發起對其餘資源的請求；而是獲取了部分的HTML內容後，就開始瞭解析，並基於解析的內容發起了針對其餘頁面元素的請求，這樣更加高效

* 從HTTP1.1 開始，支持了pipeline方式，能夠實如今同一個TCP鏈接下，一個HTTP請求若是因爲服務器處理時間或響應文件太大而暫時沒有響應，能夠繼續發出第二個HTTP請求，而沒必要等待第一個HTTP響應的返回

可是，在chrome瀏覽器中試用時，有明顯的缺陷，指望的HTTP2.0中能有所改善。

HTTP協議中有一些特性和性能息息相關：

* HTTP傳輸過程當中的數據壓縮

HTTP頭信息中 Accept-Encoding 來標識是否使用gzip，只有客戶端在頭信息中指明可使用時，服務端才返回壓縮的內容，另外一方面，服務器端也要開啓壓縮相關的設置

* 緩存的管理

在第二次請求頁面後，部分HTTP200響應被標識爲（from cache），表示本次訪問時這些URL內容都是直接從本次緩存文件中讀取，而不是經過HTTP請求來獲取的

緩存過時後，再次請求，響應爲HTTP304 Not Modified，發起了HTTP請求，可是服務器接收到瀏覽器的請求後，判斷認爲服務端最新的該文件版本和客戶端已有的一致，因而告訴客戶端不須要再傳輸完整的內容了，能夠直接用本地的版本。這樣的好處是：雖然客戶端仍是要發起請求，可是服務端只需經過304簡單應答，而沒必要從新傳輸文件的內容，一樣起到緩存的目的。

這樣處理也會有欠考慮的狀況，最好的辦法是經過Etag來判斷緩存是否有效。Etag經過計算文件的哈希值來判斷文件內容是否被修改。

web前端的性能測試方式：

前端經常使用的性能測試工具很是多，如：Fiddler、Yslow、HttpWatch、Firebug以及各個瀏覽器自帶的開發者工具等，也有一些在線的前端性能測試工具，如WebPageTest.

對於M站應用，如何來調試用手機瀏覽器訪問的頁面？

在Chrome瀏覽器上安裝ChromeADB插件—將手機經過USB線與PC鏈接，在PC的Chrome瀏覽器裏打開如下的URL：chrome://inspect/#devices就能在PC瀏覽器中看到鏈接的手機和手機上Chrome中打開的頁面，而後用PC瀏覽器進行調試。