Test stratejileri

Otomatik test, uygulama kalitesini çeşitli şekillerde artırmanıza yardımcı olur. Örneğin, doğrulama yapmanıza, gerilemeleri yakalamanıza ve uyumluluğu doğrulamanıza yardımcı olur. İyi bir test stratejisi, önemli bir avantaj olan geliştirici verimliliğine odaklanmak için otomatik testlerden yararlanmanıza olanak tanır.

Ekipler, altyapı geliştirmeleriyle birlikte sistematik bir test yaklaşımı kullandıklarında daha yüksek verimlilik düzeylerine ulaşır. Bu sayede kodun nasıl çalıştığıyla ilgili zamanında geri bildirim alabilirsiniz. İyi bir test stratejisi şunları yapar:

• Sorunları mümkün olduğunca erken tespit eder.
• Hızlı bir şekilde yürütülür.
• Düzeltilmesi gereken bir durum olduğunda net göstergeler sunar.

Bu sayfa, hangi test türlerini uygulayacağınıza, testleri nerede ve ne sıklıkta yapacağınıza karar vermenize yardımcı olur.

Test piramidi

Modern uygulamalardaki testleri boyuta göre sınıflandırabilirsiniz. Küçük testler yalnızca kodun küçük bir bölümüne odaklandığı için hızlı ve güvenilirdir. Büyük testler geniş kapsamlıdır ve sürdürülmesi zor olan daha karmaşık kurulumlar gerektirir. Ancak büyük testler daha fazla doğruluk* sunar ve tek seferde çok daha fazla sorun keşfedebilir.

*Doğruluk, test çalışma zamanı ortamının üretim ortamına benzerliğini ifade eder.

Çoğu uygulamada çok sayıda küçük test ve nispeten az sayıda büyük test olmalıdır. Her kategorideki testlerin dağılımı piramit şeklinde olmalıdır. Daha çok sayıda küçük test tabanı, daha az sayıda büyük test ise piramidin ucunu oluşturmalıdır.

Hatanın maliyetini en aza indirme

İyi bir test stratejisi, geliştiricilerin verimliliğini en üst düzeye çıkarırken hataları bulmanın maliyetini en aza indirir.

Muhtemelen verimsiz bir strateji örneğini inceleyelim. Burada, boyuta göre test sayısı piramit şeklinde düzenlenmemiştir. Çok fazla uçtan uca test ve çok az bileşen kullanıcı arayüzü testi var:

Bu, birleştirme işleminden önce çok az test yapıldığı anlamına gelir. Bir hata varsa testler, gece veya haftalık uçtan uca testler çalıştırılana kadar bu hatayı yakalamayabilir.

Bunun, hataları belirleme ve düzeltme maliyeti üzerindeki etkilerini ve test çalışmalarınızı neden daha küçük ve daha sık yapılan testlere yönlendirmeniz gerektiğini göz önünde bulundurmanız önemlidir:

• Hata bir birim testiyle yakalandığında genellikle dakikalar içinde düzeltilir. Bu nedenle maliyet düşüktür.
• Uçtan uca testte aynı hatanın bulunması günler sürebilir. Bu durum, birden fazla ekip üyesinin dikkatini dağıtarak genel verimliliği düşürebilir ve yayın tarihini geciktirebilir. Bu hatanın maliyeti daha yüksek.

Bununla birlikte, verimsiz bir test stratejisi hiç strateji olmamasından daha iyidir. Bir hata üretime girdiğinde düzeltmenin kullanıcının cihazlarına ulaşması uzun zaman alır (bazen haftalarca). Bu nedenle geri bildirim döngüsü en uzun ve en maliyetli olanıdır.

Ölçeklenebilir bir test stratejisi

Test piramidi geleneksel olarak 3 kategoriye ayrılı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:

• Birim testi, ana makinede çalıştırılır ve Android çerçevesine bağımlı olmayan tek bir işlevsel mantık birimini doğrular.
  • Örnek: Matematiksel bir fonksiyonda birer birer artan hataları doğrulama.
• Bileşen testi, bir modülün veya bileşenin işlevselliğini ya da görünümünü sistemdeki diğer bileşenlerden bağımsız olarak doğrular. Birim testlerinin aksine, bileşen testinin yüzey alanı, tek tek yöntemlerin 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 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, dağıtılabilir bir ikili dosya biçiminde uygulamanın tamamının işlevselliğini doğrular. Bunlar, test edilen sistem olarak test kancaları içerebilen bir geliştirme derlemesi gibi hata ayıklanabilir bir ikili dosya kullanan büyük entegrasyon testleridir.
  • Örnek: Katlanabilir cihazdaki yapılandırma değişikliklerini doğrulayan 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. Bunlar, uygulama ikilisi küçültülmüş ve optimize edilmiş olması dışında uygulama testlerine benzer. 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ışan büyük uçtan uca entegrasyon testleridir.
  • Örnek: Kritik kullanıcı yolculukları, performans testi

