Pengujian Interupsi di Aplikasi Seluler

⚡ Ringkasan Cerdas

Pengujian Interupsi memeriksa bagaimana aplikasi seluler berperilaku ketika panggilan, alarm, notifikasi, atau gangguan jaringan mengambil alih, dan apakah aplikasi kembali ke keadaan sebelumnya persis setelah gangguan berakhir.

🔘 Cakupan: Teknik ini termasuk dalam pengujian aplikasi seluler tetapi juga berlaku untuk perangkat lunak web dan perangkat lunak mandiri.
☑️ Sumber gangguan: Panggilan masuk, SMS, alarm, baterai lemah, pengisian daya, pembaruan aplikasi, dan perubahan jaringan mencakup sebagian besar skenario nyata.
✅ Empat hasil yang diharapkan: Berjalan di latar belakang, menampilkan peringatan, ajakan bertindak, atau tanpa dampak — setiap aplikasi menentukan opsi mana yang berlaku.
🧪 Desain pengujian: Pengujian Interupsi adalah bagian dari Pengujian Fungsional, sehingga kerangka kerja, kasus uji, dan proses eksekusi yang sama berlaku.
️ Simulasi: Emulator dengan kontrol yang diperluas, pengaturan perangkat, dan cloud perangkat nyata mereproduksi panggilan, peringatan, dan kehilangan konektivitas sesuai permintaan.
📊 Bukan pengujian pemulihan: Pengujian Pemulihan memvalidasi pemulihan setelah kegagalan, sedangkan gangguan hanyalah sebuah kesalahan.tracitu bukan kesalahan.

Baca Selengkapnya

Apa itu Pengujian Interupsi?

Pengujian Interupsi Pengujian aplikasi seluler adalah cabang dari pengujian aplikasi seluler yang membahas bagaimana aplikasi bereaksi terhadap gangguan dan kembali ke keadaan sebelumnya. Gangguan tersebut berasal dari luar aplikasi — sistem operasi, perangkat keras, atau aplikasi lain — dan pengujian memverifikasi bahwa tidak ada data, status layar, atau transaksi yang sedang berlangsung yang hilang ketika kendali kembali.

Pengujian Interupsi berlaku untuk semua jenis aplikasi — web, seluler, mandiri, dan sebagainya. Beragamnya perangkat, jaringan, dan konfigurasi membuatnya jauh lebih penting. mobil aplikasi dibandingkan dengan yang lain.

Mengapa Anda memerlukan Pengujian Interupsi?

Apa satu hal yang hampir selalu terjadi saat Anda sedang rapat? Anda akan diinterupsi, bukan? Ketika itu terjadi, beberapa orang bahkan tidak berkedip, beberapa membutuhkan waktu sejenak untuk kembali fokus, dan beberapa kehilangan alur pikirannya sepenuhnya. Singkatnya, Pengujian Interupsi mencoba untuk mengetahui perilaku mana yang ditunjukkan oleh aplikasi Anda.

Kesampingkan dulu semua penjelasan dan perhatikan situasi nyata lainnya. Katakanlah Anda memiliki senter dan menyalakannya. Baterai habis, yang merupakan gangguan terhadap kondisi aktifnya saat ini. Ganti baterai dan kembalikan ke kondisi semula. Senter seharusnya menyala kembali seperti biasa. Inilah contoh kasusnya. Disiplin pengujian yang berfokus pada apakah hal ini terjadi atau tidak disebut Pengujian Interupsi.

Alasan bisnisnya cukup jelas. Gangguan datang pada saat yang paling buruk — di tengah pembayaran, di tengah pengunggahan, di tengah pengisian formulir — dan pengguna yang kehilangan pekerjaan tersebut jarang mencoba lagi. Aplikasi macet saat melanjutkan, layar kosong, transaksi ganda, dan input formulir yang hilang adalah semua cacat yang hanya terungkap oleh gangguan, itulah sebabnya mengapa hal-hal tersebut tetap ada meskipun dilakukan pengujian fungsional yang tidak pernah mengganggu proses apa pun.

