Otomatik test, uygulama kalitesini birden fazla şekilde iyileştirmenize yardımcı olur. Örneğin, doğrulama gerçekleştirmenize, regresyonları yakalamanıza ve uyumluluğu doğrulamanıza yardımcı olur. İyi bir test stratejisi, otomatik testten yararlanarak önemli bir avantaja odaklanmanızı sağlar: geliştirici üretkenliği.
Ekipler, test için sistematik bir yaklaşımı altyapı geliştirmeleriyle birlikte kullandığında daha yüksek düzeyde üretkenlik elde eder. Böylece, kodun davranışı hakkında zamanında geri bildirim alırsınız. İyi bir test stratejisi aşağıdakileri sağlar:
- Sorunları mümkün olduğunca erken tespit eder.
- Hızlı bir şekilde yürütülür.
- Bir şeyin düzeltilmesi gerektiğinde net göstergeler sağlar.
Bu sayfa, hangi test türlerini uygulayacağınıza, bunları nerede ve ne sıklıkta çalıştıracağınıza karar vermenize yardımcı olur.
Test piramidi
Modern uygulamalardaki testleri boyuta göre kategorilere ayırabilirsiniz. Küçük testler, kodun yalnızca küçük bir bölümüne odaklandığından hızlı ve güvenilirdir. Büyük testlerin kapsamı geniştir ve bakımı zor olan daha karmaşık kurulumlar gerektirir. Ancak büyük testler daha yüksek doğruluğa* sahiptir ve tek seferde çok daha fazla sorun tespit edebilir.
*Gerçekçilik, test çalışma ortamının üretim ortamına olan benzerliğini ifade eder.
Çoğu uygulamada çok sayıda küçük, nispeten az sayıda büyük test yapılır. Her kategorideki testlerin dağılımı bir piramit oluşturmalıdır. Piramidin tabanı çok sayıda küçük testten, tepe noktası ise daha az sayıda büyük testten oluşmalıdır.
Hata maliyetini en aza indirme
İyi bir test stratejisi, geliştirici verimliliğini en üst düzeye çıkarırken hataları bulmanın maliyetini en aza indirir.
Olası bir verimsiz strateji örneğini düşünün. Burada, boyuta göre test sayısı bir piramide göre düzenlenmez. Çok fazla sayıda büyük uçtan uca test ve çok az bileşen kullanıcı arayüzü testi vardır:
Bu, birleştirme işleminden önce çok az test çalıştırıldığı anlamına gelir. Bir hata varsa gecelik veya haftalık uçtan uca testler çalıştırılana kadar testler hatayı yakalayamayabilir.
Bu durumun, hataları tespit etme ve düzeltme maliyeti üzerindeki etkilerini ve test çalışmalarınızı daha küçük ve daha sık testlere yönlendirmenin neden önemli olduğunu göz önünde bulundurmanız önemlidir:
- Hata bir birim testi tarafından yakalandığında genellikle birkaç dakika içinde düzeltilir. Bu nedenle maliyet düşüktür.
- Uçtan uca testte aynı hatanın bulunması günler sürebilir. Bu, birden fazla ekip üyesinin dahil edilmesine neden olarak genel verimliliği düşürebilir ve sürümün yayınlanmasını geciktirebilir. Bu hatanın maliyeti daha yüksektir.
Bununla birlikte, verimsiz bir test stratejisi hiç stratejiye sahip olmamaktan daha iyidir. Bir hata üretime geçtiğinde, düzeltmenin kullanıcının cihazlarına ulaşması uzun zaman alır (bazen haftalar). Bu nedenle, geri bildirim döngüsü en uzun ve en pahalı olanıdır.
Ölçeklenebilir bir test stratejisi
Test piramidi geleneksel olarak 3 kategoriye ayrılmıştır:
- Birim testleri
- Entegrasyon testleri
- Uçtan uca testler.
Ancak bu kavramların kesin tanımları yoktur. Bu nedenle ekipler, kategorilerini farklı şekilde tanımlamak isteyebilir. Örneğin, 5 katman kullanabilirler:
- Ana makinede bir birim testi çalıştırılır ve Android çerçevesine bağımlı olmadan tek bir işlevsel mantık birimini doğrular.
- Örnek: Bir matematiksel işlevde bir birimlik hataları doğrulama.
- Bileşen testi, bir modülün veya bileşenin işlevini ya da görünümünü sistemdeki diğer bileşenlerden bağımsız olarak doğrular. Birim testlerinin aksine, bir bileşen testinin yüzey alanı, tek tek yöntem ve sınıfların üzerindeki daha yüksek soyutlamalara kadar uzanır.
- Örnek: Özel bir düğme için ekran görüntüsü testi
- Özellik testi, iki veya daha fazla bağımsız bileşenin ya da modülün etkileşimini doğrular. Özellik testleri daha büyük ve daha karmaşıktır ve genellikle özellik düzeyinde çalışır.
- Örnek: Bir ekrandaki durum yönetimini doğrulayan kullanıcı arayüzü davranış testleri
- Uygulama testi, uygulamanın tamamını dağıtılabilir ikili kod biçiminde doğrular. Bunlar, test edilen sistem olarak hata ayıklama yapılabilir bir ikili dosyayı (ör. test kancaları içerebilen bir geliştirme derlemesi) kullanan büyük entegrasyon testleridir.
- Örnek: Katlanabilir cihazlardaki yapılandırma değişikliklerini doğrulamak için kullanıcı arayüzü davranışı testi, yerelleştirme ve erişilebilirlik testleri
- Sürüm adayı testi, sürüm derlemesinin işlevselliğini doğrular.
Uygulama testlerine benzerler. Tek fark, uygulama ikilisinin küçültülmüş ve optimize edilmiş olmasıdır. Bunlar, uygulamayı herkese açık kullanıcı hesaplarına veya herkese açık arka uçlara maruz bırakmadan mümkün olduğunca üretime yakın bir ortamda çalıştırılan büyük uçtan uca entegrasyon testleridir.
- Örnek: Kritik kullanıcı yolculukları, performans testi
Bu sınıflandırmada; doğruluk, zaman, kapsam ve izolasyon seviyesi dikkate alınır. Birden fazla katmanda farklı türde testleriniz olabilir. Örneğin, uygulama testi katmanı davranış, ekran görüntüsü ve performans testleri içerebilir.
Kapsam |
Ağ erişimi |
Uygulama |
Derleme türü |
Yaşam döngüsü |
|
|---|---|---|---|---|---|
Birim |
Minimum bağımlılığa sahip tek bir yöntem veya sınıf. |
Hayır |
Yerel |
Hata ayıklanabilir |
Birleştirme öncesi |
Bileşen |
Modül veya bileşen düzeyi Birden fazla sınıfı birlikte kullanma |
Hayır |
Yerel |
Hata ayıklanabilir |
Birleştirme öncesi |
Özellik |
Özellik düzeyi Diğer ekiplerin sahip olduğu bileşenlerle entegrasyon |
Yapay |
Yerel |
Hata ayıklanabilir |
Önceden birleştirme |
Uygulama |
Uygulama düzeyi Diğer ekiplerin sahip olduğu özellikler ve/veya hizmetlerle entegrasyon |
Sahte |
Emülatör |
Hata ayıklama yapılabilir |
Önceden birleştirme |
Sürüm Adayı |
Uygulama düzeyi Diğer ekiplerin sahip olduğu özellikler ve/veya hizmetlerle entegrasyon |
Üretim sunucusu |
Emülatör |
Küçültülmüş sürüm derlemesi |
Birleştirme sonrası |
Test kategorisine karar verin
Genel kural olarak, piramidin ekibe doğru düzeyde geri bildirim verebilecek en alt katmanını göz önünde bulundurmanız gerekir.
Örneğin, şu özelliğin uygulamasını nasıl test edeceğinizi düşünün: oturum açma akışının kullanıcı arayüzü. Test etmeniz gerekenlere bağlı olarak farklı kategoriler seçersiniz:
Test edilen konu |
Test edilen öğenin açıklaması |
Test kategorisi |
Örnek test türü |
|---|---|---|---|
Form doğrulayıcı mantığı |
E-posta adresini normal bir ifadeye göre doğrulayan ve şifre alanının girilmesini kontrol eden bir sınıf. Bağımlılığı yoktur. |
Birim testleri |
|
Oturum açma formu kullanıcı arayüzü davranışı |
Yalnızca form doğrulandığında etkinleşen bir düğme içeren form |
Bileşen testleri |
Robolectric'te çalışan kullanıcı arayüzü davranışı testi |
Oturum açma formu kullanıcı arayüzü görünümü |
Kullanıcı deneyimi spesifikasyonuna uygun bir form |
Bileşen testleri |
|
Kimlik doğrulama yöneticisiyle entegrasyon |
Kimlik bilgilerini bir kimlik doğrulama yöneticisine gönderen ve farklı hatalar içerebilecek yanıtlar alan kullanıcı arayüzü. |
Özellik testleri |
|
Oturum açma iletişim kutusu |
Giriş düğmesine basıldığında oturum açma formunu gösteren bir ekran. |
Uygulama testleri |
Robolectric'te çalışan kullanıcı arayüzü davranış testi |
Kritik kullanıcı yolculuğu: Oturum açma |
Bir test hesabını kullanarak hazırlık sunucusu üzerinden tamamlanmış oturum açma akışı |
Sürüm Adayı |
Cihazda çalışan uçtan uca Kullanıcı arayüzü davranış testi oluşturma |
Bazı durumlarda, bir öğenin bir kategoriye ait olup olmadığı öznel olabilir. Bir testin sırasının yukarı veya aşağı taşınmasının başka nedenleri de olabilir (ör. altyapı maliyeti, kararsızlık ve uzun test süreleri).
Test kategorisinin test türünü belirlemediğini ve tüm özelliklerin her kategoride test edilmesi gerekmediğini unutmayın.
Manuel test, test stratejinizin bir parçası da olabilir. Genellikle QA ekipleri, sürüm adayı testlerini gerçekleştirir ancak diğer aşamalara da dahil edilebilirler. Örneğin, bir özellikteki hataları komut dosyası olmadan keşifsel test etme.
Test altyapısı
Geliştiricilerin testlerini sürekli olarak çalıştırmasına ve tüm testlerin başarılı olmasını garanti eden kuralları uygulamaya koymasına yardımcı olmak için test stratejisi, altyapı ve araçlarla desteklenmelidir.
Hangi testlerin ne zaman ve nerede çalıştırılacağını tanımlamak için testleri kapsama göre kategorilere ayırabilirsiniz. Örneğin, 5 katmanlı modele göre:
Kategori |
Ortam (nerede) |
Tetikleyici (ne zaman) |
|---|---|---|
Birim |
[Local][4] |
Her commit |
Bileşen |
Yerel |
Her commit |
Özellik |
Yerel ve emülatör |
Birleştirmeden veya değişiklik göndermeden önce, birleştirme öncesi |
Uygulama |
Yerel, emülatör, 1 telefon, 1 katlanabilir |
Birleştirmeden sonra, birleştirme veya değişiklik gönderme |
Yayın Adayı |
8 farklı telefon, 1 katlanabilir cihaz, 1 tablet |
Yayın öncesi |
- Birim ve Bileşen testleri, her yeni taahhütte Sürekli Entegrasyon sisteminde çalıştırılır ancak yalnızca etkilenen modüller için çalıştırılır.
- Tüm birim, bileşen ve özellik testleri, birleştirme veya değişiklik göndermeden önce çalıştırılır.
- Uygulama testleri, birleştirme işleminden sonra çalıştırılır.
- Sürüm Adayı testleri telefon, katlanabilir cihaz ve tablette her gece çalıştırılır.
- Sürüm yayınlanmadan önce çok sayıda cihazda Sürüm Adayı testleri çalıştırılır.
Test sayısı üretkenliği etkilediğinde bu kurallar zaman içinde değişebilir. Örneğin, testleri gecelik bir tempoya taşırsanız CI derleme ve test sürelerini kısaltabilir ancak geri bildirim döngüsünü de uzatabilirsiniz.