En temel konulardan başlayalım! İki genel test modunu ve yaygın üç test otomasyonu türünü keşfetme.
Hepimizin başına gelmiştir: Gerçek hayatta çok sık tekrarlanan kod yazma meme'i nedir?
Bu meme bunu çok güzel özetliyor: Her çekmece ayrı ayrı mükemmel çalışıyor ama diğer çekmeceyle birlikte birbirlerini engellediği için işlevsiz kalıyor. Her iki çekmecenin birbiriyle uyumlu ve aynı anda çalışır durumda olmasını istersiniz.
Bunu web geliştirmeye uygulayın: Bazı testler yazdınız, hatta% 100 test kapsamına ulaştınız ancak uygulamanızın diğer bölümler de oturduğunda çalışmaya devam etmesi gerekiyor. Birimler kendi başlarına iyi çalışabilir ancak birbirleriyle ilişkili değildir. Bazı testler yazmak çok önemlidir, ancak projeniz için ideal test kurulumunun yalnızca bir kısmıdır. İlk adım olarak, uygulama kalitesinin hangi bölümlerinin sağlanması gerektiğini ve bunu nasıl başaracağınızı belirlemeniz gerekir.
Basitçe ifade etmek gerekirse, gerçek test kodunu yazmaya başlamadan önce bir plana ihtiyacınız vardır. Pratik test yapma konusuna yaklaşmak için temiz bir seçenekle başlayalım ve iki temel soruyu cevaplayalım:
- Nasıl test etmek istersiniz?
- Neyi test etmek istiyorsunuz?
Bu makale, ilk soruyu yanıtlamak için bilmeniz gereken genel bilgilere odaklanmaktadır. Ortak bir zeminden başlamak için öncelikle hangi test modlarının var olduğunu öğrenelim ve ardından yaygın test türlerine odaklanalım. Sonraki makalelerde ikinci soruyu yanıtlayıp cevapları 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 edilir sorusunu yanıtlarken açıklığa kavuşturulması gereken ilk nokta son derece soyut. Manuel olarak mı test etmeniz gerekir yoksa bir bilgisayara mı izin vermeniz gerekir? Ancak burada ikili bir düşünceye dalmamak önemlidir.
Manuel test ve otomatik test karşılaştırması
Kalite güvencesi mühendislerinden testi tanımlamalarını isterseniz önce muhtemelen bunu iki "moda" ayırırlar:
- Manuel test. Bu, gerçek kişiler tarafından yürütülen tipik bir test yöntemidir. Bir kalite güvence mühendisi uygulamayı tıklar, çalışıp çalışmadığını kontrol eder ve aynı zamanda uygulamayı kırmaya çalışır. En yaygın yöntem keşif testidir. Bu testte mühendis, uygulama hakkındaki bilgilerini kullanarak önceden tanımlanmış bir yol veya yapılacaklar listesine göre uygulamayı inceler.
- Otomatik test. Bu, bilgisayar tarafından yürütülen bir test türüdür. Kalite güvencesi mühendisleri, tekrarlayan ve tekdüze testleri otomatikleştirmek amacıyla bu yöntemi uygular.
Bu kılavuz serisi, çoğunlukla otomatik testlere odaklanacaktır. Ancak, test etmenin tek bir yoluna odaklanmamalısınız. Otomasyon çok zaman ve emek tasarrufu sağlasa bile insanlar tarafından yapılan testler ve manuel testler her zaman hayati bir rol oynar. Bunun yerine, test otomasyonu insanları keşif amaçlı testlere ve yaratıcı sorun çözmeye odaklanmaya serbest bırakmalıdır. Örneğin, kullanıcı deneyimlerinin kalitesini sağlamak veya yüksek riskli iş mantığını korumak bunlardan biridir. Diğer bir deyişle, otomasyon arkanızda. ❤️
Opak kutu ile şeffaf kutu karşılaştırması
Genel test yöntemlerini tanımladınız. Ancak bu henüz yeterli değil. Test stratejisini planlarken cevaplanması gereken bir soru daha var: Uygulamanızın nasıl çalıştığını biliyor musunuz yoksa bu bilgi olmadan test etmek daha mı iyi olur? Cevaba bağlı olarak, test durumlarını türetmek ve seçmek için seçilecek iki prosedür vardır:
- Opak kutu testi (veya kara kutu testi). Bir bileşenin veya sistemin işlevsel ya da işlevsel olmayan gereksinimlerini, dahili yapısını dikkate almadan analiz etmeye dayanır.
- Şeffaf kutu testi (veya beyaz kutu testi), ilgili kutunun dahili yapısının dikkate alındığı 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. Bununla birlikte, genel test modlarının bazı yönleri bu iki seçenekten birine daha fazla odaklanabilir. Bunu daha sonra ele alacağız. Şimdilik test otomasyonunu türlere daha ayrıntılı olarak ayıralım.
Otomasyon türlerini test etme: Nasıl test etmek istersiniz?
"Nasıl" sorusunun cevabına yaklaştıkça çoktan 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 ilişkilidir. En önemlilerini daha yakından inceleyelim.
Daha önce bahsedilen meme'te de gösterildiği gibi şu anda iki türle karşılaştınız: birim testi ve entegrasyon testi. Uçtan uca test, düşünülmesi gereken üçüncü önemli test yöntemidir. Ama hâlâ hepsi bu değil. Biraz ayrıntılarına inelim.
Birim testi
Birim testi, bir uygulamanın küçük test edilebilir parçalarının veya birimlerinin ayrı ayrı ve bağımsız bir şekilde test edildiği bir test türüdür. Bu birimlerin kapsamı işlevler, sınıflar veya arayüzlerden hizmetlere ya da eksiksiz bileşenlere kadar değişiklik gösterebilir. Birincil özellikleri yürütme hızı, izolasyon ve rahat sürdürülebilirliktir. Birim testini daha ayrıntılı bir şekilde incelemek istiyorsanız birim testiyle ilgili bu kılavuza gidin.
Entegrasyon testi
Entegrasyon testi, bileşenler veya sistemler arasındaki etkileşimlere odaklanır. Başka bir deyişle, bunların birlikte ne kadar iyi çalıştığı. 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 testler işlevlerini daha da iyi açıklar. Bu testler, uygulama yığınının tamamı da dahil olmak üzere uygulamanızın kullanıcı arayüzüyle etkileşime girer ve uygulamanızı bir uçtan öbür uca test eder.
Kalite güvencesi teorisinden bahsederseniz bunlar bir sistem testine benzeyebilir. Bu testler gerçek bir kullanıcıyı ve onun etkileşimlerini simüle eder. Uçtan uca testler tüm sistemi içerdiğinden ve çalışma zamanının artması daha fazla bilgi işlem gücü gerektirdiğinden daha uzun çalışma zamanı alır. Sonuç olarak, bu ek çaba daha yüksek bakım maliyetlerine yol açar.
Görsel kullanıcı arayüzü testi
Kullanıcı arayüzü testlerinin ilginç bir alt kategorisi de görsel testlerdir. Bu testler, bir uygulamanın görünür çıkışını doğrulamak için bir yöntem sağlayan genişletilmiş uçtan uca testlerdir. Bu tür bir test, değişiklikten sonra ekran görüntüsü alıp, "durum ko"yu (veya altın dosyayı) içeren başka bir ekran görüntüsü alır ve ardından bu sonuçları incelemesi ve kontrol etmesi için gerçek kişi olan bir incelemeciye sunar. Diğer bir deyişle, sayfa görünümündeki, tamamen işlevsel hatalardan öte, iddialara açıkça yazılmamış, "görsel hataların" tespit edilmesine yardımcı olur.
Statik analiz
Burada değinmeniz gereken bir şey daha var: statik analiz. Ders kitabı anlamında bir test türü değildir. Ancak bu, daha sonra kalite güvence stratejilerinin temel unsurlarından biri olacaktır. Bir yazım denetimi işlevi gibi çalıştığını düşünebilirsiniz: Programı çalıştırmadan kodunuzu tarayarak daha belirgin hata ve söz dizimi hatalarını tespit ederek 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 nokta, Statik Analiz hakkında bilgi edinmek için iyi bir noktadır.
Tüm şekillerde test yapma: Tüm bunlar bir arada nasıl çalışır?
Tüm bu soruların yanıtlarını ararken bazı benzetmelerle olası bir çözüm bulabilirsiniz. Özellikle web'de ve test topluluklarında, geliştiriciler bu benzetmelerden yararlanarak hangi test türünde kaç test kullanmanız gerektiği konusunda size bir fikir verebilir.
Bu resimde gösterilen aşağıdaki beş strateji en yaygın olanlardır:
- Test Piramidi
- Test Elması
- Test Buz Külahı (Test Pizza olarak da bilinir)
- Petek Testi
- Kupa Testi
Bunlar gerçekten işlenecek çok fazla bilgi. Tüm bunları dikkate alarak eşleşen bir test stratejisine nasıl karar vermeniz gerekir? Merak etmeyin, aradığınız şeyi bulacaksınız. Bir sonraki makalede bu farklı stratejileri daha ayrıntılı olarak ele alacak ve projenize en uygun stratejiyi nasıl seçeceğinizi açıklayacağız. Bizi izlemeye devam edin! 🔥