Jenis Interupsi pada Aplikasi Seluler

Gangguan dapat dikelompokkan menjadi beberapa kategori yang sudah dikenal, yang dirangkum dalam ilustrasi di bawah ini.

Kita semua sudah familiar dengan gangguan umum yang biasanya terjadi. Berikut beberapa di antaranya:

Baterai lemah
Baterai penuh — saat mengisi daya
Panggilan telepon masuk
SMS masuk
Notifikasi masuk dari aplikasi seluler lain
Dicolokkan untuk mengisi daya
Dicolokkan dari pengisian daya
Perangkat dimatikan
Pengingat pembaruan aplikasi
alarm
Kehilangan koneksi jaringan
Pemulihan koneksi jaringan

Daftar ini tidak lengkap tetapi mencakup skenario yang paling umum. Cara praktis untuk mengaturnya adalah berdasarkan asal: peristiwa yang bergantung pada perangkat seperti baterai dan pengisian daya, peristiwa yang diprakarsai pengguna seperti menjawab panggilan atau beralih aplikasi, dan peristiwa eksternal seperti kehilangan sinyal di lift atau terowongan.

Resolusi jika terjadi Interupsi

Perilaku yang diharapkan jika terjadi gangguan ini adalah salah satu dari empat hal berikut:

Jalankan di latar belakang: Gangguan tersebut mengambil alih sementara aplikasi mengambil peran sekunder. Aplikasi mendapatkan kendali setelah gangguan berakhir. Misalnya, panggilan telepon atau panggilan FaceTime yang Anda terima saat Anda membaca buku digital di iBooks (atau aplikasi serupa). Saat pengguna menjawab telepon, iBooks menunggu hingga panggilan selesai dan kemudian melanjutkan saat panggilan berakhir.
Tampilkan peringatan: Notifikasi tersebut menghilang dan Anda dapat bekerja seperti biasa. Pesan "SMS diterima" muncul di header. Pengguna tidak mempermasalahkannya dan terus menggunakan aplikasi seperti biasa. Notifikasi aplikasi seluler lainnya, seperti permintaan pertemanan baru di Facebook atau pesan WhatsApp, juga termasuk dalam kategori ini. Namun, jika pengguna memutuskan untuk membaca pesan tersebut, perilaku yang dijelaskan pada poin 1 akan diikuti. Jika notifikasi diabaikan, status aplikasi tidak berubah.
Panggilan untuk bertindak: Alarm harus dimatikan atau ditunda sebelum Anda melanjutkan pekerjaan. Hal yang sama berlaku untuk pesan pembaruan aplikasi. Anda harus membatalkan atau menerima perubahan sebelum melanjutkan. Contoh lain adalah peringatan baterai lemah — Anda dapat memilih untuk melanjutkan seperti biasa atau masuk ke mode hemat daya, jika perangkat mengizinkannya.
Tidak ada dampak: Contohnya adalah koneksi jaringan yang tersedia dan perangkat Anda terhubung ke koneksi tersebut. Selain itu, saat Anda mencolokkan perangkat untuk mengisi daya, tidak diperlukan peringatan atau langkah tindakan apa pun. Perangkat mungkin akan melakukan tugasnya sendiri sementara Anda terus menggunakan aplikasi Anda.

Oleh karena itu, tergantung pada jenis gangguan yang Anda uji, pahami perilakunya dan periksa apakah aplikasi Anda memenuhinya. Selain itu, perilaku yang dijelaskan di atas belum tentu sama untuk semua aplikasi dan perangkat. Pastikan untuk mencari tahu detail spesifik untuk aplikasi seluler Anda.

Kasus Uji Interupsi dengan Hasil yang Diharapkan