Bu sınıflandırmada doğruluk, süre, kapsam ve izolasyon düzeyi dikkate alınır. Birden fazla katmanda farklı test türleri kullanabilirsiniz. Örneğin, uygulama testi katmanı davranış, ekran görüntüsü ve performans testlerini içerebilir.

	Kapsam	Ağ erişimi	Uygulama	Derleme türü	Yaşam döngüsü
Birim	Minimum bağımlılık içeren 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ı bir arada kullanma	Hayır	Yerel Robolectric Emülatör	Hata ayıklanabilir	Birleştirme öncesi
Özellik	Özellik düzeyi Diğer ekiplere ait bileşenlerle entegrasyon	Mocked	Yerel Robolectric Emulator Cihazlar	Hata ayıklanabilir	Birleştirme öncesi
Uygulama	Uygulama düzeyi Diğer ekiplere ait özellikler ve/veya hizmetlerle entegrasyon	Sahte Aşamalandırma sunucusu Üretim sunucusu	Emülatör Cihazlar	Hata ayıklanabilir	Birleştirme öncesi Birleştirme sonrası
Sürüm Adayı	Uygulama düzeyi Diğer ekiplere ait özellikler ve/veya hizmetlerle entegrasyon	Üretim sunucusu	Emülatör Cihazlar	Küçültülmüş yayın derlemesi	Birleştirme sonrası Lansman öncesi

Test kategorisine karar verme

Genel bir kural olarak, piramidin ekibe doğru düzeyde geri bildirim verebilecek en alt katmanını dikkate almalısınız.

Örneğin, bu özelliğin uygulanması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 şeyin açıklaması	Test kategorisi	Örnek test türü
Form doğrulayıcı mantığı	E-posta adresini normal ifadeye göre doğrulayan ve şifre alanının girilip girilmediğini kontrol eden bir sınıf. Bağımlı öğe içermez.	Birim testleri	Yerel JVM birim testi
Oturum açma formu kullanıcı arayüzü davranışı	Yalnızca form doğrulandığında etkinleştirilen bir düğmeye sahip form	Bileşen testleri	Robolectric'te çalışan kullanıcı arayüzü davranış testi
Oturum açma formu kullanıcı arayüzünün görünümü	Kullanıcı deneyimi spesifikasyonuna uygun bir form	Bileşen testleri	Compose Preview Screenshot test
Kimlik doğrulama yöneticisiyle entegrasyon	Kimlik bilgilerini bir kimlik doğrulama yöneticisine gönderen ve farklı hatalar içerebilen yanıtlar alan kullanıcı arayüzü.	Özellik testleri	Sahte verilerle JVM testi
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	Hazırlık sunucusuna karşı test hesabı kullanılarak yapılan tam oturum açma akışı	Sürüm Adayı	Cihazda çalışan uçtan uca Compose kullanıcı arayüzü davranış testi

Bazı durumlarda, bir şeyin hangi kategoriye ait olduğu öznel olabilir. Bir testin yukarı veya aşağı taşınmasının başka nedenleri de olabilir. Örneğin, altyapı maliyeti, güvenilirlik 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 de test stratejinizin bir parçası olabilir. Genellikle Kalite Güvencesi ekipleri, yayın adayı testleri yapar ancak diğer aşamalarda da yer alabilirler. Örneğin, bir özellikteki hatalar için komut dosyası olmadan keşif testi.

Test altyapısı

Test stratejisi, geliştiricilerin testlerini sürekli olarak çalıştırmasına ve tüm testlerin başarılı olmasını sağlayan kuralları uygulamasına yardımcı olacak altyapı ve araçlarla desteklenmelidir.

Hangi testlerin ne zaman ve nerede çalıştırılacağını tanımlamak için testleri kapsama göre kategorize edebilirsiniz. Örneğin, 5 katmanlı modeli kullanıyorsanız:

Kategori	Ortam (nerede)	Tetikleyici (ne zaman)
Birim	[Local][4]	Her kaydetme
Bileşen	Yerel	Her kaydetme
Özellik	Yerel ve emülatörler	Birleştirme öncesinde, birleştirmeden veya değişiklik göndermeden önce
Uygulama	Yerel, emülatörler, 1 telefon, 1 katlanabilir	Birleştirme işleminden sonra, birleştirme veya değişiklik gönderme işleminden sonra
Sürüm Adayı	8 farklı telefon, 1 katlanabilir telefon, 1 tablet	Yayın öncesi

• Birim ve Bileşen testleri, her yeni commit için Sürekli Entegrasyon sisteminde çalıştırılır ancak yalnızca etkilenen modüller için çalıştırılır.
• Bir değişiklik birleştirilmeden veya gönderilmeden önce tüm Birim, Bileşen ve Özellik testleri çalıştırılır.
• Uygulama testleri birleştirme işleminden sonra çalıştırılır.
• Yayın adayı testleri her gece telefonda, katlanabilir cihazda ve tablette çalıştırılır.
• Yayın öncesinde, çok sayıda cihazda yayın adayı testleri yapılır.

Test sayısı üretkenliği etkilediğinde bu kurallar zaman içinde değişebilir. Örneğin, testleri geceye taşırsanız CI derleme ve test sürelerini kısaltabilirsiniz ancak geri bildirim döngüsünü de uzatabilirsiniz.