TEMEL FİKİR
Bir ürün kategorisi tek bir mimariyi dikte etmez. Bir sistemi hizmetlere bölmeden önce hesapları, siparişleri, verileri ve entegrasyonları anlayın.
Ticaret, ödeme düğmesinden ibaret değildir
Ürün, fiyat, sipariş, ödeme ve ücret iadesi tanımlarına; her olayın ne anlama geldiğinin açıkça belirlenmesine ihtiyaç vardır. Bir ödeme sayfasının açılması, tahsilat yapıldığını kanıtlamaz. Sağlayıcı bildirimlerinin sunucuda doğrulanmasını ve yinelenen olayların nasıl ele alınacağını planlayın. Barındırılan bir e-ticaret platformu standart işlemlere daha uygun olabilir; alışılmadık gereksinimler ise ayrıca test edilmelidir.
SaaS, müşteriler arasına sınırlar ekler
Bir sistemi birden fazla şirket kullandığında verilerin, izinlerin ve raporların ayrılması arayüzdeki bir filtreye bırakılamaz. Paylaşılan kaynakları, her kuruluşa ait kaynakları, yönetim, faturalandırma ve dışa aktarma sorumluluklarını belirleyin. Hesap sayısı, eşzamanlı istek sayısı değildir: iş yükü, kullanıcıların ne yaptığını, ne zaman yaptığını ve her işlemin ne kadar veri işlediğini açıklar.
Panolar tutarlı tanımlar gerektirir
Grafik çizmeden önce “tamamlandı”, “gecikti” ve “inceleniyor” durumlarının ne anlama geldiğini kararlaştırın. Sayılar tüm kayıtları mı, yalnızca mevcut sayfayı mı kapsıyor? Tarih, oluşturulma zamanını mı yoksa son güncellemeyi mi gösteriyor? Göstergenin kaynağını ve sınırlarını açıklayın; hesaplanmamış yüzdeler veya sayılar göstermeyin. Bunlar, grafik kütüphanesi seçilmeden önce verilmesi gereken ürün ve veri kararlarıdır.
Örnek: harici bir hizmetten geçen bir istek
Bir kullanıcının istek gönderdiğini ve sağlayıcının yanıtının kesildiğini varsayalım. Başarılı olduğu doğrulanmamış bir sonucu başarılı göstermeyin veya körü körüne yeniden denemeyin. Sunucuda anlaşılır bir durum, işlem kimliği ve güvenli bir doğrulama ya da yeniden deneme yolu tasarlayın. Sağlayıcı değişikliğinin her arayüzde değişiklik gerektirmemesi için entegrasyonu sınırları belirli bir bileşen olarak ayırın. Bu örnek, gerçek bir sağlayıcı yetkilendirmesi veya canlı entegrasyon bulunduğu anlamına gelmez.
Kanıt bunu haklı çıkardığında genişletin
Test edilebilir ve bakımı yapılabilir açık mantıksal sınırlarla başlayın. Önbelleği ve arka plan işlerini teknoloji kontrol listesini tamamlamak için değil, belirli sorunları çözmek için ekleyin. Önemli senaryoları ve hataları ölçün; izinli yük testinin nerede gerekli olduğunu belirleyin. Programlama dili veya bulut markasına dayanarak bir milyon kullanıcı garantisi vermeyin ve izinsiz olarak üçüncü taraf sistemlere yük testi uygulamayın.
EĞİTİM ÖRNEĞİ / İNCELENEBİLİR ADIMLAR
Durum testleri: abonelik, ödeme ve müşteriler arasındaki sınırlar
İki test kuruluşunun bir ürüne abone olduğu ve ödeme bildirimleri aldığı eğitim senaryosu. Hesaplar ve olaylar sentetiktir; bu, bu web sitesinde aktif bir ödeme ağ geçidi veya mevcut entegrasyon anlamına gelmez.
- Müşterilerin birbirinden ayrılması: A kuruluşuna ait bir kayıt oluşturun ve B kuruluşu kimliğiyle arayüz, API ve dışa aktarma üzerinden bu kayda erişmeyi deneyin. Kayıt kimliği bilinse bile hiçbir yoldan veri açığa çıkmamalıdır.
- Ödeme onayı: Gerçek bir ödeme yapmadan tarayıcıdaki başarı sayfasını açın. Sunucu, doğru hesap ve sipariş için yetkili kaynaktan ödeme durumunu doğrulayana kadar kullanım haklarının değişmediğini kontrol edin.
- Bildirimin kaynağı: Sağlayıcının belgelerine uygun olarak imzası geçersiz bir test olayı ve geçerli bir test olayı gönderin. İlk olayın reddedildiğini, ikincisinin belgelenmiş biçimde işlendiğini ve günlüklerde gizli bilgilerin yer almadığını doğrulayın.
- Yinelenme yönetimi: aynı olayı iki kez iletin, ardından sağlayıcının desteklediği şekilde tek işlem için iki olayı test edin. Kabul ölçütleri, yinelenen kullanım hakkı veya mali kayıt oluşmaması ve işlemenin izlenebilir olmasıdır.
- Gecikme ve sıralama: test güncellemelerini sıra dışı veya kesintiden sonra gönderin. Kabul ölçütü, aboneliği eski bir duruma döndürmek yerine yetkili kaynaktan güncel durum kontrolleri ve izin verilen geçişlerin uygulanmasıdır.
- İptal ve dışa aktarma: A kuruluşunun aboneliğini iptal edin; politikanın ek süresini ve dışa aktarmayı test edin. Kabul ölçütü, yalnızca A’nın erişiminin değişmesi, B kuruluşunun etkilenmemesi ve verilerinin açığa çıkmamasıdır.
Popülerliği değil, ihtiyaca uygunluğu karşılaştırın.
Mevcut ticaret platformu
Uygun olduğu durum: Standart satış iş akışları ve mevcut, yetkili entegrasyonlar.
Dikkate alın: Özelleştirmeyi, verileri dışa aktarmayı, ödeme durumlarını ve ücretleri inceleyin.
Özel web uygulaması
Uygun olduğu durum: Mevcut yazılımın karşılamadığı iş kuralları veya müşteri kuruluşlar arasındaki veri ve erişim sınırları.
Dikkate alın: Veri, yetki, entegrasyon ve işletim testleri gerektirir.
Mevcut sistemi iyileştirin
Uygun olduğu durum: Belirlenebilir ve yalıtılabilir bir sorunu olan uygun temel.
Dikkate alın: Kaynak kodunun anlaşılmasını, doğrulama ve önceki sürüme dönüş planını gerektirir.
Bu, bir hizmet teklifi veya performans garantisi değil, karar desteğidir. Nihai seçiminiz gereksinimlerinize ve uygulama sırasında seçilen sürümlere bağlıdır.
Daha fazla bilgi için resmî kaynaklar
OWASP — Uygulama Güvenliği Doğrulama Standardıyeni pencerede açılırPostgreSQL — belgeleryeni pencerede açılırweb.dev — Web Vitalsyeni pencerede açılırStripe — webhook doğrulaması, yinelenen olaylar ve olay sıralamasıyeni pencerede açılırKaynaklar teknolojilerin özelliklerini açıklar. Senaryolar ve ödünleşimler, karşılaştırmalı performans sonuçları değil, bağlama dayanan rehberliktir.