Setelah resolusi yang diharapkan disepakati, setiap interupsi menjadi kasus uji biasa dengan pemicu, tindakan, dan hasil yang dapat diverifikasi. Tabel di bawah ini menunjukkan bagaimana keempat resolusi di atas diterjemahkan ke dalam skenario konkret.

Gangguan	Skenario pengujian	Hasil yang diharapkan
Panggilan telepon masuk	Lakukan panggilan saat formulir terisi setengah, jawab panggilan tersebut, lalu akhiri panggilan.	Aplikasi berpindah ke latar belakang dan melanjutkan di layar yang sama dengan data yang dimasukkan tetap utuh.
SMS masuk atau notifikasi push	Kirim pesan saat video atau unggahan sedang berlangsung dan abaikan banner tersebut.	Banner muncul dan menghilang; status aplikasi tidak berubah.
alarm	Biarkan alarm terjadwal berbunyi selama sesi aktif dan kemudian matikan.	Alarm meminta tindakan terlebih dahulu, kemudian aplikasi melanjutkan dari titik terakhir berhenti.
Peringatan baterai lemah	Kosongkan perangkat hingga ambang batas peringatan selama transaksi.	Peringatan ditampilkan, transaksi tidak dibatalkan, dan mode hemat daya tidak merusak layar.
Kehilangan koneksi jaringan	Nonaktifkan konektivitas di tengah permintaan, lalu pulihkan kembali.	Pesan yang jelas ditampilkan, tidak terjadi kerusakan, dan permintaan selesai atau gagal dengan aman saat pemulihan.
Pengisian daya terhubung atau terputus	Hubungkan dan lepaskan pengisi daya selama sesi aktif.	Tidak ada dampak — aplikasi terus berjalan tanpa perubahan yang terlihat.
Pengingat pembaruan aplikasi	Tampilkan permintaan pembaruan saat aplikasi sedang digunakan.	Pengguna dapat membatalkan atau menerima, dan tampilan layar yang mendasarinya akan tetap sama terlepas dari pilihan tersebut.

Pertahankan satu baris per gangguan per layar kritis daripada satu baris per gangguan untuk seluruh aplikasi. Layar pembayaran, layar login, dan formulir panjang masing-masing mengalami kegagalan dengan cara yang berbeda, dan satu kasus umum dapat menyembunyikan hal tersebut.

Sekarang setelah kita memahami apa itu Interrupt Testing dan apa yang harus divalidasi saat menjalankannya, sekarang saatnya membahas cara melakukannya.

Bagaimana melakukan Pengujian Interupsi

Lihat pernyataan ini: iBooks harus berjalan di latar belakang saat pengguna menerima panggilan telepon masuk.

Bukankah ini bisa disebut sebagai persyaratan fungsional dari aplikasi iBooks? Saya yakin saya bisa.

Jadi, Pengujian Interupsi adalah bagian dari Pengujian Fungsional untuk aplikasi seluler. Untuk melakukan Pengujian Interupsi, Anda mengikuti kerangka kerja dan alat pengujian aplikasi seluler yang sama. Keterampilan penguji adalah untuk merancang skenario-skenario ini. Setelah itu, Anda merancang kasus uji dan menjalankannya dengan cara yang sama persis seperti pengujian lainnya.

Dalam praktiknya, urutannya singkat dan dapat diulang:

Sebutkan alur perjalanan pengguna yang penting — login, pembayaran, unggah, formulir panjang, pemutaran media.
Petakan setiap kemungkinan gangguan dari daftar di atas ke setiap perjalanan.
Sepakati resolusi yang diharapkan untuk setiap pasangan dengan pemilik produk, karena tidak ada standar default universal.
Lakukan interupsi pada saat yang paling berisiko, bukan pada saat yang senggang, lalu lanjutkan.
Verifikasi status, data, sesi, dan memori setelah dilanjutkan, bukan hanya memastikan aplikasi masih terbuka.

