Kayıt stres provası: check-in nasıl test edilir

Kayıt sürecinin yük altında kabulü için pratik bir plan: zirve senaryoları, güvenli veriler, yedekleme, PASS/FAIL kriterleri ve yüklenici raporu.

Yük testi provası neyi kanıtlamalı?

Kayıt sürecinin yük testi provası, misafir yolculuğunun tamamının gerçek akış altında çalıştığını göstermelidir: kayıt bulunuyor, QR kodu okunuyor, durum bir kez değişiyor, yaka kartı basılıyor ve sonuç yan çalışma istasyonlarında görünüyor. Burada check-in, kaydın bulunması ve misafirin gelişinin kaydedilmesidir. Tek bir formun başarılı yanıtı veya tarayıcının sesli sinyali, tüm sürecin hazır olduğunu henüz kanıtlamaz.

Biz Aventura'da önce kontrolün sınırlarını belirliyoruz. Misafir davetiyesini gösterir veya kaydının bulunmasını ister. Sistem durumu kontrol eder, gelişi kaydeder ve verileri yazdırmaya iletir.

Operatör anlaşılır bir onay alır. Bağımlılık haritasına dış servisler de dahildir.

Genel kayıt rotası, etkinlik katılımcılarının kaydı hakkındaki makalede ayrıntılı olarak ele alınmıştır. Buradaki görev daha dardır: bu rotayı akış altında test etmek ve önceden yazılmış kriterlere göre "geçti" veya "geçmedi" kararını almak.

Tarayıcı, barkod başarıyla çözüldükten sonra sesli sinyal verebilir. Bu, sembolün cihaz tarafından okunduğunu doğrular, ancak merkezi sistemde yeni bir durumun kaydedildiğini doğrulamaz. Bu nedenle gözlemci yalnızca tarayıcının tepkisini değil, operatör ekranını, misafir kartını, yazdırmayı ve nihai dışa aktarımı da karşılaştırır.

Müşteri açısından zirve akışı

Zirveyi yuvarlak bir sanal kullanıcı sayısıyla değil, misafir varış senaryosuyla tanımlıyoruz. Müşteri varış pencerelerini, ana grubun payını, birden fazla girişi, manuel durumları ve eşzamanlı işlemleri tanımlar. Teknik ekip her dakikada kaç işlemin başladığını ve her aşamanın ne kadar sürdüğünü hesaplar.

Konferans organizasyonu için ulaşım programını, genel oturumun başlangıcını, bölümlere erişimi ve materyal dağıtım kurallarını bir araya getirmek faydalıdır. Otobüs veya genel bloğun sona ermesi bir talep basamağı oluşturur. Önceki işlemler yavaşlamış olsa bile misafirler gelmeye devam eder.

Asgari model şunları içerir:

• zaman dilimlerine göre beklenen misafir sayısı;
• QR, manuel arama ve ön kaydı olmayan misafirlerin payı;
• giriş, banko, tarayıcı ve yazıcı sayısı;
• tekrarlanan taramaların ve yeniden yazdırmaların payı;
• geç gelen durum veya kategori değişiklikleri;
• ağ, e-posta, SMS ve harici veritabanlarına bağımlılıklar.

Böyle bir profil, teknik yükü görünür kuyrukla karşılaştırmayı sağlar. Sunucu hızlı yanıt verebilir, ancak çalışma istasyonu arama, yazdırma veya belirsiz bir hata nedeniyle misafire yine de yavaş hizmet verebilir. Bu nedenle sistem işlemi ile bankodaki tam döngü ayrı ayrı ölçülür.

Senaryoya hangi işlemler dahil edilmeli?

Senaryo, ekibin girişte gerçekleştirdiği iş süreçlerini istisnalar dahil yansıtmalıdır. Tek bir kayıt sayfasını test etmek, yanlış bir hazırlık hissi verir. Ana akış; ortak kaynaklar için rekabeti ve karmaşık durumların kuyruğa etkisini görmek için manuel arama, tekrar QR, geç kayıt ve yazdırma ile birlikte çalıştırılır.

Rotayı şöyle oluşturuyoruz:

