Tes Kinerja dalam pengembangan mobile: apa itu, metrik dan bagaimana melakukannya

Apa itu Tes Kinerja?

Tes Kinerja adalah jenis pengujian non-fungsional yang menentukan seberapa cepat dan efisien aplikasi menjalankan tugas-tugasnya. Berbeda dengan pengujian unit atau pengujian UI, Tes Kinerja mengukur karakteristik kuantitatif: waktu respons, beban prosesor, konsumsi RAM, dan konsumsi baterai. Menurut laporan Sauce Labs (2025), 68% tim pengembangan mobile menyertakan Tes Kinerja dalam siklus pengujian reguler, dan 41% mengotomatiskannya di CI.

Tujuan utama Tes Kinerja adalah memastikan bahwa aplikasi memenuhi persyaratan kinerja yang ditetapkan dalam spesifikasi. Jika waktu pembukaan layar melebihi 500 milidetik atau aplikasi mengkonsumsi lebih dari 200 MB RAM pada perangkat menengah, ini adalah sinyal untuk optimasi. Garis dasar kinerja ditetapkan pada tahap rilis stabil pertama dan ditinjau kembali pada setiap pembaruan besar.

Tes Kinerja dilakukan pada perangkat nyata, bukan pada simulator, karena emulasi tidak memberikan gambaran akurat tentang penggunaan CPU, GPU, dan sumber daya jaringan. Menurut Apple WWDC (2024), tes pada simulator menunjukkan hasil 15-30% lebih tinggi dibandingkan dengan perangkat nyata. Perangkat nyata tetap menjadi satu-satunya sumber data kinerja yang dapat diandalkan.

Keteraturan pelaksanaan Tes Kinerja tergantung pada siklus pengembangan. Dalam rekomendasi Google Android Performance (2024) disebutkan bahwa pengukuran dasar kinerja harus dijalankan pada setiap pull request, dan set lengkap — sebelum setiap rilis. Otomatisasi pengukuran ini memungkinkan deteksi regresi kinerja pada tahap awal.

Metrik kinerja utama

Dalam pengembangan mobile, ada lima metrik utama yang mencakup 90% skenario Tes Kinerja. Waktu startup (cold start dan warm start) — metrik pertama yang diperiksa pada setiap rilis. Google Play Console (2024) mencatat waktu startup berdasarkan ambang batas: cold start tidak boleh melebihi 5 detik, warm start — 1,5 detik. Melebihi ambang batas ini secara langsung mempengaruhi peringkat di toko aplikasi.

Waktu startup (Cold Start)

Cold start diukur dari saat klik pada ikon hingga munculnya frame pertama aplikasi. iOS menggunakan `dispatch_async` untuk inisialisasi tertunda, yang memperpendek waktu startup yang terlihat. Cold start Android mencakup pembuatan proses, inisialisasi Application, dan memulai Activity. Menurut Google Performance (2024), setiap 100 ms keterlambatan cold start mengurangi Conversion Rate sebesar 1,2% pada aplikasi e-commerce.

Frekuensi bingkai (FPS)

FPS (Frames Per Second) — frekuensi bingkai selama animasi dan pengguliran daftar. Untuk antarmuka yang halus diperlukan 60 FPS yang stabil. Android Studio Profiler dan Xcode GPU Report menunjukkan penurunan FPS pada operasi berat — memuat gambar, memparsing JSON, atau merender tata letak yang kompleks. Penurunan di bawah 30 FPS dirasakan oleh pengguna sebagai lambat dan menyebabkan penurunan Retention Rate sebesar 22% menurut Adjust (2025).

Konsumsi RAM

Konsumsi RAM — metrik kritis ketiga. Kebocoran memori — penyebab utama penurunan kinerja dalam sesi yang berlangsung lama. Instruments Allocations dan Android Memory Profiler membantu mendeteksi referensi siklik dalam Swift dan Activity yang tidak dibebaskan di Android. Konsumsi baterai — metrik yang sering diabaikan pada tahap pengujian. Menurut Apple Developer (2024), aplikasi dengan konsumsi energi tinggi dibatasi di latar belakang pada iOS. Energy Log di Xcode mencatat profil watt aplikasi selama sesi.

Jenis pengujian kinerja

Pengujian beban (Load Test) memeriksa perilaku aplikasi di bawah jumlah pengguna simultan yang diharapkan. Untuk backend mobile ini berarti simulasi 1000-10000 permintaan simultan ke API. Bagian server harus menangani beban puncak tanpa peningkatan waktu respons lebih dari 20% dari nilai dasar. Menurut tolok ukur k6 (2024), konfigurasi Load Test tipikal mencakup tanjakan dari 0 hingga 1000 VU (pengguna virtual) dalam 5 menit.

Pengujian stres (Stress Test) menentukan titik kegagalan aplikasi — saat sistem berhenti merespons permintaan atau menurun secara tidak dapat diterima. Berbeda dengan Load Test, Stress Test membebani sistem di atas batas normal. Titik kegagalan dicatat berdasarkan salah satu kriteria: waktu respons melebihi 10 detik, persentase kesalahan 5XX melebihi 5%, atau konsumsi RAM mencapai 90% dari memori yang tersedia.

