Bir ekip, spesifikasyonlarına tamamen uyan bir yazılım geliştirebilir ve yine de yanlış ürünü piyasaya sürebilir. Ayrıca, hatalarla dolu bir kod tabanı üzerinde tam olarak doğru ürünü de geliştirebilirler. Bu iki başarısızlığın isimleri vardır: birincisi bir doğrulama (verification) problemidir, ikincisi ise bir geçerleme (validation) problemidir. İkisini karıştırmak, kalite süreçlerinin meşgul ama etkisiz kalmasına neden olur.
Bu kılavuz, her iki terimi de tanımlar, farklılıklarını ortaya koyar ve her birinin Apidog ile bir API test iş akışında nerede yer aldığını gösterir.
Doğrulama (Verification) nedir?
Doğrulama şunu sorar: ürünü doğru mu geliştiriyoruz?
Bir yazılım parçasının kendi spesifikasyonuna, tasarımına ve standartlarına uygun olup olmadığını kontrol eder. Doğrulama, yapılan işi belgelenmiş amaçla karşılaştırır. Bu amacın doğru olup olmadığını sorgulamaz; yalnızca uygulamanın bu amaca uygun olup olmadığını sorar.
Doğrulama, geliştirme boyunca sürekli olarak gerçekleşir, sonunda değil. Tipik doğrulama faaliyetleri şunları içerir:
- Kod incelemeleri ve gözden geçirmeler (walkthroughs)
- Statik analiz ve linting
- Tasarım ve mimari incelemeler
- Şema ve sözleşme kontrolleri
- Bir fonksiyonun imzasının vaat ettiğini yapıp yapmadığını onaylayan birim testleri
Temel özellik, doğrulamanın çoğunlukla dahili olmasıdır. Bir artefaktı başka bir artefaktla karşılaştırır: kodu tasarımla, yanıtı şemayla, uygulamayı spesifikasyonla. Gerçek bir kullanıcıya ihtiyaç duyulmaz. Eğer spesifikasyon, uç noktanın bir Location başlığı ile 201 döndüreceğini söylüyorsa, doğrulama tam olarak bunu yaptığını onaylar.
Geçerleme (Validation) nedir?
Geçerleme şunu sorar: doğru ürünü mü geliştiriyoruz?
Yazılımın, spesifikasyonda ne söylendiğine bakılmaksızın, aslında kullanıcı ihtiyaçlarını karşılayıp karşılamadığını ve gerçek problemi çözüp çözmediğini kontrol eder. Geçerleme, yapılan işi bir belgeye karşı değil, gerçekliğe ve kullanım amacına karşı karşılaştırır.
Geçerleme, bir kullanıcı veya paydaşın kullanabileceği bir şey olduğunda daha sonra gerçekleşme eğilimindedir. Tipik geçerleme faaliyetleri şunları içerir:
- Kullanıcı kabul testleri
- Beta programları ve kullanılabilirlik testleri
- Tam iş akışlarının uçtan uca testleri
- Paydaş demoları ve onayları
Temel özellik, geçerlemenin dışa dönük olmasıdır. Bitmiş ürünün bağlamında faydalı ve doğru olup olmadığını sorar. Bir API, her doğrulama kontrolünden geçebilir, OpenAPI spesifikasyonuna mükemmel bir şekilde uyabilir ve yine de geçerleme testinde başarısız olabilir çünkü spesifikasyonun kendisi yanlış problemi çözmüştür; sayfalama modeli kullanılamazdır veya kimlik doğrulama akışı istemcilerin gerçekte nasıl entegre olduğuna uymaz.
Geçerleme ve doğrulama: Farklılıklar
| Boyut | Doğrulama (Verification) | Geçerleme (Validation) |
|---|---|---|
| Temel soru | Doğru mu inşa ediyoruz? | Doğru şeyi mi inşa ediyoruz? |
| Karşılaştırılan öğeler | Spesifikasyon, tasarım, standartlar | Kullanıcı ihtiyaçları, gerçek dünya kullanımı |
| Zamanlama | Sürekli, geliştirme boyunca | Daha sonra, bir şey kullanılabilir hale geldiğinde |
| Tipik yöntemler | İncelemeler, statik analiz, birim testleri, şema kontrolleri | Kabul testleri, beta, uçtan uca testler, demolar |
| Yön | İçe dönük: artefakt vs. artefakt | Dışa dönük: ürün vs. gerçeklik |
| Yakalananlar | Hatalar, spesifikasyon sapmaları, sözleşme kayması | Yanlış gereksinimler, kötü uyum, kullanılabilirlik boşlukları |
| Atlamanın maliyeti | İyi bir spesifikasyona uyan hatalı kod | Yanlış problemi çözen cilalı ürün |
İkisi birbirinin yerine kullanılamaz ve hiçbiri diğerinin yerini almaz. Zayıf geçerleme ile güçlü doğrulama, kimsenin istemediği hatasız bir ürün verir. Zayıf doğrulama ile güçlü geçerleme, kararsız kod üzerinde uygulanan doğru bir fikir verir. Her ikisine de doğru zamanda uygulanmış olarak ihtiyacınız var.
Basit bir anımsatıcı: doğrulama belgeye karşı test etmektir, geçerleme ise amaca karşı test etmektir.
Bunun API testlerinde nasıl işlediği
API'ler ayrımı somutlaştırır, çünkü bir API'nin açık, makine tarafından okunabilir bir spesifikasyonu vardır: OpenAPI veya şema tanımı. Bu spesifikasyon, doğrulama için temel çizgidir.
Bir API için doğrulama, uygulamanın bu sözleşmeye karşı kontrol edilmesi anlamına gelir:
- Her uç nokta belgelenmiş durum kodlarını döndürüyor mu? Bunları tutarlı hale getirmek başlı başına bir disiplindir; REST API'lerinin hangi HTTP durum kodlarını kullanması gerektiğini görün.
- Her yanıt, doğru alan adları ve türleriyle belgelenmiş şemaya uyuyor mu?
- Gerekli parametreler tam olarak belirtildiği gibi uygulanıyor mu?
- Hata formatı, belgelenmiş hata şekline uyuyor mu?
Burada ayrıca API sözleşme testi de yer alır. Bir sözleşme testi saf doğrulamadır: tüketicilerin güvendiği anlaşmaya üreticinin hala uyup uymadığını onaylar. Durum, şema ve başlıklardaki API iddiaları, doğrulama çalışmasının birimidir.
Bir API için geçerleme, API'nin tüketicilerine gerçekten hizmet edip etmediğini kontrol etmek anlamına gelir:
- Bir istemci, garip çözümler olmadan gerçek bir uçtan uca iş akışını (giriş yapma, oluşturma, güncelleme, silme) tamamlayabilir mi?
- API'nin döndürdüğü veriler, istemci geliştiricilerin sorduğu soruları gerçekten yanıtlıyor mu?
- Kimlik doğrulama modeli, mevcut entegrasyonlar için pratik mi?
- Belgelenmiş örnekler, API'nin gerçekte nasıl kullanıldığını yansıtıyor mu?
Birkaç isteği eksiksiz bir kullanıcı yolculuğuna bağlayan bir API test senaryosu geçerlemeye daha yakındır; tek uç noktalı bir şema kontrolü doğrulamadır. Her ikisi de pakette yer alır. Test senaryoları ve test durumları arasındaki farkı anlamak, hangi katmanda çalıştığınızı görmenize yardımcı olur.
Apidog nerede devreye girer?
Apidog, API tasarımı, testi ve dokümantasyonunu tek bir çalışma alanında tuttuğu için bu ayrımın her iki tarafını da destekler.
Doğrulama için, API tasarımı spesifikasyonun ta kendisidir. Bir test oluşturduğunuzda, API'yi tanımlayan aynı şemaya karşı yanıtları iddia edersiniz, böylece doğrulamanın sözleşmeden sapacak ikinci bir kopyası olmaz. Şema iddiaları, durum iddiaları ve sözleşme kontrolleri, doğruluk kaynağına karşı çalışır. Bunları CI aracılığıyla her committe çalıştırın; CI/CD'de API testlerini otomatikleştirmek, doğrulamanın sürekli olmasını sağlar ki tam olarak böyle olması gerekir.
Geçerleme için, Apidog test senaryoları, birden çok uç noktayı eksiksiz iş akışlarına bağlar. Bir kullanıcıyı kaydeden, giriş yapan, bir kaynak oluşturan ve sonucu onaylayan bir senaryo oluşturabilir, ardından bunu gerçek bir istemcinin yapacağı gibi çalıştırabilirsiniz. Bu uçtan uca uygulama, API'nin sadece her uç noktanın spesifikasyondaki satırına uymadığını değil, asıl problemi çözüp çözmediğini kontrol etmenizi sağlar.
Raporlama döngüyü tamamlar. Apidog, adım adım sonuçlar üretir, böylece başarısız bir doğrulama kontrolü (bir şema uyuşmazlığı) ve başarısız bir geçerleme kontrolü (bozuk bir çok adımlı iş akışı) hem görünür, hem ayrı hem de izlenebilirdir.
Kendi API'nizde hem sözleşme düzeyinde doğrulama hem de iş akışı düzeyinde geçerleme ayarlamak için Apidog'u indirin.
Gerçek dünya örneği
Bir ödeme API'si geliştiren bir ekip düşünün. Spesifikasyon, POST /payments adresinin bir miktar ve bir para birimi kabul ettiğini, payment_id ile 201 döndürdüğünü ve geçersiz para birimlerini 400 ile reddettiğini belirtir.
Bu API üzerindeki doğrulama sorunsuz ilerler. Kod incelemesi, işleyicinin tasarıma uygun olduğunu onaylar. Şema iddiaları, her yanıtın belgelenmiş alanlara ve türlere sahip olduğunu onaylar. Sözleşme testleri, 400 hata şeklinin tam olarak belirtildiği gibi olduğunu onaylar. Durum kodu kontrolleri genel olarak geçer. Her doğrulama ölçüsüne göre, API doğru bir şekilde inşa edilmiştir.
Ardından ilk gerçek istemci entegre olur. API'nin bir miktarı kayan noktalı bir sayı olarak kabul ettiğini keşfederler, bu nedenle 0.1 + 0.2, müşterinin faturasıyla eşleşmeyen bir değere yuvarlanır. Spesifikasyon "miktar: sayı" demişti. Uygulama buna mükemmel bir şekilde uymuştu. Spesifikasyon yanlıştı; para asla bir float olmamalıdır. Doğrulama bunu asla yakalayamazdı, çünkü doğrulama yalnızca uygulamayı spesifikasyona karşı kontrol eder ve her ikisi de aynı fikirdeydi.
Geçerleme bunu yakalar. Bir istemci gerçek bir uçtan uca ödeme yaptığında ve bunu bir faturayla karşılaştırdığında, yuvarlama hatası ortaya çıkar. Düzeltme bir kod hatası raporu değildir; bu bir spesifikasyon değişikliğidir, miktarlar tam sayı cinsinden daha küçük birimler haline gelir. Bu, bir geçerleme bulgusunun imzasıdır: yanıt "kodu spesifikasyona uyacak şekilde düzelt" değil, "spesifikasyonun kendisi yanlıştı"dır.
Bu yüzden her ikisi de önemlidir. Doğrulama, bozuk bir sözleşmenin kusursuz bir uygulamasını piyasaya sürmüş olurdu. API'yi gerçek bir tüketicinin yaptığı gibi kullanan geçerleme, sözleşmenin bir problem olduğunu ortaya çıkaran tek şeydir.
Pratik bir kontrol listesi
Her API sürümü için her iki sütunu da çalıştırın:
Doğrulama (spesifikasyona karşı):
- Her uç nokta belgelenmiş durum kodlarını döndürür
- Her yanıt kendi şemasına uyar
- Gerekli parametreler uygulanır
- Hata yanıtları belgelenmiş şekle uyar
- Tüm tüketiciye yönelik uç noktalar için sözleşme testleri geçer
Geçerleme (amaca karşı):
- Yeni bir istemci temel iş akışını uçtan uca tamamlayabilir
- Dönen veriler gerçek istemci sorularını yanıtlar
- Kimlik doğrulama akışı gerçek entegrasyon desenleri için çalışır
- Belgelenmiş örnekler gerçek kullanımla eşleşir
- Paydaşlar, API'nin amaçlanan problemi çözdüğünü onaylar
Yalnızca ilk sütun geçerse, muhtemelen yanlış bir tasarımın doğru bir uygulamasına sahipsiniz demektir. Yalnızca ikincisi geçerse, doğru fikri sallantılı kod üzerinde uygulamışsınız demektir. Güvenle göndermek her ikisini de gerektirir.
Sıkça sorulan sorular
Doğrulama mı yoksa geçerleme mi önce yapılır? Doğrulama önce başlar ve sürekli olarak çalışır, çünkü kod mevcut olduğu anda kod bir spesifikasyona karşı kontrol edilebilir. Geçerleme ise, gerçek ihtiyaçlara karşı kullanılabilecek bir ürün olduğunda gelir.
Test etmek, geçerleme ile aynı şey midir? Hayır. Test her ikisini de kapsar. Birim testleri ve şema kontrolleri doğrulamadır; kabul ve uçtan uca testler geçerlemedir. "Test etme" terimi tüm aralığı kapsar.
Yazılım doğrulamadan geçip geçerlemede başarısız olabilir mi? Evet ve bu yaygındır. Uygulama spesifikasyona mükemmel bir şekilde uyar, ancak spesifikasyon yanlış problemi çözmüştür. Bu ürün doğrulanmıştır ama geçerlenmemiştir.
Bu durum API sözleşme testlerine nasıl uygulanır? Sözleşme testi doğrulamadır. Bir API'nin tüketicilerle olan belgelenmiş anlaşmasına hala uyup uymadığını onaylar. Bu anlaşmanın doğru olup olmadığını onaylamaz; bu geçerlemenin işidir.
Hangisi daha fazla hata bulur? Doğrulama, sürekli çalıştığı ve küçük sapmaları erken yakaladığı için sayıca daha fazla hata bulur. Geçerleme daha az sorun bulur ama daha pahalı olanları bulur, çünkü bir geçerleme hatası genellikle bir gereksinimin veya tasarımın yanlış olduğu anlamına gelir, sadece kodun değil.
Otomasyon her ikisini de kapsayabilir mi? Otomasyon doğrulamayı iyi bir şekilde ele alır: şema kontrolleri, sözleşme testleri ve durum iddiaları her committe çalışır. Geçerlemeyi tamamen otomatikleştirmek daha zordur çünkü gerçek dünya uyumu hakkındaki yargıya bağlıdır, ancak uçtan uca iş akışı testleri bunun anlamlı bir bölümünü otomatikleştirir.