Soruya verilen cevap

Dağıtılmış planlama sistemlerinin manuel testi, heterojen sistemler arasında farklı tutarlılık modelleriyle durumu yönetmenin karmaşıklığından ortaya çıkmıştır. Temel sorun, zaman mantığının, kaynak kilitleme mekanizmalarının ve üçüncü taraf API entegrasyonlarının yaz saati uygulaması geçişleri ve ağ parçalanmaları gibi uç durumlar altında bütünlüğü koruyup korumadığını doğrulamaktır. Sistematik metodolojim, saat dilimi veritabanları üzerinde sınır analizi ile başlar, uygulamanın basit GMT kaymalarından ziyade Olson saat dilimi tanımlayıcılarını doğru bir şekilde işlediğini doğrular ve özellikle "bahar saatine geçiş" saat boşluklarını ve "kış saatine geri dönüş" belirsiz saatleri test ederim.

Sonrasında, son mevcut kaynak slotu için eşzamanlı rezervasyon girişimlerini simüle etmek amacıyla birden fazla tarayıcı oturumu kullanarak eşzamanlılık testi yaparım, HTTP 409 Çatışma yanıtları veya sessiz rezervasyon aşımı durumlarına dikkat ederim. Dış takvim senkronizasyonu için, iCalendar (ICS) yükü oluşturmasını incelemek üzere bir man-in-the-middle proxy kullanırım, RRULE (tekrarlama kuralları) ile UTC zaman damgalarının ve TZID parametrelerinin doğru bir şekilde serileştirildiğini doğrularken, Exchange Web Services (EWS) ve Google Calendar API'nin iptal güncellemelerini tam kaynak değiştirme yerine HTTP PATCH yöntemleri aracılığıyla ele alıp almadığını kontrol ederim.

Hayattan bir durum

HealthBridge Medical'da, hastaların eyalet sınırları boyunca uzmanlarla video seansları planlamasına olanak tanıyan bir telepsikiyatri platformu başlattık; bu da otomatik olarak HIPAA uyumlu video odaları ve dijital reçete defterleri tahsisini gerektiriyordu. Kritik bir hata, Californiya'lı bir terapistin 2:30 PM slotunun, sistemin belirsiz saat için iki geçerli örnek oluşturması nedeniyle çifte rezervasyon yapılmasıyla ortaya çıktı; Google Calendar ise ikinci örneği farklı TZID yönetimi nedeniyle 3:30 PM olarak yorumladı.

DST anormalliklerini çözmek için üç farklı mimari çözüm değerlendirdik. İlk yaklaşım, tüm randevuların hem UTC hem de yerel saat dilimi verilerini saklamasını zorunlu kılıyordu, yalnızca sunum katmanında dönüştürülüyordu. Bu, veritabanı sorgularını basitleştirse de, yaz saati uygulaması sınırlarını aşan tekrar eden randevular için kırılgan oldu çünkü yaz ve kış örneklerinin aynı yerel saat için farklı UTC kaymaları gerektiriyordu, bu da Google Calendar içe aktarımlarının yılın yarısı boyunca yanlış zamanlar göstermesine neden oldu.

İkinci yaklaşım, yerel görüntüleme için yalnızca savrulmuş zaman (saat dilimi yok) kullanarak, kullanıcının cihazının zamanı doğru yorumlamasına güveniyordu. Bu, sabit kullanıcılar için dönüştürme hatalarını ortadan kaldırdı ancak hastalar farklı saat dilimlerine seyahat ettiklerinde, mobil cihazlarının yer sağlayıcısının konumuna değil de mevcut konumuna göre savrulmuş zamanı otomatik olarak dönüştürmesi nedeniyle kritik randevu kaçırmalarına neden oldu. Dahası, bazı eski yapılandırmalarla Microsoft Exchange, savrulmuş zamanları UTC olarak yorumluyordu ve Batı Kıyısı randevuları için üç saatlik bir kayma hatası yaratıyordu.

Sonunda her bir tekrarı, sunucunun o anda mevcut tz veritabanı kurallarını kullanarak bir zaman damgası depolayan orijinal yerel zamanı ve belirli IANA saat dilimi tanımlayıcısını barındıran anchor timestamps uygulayan üçüncü yaklaşımı seçtik. Bu strateji, DST geçişlerinde ön hesaplama hatalarını önlerken mevcut Outlook randevularıyla mevcut çatışmaları tespit etmede karmaşıklık getirdi. Bu yöntemi seçtik çünkü gelecekteki saat dilimi yasası değişikliklerine karşı anlamı korurken, önceden hesaplanan örnekler bir ülkenin DST'yi kaldırması durumunda yanlış hale gelecekti.

