Manuel test, işe yaramayana kadar iyi çalışır. Bir geliştirici, sürümden önce birkaç uç noktayı tıklayabilir. Bir düzine ortamda elli hizmet çalıştıran bir ekip bunu yapamaz ve denedikleri gün, test edilmemiş bir şey yayınlanır. Otomatik test, bu ölçeklendirme sorununa cevaptır: makinelerin tekrarlayan kontrolleri her seferinde yapmasına izin verin, böylece insanlar dikkatlerini önemli yerlere harcasınlar.
Bu kılavuz, otomatik testin ne olduğunu, nerede yardımcı olup nerede olmadığını açıklamakta ve Apidog'da otomatik API testlerini adım adım kurmayı göstermektedir.
Otomatik test nedir
Otomatik test, her adımı bir kişinin elle gerçekleştirmesi yerine, testleri çalıştırmak ve sonuçları kontrol etmek için yazılım kullanmak anlamına gelir. Bir testi bir kez tanımlarsınız: girdi, eylem ve beklenen sonuç. Bundan sonra, bir araç bunu talep üzerine, belirli bir programda veya her kod değişikliğinde çalıştırır ve kimse izlemeden geçip geçmediğini rapor eder.
Değişim sadece hızla ilgili değil. Tutarlılıkla ilgili. Aynı kontrolü elli kez yapan bir insan test uzmanı, her seferinde biraz farklı yapacak ve kırkıncıda yorulacaktır. Otomatik bir test, ellinci geçişi tıpkı birincisi gibi yapar. Bu tekrarlanabilirlik, otomasyonun gerçek ürünüdür.
Otomatik test, tüm yığına uygulanır: fonksiyonlar için birim testleri, bileşenler için entegrasyon testleri, arayüzler için UI testleri ve uç noktalar için API testleri. API testi genellikle başlamak için en değerli yerdir, çünkü API'ler kararlıdır, çağrılması hızlıdır ve temel iş mantığını taşır. Bir API testi milisaniyeler içinde çalışır ve uğraşılması gereken değişken bir tarayıcı yoktur.
Ekipler neden testleri otomatikleştirir
Manuel test ölçeklenmez. Her yeni uç nokta kontrol ekler. Her ortam bunları çarpar. Belirli bir büyüklüğün ötesinde, her sürümden önce tam manuel kapsam fiziksel olarak imkansız hale gelir, bu nedenle sessizce köşe kesmeler yapılır.
O olmadan regresyonlar gözden kaçar. Bir hizmetteki bir değişiklik, üç hizmet ötedeki bir sözleşmeyi bozabilir. Bunu ancak her değişiklikte her şeyi yeniden çalıştıran bir test paketi yakalar ve yalnızca otomasyon, "her şeyi yeniden çalıştırmayı" sürekli yapabilecek kadar ucuz hale getirir.
Testler yeniden kullanılabilir varlıklara dönüşür. Manuel bir test, çalıştığı anda tükenir. Otomatik bir test bir kez yazılır ve binlerce kez çalıştırılır. Maliyet önden yüklenir; getirisi katlanarak artar.
Geri bildirim hızlı olur. Testler bir pipeline'da otomatik olarak çalıştığında, bir geliştirici bir değişikliğin bir şeyi bozduğunu dakikalar içinde öğrenir, bağlam hala taze iken. Üretimde bulunan bir hatayı düzeltmek, CI'da bulunan aynı hatadan çok daha pahalıya mal olur.
İnsanlar daha iyi iş yapar. Otomasyon, test uzmanlarının yerini almaz. Onları ezbere tıklamalardan kurtarır, böylece makinelerin kötü olduğu keşif testleri, uç durum avcılığı ve kullanılabilirlik çalışmaları yapabilirler.
Otomatik testin çözemediği şeyler
Otomasyon ücretsiz değildir ve aksini iddia etmek hayal kırıklığına yol açar.
Otomatik testler, yazmak ve sürdürmek için çaba gerektirir. API değiştiğinde, testler de değişir. Yanlış nedenlerle başarısız olan eski bir test paketi, hiç test paketi olmamasından daha kötüdür, çünkü ekip kırmızı derlemeleri görmezden gelmeyi öğrenir.
Otomasyon, yazılımın iyi olup olmadığını da yargılayamaz, sadece testin beklediğiyle eşleşip eşleşmediğini kontrol eder. Bir iş akışının kafa karıştırıcı olduğunu veya bir yanıtın teknik olarak doğru olsa da bir istemci için işe yaramaz olduğunu fark etmez. Bu yargı insanlara aittir.
Ve her şey otomatikleştirilmeye değmez. İki kez çalıştıracağınız bir kontrol değmez. İki yıl boyunca her taahhütte çalıştıracağınız bir kontrol kesinlikle değer. İlk olarak istikrarlı, tekrarlayan, yüksek değerli yolları otomatikleştirin; nadir ve keşif amaçlı çalışmaları manuel bırakın.
Apidog'da otomatik API testi nasıl kurulur
Apidog otomatik API testlerini görsel olarak oluşturur, bu sayede çalışan bir paket elde etmek için test betikleri yazmanıza veya sürdürmenize gerek kalmaz. İşte tam akış.
Adım 1: API'nizi tanımlayın veya içe aktarın. Uç noktalarınızı bir OpenAPI dosyasından, bir Postman koleksiyonundan getirin veya doğrudan Apidog'da tanımlayın. Her uç nokta, iddialar için temel oluşturan istek şemasını ve yanıt şemasını taşır. Bir spesifikasyondan başlarsanız, API sözleşmesi ve testler otomatik olarak senkronize kalır.
Adım 2: Her isteğe iddia ekleyin. Bir uç nokta için iddia panelini açın ve kodlama yapmadan kontroller ekleyin: durum 200'e eşit, bir gövde alanı var ve doğru türe sahip, yanıt şemayla eşleşiyor, yanıt süresi bütçenizin altında. Bu görsel API iddiaları testin özüdür; iddia içermeyen bir istek sadece sunucunun yanıt verdiğini kanıtlar.
Adım 3: Bir test senaryosu oluşturun. İlgili istekleri "kullanıcı yaşam döngüsü" gibi adlandırılmış bir senaryoda gruplandırın. Çıktının akış aşağı gitmesi için onları zincirleyin: bir oturum açma işlemi bir jeton döndürür, sonraki istek bunu tüketir. Her istek artı iddia bloğu bir test durumudur; API test durumları nasıl yazılır yapıyı kapsar.
Adım 4: Veriye dayalı kapsam ekleyin. Bir CSV veya JSON dosyası ekleyerek bir senaryonun birçok girdi satırına karşı çalışmasını sağlayın. Yirmi neredeyse aynı test durumu yazmak yerine, bir tane yazar ve ona yirmi veri kümesi beslersiniz. Veriye dayalı API testi, küçük bir paketin büyük bir girdi alanını nasıl kapsadığını gösterir.
Adım 5: Senaryoyu çalıştırın. Talep üzerine çalıştırın ve tekrar altında kararlılığı kontrol etmek için yineleme sayısını, örneğin elli çalıştırma olarak ayarlayın. Apidog her durumu çalıştırır, her iddiayı değerlendirir ve beklenen ve gerçek değerlerle birlikte başarısız olan iddiayı adlandıran bir rapor üretir.
Adım 6: Test paketleri halinde düzenleyin. Senaryoları test paketleri halinde toplayın, böylece tüm bir API tek tıklamayla çalışır. Paketler, kapsam genişledikçe büyüyen bir test tabanını yönetilebilir tutar.
Adım 7: CI/CD'ye entegre edin. Bu, bir test paketini otomatik test haline getiren adımdır. Her commit veya çekme isteğinde paketi çalıştırın, böylece birleşmeden önce regresyonlar ortaya çıksın. Apidog herhangi bir pipeline'da çalışır; CI/CD'de API testlerini otomatikleştirme bunu ayrıntılı olarak anlatır ve GitHub Actions'da API testlerini çalıştırma bu platformu özel olarak kapsar.
İlk otomatik senaryonuzu oluşturmak ve çalıştığını görmek için Apidog'u indirin.
Otomatik testlerin ana türleri
Otomatik test tek bir şey değildir. Her biri farklı bir hata sınıfını farklı bir maliyetle yakalayan katmanlı bir test türleri kümesidir.
Birim testleri, izole edilmiş tek bir fonksiyonu veya sınıfı kontrol eder. Hızlı, ucuzdur ve binlerce kez çalışır, ancak bileşenler birbiriyle konuştuğunda ortaya çıkan sorunları yakalayamazlar.
Entegrasyon testleri, bileşenlerin birlikte çalıştığını kontrol eder: bir hizmet ve veritabanı veya bir ağ sınırı boyunca iki hizmet. Birim testlerinin gözden kaçırdığı bağlantı hatalarını yakalarlar, ancak daha yavaş olmaları ve daha fazla kurulum gerektirmeleri pahasına.
API testleri ideal bir noktada bulunur. Bir uç noktayı HTTP üzerinden, gerçek bir istemcinin yaptığı gibi çalıştırırlar, böylece gerçek sözleşmeyi doğrularlar. Hızlı çalışır, tarayıcıya ihtiyaç duymazlar ve en önemli iş mantığını kapsarlar. Çoğu ekip için bu, çabaya karşı en iyi getiriyi sağlayan katmandır.
Uçtan uca testler, gerçek sistem üzerinden, genellikle UI da dahil olmak üzere eksiksiz bir iş akışını yürütür. En gerçekçi ve en yavaş olanlardır ve en kararsız olma eğilimindedirler, bu nedenle ekipler bunları az sayıda tutar ve kritik yolculuklara odaklanır.
Yaygın olarak atıfta bulunulan test piramidi dengeyi yakalar: tabanda çok sayıda hızlı birim testi, ortada daha az entegrasyon ve API testi ve üstte ince bir uçtan uca test katmanı. Tersine şekilli, çoğunlukla yavaş uçtan uca testlerden oluşan bir paket yavaş çalışır ve öngörülemeyen bir şekilde başarısız olur. API testleri, bir ekibin uçtan uca maliyeti ödemeden geniş, güvenilir kapsam elde ettiği yerdir ve bu yüzden önerilen başlangıç noktasıdır.
Otomasyonun karşılığını almak
Birkaç alışkanlık, kendini amorti eden test paketlerini çürüyen test paketlerinden ayırır.
Testleri API tasarımına yakın tutun. Sözleşme ve testler tek bir yerde yaşadığında, sözleşme değişikliğini testlerde unutmak zordur. Sapma, test paketlerinin bozulmasının ana nedenidir.
Sadece durum kodlarını değil, gerçek sonuçları iddia edin. Yalnızca 200 durum kodunu kontrol eden otomatik bir test, önemsiz veriler döndürürken geçecektir. Güçlü iddiaları otomatikleştirin, aksi takdirde yanlış bir güvenlik hissini otomatikleştirmiş olursunuz.
Başarısızlıkları anlaşılır hale getirin. İyi bir rapor, yalnızca başarısız olan testi değil, başarısız olan iddiayı adlandırır. Bir geliştirici başarısızlığı ne kadar hızlı okuyabilirse, ekip o test paketine o kadar güvenir.
Kararların alındığı yerde çalıştırın. Sadece birisi hatırladığında çalışan bir test paketi otomatik değildir. İstemeden çalışması için pipeline'a koyun.
Sıkıcı kısımlar için yapay zekaya yaslanın. Bir spesifikasyondan ilk taslak test durumlarını oluşturmak veya uç durumları genişletmek yardıma oldukça uygundur; yapay zeka destekli API otomasyon testi bunun nerede yardımcı olduğunu ve insan incelemesinin hala nerede gerektiğini gösterir.
Sıkça sorulan sorular
Otomatik test manuel testten daha mı iyi? Biri diğerinin yerini almaz. Stabil, tekrarlayan, yüksek değerli kontrolleri otomatikleştirin. Keşif testlerini, kullanılabilirlik incelemesini ve yargı gerektiren işleri manuel bırakın. En iyi ekipler her ikisini de yapar.
API testlerini otomatikleştirmek için kod yazmayı bilmem gerekiyor mu? Görsel bir araçla değil. Apidog'da istekleri, iddiaları ve senaryoları tıklayarak oluşturursunuz ve yalnızca görsel oluşturucunun ifade edemediği mantık için betiklere girersiniz.
Bir ekip otomasyona nereden başlamalı? API testlerinden. Hızlı, kararlıdırlar ve UI otomasyonunun değişkenliği olmadan temel mantığı kapsarlar. Kritik uç noktalarla başlayın ve genişletin.
Otomatik testler ne kadar bakım gerektirir? API her değiştiğinde onlar da değişir. Testleri API tasarımına yakın tutmak sürprizleri en aza indirir, ancak devam eden zamanı bütçelendirin; bakımı yapılmayan bir test paketi güvenilir olmaktan çıkar.
Otomatik bir testi ne kararsız yapar ve nasıl düzeltirim? Kararsızlık genellikle zamanlama varsayımlarından, testler arasındaki paylaşılan durumdan veya zaman damgaları gibi değişken veriler üzerindeki iddialardan kaynaklanır. Test verilerini izole ederek, tam değişken değerler yerine yapıya iddia ederek ve testler arasındaki örtük sıralamayı kaldırarak düzeltin. Kararsız bir test paketi, ekibi başarısızlıkları görmezden gelmeye alıştırır, bu nedenle kararsızlığı gerçek bir hata olarak ele alın.
Otomatik testimin çalışıp çalışmadığını nasıl ölçerim? Test paketinin sürümden önce kaç gerçek hata yakaladığını, üretime kaç hatanın sızdığını ve test paketinin ne kadar hızlı çalıştığını takip edin. Üretim hataları sızarken aylarca yeşil kalan bir test paketi sizi korumuyordur; anlamlı iddiaların kapsamı, ham test sayısından daha önemlidir.