Görsel iş mantığı testini öğrenin: otomasyona pratik sıra—önce iş akışları, sonra API sözleşmeleri ve model değişikliklerinden sonra bile çalışan stabil test verileri.
Görsel iş akışları mantıklı hissettirir çünkü mantığı görebilirsiniz. Yine de sık değişirler ve küçük düzenlemeler gerçek kullanıcı yollarını bozabilir. Bu yüzden görsel iş mantığı testi, kodsuz araçlarda bile önemlidir.
En sık kırılan şey iş akışının “büyük fikri” değil, küçük bağlantılardır: bir koşul ters döner ("VE" yerine "VEYA"), varsayılan değer değişir, bir adım yanlış sırada çalışır veya hata kolu atlanır. AppMaster içinde bu, bir Business Process düzenlendiğinde, Data Designer alanı yeniden adlandırıldığında veya bir API yanıtı şekli evrildiğinde görebileceğiniz bir durumdur.
Birçok hata sessizdir. Her şey dağıtılır, UI hâlâ yüklenir ama iş akışı yanlış mesajı gönderir, çoğaltmalar oluşturur veya engellenmesi gereken bir şeyi onaylar. Manuel rastgele kontroller bu problemleri kaçırır çünkü ekranlar hâlâ düzgün görünür.
Amaç her şeyi test etmeden hızlı geri bildirim almaktır. Çekirdek mantık değiştiğinde bağıran küçük bir otomatik kontrol seti istersiniz; kenar durumlar ve görsel incelikleri manuel incelemeye bırakın.
Kapsamı düşünmenin pratik yolu birbirini destekleyen üç katmandır:
Örnek: bir destek uygulamasında “iade onayı” iş akışı varsa, her ekranı test etmeniz gerekmez. İhtiyacınız olan; limitin üzerindeki isteklerin her zaman bir yöneticinin onayına gitmesi, durumun doğru güncellenmesi ve e-posta veya Telegram ile gönderilen mesajın doğru alanları içermesinden emin olmaktır.
Ne test ettiğinizi (mantık) çalıştığı yerden (iş akışı, API veya UI) ayırdığınızda test etmek daha kolaylaşır. Amaç her şeyi her yerde test etmek değil. Özelliğin hâlâ çalıştığını kanıtlayan en küçük dilimi seçmektir.
"Birim tarzı" mantık kontrolleri tek bir kurala odaklanır: bir hesaplama, bir koşul, bir durum değişikliği. Hızlıdırlar ve hatanın yerini tam olarak gösterirler, ama yalnızca birden fazla adım zincirlendiğinde ortaya çıkan sorunları kaçırırlar.
İş akışı düzeyi testleri orta katmandır. Açık bir durumdan başlarsınız, gerçekçi girdiyi iş akışına gönderirsiniz ve önemli sonuçları doğrularsınız (oluşturulan kayıtlar, değişen statüler, gönderilen bildirimler, reddedilen eylemler). AppMaster'da bu genellikle Business Process'i tüm UI'yi tıklamadan uçtan uca çalıştırmak anlamına gelir.
Uçtan uca UI testleri en üsttedir. Bağlantı sorunlarını yakalayabilirler ama yavaş ve kırılgandırlar çünkü küçük UI değişiklikleri bile bunları bozar; mantık doğru olsa bile testler kırılır. Sadece UI testlerine güvenirseniz, hataları bulmaktan çok testleri düzeltmekle uğraşırsınız.
En küçük güvenilir test dilimini seçerken şu sıra iyi işler:
Bir onay süreci için bu, Draft'tan Approved'e taşıyan bir iş akışı testi, status alanını tutarlı tutmak için bir sözleşme kontrolü ve kullanıcıların istek gönderebildiğini kanıtlayan bir UI testi olabilir.
Küçük bir mantık hatasının en çok zarar verdiği yerden otomasyona başlayın. Bu genellikle para, izinler veya müşteri verisiyle bağlı iş akışlarıdır. Yanlış bir işlem yanlış tutarı tahsil edebiliyorsa, bir kaydı açığa çıkarabiliyorsa veya bir kullanıcıyı kilitleyebiliyorsa, önceliklidir.
Sonra kasıtlı olarak karmaşık iş akışlarını hedefleyin: çok sayıda adım, dallanma, yeniden deneme ve entegrasyon içerenler. Demo “mutlu yol”unda kaçan bir koşul, bir API yavaşladığında, bir ödeme reddedildiğinde veya kullanıcı alışılmadık bir role sahip olduğunda gerçek bir olaya dönüşür.
Frekans da önemlidir. Günde binlerce kez çalışan bir iş akışı (sipariş oluşturma, bilet yönlendirme, şifre sıfırlama) ayda bir çalışan bir yönetici sürecinden önce otomasyon gerektirir.
Bir test yazmadan önce sonucu ölçülebilir hâle getirin. İyi bir otomatik test “görünüyor gibi” değil; "kayıt X durum Y ile sonuçlanır ve bu yan etkiler tam olarak bir kez oluşur" demelidir. AppMaster Business Process'leri için bu, girdiler, beklenen durum değişiklikleri ve beklenen çağrılar veya mesajlar olarak temizce tercüme edilir.
Önceliklendirme filtresi:
Keşifsel kontroller, görsel düzen ve hâlâ keşfedilen kenar durumlar için manuel testleri bırakın. Davranış stabil olduğunda ve herkes “başarı” anlamında anlaştığında otomatikleştirin.
İş akışı düzeyi testleri birim tarzı kontrollerin bir üstünde durur. Bir iş akışını kara kutu gibi ele alırlar: tetikleyin, sonra son durumu ve yan etkileri doğrulayın. Kullanıcıların gerçekten hissettiği kırılmaları burada yakalarsınız.
Bir tetik ve önemli bir çıktı adı vererek başlayın. Örneğin: “Bir istek gönderildiğinde, durum Pending olur ve bir onaycı bilgilendirilir.” Bu doğru kaldığı sürece küçük iç refaktörler genellikle önemli değildir.
Çıktıları değiştiren dalları kaplayın, her düğümü değil. Kısa bir set:
Son olarak iş akışının gerçekten çalıştığını kanıtlayan yan etkileri kontrol edin: PostgreSQL'de oluşturulan veya güncellenen kayıtlar, değişen durum alanları ve kullandıysanız gönderilen mesajlar (e-posta/SMS veya Telegram).
Testleri kısa tutmanın bir deseni “tetikle, sonra çıktıları doğrula”dır:
Burada piksel mükemmelliğinde UI kontrollerinden kaçının. Bir buton yer değiştirdiyse, iş kurallarınız değişmedi. UI nasıl görünürse görünsün, iş akışının garanti etmesi gerekenleri doğrulayın.
Her iş akışı testini bir sonuca odaklı tutun. Bir test beş kuralı ve üç yan etkiyi doğrulamaya çalışırsa okunması zor ve düzeltmesi acı verir.
Bir API sözleşmesi API'nizin verdiği vaattir: neyi kabul eder, ne döndürür ve nasıl hata verir. Bu vaat habersiz değiştiğinde en kötü türde hatayı alırsınız: her şey normal göründüğü sürece gerçek kullanıcı belirli bir yola geldiğinde hata oluşur.
Sözleşme kontrolleri, iş akışlarına bağlı endpointleri korumanın hızlı yoludur. İş mantığının doğru olduğunu kanıtlamazlar ama kıran değişiklikleri erken yakalarlar, UI hataları olarak görünmeden önce.
İstemcileri sessizce bozan şeylerden başlayın:
Amaçlı negatif vakaları ekleyin: gerekli alan eksik, yanlış tip gönderme ya da izin olmadan bir eylem deneme. Bu testler ucuzdur ve iş akışıyla API arasındaki uyumsuz varsayımları ortaya çıkarır.
AppMaster'da geliştiriyorsanız, model veya mantık değiştirip uygulamayı yeniden oluşturduğunuzda sözleşmeler daha da önem kazanır. Yeniden adlandırılan bir alan, sıkılaşan bir doğrulama kuralı veya yeni zorunlu bir özellik eski istemcileri kırabilir, backend sorunsuz derlense bile.
En az bir güvenilir yer seçin, sonra daha hızlı geri bildirim gerekiyorsa ekleyin:
Uyumluluk beklentilerinde anlaşın. Eski istemcilerin çalışmaya devam etmesi gerekiyorsa, alan kaldırmayı veya anlam değiştirmeyi sürümlü bir değişiklik olarak ele alın, küçük bir refaktör olarak değil.
İş akışı testleri yalnızca her seferinde aynı yerden başlarsa yardımcı olur. Tekrarlanabilir test verisi tahmin edilebilir, diğer testlerden izole ve önceki çalıştırmanın bugünkü sonucu etkilememesi için kolayca sıfırlanabilir olmalıdır. Birçok test çabası burada sessizce başarısız olur.
Roller ve iş akışlarınızın ihtiyaç duyduğu temel kayıtları kapsayan küçük bir seed veri seti tutun: bir Admin kullanıcı, bir Manager, standart bir Çalışan, bir Müşteri, bir aktif Abonelik ve bir “problem vakası” kaydı (ör. gecikmiş fatura). Bu seedleri testler arasında yeniden kullanın; böylece mantığı doğrulamaya zaman harcarsınız, veri yeniden icat etmeye değil.
Daha fazla test eklemeden önce ortamın nasıl temiz bir duruma döneceğine karar verin:
Temel kontroller için rastgelelikten kaçının. Rastgele isimler, zaman damgaları ve tutarlar keşif için iyidir ama geçme/kalma karşılaştırmalarını zorlaştırır. Çeşitliliğe ihtiyaç varsa, sabit değerler kullanın (örneğin InvoiceTotal = 100.00) ve test bir kuralı kanıtlamalıysa sadece bir değişkeni değiştirin.
Ayrıca her workflow testi için minimum gerekli veriyi yazın: hangi kullanıcı rolü, hangi durum alanları ve hangi ilişkili varlıkların Business Process başlamadan önce var olması gerektiği. Bir test başarısız olduğunda, mantığın mı yoksa kurulumun mu bozulduğunu hızla anlayabilirsiniz.
Model değişiklikleri, “iyi” testlerin ansızın başarısız olmasının bir numaralı nedenidir. Bir alanı yeniden adlandırırsınız, bir tabloyu ikiye bölersiniz, bir ilişkiyi değiştirirsiniz veya Data Designer'ı güncelledikten sonra AppMaster uygulamayı yeniden oluşturursunuz ve test kurulumları eski şekle yazmaya devam eder. Daha kötüsü, testler kırılganken yanlış şeyi kontrol ediyor gibi geçebilir çünkü kırılgan iç ID'lere dayanırlar.
Veritabanı ID'lerini veya otomatik UUID'leri hardcodlamak yaygın bir tuzaktır. Bu değerlerin iş anlamı yoktur ve veri yeniden seed edildiğinde, ortamlar yeniden inşa edildiğinde veya yeni varlıklar eklendiğinde değişebilir. Testleri e-posta, sipariş numarası veya insan tarafından okunabilir bir kod gibi stabil iş tanımlayıcılarına bağlayın.
Test verisini küçük bir ürün özelliği gibi ele alın. Varlıkları bugünün modeline göre oluşturan data builder'lar kullanın, geçen ayın modeline göre değil. Zorunlu bir alan eklediğinizde builder'ı bir kere güncellersiniz ve her test bundan fayda sağlar.
Küçük bir kanonik varlık seti tutun ve uygulamayla birlikte evrilmesine izin verin. Örneğin her zaman aynı rolleri oluşturun (Requester, Approver), bir departman ve bir örnek müşteri. Bu, workflow testlerini okunur tutar ve tek kullanımlık fixture yığını oluşturmayı önler.
Suitleri stabil tutacak kurallar:
employee_email).Bu migration-check testi basit ama güçlüdür: seed verisi modelle uyumlu değilse hemen öğrenirsiniz, onlarca workflow testinin kafa karıştırıcı şekilde kırılmasından önce.
AppMaster hızlı ilerlemeyi kolaylaştırır ve bu uygulamanızın hızla şekil değiştirebileceği anlamına gelir. Görsel ve model değişikliklerini "daha sonra kontrol ederiz" gibi değil, test tetikleyicisi olarak ele alın. Görsel iş mantığı testi, model değişiklikleri sırasında hataları yakalamaya yarar; kullanıcılar yakaladıktan sonra değil.
Data Designer (PostgreSQL modeli) düzenlediğinizde eski seed verisinin artık uymayabileceğini varsayın. Yeniden adlandırılan bir alan, yeni zorunlu bir kolon veya değişen bir ilişki kurulum scriptlerini kırabilir ve testlerin yanlış nedenle fail olmasına yol açar. Her veri modeli güncellemesini seed verilerini yenilemek için bir uyarı olarak kullanın ki testler temiz, gerçekçi bir başlangıç noktasından başlasın.
Business Process Editor güncellemeleri aynı disiplini hak eder. Eğer bir iş akışı değiştiyse (yeni dal, yeni statü, yeni rol kontrolü), iş akışı düzeyi testlerini hemen güncelleyin. Aksi halde yanlış bir güven hissi oluşur: testler geçiyor ama artık gerçek süreçle eşleşmiyorlar.
API'ler için endpoint değişikliklerini sözleşme snapshot'larına bağlayın. Girdiler veya çıktılar değişirse, aynı çalışma oturumunda sözleşme kontrollerini güncelleyin ki web veya mobil uygulamaya sessiz bir kırılma göndermeyin.
Her test ortamında şunları iki kere kontrol edin:
Örnek: zorunlu bir Department alanı ekleyip bir BP adımını otomatik yönlendirecek şekilde ayarladınız. Seed kullanıcıları departmanla güncelleyin, sonra onay iş akışı testini yeni yönlendirmeyi doğrulayacak şekilde güncelleyin. AppMaster temiz kaynak kodu yeniden ürettiği için sürüklenmeyi azaltır, ama yalnızca testler davranışa (çıktılar, statüler, izinler) dayanıyorsa işe yarar.
Model veya ekranlar değiştiğinde bile çalışması gerekenleri seçin. Bu genellikle para, onaylar, erişim veya müşteri vaatlerini taşıyan iş akışlarıdır.
Kritik iş akışlarının kısa bir listesini yazın ve sonucu sade bir cümleyle tanımlayın. "Fatura yöneticinin onayıyla bir ödeme talebi oluşturur" testlenebilir. "Onay çalışıyor" değil.
Her iş akışı için minimal bir seed veri seti oluşturun. Küçük ve isimlendirilmiş tutun ki loglarda kolayca görülsün: her rol için bir kullanıcı, bir hesap, her statü için bir doküman. AppMaster'da bunu Data Designer modelinizle hizalayın ki alanlar evrildikçe veriler tutarlı kalsın.
Sadece en üstteki birkaç akışı uçtan uca iş akışı düzeyinde otomatikleştirin. Örneğin onay iş akışını başlatın, yönetici kararını simüle edin ve nihai durumu kontrol edin (onaylandı, denetim kaydı oluşturuldu, bildirim gönderildi).
Bu akışların bağımlı olduğu endpointler için yalnızca API sözleşme kontrolleri ekleyin. Amacınız her şeyi test etmek değil; iş akışını sessizce kıracak şekil değişikliklerini yakalamaktır.
Çalıştırmaları tekrar edilebilir kılın:
Bu, paketi küçük, hızlı ve görsel mantık büyüdükçe faydalı kılar.
Kırılgan testler hiç test olmamasından daha kötüdür. İnsanları hataları görmezden gelmeye alıştırır ve gerçek mantık hataları gözden kaçar. En büyük neden, iş akışlarını bir UI scripti gibi ele almaktır, bir iş sistemi gibi değil.
Fazla tıklama otomasyonu klasik bir tuzaktır. Testiniz bir butona basılabildiğini kanıtlıyorsa, doğru sonucun oluştuğunu kanıtlamaz. Daha iyi bir kontrol: iş akışı doğru kayıtları oluşturdu mu, doğru durumu ayarladı mı ve doğru mesajı gönderdi mi? AppMaster ile bu genellikle Business Process'in ürettiği şeyleri (alanlar, geçişler, yan etkiler) doğrulamaktır, nasıl gezindiğiniz değil.
Bir diğer kırılganlık kaynağı düzensiz, paylaşılan test hesaplarıdır. Takımlar tek bir "test kullanıcı"yu uzun süre kullanır; yüzlerce eski istek, garip izinler ve kalan taslakla hesaba dönüşür. Yeni bir çalışma bazen başarısız olur. Her çalıştırma için taze kullanıcılar tercih edin veya küçük veri setini bilinen bir duruma sıfırlayın.
Model değiştiğinde bozulacak varsayımlardan kaçının. ID'leri sabitlemek, kayıt sırasına güvenmek veya "listedeki ilk öğeyi seçmek" testleri kırılgan yapar. Kontrolleri sizin kontrol edebileceğiniz stabil anahtarlara dayandırın (dış referans, e-posta, test sırasında oluşturduğunuz kod).
Erken düzeltmeye değer desenler:
Eğer bir onay iş akışı Submit butonunu bir bütçe eksikse engellemeliyse, eksik bir bütçe durumunu bekleyen negatif bir test yazın ve açık bir hata durumu bekleyin. Bu tek test, bir sürü tıklama scriptinden daha fazla regresyonu yakalar.
Her yeni test eklemeden önce onun kendine fayda sağlayacağını doğrulayın. En hızlı büyüme yolu, okunması zor, yeniden çalıştırması zor ve kolay kırılan testler eklemektir; bu da takımın testleri görmezden gelmesine yol açar.
Her yeni testi küçük bir ürün özelliği gibi ele almak iyi bir alışkanlıktır: net hedef, stabil girdiler, bariz geçme/kalma koşulu.
Kısa bir ön uç kontrol listesi:
AppMaster'da inşa ediyorsanız, test kayıtlarını uygulamanın kullandığı aynı API veya Business Process ile oluşturmayı tercih edin. Bu, testleri gerçek davranışa yakın tutar ve model evrildikçe kırılmayı azaltır.
Bir iç onay uygulaması hayal edin: bir isteği talep eden gönderir, bir onaycı inceler ve istek net statüler arasında dolaşır. Değer basittir: doğru kişi isteği bir sonraki doğru duruma geçirebilir. Bu, başlamak için güçlü bir nokta.
Önce yalnızca en önemli eylemleri test edin:
Pending durumundan Approved'a taşıyabilir ve audit alanları (kim, ne zaman) doğru şekilde ayarlanır.Rejected durumuna taşıyabilir ve bir sebep gereklidir.Needs changes durumuna taşıyabilir ve talep eden yeniden gönderebilir.Onay endpoint'i etrafında bir API sözleşme kontrolü ekleyin çünkü sessiz kırılmalar burada daha çok zarar verir. Örneğin workflow'ınız POST /requests/{id}/approve çağrısı yapıyorsa doğrulayın:
status bilinen bir değer, updated_at var)Draft'tan doğrudan Approved'a atlayamaması)Test verisini küçük ve tekrar edilebilir tutun. Mantığın ihtiyaç duyduğu kadar seedleyin: bir requester, bir approver ve Pending durumda bir istek. Sabit tanımlayıcılar (ör. sabit e-postalar) yeniden üretim sonrası aynı kayıtları bulmayı kolaylaştırır.
Şimdi model değişikliğini hayal edin: yeni zorunlu bir alan cost_center eklediniz. Birçok suite, istekleri eski şekle göre oluşturduğu için kırılır.
Her testi yeniden yazmak yerine, ortak "istek oluştur" helper'ınızı (veya seed adımını) cost_center ekleyecek şekilde güncelleyin. Workflow testleriniz statü geçişlerine odaklı kalsın; sözleşme kontrolünüz de yeni zorunlu alanın istek veya yanıt şemasını nasıl etkilediğini yakalasın.
Bir test paketi yalnızca insanlar ona güvendiği sürece yardımcı olur. Güven, paket çok hızlı büyüdüğünde ve sonra çürüdüğünde kaybolur. Gerçek işletme değeri olan küçük bir iş akışı setine odaklanın.
Önceliklendirdiğiniz iş akışı listesini küçük, tekrar edilebilir bir test backlog'una dönüştürün. Her iş akışına bir cümlelik geçme koşulu verin. "Bitti"nin ne demek olduğunu söyleyemiyorsanız, test de muğlak olur.
Çoğu takım için işe yarayan basit bir ritim:
Temizlemek gerçek iştir. Bir iş akışı değiştiyse ve eski test artık gerçeği temsil etmiyorsa, testi hemen kaldırın veya yeniden yazın.
AppMaster (appmaster.io) üzerinde workflow'lar ve API'ler inşa ediyorsanız, aynı görünürlüğü somut çıktılar tanımlamak ve küçük bir dizi workflow düzeyi kontrolü erken sabitlemek için kullanabilirsiniz. Bu, veri modeli evrildikçe testlerin hizalı kalmasını sağlamanın en basit yolu olacaktır.
Görsel iş akışlarını test ederken önce neyi otomatikleştirmeliyim?Otomasyona ilk olarak küçük bir mantık hatası gerçek zarar veriyorsa başlayın: para akışları, izinler, onaylar ve müşteri verisi değişiklikleri. Bir veya iki temel iş akışını seçin ve son durumları ile yan etkileri kontrol eden doğrulamalar yazın; tüm ekranları test etmek yerine davranışa odaklanın.
Görsel iş mantığı hataları neden manuel testleri atlıyor?Çünkü birçok iş akışı hatası sessizdir: UI yüklenir, deploy başarılıdır ama akış yanlış kişiye gider, bir hata dalı atlanır veya kopyalar oluşur. Otomatik kontroller, durum değişiklikleri, oluşturulan kayıtlar ve gönderilen bildirimler gibi sonuçları doğrulayarak bu regresyonları yakalar.
Pratikte workflow düzeyi testi nedir?Bir workflow düzeyi testi, Business Process'i gerçekçi girdiyle tetikler ve sonunda doğru olması gerekenleri ile önemli yan etkileri doğrular. Akışı kara kutu gibi ele alır; bu da iç refaktörlere ve küçük UI değişikliklerine karşı dayanıklı olmasını sağlar.
Uçtan uca UI testlerini ne zaman kullanmaya değer?Yalnızca bir veya iki kritik kullanıcı yolu için UI testleri kullanın; örneğin giriş veya bir isteğin gönderilmesi gibi. Bu testleri küçük tutun, çünkü layout veya selector değiştikçe bozulma eğilimindedirler, oysa alttaki mantık doğru olabilir.
API sözleşme kontrolleri aslında beni neyin önünden korur?Sözleşme testleri API'nin verdiği sözü doğrular: gerekli alanlar, tipler, durum kodları ve hata şekli. İş kurallarının doğru olduğunu kanıtlamazlar ama web veya mobil uygulamanızın veya entegrasyonların sessizce kırılmasını önlerler.
Bir API sözleşme kontrolünde neleri dahil etmeliyim?Başarı ve yaygın hata durumları için durum kodlarını, istek ve yanıtlarda gerekli alanları ve null olabilme durumunu, alan formatlarını ve enum değerlerini, tutarlı bir hata yanıt yapısını kilitleyin. Doğrudan uyumluluğa odaklanın; zararsız bir backend refaktörü gürültü yaratmamalı.
Test verilerini nasıl tekrar edilebilir ve güvenilir yaparım?Roller ve iş akışlarınızın dayandığı birkaç kaydı kapsayan küçük, isimlendirilmiş bir seed veri seti hazırlayın ve her çalıştırmada aynı biçimde sıfırlayın. Miktardan ziyade öngörülebilirlik önemlidir; sabit girdiler hataları görmek ve yeniden üretmek için daha iyidir.
Testlerim veri model değişikliklerinden nasıl kurtulur?İç ID'leri sabitlemekten kaçının ve bunun yerine e-posta, dış referans veya insan tarafından okunabilir kodlar gibi stabil iş anahtarlarına dayanın. Varlık yaratmayı bir builder veya yardımcıda merkezileştirerek Data Designer değiştiğinde tek yerden güncelleyin.
AppMaster projelerinde hangi konular ekstra dikkat gerektirir?Data Designer veya Business Process Editor'da yapılan her değişikliği seed verileri, workflow testleri ve ilgili API sözleşmeleriyle aynı çalışma oturumunda güncelleyin. AppMaster kaynak kodu yeniden üretiyor olsa da, testlerin davranışa dayalı kalması gerekir.
Aşırıya kaçmadan güvenilir bir test paketi oluşturmak için basit bir plan nedir?Küçük başlayın: 5–10 vazgeçilmez iş akışını tanımlayın, her sonuç için bir workflow düzeyi testi yazın, bu akışların ihtiyaç duyduğu endpointler için birkaç sözleşme kontrolü ekleyin ve UI testlerini minimumda tutun. AppMaster ile Business Process ve API etrafında otomasyona odaklanın; kapsamı yalnızca gerçek bir hata kaçtığında veya özellik kararlı olduğunda genişletin.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