Pengujian volume (Volume Test) mengevaluasi perilaku aplikasi saat bekerja dengan volume data besar. Dalam konteks mobile ini adalah pemeriksaan kerja dengan ribuan catatan di database lokal, puluhan gigabyte cache, atau jutaan notifikasi push. SQLite di Android dan Core Data di iOS menunjukkan kinerja berbeda pada volume di atas 100000 catatan.

Alat untuk Tes Kinerja

Xcode Instruments

Xcode Instruments — alat utama untuk profiling aplikasi iOS. Time Profiler menunjukkan metode mana yang paling banyak mengonsumsi CPU, dan Allocations melacak alokasi dan pembebasan memori. Instruments mendukung perekaman selama sesi panjang (hingga 30 menit) dan ekspor jejak untuk perbandingan antar build. Activity Monitor di dalam Instruments menunjukkan beban sistem secara keseluruhan secara real-time.

Android Studio Profiler

Android Studio Profiler — profiler bawaan untuk Android. Ini menggabungkan profil CPU, Memory, Network, dan Energy dalam satu antarmuka. Keistimewaan Android Profiler adalah dukungan untuk sesi interaktif: pengembang dapat melakukan tindakan di aplikasi dan melihat reaksi instan dari metrik. Menurut Google I/O (2024), Profiler mendukung perekaman dalam format .perf, yang dapat dibandingkan dengan baseline di CI.

Charles Proxy

Charles Proxy dan Proxyman — alat untuk analisis lalu lintas jaringan. Mereka menunjukkan waktu setiap permintaan HTTP, ukuran respons, dan header. Untuk Tes Kinerja penting untuk mencatat permintaan yang memakan waktu lebih dari 500 ms — ini adalah kandidat untuk caching atau optimasi. Charles mendukung mode throttle yang mensimulasikan jaringan lambat: 3G, Edge, dan LTE. Proxyman — alternatif yang lebih ringan untuk macOS dengan arsitektur Swift asli.

import XCTest

class PerformanceTests: XCTestCase {

    func testLaunchPerformance() {
        measure(metrics: [XCTClockMetric(),
                         XCTMemoryMetric()]) {
            XCUIApplication().launch()
        }
    }

    func testScrollPerformance() {
        let app = XCUIApplication()
        app.launch()
        let tableView = app.tables["list"]
        measure {
            tableView.swipeUp()
            tableView.swipeDown()
        }
    }
}

Tes Kinerja dalam pipeline CI/CD

Mengintegrasikan Tes Kinerja ke dalam CI/CD adalah standar industri untuk 2025-2026. Pipeline kinerja mencakup tiga tahap: pre-commit (pengukuran cepat pada pull request), nightly (set pengujian lengkap), dan pre-release (perbandingan dengan baseline pada perangkat referensi). Bitrise dan GitHub Actions mendukung menjalankan Xcode Instruments CLI dan Gradle Profiler.

GitHub Actions (2024) menerbitkan template resmi untuk Tes Kinerja iOS menggunakan `xcodebuild test-without-building`. Template menjalankan pengujian di salah satu mesin GitHub dan mempublikasikan laporan di artifact. Baseline disimpan dalam file JSON di repositori: ketika ambang batas terlampaui sebesar 10%, pipeline gagal dengan kesalahan. Pendekatan ini mencegah degradasi kinerja tanpa pemeriksaan manual setiap build.

Masalah Tes Kinerja mobile di CI adalah ketidakstabilan hasil pada mesin yang berbeda. Apple Silicon (M1-M4) dan Intel Xeon memberikan waktu eksekusi yang berbeda. Solusinya adalah menggunakan rasio persentase terhadap baseline, bukan nilai absolut. Jika pengujian berlangsung 15% lebih lama dari baseline — build ditandai sebagai perlu pemeriksaan.

Menulis Tes Kinerja di iOS dan Android

XCTest Performance di iOS menggunakan metode `measure(metrics:)`, yang menjalankan blok kode 10 kali dan mengembalikan statistik: rata-rata, median, deviasi standar. Untuk menguji kinerja database, XCTest nyaman menggunakan XCTMemoryMetric, yang mencatat konsumsi RAM puncak. Ambang ditetapkan melalui `XCTPerformanceReport` setelah pengujian selesai.

Android Macrobenchmark — pustaka dari Google untuk mengukur kinerja di tingkat aplikasi. Macrobenchmark menjalankan skenario pengguna (memulai Activity, menggulir RecyclerView, membuka WebView) dan mengukur waktu eksekusi. Baseline Profile — kumpulan kelas dan metode yang dioptimalkan sebelumnya oleh kompiler Android. Google Play menggunakan Baseline Profile untuk mempercepat startup pertama sebesar 30%.

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {
    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun startup() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 5
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}

Kedua pendekatan — XCTest Performance dan Android Macrobenchmark — menggunakan konsep yang sama: pengukuran berganda dengan rata-rata dan perbandingan dengan ambang. Kinerja tidak dapat direduksi menjadi satu angka. Setiap rilis harus disertai dengan laporan kinerja yang berisi tren metrik selama 5 build terakhir. Laporan semacam itu memungkinkan tim melihat degradasi sebelum pengguna menyadarinya.