1）更好地了解網路運作模式

為了更好地理解網路運作，首要是查看開放系統互連網路模型（Open Systems Interconnection Model, OSI，後續簡稱OSI模型）。OSI模型是促進不同主機之間通訊的標準。

1. 會話層（Session Layer）：負責在資料傳輸中設定和維護裝置網路中兩台裝置之間的通訊連接。
2. 傳輸層（Transport Layer）：提供使用TCP / IP通訊協定進行資料傳輸。
3. 網路層（Network Layer）：定義了網路中資料的路由。
4. 資料鏈接層（Data Link Layer:）：在網路間建立邏輯連結，且在傳輸過程中處理錯誤偵測以及流量控制
5. 物理層（Physical Layer）：舉凡涉及網路的所有實體設備，例如：電纜、交換機、路由器、以太網等。
6. 表示層（Presentation Layer:）：把資料轉換成能相容接收者的系統並適合傳輸的格式。
7. 應用層（Application Layer）：提供使用者界面層，其中使用者和網路與應用程式進行互動。

在真實場景中，瀏覽器和應用程式的溝通行為會在應用程式層、表示層和會話層等層中使用HTTP進行。TCP協定在傳輸層中執行，而IP協定在網路層中執行。Wi-Fi在物理和資料鏈路層中執行。

網路方面

在檢查網路中的資料傳輸行為時，需要考慮以下3個重要因素。

1. 延遲：透過網路將封包從一個節點傳輸到另一個節點，所需的接收回應時間。
2. 流量：在特定時間內所發出的傳輸的資料總量，以每秒位數或每秒封包為單位。
3. 封包遺失：主機發送10個封包時遺失的封包數量。

TCP模型中的”Window Sizing”

因此，封包遺失會嚴重影響流量。

連接故障

這是建立連接時執行的任務：

1. DNS (Domain Name System, 又稱：網域名稱系統)查詢：當使用者在瀏覽器利用網址列中輸入網址時，主機將向網路供應商發送DNS請求並從網路供應商接收IP位置。
2. 安全通訊協定(Secure Sockets Layer, SSL)交握：為了保護資料的隱私性和完整性，經Client端驗證伺服器之鑑別性後，兩者之間會建立安全傳輸通道並進行資料傳輸通訊。整個建立安全傳輸通道的過程稱為”SSL交握”。
3. 發送請求(Send request)：建立安全連接後，Client端會將請求發送到伺服器。
4. 等待回應(Wait for response)：發送請求後，Client端等待伺服器提供的訊息。
5. 下載的內容：當伺服器提供所需的訊息時，使用者可以下載所需的內容。

為了分析移動效能，計算每個任務的時間很重要。

1. DNS Time：當使用者嘗試打開CNN網站時，使用者在瀏覽器網址列中輸入URL。DNS時間是Client端主機與DNS伺服器聯繫並接收IP位置所花費的時間。
2. 連接時間：Client端使用SYN(Synchronize sequence numbers)來發起與CNN Web伺服器的連接。Web伺服器以SYN / ACK進行回應，而Client端以ACK (Acknowledgment field significant)進行確認。整個過程的總時間就是連接時間。
3. SSL時間：Client端主機和Web伺服器之間進行SSL交握所花費的時間
4. 等待時間：Client端主機等待從Web伺服器接收訊息的時間。
5. 接收時間：Web伺服器將所需訊息提供給Client端所花費的時間。

在實際情況下，如果使用代理伺服器進行連線。上述的整個過程將會重複進行。Client端通過代理伺服器與Web伺服器建立連線。此時需將額外花費時間納入考慮。

使用Waterfall view方式檢視HAR

HTTP存檔格式（HTTP Archive Format, HAR）是一個有用的選項，可讓您記錄和跟踪瀏覽器與網站的互動。使用HAR文件，您可以分析效能問題以及頁面渲染問題。

• 要在Chrome中生成HAR檔，請打開Chrome瀏覽器，然後打開Experitest網站。
• 轉到Chrome設定 -> 更多工具
• 選擇開發工具 -> 網路
• 選擇保存日誌複選框，然後單擊錄製按鈕
• 錄製完成後，右鍵單擊並將其保存為帶有內容的HAR

HAR文件如下圖所示：

清楚地視覺化了Experitest網站的加載過程。由此可瞭解網站的各項元件加載到螢幕上需要花費多少時間。

2）效能 – 使用者角度

從使用者角度來說，評估App的效能可歸納成以下三個面向。

• 持續時間：網站需要耗費3秒以上才能加載完成，有50%的使用者會感覺厭惡。
• 佔用資源：使用者會因為App消耗更多資源（例如：CPU、儲存空間、電池和資料）而刪除。
• App Store：使用者會依據App Store的評分來進行判斷，評分五星往往是因為效能優良，故吸引更多客戶使用該應用程式。

專注於交易

交易是一個透過使用者介面觸發向伺服器發送請求並獲得回應的過程。從使用者的角度來看，交易所花費的時間很重要。

以下是交易的關鍵指標。

• 持續時間：交易時間應盡可能短
• CPU/電池：盡可能降低CPU和電池的消耗，可提高客戶體驗
• API呼叫次數：使API呼叫次數保持最小並並行執行很重要
• 下載資料：降低通過REST API下載圖像和影片，可提高交易效能
• 伺服器回應時間：伺服器回應Client端請求所花費的時間很重要。測量單位應為接收第一位所花費的時間。

速度指數