Untuk informasi lebih lanjut mengenai disiplin ilmu yang lebih luas, lihat Pengujian Seluler tutorial dan contoh kasus di Pengujian Aplikasi Seluler.

Alat dan Teknik untuk Mensimulasikan Gangguan

Skenario-skenario di atas harus diproduksi sesuai permintaan, bukan ditunggu, dan setiap platform menyediakan cara untuk melakukannya.

Android Kontrol tambahan emulator: Panel samping emulator mensimulasikan panggilan masuk, SMS, level baterai dan status pengisi daya, serta kekuatan sinyal seluler, sehingga sebagian besar daftar gangguan dapat diatasi tanpa memerlukan handset kedua.
Simulator iOS dan Xcode: Konektivitas dan status perangkat keras dapat diubah dari simulator dan dari pengaturan perangkat, sementara perangkat fisik yang terpasang mencakup skenario panggilan yang tidak dapat ditimbulkan oleh simulator.
Perangkat fisik kedua: Melakukan panggilan atau mengirim pesan ke perangkat yang sedang diuji dari perangkat lain tetap menjadi cara paling akurat untuk mereproduksi gangguan nyata, terutama untuk kasus yang sensitif terhadap waktu.
Pengaturan alat: Mode pesawat, pengaktifan/penonaktifan Wi-Fi, Jangan Ganggu, penghemat baterai, dan alarm terjadwal mencakup konektivitas dan gangguan daya pada perangkat keras nyata.
Kerangka kerja otomatisasi: Tumpukan otomatisasi yang sama yang digunakan untuk seluruh rangkaian fungsi Anda dapat menggerakkan aplikasi sebelum dan sesudah interupsi, sehingga pemeriksaan melanjutkan eksekusi dilakukan secara otomatis dan bukan hanya berdasarkan pengamatan visual.
Komputasi awan pada perangkat nyata: Sebuah farm perangkat yang dihosting memperluas cakupan di berbagai produsen dan versi OS, yang penting karena penanganan interupsi adalah salah satu area di mana kustomisasi vendor paling berbeda.

Apa pun mekanismenya, catat momen pasti terjadinya interupsi dalam kasus uji. "Interupsi selama pengunggahan" dan "interupsi setelah pengunggahan" adalah pengujian yang berbeda dengan mode kegagalan yang berbeda.

Praktik Terbaik untuk Pengujian Interupsi

Beberapa kebiasaan membedakan rangkaian interupsi yang berguna dari sekadar formalitas.

Menginterupsi di saat yang paling buruk: Target Saat transaksi diselesaikan atau file sedang ditulis, karena di situlah status paling rentan.
Uji resume, bukan gangguannya: Cacat tersebut hampir selalu muncul setelah kontrol kembali, jadi pernyataan tersebut harus ada di layar yang dipulihkan.
Mencakup kedua arah perubahan jaringan: Kehilangan koneksi dan mendapatkannya kembali adalah kasus yang berbeda, dan yang kedua lebih sering dilewati.
Variasikan durasinya: Peringatan dua detik dan panggilan sepuluh menit mendorong aplikasi melalui jalur siklus hidup yang berbeda, termasuk dikeluarkan dari memori.
Tersebar di berbagai versi sistem operasi dan perangkat keras kelas bawah: Penghapusan data latar belakang jauh lebih agresif pada perangkat dengan keterbatasan sumber daya, yang memunculkan kekurangan yang disembunyikan oleh ponsel unggulan.
Otomatiskan yang berulang: Gangguan konektivitas dan baterai diotomatiskan dengan rapi, membebaskan upaya manual untuk skenario panggilan dan alarm.
Perhatikan penggunaan sumber daya serta kondisinya: Gangguan yang menyebabkan kebocoran memori atau menguras baterai saat melanjutkan merupakan cacat meskipun tampilan layar terlihat benar, yang menghubungkan pekerjaan ini dengan pengujian kinerja aplikasi seluler.

Bukankah Pengujian Interupsi sama dengan Pengujian Pemulihan?

