Temel bilgilerle başlayalım. İki genel test modunu ve yaygın üç test otomasyonu türünü keşfetme.
Hepimiz bu durumu yaşamışızdır: Gerçek hayatta çok sık karşılaşılan, kodlamayla ilgili tekrarlanan bir meme nedir?
Bu meme, durumu gayet güzel özetliyor: Her çekmece tek başına mükemmel şekilde çalışır ancak diğer çekmeceyle birlikte kullanıldığında birbirlerini engeller ve çalışmaz. Her iki çekmecenin de birbiriyle iyi çalışmasını ve aynı anda kullanılabilmesini istiyorsunuz.
Bunu web geliştirmeye uygulayalım: Bazı testler yazdınız, hatta% 100 test kapsamına ulaştınız ancak diğer parçalar yerine oturduktan sonra uygulamanızın yine de çalışması gerekir. Birimler tek başlarına iyi çalışabilir ancak birbirleriyle ilgili olarak çalışmayabilir. Bazı testler yazmak çok önemlidir ancak projeniz için ideal test kurulumunun yalnızca bir parçasıdır. İlk adım olarak, uygulama kalitesinin hangi bölümlerinden emin olmanız gerektiğini ve bunu nasıl başarabileceğinizi belirlemeniz gerekir.
Basitçe söylemek gerekirse, gerçek test kodunu yazmaya başlamadan önce bir plana ihtiyacınız vardır. Pratik olarak nasıl test yapılacağı konusuna değinmek için sıfırdan başlayıp iki temel soruyu yanıtlayalım:
- Nasıl test etmek istiyorsunuz?
- Neyi test etmek istiyorsunuz?
Bu makalede, ilk soruyu yanıtlamak için bilmeniz gereken genel bilgiler ele alınmaktadır. Ortak bir noktadan başlamak için önce hangi test modlarının mevcut olduğunu öğrenelim ve ardından yaygın test türlerine odaklanalım. Sonraki makalelerde ikinci soruyu yanıtlayacak, yanıtları birleştirecek ve projeniz için en uygun test stratejisini bulacağız. Başlayın! 🙌
Temel bilgilerle başlayın: Genel test modları
Nasıl test edileceği sorusuna yanıt verirken açıklanması gereken ilk nokta çok soyuttur. Testi manuel olarak mı yoksa bilgisayarın devralmasına izin vererek mi yapacaksınız? Ancak burada ikili düşünmeye düşmemek önemlidir.
Manuel test ve otomatik test karşılaştırması
Kalite güvencesi mühendislerinden testleri tanımlamalarını isterseniz muhtemelen önce iki "mod"a ayırırlar:
- Manuel test. Bu, gerçek kişiler tarafından yürütülen tipik bir test yöntemidir. Kalite güvencesi mühendisi, uygulamayı tıklayarak çalışıp çalışmadığını kontrol eder ve aynı zamanda uygulamayı bozmaya çalışır. En yaygın yöntem, mühendisin uygulama hakkındaki bilgilerini kullanarak uygulamayı önceden tanımlanmış bir yola veya yapılacaklar listesine göre incelediği keşifsel testtir.
- Otomatik test. Bu, bilgisayar tarafından yürütülen bir test türüdür. Kalite güvencesi mühendisleri, tekrarlanan ve monoton testleri otomatikleştirmek için bu özelliği uygular.
Bu kılavuz serisi çoğunlukla otomatik teste odaklanmıştır. Ancak yalnızca bir test yöntemine odaklanmamalısınız. Otomasyon çok fazla zaman ve çaba tasarrufu sağlasa da gerçek kişiler ve manuel testler her zaman önemli bir rol oynayacaktır. Test otomasyonu, kullanıcıların keşifsel testlere ve yaratıcı problem çözmeye odaklanmalarını sağlamalıdır. Örneğin, kullanıcı deneyimlerinin kalitesini sağlamak veya yüksek riskli iş mantığını korumak. Başka bir deyişle, otomasyon size destek olur. ❤️
Opak kutu ve şeffaf kutu
Genel test modlarını tanımladınız. Ancak bu henüz yeterli değil. Test stratejisini planlamak için yanıtlanması gereken bir soru daha vardır: Uygulamanızın temel işleyişini bilmeli misiniz yoksa bu bilgiye sahip olmadan test etmek mi daha iyidir? Yanıta bağlı olarak, test durumlarını türetmek ve seçmek için iki prosedürden birini kullanabilirsiniz:
- Görünmez kutu testi (veya siyah kutu testi). Bir bileşenin veya sistemin işlevsel ya da işlevsel olmayan gereksinimlerini (özellikleri), iç yapısını dikkate almadan analiz etmeyi temel alır.
- Clear box testi (veya beyaz kutu testi), söz konusu kutunun iç yapısını dikkate alan bir prosedürdür. Diğer bir deyişle, uygulamanızın arka planda nasıl çalıştığı.
Her iki prosedür de manuel ve otomatik testlere uygulanabilir. Ancak genel test modlarının bazı yönleri ikisinden birine daha fazla odaklanabilir. Bu konuyu daha sonra ele alacağız. Şimdilik test otomasyonunu türlere ayıralım.
Test otomasyonu türleri: Nasıl test etmek istiyorsunuz?
"Nasıl?" sorusuna yanıt bulmaya yaklaşırken bazı manuel testler yapmaya karar verdiniz. Ancak test otomasyonu türlerini seçmek ve uygulamak biraz daha zordur. Otomasyon testi türleri, projelerinizde oluşturmak istediğiniz metriklerle yakından ilgilidir. Bu nedenle, en önemlilerine daha yakından bakalım.
Daha önce bahsedilen meme'de gösterildiği gibi, birim testi ve entegrasyon testi olmak üzere iki türe zaten rastlamışsınızdır. Dikkate alınması gereken üçüncü önemli nokta ise uçtan uca testtir. Ancak bu, henüz her şey değil. Daha yakından inceleyelim.
Birim testi
Birim testi, bir uygulamanın küçük test edilebilir bölümlerinin veya birimlerinin düzgün çalışması için ayrı ayrı ve bağımsız olarak test edildiği bir test türüdür. Bu birimlerin kapsamı işlevlerden, sınıflardan veya arayüzlerden hizmetlere ya da tüm bileşenlere kadar değişebilir. Bu türlerin başlıca özellikleri yürütme hızı, yalıtım ve kolay bakımdır. Birim testiyle ilgili daha fazla bilgi edinmek istiyorsanız birim testi kılavuzuna göz atın.
Entegrasyon testi
Entegrasyon testi, bileşenler veya sistemler arasındaki etkileşimlere odaklanır. Diğer bir deyişle, birlikte ne kadar iyi çalıştıklarına bağlıdır. Entegrasyon testlerine örnek olarak API veya bileşen testleri verilebilir.
Uçtan uca test
Bu testlere genellikle kullanıcı arayüzü testleri denir ve bu ad, işlevlerini daha da iyi açıklar. Bu testler, uygulama yığınının tamamı dahil olmak üzere uygulamanızın kullanıcı arayüzüyle etkileşime geçer ve uygulamanızı baştan sona test eder.
Kalite güvencesi teorisine göre bu testler bir sistem testine benzer. Bu testler, gerçek bir kullanıcıyı ve kullanıcının etkileşimlerini simüle eder. Uçtan uca testler, sistemin tamamını içerdiğinden daha fazla çalışma zamanı alır ve daha fazla çalışma zamanı için daha fazla işlem gücü gerekir. Sonuç olarak bu ek çaba, daha yüksek bakım maliyetlerine neden olur.
Görsel kullanıcı arayüzü testi
Kullanıcı arayüzü testlerinin ilginç bir alt kategorisi görsel testlerdir. Bu testler, bir uygulamanın görünür çıktısını doğrulama olanağı sağlayan genişletilmiş uçtan uca testlerdir. Bu tür bir testte, değişiklikten sonra bir ekran görüntüsü ve "mevcut durumu" (veya altın dosyayı) içeren başka bir ekran görüntüsü alınır. Ardından bu sonuçlar, inceleme ve kontrol için gerçek bir incelemeciye sağlanır. Diğer bir deyişle, yalnızca işlevsel hataların ötesinde ve açıkça beyanlarda yazılmayan bir sayfanın görünümündeki "görsel hataları" bulmaya yardımcı olur.
Statik analiz
Burada bahsetmemiz gereken bir konu daha var: statik analiz. Bu, ders kitabı anlamında bir test türü değildir. Ancak daha sonra kalite güvencesi stratejilerinde önemli bir unsur olacaktır. Bu aracın bir yazım denetimi işlevi gibi çalıştığını düşünebilirsiniz: Programı çalıştırmadan kodunuzu daha önemli kusurlar ve söz dizimi hataları açısından tarar, böylece kod stili sorunlarını tespit eder. Bu basit önlem birçok hatayı önleyebilir. Statik analiz hakkında daha ayrıntılı bilgi edinmek istiyorsanız bu konuyu incelemek için iyi bir zamandır.
Her türlü test: Tüm bunlar nasıl bir arada çalışır?
Tüm bu soruların yanıtlarını ararken bazı analojilerde olası bir çözüm bulabilirsiniz. Özellikle web ve test topluluklarında geliştiriciler, hangi türde kaç test kullanmanız gerektiği konusunda size fikir vermek için bu benzetmeleri kullanma eğilimindedir.
Bu resimde gösterilen beş strateji en yaygın olanlardır:
- Test Piramidi
- Test Elmas
- Test Pizzası olarak da bilinen Test Dondurma Külahı
- Test Petek
- Test Trophy
Bu gerçekten çok fazla bilgi. Tüm bu bilgilere dayanarak eşleme testi stratejisine nasıl karar vermelisiniz? Endişelenmeyin, size yardımcı olacağız. Bir sonraki makalede, bu farklı stratejileri daha ayrıntılı olarak ele alacak ve projeniz için en uygun stratejiyi nasıl seçeceğinizi açıklayacağız. Bizi izlemeye devam edin! 🔥