當使用者打開網站時，網路伺服器端會接受到Client的請求，其後便會回應所有網站內容。瀏覽器處理回應內容的時間會大大影響使用者的體驗。換句話說，頁面加載時間會影響應用程式效能。

如下圖範例所示：網站A加載需要5秒鐘，一次性載入並顯示所有元素；網站B加載需要5秒，但是在開始的2秒內加載了50％的頁面元素，然後逐步加載了其他元素。對使用者來看說，網站B提供了良好的體驗。

在檢視頁面加載時間時，兩個網站在1秒後處於相同的級別，但是網站Ｂ在下一秒躍升到90％。

3）如何提高移動效能？

上述的網路概念點出了對於測試環節的重要性，組織更應該專注於如何改進效能測試流程。通常，組織會依據構建App、構建伺服器、部署伺服器、上傳App並執行測試等流程不斷循環。往往效能測試環節會在整個開發流程的最後一步。甚至出現由使用者發現效能問題的情況。然而，最好的方法是利用CI / CD管道將測試流程整合在開發過程中。

改善使用者體驗的最佳方法是將效能測試合併到功能測試部分中。為此，建議請將收集交易資料作為功能測試的一部分。

例如：創建一個將存儲所有交易訊息的交易訊息資料庫。當執行手動和自動測試時，交易資料將存儲在此資料庫中。然後，對此資料執行交易分析以分析和調試問題。

以現有版本或早期版本的交易時間作為比較基準。例如：當前版本之App”登入”通常需要4秒鐘。可能無法直觀判斷速度快慢；但當改版後的App登入時間增加到6-8秒時，就可以非常明確的肯定時間變慢。透過分析資料的過程找尋導致延遲的原因。例如：使用HAR可視化工具分析資產的加載方式並確定回歸問題。

這是一個演示，展示瞭如何識別效能問題。

• 打開Experitest雲端測試平台。

在這裡，您可以查看全球範圍內的智慧型裝置列表。因此，您可以在各種裝置上執行測試。現在打開一個裝置進行測試。

圖中，可以看到一個事務記錄器，當您按下紅色按鈕時，系統開始記錄在遠端裝置上完成的事件。

• 設定測試的實體網路類型

在智慧型裝置上打開一個網頁並執行記錄器。例如：Netflix。由於大部分使用者會透過3G/4G網路進行上網，為了讓測試貼近使用者的實際使用狀況，建議測試過程中使用3G網路連線而非Wi-Fi。

首先，在網址列中輸入URL，接著按“Record”按鈕，然後在進行前往頁面的動作。

Netflix的網頁在在完全打開網站之前，便加載大多數頁面元素。因此，提供了良好的使用者體驗。

• 檢視測試過程

• 測試過程

首先在測試平台中開啟一個新的裝置，並安裝應用程式。

打開應用程式並進行登入。請注意，測試會在事件在點擊登入按鈕後發生，而不是在輸入使用者名和密碼時開始。因此，在輸入使用者名和密碼，記得點選按記錄器按鈕，然後點擊登入按鈕，App便會與伺服器後台進行身份認證行為。

頁面完全渲染後，停止事務並保存記錄。

打開記錄時，您可以看到交易明細。

事後分析時，不可使用單個測試事件來分析應用程式效能。樣本數量會直接影響分析的結果。建議在收集了百次測試執行後，針對日誌記錄事務進行比較、分析持續時間的變化以便歸納問題。

       以下使用Appium和IntelliJ IDE進行功能測試的範例。

• • 從IntelliJ IDE安裝新版本的應用程式
  • 登入到應用程式並設定使用者名和密碼

• • 開始登入流程
  • 點擊登入按鈕，然後等待身份驗證流程

• • 當整個測試流程錄製完成後。即可以在多個設備上多次執行測試
  • 打開Jenkins CI / CD工具

• • 若要進行複雜的視覺化呈現，請使用Jenkins的套件Blue Ocean

• • 在Jenkins CI / CD管道中，查看構建、部署和執行測過程

• • 進行測試執行

Jenkins即會自動進行下載資源、編譯以及執行測試。

在儀表板上會顯示所有測試項目以及執行畫面

分析時可選擇多個測試結果的資料。另外可以針對測試類型、裝置類型、App版本等進行調整。在下圖選擇了登入驗證、Android裝置和最新的3個App版本。

結果如下：

如結果所示，在比較100筆登入流程的平均時間中App版本1花費了 2秒、版本1.1花費 4秒、版本1.2花費了 6-7秒。在大樣本數的測試下，將舊版程式的測試時間作為基準，利用測試時間的變化量、檢查儲存空間、CPU和其他資源的使用情況等進行問題歸納。當問題被確認時，可藉由可瀑布圖中打開該流程並確定各個元素的執行情況。

僅需在程式碼中添加以下兩行程式，即可在現有的功能測試中執行效能測試，並獲得資料進行分析。

• • startPerformanceTransaction()
  • endPerformanceTransaction()

當以上命令將啟動效能日誌收集，其中包含：CPU、電池、持續時間、網路流量等方面的資料。實體網路型態設定部分建議使用3G average網路模擬在惡劣的網路條件下執行所有測試。

摘要

      現今UI效能已成為涉足App發行的潛在遊戲規則。因此，企業應更注重UI效能測試，以改善使用者體驗，從而在增加使用者同時留住現有客戶。UI效能取決於現有的功能測試環境。從使用者角度更好地了解網路效能非常重要。其中關鍵是將App效能測試整合至CI / CD流程中。即可在開發流程的一開始就發現問題並為您的客戶提更完善的使用者體驗。