1. Misafir QR kodunu gösterir veya arama için bilgilerini söyler.
2. Operatör tek doğru kaydı bulur.
3. Sistem mevcut durumu ve erişim haklarını kontrol eder.
4. Check-in durumu tam olarak bir kez değiştirir.
5. Yazıcı güncel kategoriyle birlikte yaka kartını basar.
6. Yan banko, verileri manuel olarak yenilemeden değişikliği görür.
7. Nihai dışa aktarım tek bir onaylanmış işaret içerir.

Senaryoya bir yazım hatası, aynı soyadlı bir kişi, QR kodu olmayan bir durum, daha önce kullanılmış bir kod, geç kayıt ve tekrar yaka kartı talebi eklenir. Ayrıntılı taşıyıcı seti, yük testini ayrı bir QR güvenlik denetimine dönüştürmeden etkinlikte güvenli QR kodları hakkındaki makaleyle karşılaştırılabilir.

Geç değişiklik de tüm çevrimden geçmelidir. Kayıt, kontrol dışa aktarımından sonra oluşturulur veya değiştirilir; ardından arama, haklar, yazdırma ve yeni durumun yayılması kontrol edilir. Geç kayıtlar hakkındaki yan içerik, projenin tüm takvimini tekrarlamadan böyle bir senaryo hazırlamaya yardımcı olur.

Kayıt, etkinlik üretiminin tamamına entegre edilmiştir. Mekan, yükleniciler ve giriş ekibinin genel çevrimi gerekiyorsa, kurumsal etkinlik organizasyonuna göz atın: rolleri, kontrol noktalarını ve yedek çözümleri önceden kararlaştırıyoruz.

Mekan hazırlığı ve ekip çalışmasına dair pratik incelemeleri de Aventura'nın Telegram kanalında yayınlıyoruz.

Üç test modu

Kabul protokolümüzde üç mod kullanıyoruz: temel zincirin kısa kontrolü, beklenen iş akışı ve ani yükseliş. Bunlar farklı sorulara yanıt verir. Tek bir sorunsuz hızlanma senaryo hatasını gizleyebilir; sınır kapasitesinin aranması ise üzerinde anlaşılan zirvenin iş kriterlerini karşıladığını doğrulamaz.

k6 dokümantasyonunda temel kontrol, normal yük, aşırı yük, ani yükseliş ve sistem sınırının aranması için ayrı modlar bulunur. Müşterinin aracın yapılandırmasını anlaması gerekmez, ancak testin amacını anlaması gerekir.

Bir mod ani akına tepkiyi gösterir, diğeri sınırı arar. İş testi etkinliğin belirli senaryosunu doğrular.

Büyük provadan önce ekip her yol için temel bir test yapar. Bu test hatalı test kayıtlarını, eksik izinleri ve entegrasyon hatalarını yakalar. Ardından yük, teknik uzmanın doğaçlamasıyla değil, üzerinde anlaşılan profile göre artırılır.

Güvenli test verileri nasıl hazırlanır?

Prova için, gerçek iletişim bilgileri olmadan misafir veri tabanının yapısını tekrarlayan sentetik profiller kullanmak en iyisidir. Set farklı roller ve kategoriler içerir. Bazı kayıtlar benzer soyadlarını, geç değişiklikleri ve istisnaları taklit eder. Başlatmadan önce ekip erişimleri ve silme süresini kararlaştırır, harici gönderimleri ise güvenli bir test ortamına yönlendirir.

152-FZ sayılı Federal Kanun'un beşinci maddesinin ilkeleri, belirli bir işleme amacı, verilerin bu amaca uygunluğu ve aşırılık içermemesi gerekliliğini ortaya koyar. Yük testi için bu, aynı senaryo kurgusal kayıtlarla yeniden üretilebiliyorsa, "gerçekçilik için" canlı veri tabanını kopyalamamak adına pratik bir gerekçedir.

Set adım adım hazırlanır:

