Tam olarak bir entegrasyon testi nedir?

Arkadaşlarım ve ben bir entegrasyon testinin tam olarak ne olduğunu sınıflandırmak için uğraşıyoruz.

Şimdi, eve döndüğümde, farkına vardım ki, gerçek bir dünyaya bir entegrasyon testi örneği vermeye her çalıştığımda, bunun bir kabul testi olduğu ortaya çıktı. Bir işadamının yüksek sesle söyleyeceği, sistemin neyi sağlaması gerektiğini belirten bir şey.

Ruby on Rails belgelerini bu test türlerinin sınıflandırılması için kontrol ettim ve şimdi tamamen atıldı.

Bana gerçek dünyadan bir örnekle bir entegrasyon testinin kısa bir akademik tanımını verebilir misiniz?

Şu anda bu ifadeyi beğendim: Bu makalede Gojko Adziç tarafından yapılan "Bu ne dediğiniz önemli değil, ne yaptığı önemli" .

Gerçekten test etmeyi düşündüğünüz testlerden bahseden kişilerle belirtmeniz gerekir.

Rollerinin ne olduğuna bağlı olarak farklı görüşlere sahip birçok insan var.

Test edenler için Hollanda'da kabul görmüş genel bir test metodolojisi TMap'tır . TMap aşağıdaki ayrımı yapar.

• ünite testi
• birim entegrasyon testi
• sistem testi
• sistem entegrasyon testi
• Kabul testi (her çeşit / seviye)
• fonksiyonel kabul testi
• Kullanıcı kabul testi
• üretim kabul testi

Yukarıda belirtilen testlerde yapılabilecek daha spesifik testlere sahiptirler. Genel bakış için bu kelimeye bakınız .

Wikipedia'da ayrıca güzel bir genel bakış var .

Kitap pragmatik programcı diyor ki:

• Birim testi, bir modülü çalıştıran bir testtir
• entegrasyon testleri, sistemin ana bölümlerinin birlikte iyi çalıştığını göstermektedir

Bu farklı kaynaklara bakmak ve kendi deneyimlerimi ve görüşlerimin bir kısmını koymak, üç kategoriye göre ayrım yaparak başlayacağım

• genel olarak testi kim yapar
• ne test edildi

• testin amacı nedir

  • Birim testi : sınıflarda kod seviye doğruluğunu göstermek için programcılar tarafından test mantığı. Hızlı olmalılar ve test etmek istemediğiniz sistemin diğer bölümlerine bağlı olmamalıdırlar.
  • İşlevsel kabul testi : Test kullanım senaryosu, belirtilen her senaryonun belirtilen şekilde çalıştığını göstermek için test departmanı tarafından yapılan sınırlı (özel olarak oluşturulmuş) bir veri üzerindedir.
  • Kullanıcı kabul testi : Kullanıcıların resmi olarak kabul etmelerini sağlamak için kullanıcıların temsilcileri tarafından yapılan veriler gibi üretimde kullanım senaryosunu test etme
  • Entegrasyon testi : Tüm modüllerin birlikte doğru çalıştığını göstermek için, test departmanı tarafından veya modül tarafından yapılan modülün farklı parçaları arasındaki iletişim yollarını test edin.

Yukarıdaki listem sadece bir başlangıç ​​ve öneri ama gerçekten düşünüyorum: "Ne dediğiniz değil, ne dediği önemli değil"

Bu yardımcı olur umarım.

26-10-2016 Düzenleme: Yakın zamanda YouTube Ünite testlerine ve Entegrasyon testlerine çok hoş bir giriş yapıldı - MPJ'in Musings - FunFunFunction # 55

entegrasyon testi, bir kabul testi olduğu ortaya çıkıyor

Açıkçası.

Bu ikisi neredeyse aynı şey. Ancak, test tanımında biraz farklı boyutlar vardır.

Entegrasyon == sistemi bir bütün olarak.

Kabul == sistemi bir bütün olarak.

Tek fark - ve bu ince - test durumlarının tanımıdır.

