使用效能測試 Digital.ai Continuous Testing

背景

在軟體測試領域，效能測試對不同的團隊和個人來說​​可能意味著不同的東西，這取決於他們測試的對象。例如，使用 JMeter 或 SoapUI 等工具進行的負載測試和壓力測試通常與效能測試聯繫在一起，用於驗證應用程式後端伺服器在多個使用者同時與應用程式互動時的效能。

然而，iOS 或 Android 行動 Web 和原生應用程式的效能測試是一個鮮有組織涉足的領域，部分原因是市場上很少有工具能夠為行動裝置提供像樣的效能測試解決方案。

過去幾年，擁有面向客戶應用程式的組織已將行動端自動化測試列為優先事項。然而，隨著應用程式的成長，客戶對應用程式流暢運行、無中斷的需求也日益增長。例如，假設用戶從應用程式商店下載了一個應用程序，但遇到加載緩慢或崩潰等問題。在這種情況下，他們很可能會轉而使用其他能夠滿足其需求的應用程式。

傳統的自動化腳本雖然專注於應用程式的功能方面，卻忽略了驗證應用程式效能的其他關鍵要素。例如，它們無法驗證導航到新頁面所需的時間、CPU、記憶體和電池使用量的峰值，以及使用者流程中任何不必要的網路呼叫。這些都是使用者每天都會遇到的問題，但企業卻往往忽略了對行動應用程式這些方面的測試。

如何 Digital.ai 應對挑戰？

行動裝置效能測試的真正價值在於，您可以針對各種裝置型號和作業系統版本執行大量效能測試。

僅對單一裝置進行效能測試可能無法準確反映使用者實際遇到的情況，但透過分析趨勢並了解單一交易在各種裝置型號和作業系統版本上的表現，可以更好地了解情況。

但是，如何擴展行動裝置效能測試規模來衡量此類數據呢？

Digital.ai 引入了可在功能性 Appium 腳本中實現的命令；這意味著我們可以將功能性自動化腳本與效能測試結合。

如果我們來看一個簡化的 Appium 函數式腳本，用於測試應用程式的登入功能，我們可以看到測試非常簡單。首先，我們填寫使用者名稱和密碼字段，然後點擊登入按鈕，直到最終跳到下一頁：

如果要在這個 Appium 函數腳本中實現效能測試，它看起來會像這樣：

在腳本點擊登入按鈕之前，我們啟動一個效能事務，一旦到達下一頁，我們就結束該效能事務。

由於從自動化腳本輸入文字可能無法準確反映使用者實際輸入憑證所需的時間，因此捕獲用於填充使用者名稱和密碼欄位的效能事務並不那麼重要。

我們可以測量從登入頁面導航到下一頁所需的時間，或點擊登入按鈕時 CPU、記憶體或電池消耗是否出現任何峰值。

我們還可以模擬不同的網路條件，看看最終用戶在不同網路條件下使用該應用程式的體驗，網路設定檔作為第一個參數傳遞：

driver.executeScript(“seetest:client.startPerformanceTransaction(\”4G-average\”)”);

讓我們來看看我們收集的指標類型，以及它們如何幫助我們了解績效交易的進展。

績效交易中會收集哪些類型的指標？

對於每筆性能交易，我們都會收集以下指標：

• 時間： 整個交易過程的持續時間，從開始到結束
• 速度指數： 計算最終內容繪製速度的總分
• 中央處理器： 圖表顯示了事務消耗的 CPU、平均值和最大值。
• 內存： 圖表顯示了事務消耗的記憶體、平均值和最大值。
• 電池： 圖表顯示了交易中消耗的電池電量、平均值和最大值。
• 網絡： 根據所應用的網路設定文件，計算交易期間上傳/下載的總 KB 數。
• 網路通話： 交易期間發出的所有網路調用

我們現在看到的是在 iPhone 13 Pro 上運行的單一效能事務。我們可以回放作為性能事務一部分而捕獲的視頻，並結合視頻，追蹤 CPU、內存和電池的消耗情況。

這份報告如何幫助我了解趨勢和潛在瓶頸？

我們剛才看到的報告側重於單一效能事務。但想像一下，如果我們現在在多種設備型號和作業系統版本上大規模運行相同的效能事務，我們就可以利用內建的報告功能開始分析趨勢。

以下是一個範例報告，該報告經過篩選，顯示了我在特定版本和特定交易（例如，在原生應用程式中從搜尋欄位搜尋商品，並了解在零售應用程式的上下文中加載下一頁所需的時間）下運行的所有交易：