Uygulama, saat dilimiyle ilgili çifte rezervasyonları tamamen ortadan kaldırdı ve sonraki DST geçişinde dış takvimlerle %99.97 senkronizasyon doğruluğu sağladı. Dağıtım sonrası izleme, "kaybolan saat" hatası olarak sıfır durumu doğruladı, manuel regresyon testleri ise Exchange kaynak postaların iptal sonrası ekipmanın iki saniye içinde doğru bir şekilde serbest bırakıldığını doğruladı, böylece daha önce manuel idari müdahaleyi gerektiren kaynak kilitlenmelerini önledi.

Adayların genellikle kaçırdığı noktalar

Randevu serisi güncellendiğinde (istisnalar) sonsuz döngüler veya veri bozulması yaratmadan nasıl test edersiniz?

Adaylar genellikle yalnızca olumlu yol tekrarlayan serileri test eder, ancak istisna işleme karmaşasını kaçırır. Haftalık tekrarlayan bir seri oluşturmalısınız, ardından bir örneği farklı bir zamana (istisna oluşturarak) değiştirmelisiniz, başka bir örneği silin ve ardından seri ana zamanını güncelleyin. İstisnaların ilgili kaymalarını veya belirli istisnaların geri dönüş yapmadan korunduğunu, silinen örneklerin ise yeniden oluşmadığından emin olun.

Ayrıca, ana seriyi farklı bir saat dilimine taşıdığınızda ne olacağını test edin; istisnaların, serinin kalıbını izleyecek şekilde tasarlanmamışsa, ideal olarak orijinal yerel zamanlarını koruması gerekir. Bu, ICS dışa aktarımlarındaki RECURRENCE-ID alanlarının orijinal örneğin zaman damgalarıyla eşleştiğini kontrol etmeyi gerektirir, böylece dış takvimler, örneğin Outlook, istisnayı orijinal oluşum slotu ile doğru bir şekilde ilişkilendirebilir.

Randevular iptal edildiğinde, özellikle sınırlı erişim pencereleri olan özel ekipmanlar için kaynak deallocate edilmesinin doğru bir şekilde gerçekleştirildiğini nasıl doğrularsınız?

Bu, yumuşak silme ile sert silme senaryolarını içeren tam yaşam döngüsünü test etmeyi gerektirir. Salı sabahı için tek mevcut EEG makinesi'ni işgal eden bir randevu oluşturun, UI aracılığıyla iptal edin ve ardından hemen o slotu farklı bir hasta ile rezervasyon yapmayı deneyin. Kaynağın ACID işlem tutarlılığı içinde mevcut olduğunu ve eşzamanlı oturumlarda hayalet okumaların oluşmadığını doğrulayın.

İnce hata, iptal işleminin yerel veritabanını güncelleyip Microsoft Exchange kaynak postalarına yayılmadığı durumda meydana gelir, bu da ekipmanın Outlook'ta rezerve kaldığı ancak uygulamanızda serbest olduğu durumları bırakır. Gerçekten serbest kaldığına dair EWS GetUserAvailability çağrılarıyla doğrulama yapmalısınız ve dış senkronizasyon başarısız olduğunda ancak yerel işlem başarıyla gerçekleştiğinde telafi mantığını test etmelisiniz, böylece sistem ya her iki tarafı geri alır ya da tutarsızlık bırakmadan bir yeniden deneme kuyruğu oluşturur.

Dış takvim API'leri, hız kısıtlamalarını zorladığında (Google Calendar günde yaklaşık 1 milyar kota birimi sağlar ancak patlayan trafiği sınırlamaz) veya eski önbelleğe alınmış veriler döndüğünde test etmeyi nasıl ele alırsınız?

Manuel testçiler genellikle HTTP 429 Çok Fazla İstek veya HTTP 503 Servis Kullanılamaz yanıtlarına karşı dayanıklılık testlerini gözden kaçırır. Hız limitini simüle etmek için hızlı bir şekilde birden çok randevu oluşturarak ve değiştirerek otomatik betikler veya tarayıcı konsolu otomasyonu kullanmalısınız ve ardından uygulamanızın üssel geri dönme ve jitter uygulayıp uygulamadığını ya da sessizce veri kaybıyla başarısız olup başarısız olmadığını gözlemlemelisiniz. UI'nın uygun yükleme durumlarını gösterdiğinden ve kotayı yeniden doldururken yinelenen gönderimleri engellediğinden emin olun.

Eski veri senaryoları için, randevuyu doğrudan Google Calendar'da (uygulamanızı atlayarak) değiştirin, ardından uygulamanızda bir senkronizasyon tetikleyin. Çatışma çözümleme algoritmasının dış değişikliği ETag karşılaştırması veya senkronizasyon tokenları aracılığıyla tespit ettiğini doğrulayın, eski yerel durumu üzerine yazmak yerine. Dış takvimin kritik bir rezervasyon sırasında geçici olarak kullanılamadığı senaryoyu özel olarak test edin; sistem, rezervasyonu kaybetmeden veya her iki sistemde hayalet girişleri oluşturmadan senkronizasyonu kuyruklayıp daha sonra uzlaşmalıdır.