Tidak, bukan itu. Pengujian Pemulihan Memvalidasi pemulihan dari kegagalan. Gangguan tidak selalu berarti kegagalan — itu hanyalah sebuah gangguan kecil.traction.

Ini seperti perbedaan antara koma dan titik dalam bahasa Inggris. Perbedaannya hanya bersifat teknis, tetapi gambaran keseluruhannya jelas. Pengujian Pemulihan (Recovery Testing) menanyakan apakah aplikasi dapat kembali berfungsi setelah terjadi kerusakan; Pengujian Interupsi (Interrupt Testing) menanyakan apakah ada sesuatu yang rusak sama sekali ketika sesuatu yang lain mengambil alih peran utama.

Itulah yang perlu diketahui untuk memulai Pengujian Interupsi — cabang penting dan intuitif dari Pengujian Aplikasi Seluler.

Pertanyaan Umum Demo Slot

Skenarionya sama, tetapi hasilnya berbeda. Kedua platform tersebut mengelola aplikasi latar belakang dan penghapusan memori secara berbeda, dan Android Vendor skin menambahkan aturan baterai mereka sendiri, sehingga pengujian yang identik dapat berhasil pada satu keluarga perangkat dan gagal pada keluarga perangkat lainnya.

Model AI membaca cerita pengguna dan laporan kerusakan, lalu mengusulkan pasangan gangguan yang mungkin tidak tercantum dalam daftar penguji — misalnya, panggilan yang datang tepat saat token diperbarui. Pembelajaran mesin juga mengelompokkan log kerusakan produksi untuk menunjukkan gangguan mana yang benar-benar pertama kali menyebabkan pengguna nyata mengalami masalah.

Copilot menyusun skrip standar dengan baik — menjalankan aplikasi di latar belakang, mengaktifkan dan menonaktifkan konektivitas, menunggu, lalu menampilkan kembali layar yang dipulihkan. Keputusan kapan harus menginterupsi dan kondisi apa yang harus dipertahankan tetap berada di tangan penguji, jadi perlakukan skrip yang dihasilkan sebagai draf awal untuk ditinjau.

Ya. Kedua nama tersebut menggambarkan aktivitas yang identik dan digunakan secara bergantian di berbagai tim dan alat. Pilih satu ejaan untuk rencana pengujian Anda dan gunakan secara konsisten, karena terminologi campuran membuat rangkaian pengujian lebih sulit dicari dan kasus duplikat lebih mudah dibuat.

Gunakan keduanya. Emulator ideal untuk konektivitas yang cepat dan berulang serta wadah baterai dalam alur kerja. Perangkat nyata diperlukan untuk panggilan asli, pengelola baterai vendor, dan penghapusan memori rendah, yang justru merupakan kondisi yang paling sulit untuk mendeteksi cacat saat melanjutkan proses.

Aplikasi mengalami crash saat dilanjutkan, layar kosong atau salah setelah kembali, input formulir hilang, pembayaran ganda dari permintaan yang dicoba ulang, sesi rusak yang memerlukan login baru, pemutaran media macet, dan kebocoran memori atau baterai yang hanya muncul setelah aplikasi berulang kali dijalankan di latar belakang.

Keduanya benar. Gangguan jaringan, baterai, dan peralihan aplikasi dapat diprogram dengan andal dan termasuk dalam pengujian regresi. Panggilan masuk, alarm, dan peringatan daya khusus vendor biasanya lebih cepat diuji secara manual pada perangkat genggam sungguhan, sehingga sebagian besar tim menyimpan satu set kecil perangkat manual.

Mulailah sesegera mungkin setelah perjalanan kritis selesai dikembangkan, bukan selama minggu pengerasan akhir. Perbaikan cacat seringkali memerlukan perubahan siklus hidup atau manajemen status, dan hal itu mahal untuk diterapkan kembali setelah kandidat rilis dibekukan.