Görüntü işleme kodunu nasıl test edebilirim?

Görüntü işleme (özellikle OCR) üzerinde çalışıyorum ve birim testlerini gelişimime nasıl entegre etmem gerektiğini merak ediyorum.

Zaten daha "ortak" kod türü için birim testleri kullanıyorum ama görüntü işleme kodu ile uğraşırken onunla başa çıkmak nasıl emin değilim. Bu tür bir kod her zaman bazı görüntü veri giriş / çıkışına ihtiyaç duyar ve alay etmek bu açık değildir. Şimdilik çoğunlukla entegrasyon testleri yapıyorum ama çalışması biraz zaman alıyor ve bunları daha hızlı çalıştırabilmem için bu tür kodları birim testlerine nasıl ayırabileceğime dair bazı fikirler istiyorum.

Düzenleme: Bir karakteri analiz birden fazla döndürme, ölçekleme ve morfolojik işlemleri içeren birçok adımlardan geçebilir. Bu adımlar, algoritma geliştirilirken sıklıkla değişir. Böylece girdi ve beklenen çıktı test sırasında çok gelişebilir. Her karakter 100x100 piksel olabilir, bu yüzden kodda sabit kodlama yapmak veya oluşturulan verilerle çalışmak söz konusu değildir.

— rold2007
kaynak

Birim testi oluşturmada sorun yaşadığınız bir işlevin örneğini çizebilir misiniz?

— Doc Brown

Gerçek bir cevap için çok kısa ve gerçekten birim testi değil: Verileri elle işliyoruz (olduğu gibi: çok sayıda örnek üzerinden geçiyorum - Bu tür sınıflandırma görevleri için genellikle 1000'in ötesine geçiyorum, ancak genel örneklem boyutunuza bağlı ) ve nihai sonuçların elle işlenen verilerle otomatik olarak karşılaştırılması. Bunu yapmak için küçük bir çerçeve kurdum, birkaç hafta içinde açık kaynak olacak, ama bu açıklama - süreci klonlayabilirsiniz: birgitplays.wordpress.com/2012/09/15/…

— Birgit P.

Örneğin, döndürmeyi, ölçeklemeyi vb. Küçük test birimleri olarak kolayca test edebilirsiniz. Belirli bir görüntüyü 45 derece döndürmek fazla değişmemelidir. Bu aynı zamanda ölçeklendirme ve morfolojik işlemler için de geçerlidir. Bununla birlikte, uygulama sırasında beklenen çıktının geliştiği bir şeyi test etmek zordur. Bir kalite ölçümü yapmaya çalışabilir ve kalite> = bazı_kalite diyebilirsiniz. Kalitenizin bozulmadığından emin olmak için, ancak bu da zor olabilir. Bunun dışında, yapabileceğiniz tek şey, altta yatan parçaların kırılmadığını kanıtlayan testlere sahip olmaktır. Ölçek / döndür / vb.

— martiert

@ martiert: Bunları iyi test edildiğine inandığım bir 3. kütüphaneden çağırırken rotasyon, ölçekleme vb. test etmiyorum. OCR algoritması bu işlemlerin çoğundan oluşur. Ama dediğin gibi, bir çıktının evrimleştiği bir şeyi test etmek zor. Belki de seçim seçeneğimiz yok ama entegrasyon testlerine güvenmek için iyi bir uyarı ...

— rold2007

@Birgit P .: İlginç bir çözüm. Dediğiniz gibi hala entegrasyon testi. Sizinki gibi bir çerçeveye sahip olmak, bu testleri daha hızlı kurmanıza yardımcı olur, ancak daha hızlı çalışmazlar ...

— rold2007

Video kayıt / analiz / akış yazılımı ile çalışıyorum ve çok benzer bir sorunla karşılaştık. Aşağıda çözümümüz vardı, uzun vadede nasıl çalışacağından emin değilim ama şimdilik işe yarıyor gibi görünüyor.

Giriş / çıkış görüntülerini birim test projenize kaynak olarak kaydedin. Ardından, belirli bir giriş verildiğinde söz konusu çıktının üretildiğini doğrulamak için birim testini yaptırın.

Kodu yeniden düzenlediğinizde ve başka işlevler eklediğinizde 9/10 kez, görüntü işleme yordamlarınızın davranışının değişmemesini beklersiniz, bu nedenle ani birim testleri başarısız olursa, büyük olasılıkla bir hatadan kaynaklanır.

Öte yandan, gerçek algoritmada değişiklikler yaparsanız, bu da birim sınaması hatasına neden olur. Bu durumda, sonuçların doğru olduğunu manuel olarak / görsel olarak doğrulamanız ve iyi görünmeleri durumunda birim testini tekrar geçmek için görüntü kaynaklarını güncellemeniz gerekir.

Projemizde, hem girdi hem de çıktı için bize veri besleyebilen "sahte" (ya da yapacaksanız sahte) video kaynakları geliştirdik. Ancak verilerin kendisi sahte değildir, manuel testler yaptığımızda ve her şeyin çalıştığını doğruladığımızda aslında çalışan bir sistemden yardımcı veri kayıt sınıfları kullanılarak yakalandı.

— DXM
kaynak

Katılıyorum, dosyalarla çalışan rutinleri test ederken testlerinizdeki bazı somut dosyalara güvenmek uygun (entegrasyon testleri ile daha sık görüyorsunuz).

— Kemoda

İşlem zincirinin tamamında bir girdi çalıştırıp çıktıyı kontrol ederseniz, birim testi değil, entegrasyon testi yaparsınız.

— tdammers

@tdammers: Bunu asla tüm zincir boyunca çalıştırmayı söylemedim. Tüm girişi bir zincirden değil, bir "birimden" geçirin. Ve bunun çıktısının görüntülerden başka bir şey olacağından emin olun, o zaman girişin sadece görüntü kaynakları olarak kaydedilmesi gerekir.

— DXM

@DXM: Çözümünüzü anlıyorum ama sanırım aynı kısıtlamalara sahip olmayabiliriz. Algoritma geliştirilirken girdi / çıktı verilerim çok değişiyor. Bu düzenli değişikliklerle nasıl başa çıkıyorsunuz? OCR'de% 99'un üzerinde doğruluk elde edebilirim, bu yüzden entegrasyon testleri bana daha sonra algoritmayı gerçekten kötüleştirdiğimi söylerken sadece birkaç görüntü üzerinde test yapmak bana yanlış bir başarı hissi verebilir ...

— rold2007