GAGASAN UTAMA
Kategori produk tidak menentukan satu arsitektur. Pahami akun, pesanan, data, dan integrasi sebelum membagi sistem menjadi layanan.
Perdagangan lebih dari sekedar tombol pembayaran
Anda perlu mendefinisikan produk, harga, pesanan, pembayaran dan pengembalian dana dengan makna peristiwa yang jelas. Membuka halaman pembayaran bukan bukti bahwa pembayaran telah diterima. Rencanakan verifikasi notifikasi penyedia di server dan penanganan peristiwa duplikat. Platform perdagangan yang dihosting mungkin lebih sesuai untuk operasi standar, sedangkan persyaratan yang tidak biasa perlu diuji secara terpisah.
SaaS menambahkan batasan antar pelanggan
Ketika beberapa perusahaan menggunakan suatu sistem, pemisahan data, izin, dan laporan tidak dapat diserahkan kepada filter antarmuka. Tentukan sumber daya bersama dan milik penyewa serta kepemilikan administrasi, penagihan, dan ekspor. Jumlah akun bukanlah jumlah permintaan secara bersamaan: beban kerja menjelaskan apa yang dilakukan orang, kapan mereka melakukannya, dan berapa banyak data yang ditangani setiap tindakan.
Dasbor memerlukan definisi yang konsisten
Sebelum menggambar bagan, sepakati apa yang dimaksud dengan “selesai”, “terlambat”, dan “dalam peninjauan”. Apakah penghitungan mencakup seluruh catatan atau hanya halaman saat ini? Apakah tanggal mewakili pembuatan atau pembaruan terkini? Perjelas sumber dan batas metrik dan jangan tampilkan persentase atau angka yang tidak dihitung. Ini adalah keputusan produk dan data sebelum menjadi pilihan perpustakaan bagan.
Contoh: permintaan melintasi layanan eksternal
Misalkan pengguna mengirim permintaan dan respons penyedia terputus. Jangan menganggap operasi berhasil tanpa bukti atau mencoba ulang tanpa pemeriksaan. Rancang status yang mudah dipahami, pengenal operasi dan jalur verifikasi atau percobaan ulang yang aman di server. Pisahkan integrasi dengan batas yang jelas agar perubahan penyedia tidak memerlukan perubahan pada setiap antarmuka. Contoh ini tidak menunjukkan adanya otorisasi penyedia atau integrasi aktif yang sesungguhnya.
Perluas ketika bukti membenarkannya
Mulailah dengan batasan logis yang jelas yang dapat diuji dan dipertahankan. Tambahkan caching dan pekerjaan latar belakang untuk memecahkan masalah tertentu, bukan untuk menyelesaikan daftar periksa teknologi. Ukur skenario dan kegagalan penting serta identifikasi di mana pengujian beban resmi diperlukan. Jangan menjamin satu juta pengguna berdasarkan bahasa atau merek cloud, dan jangan melakukan pengujian beban pada sistem pihak ketiga tanpa izin.
CONTOH PENDIDIKAN / LANGKAH YANG DAPAT DITINJAU
Pengujian status: langganan, pembayaran & pemisahan pelanggan
Skenario pendidikan dengan dua organisasi pengujian berlangganan suatu produk dan menerima pemberitahuan pembayaran. Akun dan peristiwa bersifat sintetis; ini tidak berarti gateway pembayaran aktif atau integrasi yang ada di situs web ini.
- Pemisahan pelanggan: buat catatan organisasi A dan minta sebagai organisasi B melalui antarmuka, API dan ekspor. Tidak menerima pengungkapan melalui jalur apa pun, bahkan dengan ID rekaman yang diketahui.
- Konfirmasi pembayaran: membuka halaman sukses browser tanpa pembayaran sebenarnya. Terima hak yang tidak berubah hingga server memverifikasi status otoritatif untuk akun dan pesanan yang benar.
- Asal notifikasi: kirim satu peristiwa pengujian dengan tanda tangan tidak valid dan satu dengan tanda tangan valid sesuai dokumentasi penyedia. Kriteria penerimaan: peristiwa pertama ditolak dan peristiwa kedua diproses dengan dokumentasi, tanpa mencantumkan rahasia dalam log.
- Penanganan duplikat: kirimkan kejadian yang sama dua kali, lalu uji dua kejadian untuk satu operasi yang didukung oleh penyedia. Tidak menerima hak duplikat atau catatan keuangan, dengan pemrosesan yang dapat dilacak.
- Keterlambatan dan urutan: kirim pembaruan pengujian dengan urutan yang tidak sesuai atau setelah gangguan layanan. Kriteria penerimaan: periksa status terkini dari sumber otoritatif dan gunakan transisi yang diizinkan, tanpa mengembalikan langganan ke status lama yang sudah tidak berlaku.
- Pembatalan dan ekspor: batalkan organisasi A dan uji masa tenggang kebijakan dan ekspor. Terima perubahan hanya pada akses A, dengan organisasi B tidak terpengaruh dan datanya tidak diungkapkan.
Bandingkan kecocokan, bukan popularitas.
Platform perdagangan yang ada
Cocok: Alur kerja penjualan standar dan integrasi resmi yang tersedia.
Pertimbangkan: Periksa penyesuaian, ekspor, status pembayaran, dan biaya.
Aplikasi web khusus
Cocok: Aturan bisnis atau batasan penyewa tidak tercakup dalam perangkat lunak yang ada.
Pertimbangkan: Membutuhkan data, izin, integrasi, dan pengujian operasi.
Memperbaiki sistem yang ada
Cocok: Fondasi yang sesuai dengan masalah yang dapat diidentifikasi dan dapat diisolasi.
Pertimbangkan: Memerlukan pemahaman sumber dan rencana verifikasi/pengembalian.
Ini adalah dukungan keputusan, bukan tawaran layanan atau jaminan kinerja. Pilihan akhir Anda bergantung pada kebutuhan Anda dan versi yang dipilih saat implementasi.
Sumber resmi untuk bacaan lebih lanjut
OWASP — Standar Verifikasi Keamanan Aplikasiterbuka di jendela baruPostgreSQL — dokumentasiterbuka di jendela baruweb.dev — Web Vitalsterbuka di jendela baruStripe — verifikasi webhook, peristiwa duplikat dan urutan peristiwaterbuka di jendela baruSumber menjelaskan karakteristik teknologi. Skenario dan trade-off yang ada merupakan panduan kontekstual, bukan hasil tolok ukur.