翻譯及整理：叡揚資訊 資安直屬事業處
資料來源：Performance Testing with Digital.ai Continuous Testing
在軟體測試的領域，App 功能測試中的效能測試對於不同的團隊和不同的人代表著不同的意義，這取決於他們的測試內容。例如，使用 JMeter 或 SoapUI 等工具進行負載測試和壓力測試，這通常與效能測試有關，以便在多個使用者與應用程式互動時，同時驗證應用程式的後端系統。
然而，iOS 或 Android 行動裝置網頁和本地應用程式的效能測試是一個大部分組織還未探索的領域，一部分的原因是市場上很少有工具為行動裝置提供一個合適的效能測試解決方案。
在過去幾年中，擁有顧客導向類型的 App 已經將行動裝置的自動化測試列為優先事項。然而，隨著應用程式的發展，顧客對應用程式的需求也在不斷地增長，他們希望應用程式能夠以最佳狀態運行、不受干擾。例如，假設使用者從 AppStore 下載一個應用程式，出現載入緩慢或當機的問題。在這種情況下，他們更傾向於會選擇另一個更符合他們需求的應用程式。
雖然傳統的自動化腳本非常注重應用程式的功能面，但它們未能驗證應用程式其他重要的方面。例如，它們沒有驗證瀏覽和載入新頁面所需的時間，CPU、記憶體和電池使用量，或進行任何不必要且耗費流量的網路請求。這些都是使用者每天面臨的挑戰，但企業卻未能測試這些面向。
當你能在不同的機型和不同的作業系統版本上運行大量的效能測試時，行動端的效能測試價值是可衡量的。
測試單一設備的效能可能無法準確反映使用者實際面臨的情況，但利用效能數據的趨勢和瞭解在不同機型和作業系統版本上的表現，更能描繪出較佳的現況。
但是，你如何在行動裝置上進行效能測試以測量此類數據？
Digital.ai 引入了可以在測試功能性的 Appium 腳本中實現的指令；這意味著我們可以將測試功能的自動化腳本與效能測試結合。
我們來看下面這個簡化的 Appium 功能腳本。在這個情境中，在測試一個應用程式的登入時，我們可以看到測試是直接、簡單的。首先，我們填入使用者名稱和密碼欄位，點擊登入按鈕，直到最後載入下一個頁面：
如果要在這個功能測試 Appium 腳本中實施效能測試，它看起來會是這樣的：
在腳本點擊登入按鈕之前，我們啟動一個效能測試，當我們載入下一個頁面，就結束效能測試。
分析用於填寫使用者和密碼欄位的效能並不是那麼重要，因為從自動化腳本中輸入文字可能無法準確地代表使用者輸入憑證時所需的時間。
我們可以測量從登入頁面載入到下一個頁面需要多長時間，或者當我們點擊登入按鈕時，CPU、記憶體或電池的消耗是否有任何起伏。
還可以模擬不同的網路條件，看看使用者在不同的網路條件下如何使用應用程式。第一個參數以網路設定檔傳遞：
讓我們看看效能測試的指標類型，以及如何幫助了解效能測試的情況。
對於效能測試，我們記錄的指標如下：
持續時間：從開始到結束，整體的效能測試時間
速度指標：頁面的內容被載入花了多少時間，並計算出總體分數
我們看到的是一個在 iPhone 13 Pro 上執行的單一設備的效能測試。在這裡可以播放效能測試的紀錄影片，在影片中，我們可以查看 CPU、記憶體和電池的消耗情況。
剛才看的報告注重在單一設備的效能測試。但想像一下，如果我們現在在許多設備和作業系統版本上大規模運行相同的效能測試，就可以利用報告功能查看趨勢。下圖是一個範例報告，此報告經過篩選，以顯示在特定的測試案例下所得的結果（例如，在一個本地端的應用程式中從搜尋欄搜尋一個項目，並了解一個零售業的應用程式加載下一個頁面所需要的時間）：
這份報告告訴我們，與其他 iOS 版本相比，iOS 13.2 版本的速度指標明顯更高。
同樣地，我們也可以看看其他指標，如 CPU、記憶體和電池：
這些訊息讓 QA 測試人員和開發人員能夠調查特定的設備型號和作業系統版本的潛在問題，並識別正在測試的行動應用程式中有沒有需要改進的地方。
值得注意的是，不同設備或網路之間可能存在效能差異。在不同的設備型號之間看到高達 30% 的差異是很常見的，這並不一定表明有嚴重的效能問題。然而，效能問題可能導致測量基準有 10-100 倍的差異。
在現有的功能化測試腳本中實施效能測試，還是為效能測試建立新的獨立腳本，取決於當前自動化框架的靈活性和複雜性。
在之前給出的例子中，程式碼被過度簡化了。不過，讓我們在現有自動化框架的背景下思考同樣的方法。當呼叫一個方法來執行 Click 或 Send Keys 時，可能會涉及到更多的依賴關係 和層級。
現在來看一個例子：
在現有的自動化框架中增加更多的邏輯，可能會增加運行自動化腳本所需的整體時間，這可能會對效能測試產生負面影響，並且不能提供有價值的指標。
如果現有自動化框架的複雜性阻礙了效能測試，建議編寫單獨的自動化腳本，專門用於獲取效能測試的指標。
這使我們能夠在一定程度上簡化程式碼邏輯，使我們能夠為效能測試提供適當的指標。
在測量效能時，沒有通用或標準化的指標，因為每個組織及其團隊都會為自己的應用程式定義使用者體驗。此外，根據應用程式的複雜性，不同的頁面或應用程式的基準可能不同。
TTI（測量載入互動性）是一個可以使用的指標，它衡量一個應用程式在使用者啟動後需要多長時間才可以使用。
在研究 HCI（人機互動）後，一些經驗法則告訴我們：
但也有其他指標被認為是關鍵效能指標，例如：
如果你的伺服器的反應時間很慢，會損害使用者體驗。Google PageSpeed Insights 建議伺服器的反應時間在 200 毫秒以下。300-500 毫秒的範圍被認為是標準的，而任何超過 500 毫秒的回應都是低於可接受的標準。
值得注意的是，這些指標沒有一個放諸四海而皆準的答案，基準可能因情況不同而不同。因此，重要的是要了解被測試的應用程式的什麼情況是可被接受的。這可能牽涉到與應用程式開發人員的合作，並深入了解應用程式的後端，例如在特定的流量中進行的網路請求的數量，與某些應用程式元件互動時在後端執行的大量程式，以及其他的相關因素。
執行少量的效能測試也是很有幫助的，然後將其作為一個基準。
決定哪些設備需要進行效能測試時，最重要的是要考慮哪些裝置可以產生最大的收益，需要清楚地了解客群和被測試的應用程式最常使用的裝置類型。
建議選擇前 5-10 個裝置進行測試（設備數量可能根據項目的規模和客群變化）。這種方法有助於為被測試的裝置建立一個基準，使效能測試更加準確。
效能測試對於確保軟體、應用程式和系統能夠處理預期的負荷量和流量至關重要。它有助於在應用程式部署前識別和解決效能問題，確保使用者有一個順暢的體驗。
與傳統的自動化腳本相比，效能測試的目的是測試使用者在頁面之間瀏覽的時間，識別 CPU、記憶體和電池的消耗量，並找出不必要的網路請求。
效能測試的價值在於能夠在開發過程的早期發現問題，減少後期修復的相關費用。此外，它有助於建立一個效能指標的基準，可以隨著時間的推移進行監控和比較，提供對系統的變化如何影響效能的洞察。效能測試對於任何軟體的開發週期，從開發到部署以及其他方面，都是必不可少的。
準備好開始效能測試了嗎？ 歡迎造訪網站了解更多：https://www.gss.com.tw/digital-ai-continuous-testing