這份報告顯示，iOS 13.2 版本的速度指數明顯高於其他 iOS 版本。

同樣，我們也可以查看其他指標的趨勢，例如 CPU、記憶體和電池：

這種程度的資訊使品質保證測試人員和開發人員能夠調查特定設備型號和作業系統版本是否存在潛在瓶頸，並確定正在測試的行動應用程式中需要改進的地方。

需要注意的是，不同設備或網路之間可能存在效能差異。設備間出現高達 30% 的效能差異是常見的，這並不一定意味著有嚴重的效能問題。然而，效能問題可能會導致效能差異達到基準測量的 10 到 100 倍。

我是否需要在現有的功能自動化腳本中實現效能測試？

將效能測試整合到現有功能腳本中是否合理，還是建立新的獨立腳本進行效能測試，取決於目前自動化框架的靈活性和複雜性。

在我之前給的例子中，程式碼過於簡化。不過，我們不妨在現有的自動化框架中考慮同樣的方法。當呼叫方法執行諸如點擊或發送按鍵之類的操作時，可能會涉及更多依賴項和層級。

讓我們看一個例子：

在現有自動化框架中添加更多邏輯可能會增加執行自動化腳本所需的總時間，這可能會對效能測試產生負面影響，並且無法提供有價值的指標。

如果現有自動化框架的複雜性阻礙了效能測試，建議編寫專門用於擷取效能指標的單獨自動化腳本。

這樣一來，我們就可以在一定程度上簡化程式碼邏輯，從而準確地取得效能測試的適當指標。

我應該設定什麼樣的基準數值才能確保所收集的數據是可衡量的？

衡量效能時沒有通用的或標準化的指標，因為每個組織及其團隊都會根據自身應用程式的使用者體驗來定義使用者體驗。此外，根據應用程式的複雜程度，基準數值可能會因頁面或應用程式的不同而有所差異。

可以使用的指標範例是 TTI（互動時間），它衡量的是用戶啟動應用程式後，應用程式變得可用的時間。

這方面已經有人做過研究，一些基於人機互動（HCI）研究的有用經驗法則告訴我們：

• 任何超過 500 毫秒的延遲都會變成「認知」事件，這意味著使用者知道時間已經過去了。
• 任何超過 3 秒的延遲都會變成一個「反思」事件，這意味著用戶有時間意識到時間已經流逝。他們可能會分心，或選擇去做其他事情。

但還有其他一些指標也被視為關鍵績效指標，例如：

• 最高回應時間
• 平均響應時間
• 最大請求數

如果伺服器回應速度慢，會影響使用者體驗。 Google PageSpeed Insights 建議伺服器回應時間低於 200 毫秒。 300-500 毫秒的範圍被認為是標準範圍，而超過 500 毫秒則低於可接受的標準。

需要注意的是，這些指標並沒有統一的標準答案，基準線的決定也會因具體情況而有所不同。因此，了解被測應用程式的可接受範圍至關重要。這可能需要與應用程式開發人員合作，深入了解應用程式的後端，例如特定使用者流程期間的網路呼叫次數、與某些應用程式元件互動時後端執行的繁重操作以及其他相關因素。

運行一些性能測試並將其用作基準也很有幫助。

我應該在所有可用的設備組合上執行效能測試嗎？

在決定對哪些設備進行性能測試時，請務必考慮那些能帶來最高效益的設備。要確定這一點，需要對使用者群體以及使用者最常用於測試應用程式的裝置類型有清晰的了解。

接下來，建議選擇 5-10 台效能最強的設備進行持續測試（具體數量可能會因專案規模和使用者基數而異）。這種方法有助於建立被測設備的基準線，從而實現更準確的效能測量。

摘要

效能測試對於確保軟體、應用程式和系統能夠處理預期的負載和流量至關重要。它有助於在部署前識別和解決效能瓶頸和潛在故障，從而確保最終用戶獲得流暢的體驗。

與傳統的自動化腳本不同，效能測試旨在測量使用者在頁面之間導航所花費的時間，識別 CPU、記憶體和電池消耗的任何峰值，並找出不必要的網路呼叫。

效能測試的價值在於能夠在開發過程早期發現問題，從而降低後期修復問題的成本。此外，它還有助於建立效能指標的基準線，以便進行長期的監控和比較，從而深入了解系統變更對效能的影響。效能測試對於任何軟體開發週期都至關重要，貫穿從開發到部署及後續階段。

 

準備好開始行動端效能測試了嗎？立即聯絡我們 https://digital.ai/why-digital-ai/contact/