Daftar Periksa Pengujian Email untuk Pengembang: Dari Permintaan hingga Kedaluwarsa
Ditinjau oleh Tinjauan editorial Bahasa Indonesia Once Email
Panduan artikel
Mengapa artikel ini layak dibaca
- Analisis asli
- Daftar periksa ini mengikuti satu peristiwa melalui permintaan, antrean, pengiriman, rendering, tindakan, masa berlaku, dan percobaan ulang sehingga pemeriksaan kotak masuk yang lewat tidak dapat menyembunyikan siklus hidup yang rusak.
- Konteks tren
- Login tanpa kata sandi dan alur transaksi multiklien meningkatkan jumlah kasus batas, sementara pengujian resmi dan perilaku kegagalan yang aman tetap tidak dapat dinegosiasikan.
- Nilai praktis
- Pengembang dapat mengubah bagian tersebut menjadi kasus pengujian yang dapat direproduksi dengan hasil yang diharapkan, stempel waktu, dan bukti kegagalan daripada mengandalkan pemeriksaan visual informal.
Di halaman ini
Pengujian email lebih dari sekadar mengonfirmasi bahwa sebuah pesan muncul. Pengujian yang andal mengikuti peristiwa dari permintaan aplikasi melalui pengiriman, rendering, tindakan pengguna, kedaluwarsa, dan perilaku coba lagi. Ini juga memeriksa apakah aliran gagal dengan aman.
Gunakan daftar periksa ini hanya pada sistem dan akun yang Anda miliki atau yang diizinkan untuk diuji. Jangan gunakan kotak masuk sementara untuk membuat akun massal, menghindari batasan situs web lain, atau menguji alur penyetelan ulang pihak ketiga tanpa izin. Once Email hanya menerima pesan; tidak mengirimkan balasan dan tidak dapat membuktikan apa yang terjadi di dalam aplikasi pengirim.
1. Tentukan satu kasus uji sebelum meminta email
Catat lingkungan, build, browser, fitur, dan hasil yang diharapkan sebelum menekan tombol. Berikan setiap proses pengenal netral seperti signup-valid-address atau reset-expired-link; jangan memasukkan kata sandi, token, atau alamat pribadi pada nama tes.
Siapkan kasus untuk jalur yang sebenarnya didukung produk:
- permintaan pendaftaran atau verifikasi alamat yang valid;
- alamat dengan kesalahan input yang jelas;
- permintaan berulang saat pesan pertama masih valid;
- kode yang kadaluwarsa atau sudah digunakan;
- permintaan pengaturan ulang kata sandi untuk akun yang sudah ada dan yang belum ada;
- pembatalan, navigasi kembali, dan sesi browser kedua jika relevan.
Panduan Pengujian Keamanan Web OWASP memperlakukan pengaturan ulang sebagai rute alternatif ke akun dan merekomendasikan peninjauan setiap antarmuka yang didukung. Oleh karena itu, rencana pengujian Anda harus mencakup antarmuka web, aplikasi seluler, dan API secara terpisah jika perilakunya berbeda.
2. Periksa respons permintaan tanpa menghitung pengguna
Kirimkan satu permintaan resmi dan catat respons, status, dan waktu yang terlihat. Untuk pemulihan kata sandi, akun yang ada dan yang tidak ada tidak boleh mengungkapkan keanggotaan akun melalui pesan atau waktu respons yang jelas berbeda.
Jangan membuat sampel besar untuk mengujinya. Koordinasikan pengujian beban, penyalahgunaan, dan batas kecepatan dengan pemilik sistem, gunakan lingkungan khusus, dan berhenti pada batas yang disetujui. Lembar Cheat Lupa Kata Sandi OWASP merekomendasikan respons dan perlindungan yang konsisten terhadap pengiriman otomatis yang berlebihan karena titik akhir penyetelan ulang dapat mengekspos keberadaan akun atau membanjiri kotak masuk.
Verifikasi bahwa klik kedua tidak secara diam-diam membuat kumpulan rahasia yang valid secara bersamaan dan tidak aman. Kebijakan yang dimaksud mungkin membuat kode pertama menjadi tidak valid, menggunakan kembali permintaan yang tertunda, atau mengizinkan sejumlah kode yang dibatasi; tim produk harus menentukan hasil mana yang benar.
3. Amati pengiriman sebagai keadaan yang berjangka waktu, bukan pernyataan instan
Mulai pengatur waktu ketika aplikasi menerima permintaan. Catat saat pesan terlihat, namun gunakan jendela observasi yang masuk akal daripada menganggap penundaan beberapa detik sebagai kegagalan. Email melewati antrian dan filter, sehingga waktu kedatangan merupakan distribusi, bukan konstanta tetap.
Saat menggunakan Once Email untuk pengujian risiko rendah resmi:
- Buat atau pilih alamat hanya terima dengan sisa masa pakai yang cukup.
- Salin alamat persisnya ke dalam aplikasi yang sedang diuji.
- Minta satu pesan dan biarkan kotak masuk tetap terbuka.
- Jika tidak muncul, segarkan dengan sengaja dan ikuti daftar periksa pemecahan masalah email verifikasi.
- Catat permintaan dan waktu kedatangan yang diamati dalam UTC, ditambah lingkungan pengujian.
Jangan mengklaim bahwa pesan yang hilang membuktikan pengirimnya tidak pernah mengirimkannya. Log aplikasi, peristiwa penyedia, dan header pesan merupakan sumber bukti yang terpisah. Gunakan nilai korelasi yang dibuat oleh sistem pengujian jika memungkinkan, namun jangan memaparkannya secara publik jika sistem memberikan akses atau mengidentifikasi pengguna.
4. Validasi pesan baik isi maupun datanya
Bandingkan subjek yang diterima, domain pengirim, dan tujuan yang terlihat dengan templat yang disetujui. Periksa alternatif teks biasa dan HTML saat aplikasi menghasilkan keduanya. Tinjau jarak, pembungkusan, kontras warna, dan urutan konten yang bermakna di desktop dan area pandang seluler yang sempit.
Kemudian periksa data variabel:
- alamat tes yang dimaksud muncul jika diperlukan dan tidak terduga;
- nama lingkungan cukup jelas untuk mencegah kesalahan staging mail sebagai produksi;
- tanggal dan pernyataan kadaluwarsa menggunakan zona waktu yang tidak ambigu;
- kode atau tindakan dikaitkan dengan kasus uji yang benar;
- tautan menggunakan HTTPS dan host yang diharapkan;
- tidak ada jejak tumpukan internal, kunci API, kata sandi, atau data pelanggan yang tidak terkait yang muncul.
Jangan membuka tautan yang mencurigakan hanya untuk mengetahui tujuannya. Salin pesan HTML ke browser-lokal pemeriksa tautan email untuk mencantumkan URL dan sumber daya jarak jauh tanpa merender email, lalu bandingkan host tujuan dengan spesifikasi pengujian.
5. Latihan sukses, digunakan kembali dan kadaluarsa
Untuk kode atau tautan, uji jalur bahagia yang disetujui satu kali. Konfirmasikan bahwa halaman tersebut hanya melakukan tindakan yang diinginkan, mencapai lingkungan yang benar, dan tidak mengungkap rahasia dalam elemen halaman atau peristiwa analitik yang tidak perlu.
Selanjutnya, periksa transisi keamanan:
- rahasia sekali pakai berhenti bekerja setelah sukses;
- rahasia yang sudah kadaluwarsa ditolak tanpa menyelesaikan tindakan;
- nilai yang salah formatnya gagal dengan aman;
- permintaan penggantian mengikuti aturan pembatalan yang terdokumentasi;
- membuka tindakan di browser lain tidak mengabaikan konteks yang diperlukan;
- pengaturan ulang kata sandi tidak secara otomatis melemahkan otentikasi multi-faktor atau membiarkan sesi yang tidak diinginkan tetap aktif.
OWASP merekomendasikan rahasia penyetelan ulang yang acak, cukup panjang, disimpan dengan aman, sekali pakai, dan kedaluwarsa. Ini juga merekomendasikan URL penyetelan ulang HTTPS dan perlindungan terhadap tebakan. Pengujian Anda harus memverifikasi perilaku produk, bukan mencoba melakukan kekerasan yang tidak terkendali.
6. Uji pesan kegagalan dan pemulihan
Pengguna memerlukan langkah berikutnya yang berguna ketika pengiriman tertunda, kode kedaluwarsa, atau tautan telah digunakan. Konfirmasikan bahwa kesalahan tidak mengungkapkan keberadaan akun, fragmen rahasia, atau infrastruktur internal. Antarmuka harus memungkinkan percobaan ulang yang sah tanpa mendorong permintaan cepat yang berulang.
Uji juga apa yang terjadi ketika kotak masuk sementara habis masa berlakunya sebelum alur akun selesai. Alamat sekali pakai tidak cocok jika akun memerlukan pemulihan jangka panjang, tanda terima, atau pemberitahuan keamanan. Panduan email sementara versus permanen menjelaskan kapan alamat permanen dan terkontrol merupakan asumsi pengujian yang lebih aman.
7. Catat hasil minimal yang dapat direproduksi
Hasil pengujian yang berguna mencakup kasus, lingkungan, pembangunan, garis waktu UTC, hasil yang diharapkan, hasil aktual, dan satu item bukti yang disunting dengan cermat. Nyatakan apakah masalahnya ada pada pembuatan permintaan, pengiriman pesan, konten, tindakan, kedaluwarsa atau pemulihan. Hindari hasil yang tidak jelas seperti “email rusak”.
Jika bukti berisi alamat, kode verifikasi, tautan setel ulang, ID Pesan, cookie, atau nama host internal, jangan mengunggahnya tanpa mengubah. Ikuti panduan redaksi bukti tes email sebelum melampirkannya ke suatu terbitan.
Rilis daftar periksa keputusan
Sebelum menandai alur siap, konfirmasikan bahwa kasus berhasil yang diotorisasi telah lolos, kasus negatif gagal dengan aman, aturan percobaan ulang dan kedaluwarsa sesuai dengan spesifikasi, konten berfungsi dengan lebar yang sempit, tidak ada rahasia yang masuk ke log atau analitik, dan bukti dapat mereproduksi kegagalan tanpa memperlihatkan kredensial yang dapat digunakan. Satu kedatangan yang berhasil merupakan bukti yang berguna, namun ini bukanlah tes aliran email yang lengkap.
Panduan terkait
Mengapa Once Email Dirancang Hanya untuk Menerima Email
Pengenalan faktual tentang Once Email, masalah yang dapat diselesaikan oleh kotak masuk sementara, kasus-kasus yang tidak boleh digunakan, dan batasan keamanan di balik layanan.
Cara Menyimpan Bukti Tes Email Tanpa Membeberkan Rahasia
Buat tangkapan layar, header, dan laporan bug yang berguna sambil menghapus kode verifikasi, setel ulang token, alamat email, pengidentifikasi, dan data pribadi yang tidak terkait.