1. Check-in sürecinde gerçekten yer alan alanlar ve durumlar belirlenir.
2. Gerekli kategorilerde ve dağılımda sentetik kayıtlar oluşturulur.
3. Tekrar QR, geç değişiklik ve yeniden yazdırma için kayıtlar ayrıca işaretlenir.
4. Operatörlerin ve gözlemcilerin erişimleri test rolleriyle sınırlandırılır.
5. Gerçek alıcılara e-posta ve mesaj gönderimi engellenir.
6. Kabul sonrasında kayıtların, logların ve dışa aktarımların silinme süresi belirlenir.

Form ve onaylara ilişkin yasal gereklilikler ayrıca kontrol edilmelidir. Bunun için 152-FZ kapsamında kayıt formu hakkında bir materyal bulunmaktadır. Yük provasında biz zaten onaylanmış veri şemasını kontrol ediyoruz. Test kayıtlarının içeriği, erişimler, günlükleme ve saklama süreleri kişisel verilerden sorumlu kişi veya avukatla kararlaştırılır.

Başlatmadan önce "geçti / geçmedi" (PASS/FAIL) kriterleri

PASS/FAIL, önceden yazılmış bir kritere göre "geçti / geçmedi" anlamına gelir. Kabul kriterlerini testten önce yazın ve bunları vaat edilen misafir yolculuğuyla ilişkilendirin. Gecikme veya işlem sayısı için evrensel bir norm yoktur. Proje ekibi kabul edilebilir akışı, hataları, hizmet süresini ve durdurma kurallarını belirler, ardından eşikleri sonradan düzeltmeden gerçek sonucu bunlarla karşılaştırır.

k6 eşik koşulları, metrik için kriterin geçilip geçilmediğini otomatik olarak işaretler. Dokümantasyondaki belirli değerler projeye normatif değer olarak aktarılamaz. Bunlar, kabul edilebilir kuyruk ve vaat edilen hizmet dikkate alınarak sistem sahibi, müşteri ve operasyon ekibi tarafından belirlenir.

Özel bir kriter yük jeneratörüyle ilgilidir. Planlanan işlemler başlatılmadıysa rapor, beyan edilenden daha düşük bir akış tanımlar. dropped_iterations metriği, test edilen sistemin bozulmasını kaynak yetersizliğinden veya jeneratörün kendi yanlış yapılandırmasından ayırmaya yardımcı olur.

Prova sırasında neleri bozmalıyız?

Prova sırasında, üzerinde anlaşılmış bir zaman aralığında ağ, yazıcı, harici servis veya tek bir iş istasyonu gibi bağımlılıkları sırayla devre dışı bırakır veya yavaşlatırız. Ekip, tespit hızını, mesajın anlaşılırlığını ve yedek sisteme geçişi kontrol eder. Her arıza, derhal durdurma hakkı ve önceden atanmış bir prova yöneticisi ile senaryoya göre tetiklenir.

Faydalı arıza seti:

• yavaş veya kısa süreli erişilemeyen ağ;
• tek bir tarayıcı veya yazıcının arızalanması;
• check-in fiilen gerçekleştikten sonra kaybolan yanıt;
• tekrara kadar bekleme süresini belirten HTTP "Çok Fazla İstek" yanıtı;
• erişilemeyen harici veritabanı veya yazdırma servisi;
• belirsiz durum nedeniyle operatörün tekrar basması;
• manuel işaretlemelerden sonra bağımlılığın geri gelmesi.

Anında otomatik tekrarlar yeni bir istek dalgası yaratabilir: zaten aşırı yüklenmiş servis daha da fazla çağrı alır ve daha uzun sürede toparlanır. İşlem misafirin durumunu değiştiriyorsa, kör bir tekrar kopya oluşturabilir. Sistem güvenli tekrarı, beklemeyi ve sonucun manuel kontrolünü birbirinden ayırt etmelidir.

Ağ kısmının mekânın altyapı sahibiyle koordine edilmesi daha iyidir. Konferansta misafir Wi-Fi'ı hakkındaki makale, hizmet kaydının misafir trafiğiyle birlikte tek bir genel hız testiyle değerlendirilemeyeceğini açıklar.

Stantlar, QR kodlar ve geri bildirim

