Kasus Uji Alamat Checkout: Autofill, Koreksi, dan Perhitungan Ulang Pengiriman

Entri alamat memiliki banyak jalur

Meliputi entri keyboard, isi otomatis browser, tempel multibaris, saran, dan alamat tersimpan. Setiap jalur harus menghasilkan satu kontrak API dengan tetap mempertahankan detail negara dan unit.

Batas waktu saran tidak boleh menghalangi entri manual yang valid. Jelaskan bahwa pembeli dapat melanjutkan daripada menjebak mereka dalam daftar kosong.

Jaga agar pembelanja tetap mengendalikan koreksi

Tampilkan alamat yang dimasukkan dan disarankan secara berdampingan, sorot perubahan, dan izinkan alamat asli. Jangan pernah diam-diam mencantumkan nama apartemen atau gedung.

Uji terima, pertahankan, buka kembali, batas waktu, dan saran hilang baris 2.

Hitung ulang metode pengiriman, pajak, dan pengiriman

Pengeditan negara, wilayah, atau kode pos dapat membuat metode tidak valid dan mengubah pengiriman, pajak, ambang batas, dan tanggal. Blokir pengiriman akhir hingga penawaran baru tiba.

Pengeditan cepat membuat kutipan bersamaan. Terapkan hanya hasil yang cocok dengan versi alamat terbaru.

• Hapus metode yang tidak valid setelah perubahan negara
• Perbarui pengiriman dan pajak secara bersamaan
• Abaikan tanggapan kutipan basi
• Pertahankan keranjang dan alamat setelah kegagalan

Penagihan dan pengiriman memerlukan salinan independen yang dapat diedit

Sama seperti pengiriman dapat membuat salinan, namun keduanya tidak boleh berbagi objek yang bisa berubah. Mengedit penagihan setelah menghapus centang tidak boleh mengubah pengiriman.

Gunakan sandbox penyedia pembayaran dan pemicu yang terdokumentasi, bukan data acak untuk pemeriksaan alamat pembayaran.

shippingAddress = structuredClone(selectedAddress);
billingAddress = sameAsShipping
  ? structuredClone(shippingAddress)
  : enteredBillingAddress;

Jadikan penyerahan akhir idempoten dan potret alamatnya

Klik dua kali, percobaan ulang batas waktu, dan navigasi kembali seluler dapat mengulangi permintaan. Nonaktifkan tindakan UI berulang dan gunakan kunci idempotensi sisi server.

Simpan cuplikan alamat yang dikonfirmasi dan versi penawaran pada pesanan alih-alih hanya mereferensikan entri buku alamat yang dapat diedit.

Cakupan seluler harus mencakup keyboard perangkat lunak yang menyembunyikan tindakan utama, memindahkan aplikasi ke latar belakang lalu memulihkan halaman, dan kembali dari otorisasi pembayaran eksternal. Saat melanjutkan, kueri pesanan yang ada atau permintaan idempoten sebelum mengirim operasi pembuatan lainnya.

Audit pesanan yang alamatnya berubah dua kali saat checkout. Cuplikannya harus berisi versi akhir yang dikonfirmasi, penawaran pengirimannya harus termasuk dalam versi tersebut, dan pengeditan selanjutnya pada buku alamat pembeli tidak boleh menulis ulang riwayat pesanan.

Uji juga kegagalan yang ambigu: waktu browser habis setelah pengiriman, tetapi server telah membuat pesanan. Percobaan ulang dengan kunci yang sama harus mengembalikan hasil asli, bukan membebankan biaya lagi atau mencadangkan inventaris dua kali. Alat pendukung harus mengekspos kunci permintaan, versi alamat, dan pengidentifikasi pesanan tanpa menampilkan alamat lengkap di log rutin. Hal ini membuat pemulihan dapat diuji sambil membatasi akses data pribadi yang tidak diperlukan.

• Simulasikan klik dua kali, coba lagi batas waktu, dan pengembalian pembayaran
• Status idempoten kueri setelah restorasi halaman
• Cocokkan alamat pesanan dan versi penawaran
• Buka kembali riwayat setelah mengedit buku alamat