Entegrasyon == entegrasyonun derinliğini ve derecesini test etmek için test durumları. Tüm kenar kasaları ve köşe kasaları için işe yarıyor mu? Test durumları tasarımcı ve kodlayıcılar tarafından yazılmış teknik olma eğilimindedir.

Kabul == özellik setinin sadece son kullanıcı odaklı% 80'ini uygulamak için test durumları. Tüm kenar ve köşe kılıfları değil. Test durumları teknik olmayan ve son kullanıcılar tarafından yazılmış olma eğilimindedir.

Şahsen sistemin her bileşeni gerçek olduğunda , sahte nesneler olmadığında bir entegrasyon testini bir özellik testi olarak düşünmeyi seviyorum .

Gerçek bir depo, gerçek bir veritabanı, gerçek bir kullanıcı arayüzü. Sistem tamamen monte edildiğinde ve devreye alındığında olması gerektiği gibi olduğunda belirli işlevleri test edersiniz.

Çok az deneyime sahip olduğumda, entegrasyon kelimesinin gerçekten yanlış anlamalara yol açabileceğini anladım: gerçekten, bir sistemde tamamen yalıtılmış bir şey bulmak zor, bazı elementlerin kesin bir entegrasyona ihtiyacı olacak.

Böylece, aşağıdaki ayrımları yapmaya alıştım:

• Test ettiğim sınıfın başarmasından sorumlu olduğu tüm davranışları tanımlamak, belgelemek ve vurgulamak için birim test kullanıyorum .
• Sistemimde başka bir " harici " sistemle sohbet eden bir bileşen (belki birden fazla) olduğunda entegrasyon testleri yapıyorum . (aşağıda devam ediyor ...)
• Sistemin beklediği belirli bir iş akışını tanımlamak, belgelemek ve vurgulamak için bir kabul testi yapıyorum .

Entegrasyon testi tanımında, dışsal anlamda, geliştirme alanım dışında kalan bir sistem kastedildi : Herhangi bir nedenden ötürü hemen davranışlarını değiştiremiyorum. Bir kütüphane olabilir, sistemin değiştirilemeyen bir bileşeni olabilir (örn. Şirketteki diğer projelerle paylaşılır), bir dbms, vb. Bu testler için sistemin gerçek ortamına çok benzer bir şey kurmam gerekiyor. çalışacak: harici bir sistem başlatılmalı ve belirli bir duruma getirilmelidir; gerçekçi veriler db'ye kaydedilmelidir; vb.

Bunun yerine, kabul testini yaparken, sahte şeyler yapıyorum : Farklı bir şey üzerinde çalışıyorum, sistemin özellikleri üzerinde çalışıyorum, dış varlıklar ile işbirliği yapma yeteneği üzerinde değil.

Bu, KeesDijk'in daha önce anlattıklarına kıyasla daha dar bir görüş, ancak şimdiye kadar üzerinde çalıştığım projeler bu basitleştirme seviyesine izin verecek kadar küçüktü.

Bir entegrasyon testi , karmaşık bir sistemin bileşenlerinin (örneğin yazılım, uçak, elektrik santrali) tasarlandığı gibi birlikte çalıştığını doğrular.

Bir uçaktan bahsettiğimizi hayal edelim (yazılımla farkı daha soyut ve fark etmesi zor). Entegrasyon testleri şunları doğrular:

• Bazı bileşenler arasında doğru etkileşim. Örnek: start düğmesine basıldığında motor çalışır ve pervane beklenen dönme hızına ulaşır (uçak hala yerde kalır)
• dış bileşenlerle doğru etkileşim. Örnek: gömülü radyonun sabit bir telsizle iletişim kurabildiğini kontrol edin (uçak hala yerde)
• İlgili tüm bileşenler arasındaki doğru etkileşimi, böylece bir bütün olarak sistem beklendiği gibi çalışır. Örnek: Test pilotları ve mühendislerinden oluşan bir ekip uçağı başlatır ve onunla uçar (hepsi paraşüt giyerler ...).

Entegrasyon testi Teknik bir sorunu giderir sistem bileşenlerine onun alt bölümü rağmen çalışır yani o. Yazılımda bileşenler kullanım durumları, modüller, fonksiyonlar, arayüzler, kütüphaneler vb. Olabilir.