Laboratuvar testi, gerçek stantlar, cihazlar ve taşıyıcılar üzerinde yerinde bir prova ile tamamlanır. Ekip, farklı parlaklıktaki telefon ekranlarını, kâğıt kodları, yansımaları, tekrar yaklaştırmayı ve gürültüyü kontrol eder. Operatör, yalnızca arayüzdeki sese veya renge bağlı olmayan, net bir işlem sonucu görmelidir.

GS1, iki boyutlu kodun okunabilirliğini sembolün etrafındaki boş alan, kontrast, düzgün ızgara ve grafik gürültünün olmamasıyla ilişkilendirir. Bu nedenle provaya misafirlerin karşılaşacağı boyutlar, malzemeler ve gösterim yöntemleri dahil edilir. Monitördeki kusursuz test görüntüsü, gerçek taşıyıcının yerini tutmaz.

Senaryomuzda altı ayırt edilebilir durumu kontrol ederiz: "kod okundu", "kontrol ediliyor", "giriş onaylandı", "zaten işaretlendi", "kayıt bulunamadı" ve "bağlantı yok". W3C'nin durum mesajları kılavuzu, durum değişikliğinin odağı zorla taşımadan programatik olarak belirlenebilmesini gerektirir. Bir stant için bu aynı zamanda personelin eğitim hızı sorunudur.

Girişlerin fiziksel düzeni, kuyruklar ve ekipman yerleşimi mekân seçiminde dikkate alınmalıdır. Sistem sunucu testini geçebilir, ancak dar bir fuaye, birkaç kategori için ortak bir hat veya operatörlerin misafir akışı içinden geçerek ulaştığı bir yazıcı nedeniyle verim kapasitesini kaybedebilir.

Yedekleme ve kurtarma nasıl kontrol edilir?

Yedekleme ancak fiili geçiş, girişin devam etmesi ve karşılıklı mutabakat sonrasında çalışır sayılır. Yerel veya otonom mod beyan edilmişse ekip ana bağımlılığı devre dışı bırakır, işlemleri biriktirir, bağlantıyı geri getirir ve çakışmaları kontrol eder. Otonom mod yoksa manuel süreç ve tüm raflar için tek bir geçiş komutu prova edilir.

Kurtarma senaryosu şöyle işler:

1. Prova yöneticisi seçilen bağımlılığın arızasını ilan eder.
2. Ekip tespit zamanını ve görünen belirtiyi kaydeder.
3. Kıdemli kayıt sorumlusu tek bir mutabık kalınmış geçiş komutu verir.
4. Operatörler girişe yedek güzergâh üzerinden devam eder.
5. Gözlemci manuel ve yerel işaretlemeleri kaydeder.
6. Ana hizmet mutabık kalınan sırayla geri alınır.
7. Veriler karşılaştırılır, çakışmalar çözülür, nihai sürüm onaylanır.

Bağlantı şeması ve yerel listelerle çalışmaya dair ayrıntılı bilgi mobil internet olmadan etkinlik makalesinde yer alıyor. Mevcut provada geçiş noktaları ve geri senkronizasyon önemlidir: komutu kim veriyor, operatör ne görüyor ve katılımın iki kez işaretlenmesi nasıl önleniyor.

Yedekleme her raf tarafından kendi başına devreye alınmamalıdır. Mutabık kalınmamış yerel kararlar birden fazla doğru versiyonu yaratır. Mod konusunda kararı tek bir yönetici verir ve prova günlüğü zamanı, nedeni ve kapsamı kaydeder.

Test çalıştırması sonrası yüklenici raporu

Rapor, gerçekte oluşturulan yükü ve her iş operasyonunun sonucunu göstermelidir. Kısıtlamalar ve düzeltmelerden sorumlu kişiler ayrıca belirtilir. Tek başına ortalama gecikme grafiği yeterli değildir.

Müşteri, zaman bazlı profili, yazdırma durumunu ve yedek sistemin çalışmasını görmek ister. Kritik hatalar için orijinal senaryoya göre tekrarlanan test çalıştırmasının sonucu da eklenir.

Rapora şunlar dahil edilir:

• sistem ve senaryo sürümü;
• test verileri ve donanım sürümü;
• operasyonların planlanan başlangıç profili;
• gerçekte oluşturulan profil;
• her bir operasyonun sonuçları;
• hatalar ve zaman aşımları;
• «Çok fazla istek» yanıtları ve yeniden deneme davranışı;
• dropped_iterations ve üretici kaynakları;
• iş istasyonunda toplam hizmet süresi;
• yazdırma kuyruğu ve yeniden verilme durumları;
• yedek sisteme geçiş ve geri dönüş sonucu;
• hataların listesi, sorumlular ve yeniden kontrol kriterleri.

Hatayı yeniden üretilebilir bir senaryoyla ilişkilendiriyoruz. Kartta başlangıç koşulları ve işlem sırası kalır. Aynı yerde beklenen sonucu ve ekibin test çalıştırmasında gördüklerini belirtiyoruz.

Çalışmanın devamı için etki, geçici önlem ve sorumlu kişi kaydedilir. Genel yaklaşım etkinlikteki olay günlüğü ile karşılaştırılabilir. Mekan açılmadan önce hatalar etkinliğin çalışma günlüğünden ayrı tutulur.

«Düzeltildi» mesajı bir bulguyu kapatmaz. Ekip aynı senaryoyu benzer başlangıç koşullarıyla tekrarlar. Sonuç değişirse raporda yeni bir PASS görünür. Değişmezse hata açık kalır veya açıkça mutabık kalınan bir kısıtlama olarak kabul edilir.

Müşteri için kabul kontrol listesi

Size her teknik çizelgeye erişim değil, anlaşılır onaylardan oluşan kısa bir liste gerekiyor. Prova tamamlanmadan önce varış profilinin yeniden oluşturulduğunu, karmaşık durumların ana akışı durdurmadığını ve yedek sistemin fiilen devrede olduğunu kontrol edin. Her kritik hata için bir sorumlu atayın ve düzeltmeden sonra sonucu kayıt altına alarak tekrar bir prova yapın.

1. Varış pencereleri, girişler ve işlemlerin kapsamı tanımlandı.
2. Her rotanın temel provası yoğun yükten önce tamamlandı.
3. Beklenen akış ve ani yükselme ayrı ayrı test edildi.
4. Fiili yoğunluk planla örtüşüyor ya da fark açıklandı.
5. Başarılı QR tek bir doğru işaretle sonuçlanıyor.
6. Zaman aşımından sonra tekrar deneme kopya kayıt oluşturmuyor.
7. Yazdırma gerçek yazıcılar ve sarf malzemeleriyle test edildi.
8. Manuel durumlar ayrı bir hatta ilerliyor ve ana akışı engellemiyor.
9. Operatörler anlaşılır durumları ve sonraki adımı görüyor.
10. Erişimi kısıtlanmış sentetik veriler kullanıldı.
11. Bağımlılık arızası ve kurtarma pratikte test edildi.
12. Her kritik hata düzeltmeden sonra tekrar kontrol edildi.

Yüz yüze provayı etkinliğin teknik provası ile aynı kurallara göre kurgulamak uygundur: senaryo, gözlemlenebilir sonuç, not için sorumlu ve tekrar kontrol. Fark odak noktasındadır - burada tüm ekip yalnızca kayıt hattına ve bağımlılıklarına odaklanır.

Kabul, gerçek akış altında, arıza sırasında ve kurtarma sonrasında misafirin tüm yolculuğunu kapsamalıdır. Tek başına bir tarayıcı veya form tam bir resim vermez.

Kaynaklar

• Grafana k6: yük testi türleri
• Grafana k6: thresholds kriterleri
• Grafana k6: dropped iterations
• Microsoft Azure Architecture Center: Retry Storm antipattern
• Microsoft Azure Architecture Center: Retry pattern
• Zebra DataWedge: barcode input and feedback
• GS1: iki boyutlu kodların kalitesi ve okunabilirliği kılavuzu
• IETF RFC 6585: HTTP 429 Too Many Requests
• W3C WCAG 2.2: Status Messages
• Federal Law No. 152-FZ: kişisel verilerin işlenmesi ilkeleri