Kabul testi ürün amaca uygun olduğunu doğrular. Prensip olarak müşteri tarafından gerçekleştirilirler. Uçak analojisini alarak, şunları doğrulamayı içerir:

• Öngörülen iş senaryoları, neredeyse gerçek bir durumda beklenen sonuca yol açmaktadır. Örnek: Personelin binişleri çalışma prosedürlerinde beklendiği gibi izleyebildiğini kontrol etmek için test yolcuları ile bir biniş provası. Bazı senaryolar ünite testi gibi görünecek kadar basit olabilir, ancak kullanıcı tarafından gerçekleştirilirler (örn. Elektrik fişlerini firmaların ekipmanıyla deneyin).
• sistem neredeyse gerçek bir iş durumunda çalışıyor. Örnek: iki gerçek varış noktası arasında boş bir deneme uçuşu yapın, yakıt tüketiminin vaat edildiği gibi olup olmadığını kontrol etmek için havayolundan yeni eğitilmiş pilotlarla.

Kabul testi daha bir sorumluluk sorununu giderir . Bir müşteri / tedarikçi ilişkisinde, sözleşmeye bağlı bir sorumluluk olabilir (tüm gerekliliklere uygun). Ancak, her durumda, görevlerini sistemle sürdürebilmelerini sağlamak ve öngörülmeyen herhangi bir sorunu ihtiyatlı bir şekilde önlemek (örneğin, bazı quaileri kısaltmak zorunda kaldıklarını tespit eden bu demiryolları şirketi gibi) kullanmaktan kullanan kurumun sorumluluğundadır. Yeni vagonlar 5 cm büyüktü - şaka yapılmadı!).

Sonuç: Entegrasyon ve kabul testleri örtüşüyor. Her ikisi de sistemin bir bütün olarak çalıştığını göstermeye niyetli. Ancak “bütün” müşteri için daha büyük olabilir (çünkü sistemin kendisi daha büyük bir organizasyon sisteminin parçası olabilir) ve sistem entegratörü için daha teknik olabilir:

Entegrasyon testi, iki modül arasında veri akışının bağlantısını ve doğruluğunu kontrol etmekten başka bir şey değildir.

Örneğin: Bir posta (bir modül) oluşturup bazı geçerli kullanıcı kimliğine (ikinci modül) gönderdiğimizde entegrasyon testi, gönderilen postanın gönderilen öğelerde olup olmadığını kontrol etmektir.

Bir entegrasyon testinin pratik bir tanımı: İşlem dışı bir şeyle etkileşimi gerektiren herhangi bir test.

Örneğin:

• Dosya sistemi
• Ağ
• Bir veritabanı
• Harici bir API

Sürecinizle dış dünya arasında bir çeşit sözleşme mevcut ve asgari olarak bir entegrasyon testinin hedefi olması gerektiğini doğrulamak. yani sözleşmeyi doğrulamaktan daha fazlasını yapmamalıdır. Eğer öyleyse, sistem / uçtan uca boşluğa doğru ilerliyorsunuzdur.

Birim testleri, işlem sınırınızdaki tüm mantığı test edebilir ve yavaş / kırılgan / karmaşık "dış dünya" ya bağımlı olmadığından kesin olarak kolayca yapabilirler .

Entegrasyon testleri varken, bu tanım kapsamaz (bu nedenle neden pratik bir tanım olarak adlandırdım ) daha az yaygın / yararlı olduklarını düşünüyorum.

Not: Açıkça söylemek gerekirse, bu tanım, sistem / uçtan uca testleri de kapsayacaktır. Benim felsefemde, onlar 'aşırı' bir entegrasyon testi şeklidir, bu yüzden isimleri neden başka bir yönü vurgulamaktadır. Diğer bir yönde, bir birim testi sıfır bileşenli bir entegrasyon testi olarak kabul edilebilir, yani tüm testlerin 0-n bileşenler arasında entegrasyonla entegrasyon spektrumunda bir yerde olduğu düşünülebilir. :-)