Örnek Test Durumu

Örnek uygulamamızın adı Scribble. Değinmek istediğimiz noktaları göstermek amacıyla kullanılan çok basit bir kelime işlemcidir. Gerçek uygulamalar çok daha karmaşık olacak ve bu, testlerini otomatikleştirme sorunlarını da buna bağlı olarak daha karmaşık hale getirecek.

Karalama’nın bir özelliği, bir belgenin Liste olarak bilinen bir yapı içerebilmesidir. Bu bölümde kullandığımız örnek test durumu, bazı Liste düzenleme işlevlerini kullanır.

Listede (Hollanda) yalnızca bir öğe bulunan ilk durumdan başlayarak, Listenin sonuna eklenen yeni bir öğe olan Belçika’yı (Öğe Ekle işlevini kullanarak) ekliyoruz. Ardından, iki öğenin sırasını değiştiren Listeyi sıralarız.

Üçüncü öğeyi (Danimarka) eklediğimizde, artık sıralanmamış değil sıralanmış bir Liste olduğu için Listeye doğru yere eklenir. Son olarak, Listedeki (Belçika) ilk öğeyi, Öğeyi sil’i seçip konum numarasını girerek siliyoruz.

Bir Karalama Listesi Testi

Artık uygulamamızı (manuel olarak) test etmeye hazırız. Ülkeler adlı bir belgede bir Listenin düzenlenmesini test edeceğiz (‘dcm’ soneki ‘belge’ anlamına gelir). Başlangıç durumu, üç öğeden oluşan sıralanmış bir Listedir.

Test durumu aşağıdakileri gerçekleştirecektir:

• sıralanan listeye iki yeni öğe ekleyin;
• bir öğeyi hareket ettirin (bu, Listeyi sıralanmamış hale getirir);
• sıralanmamış listeye bir öğe ekleyin;
• bir öğeyi silin;
• orada olmayan bir öğeyi silmeye çalışın (geçersiz konum numarası).

Bu çok titiz bir test durumu değil ve elbette bu işlevselliği yeterince test etmek için başkaları da gerekecek. Ancak, yukarıdaki test durumunu amaçlarımız için makul olarak seçtik. Test senaryosunun yürütülmesi bir dizi ekran görüntüsünde gösterilmektedir.

Test Girdisi Nedir?

Yukarıdaki test durumunda, uygulamayı ilk çalıştırmadan tamamlamaya götürmek için girdi girdik ve test senaryosunu gerçekleştirmek için belirli verileri girdik. Gerçekleştirdiğimiz belirli tuş basmaları ve/veya fare eylemleri gösterilir.

Eylemlerimizi fiziksel konumları yerine ekrandaki mantıksal öğeler açısından tanımladığımıza dikkat edin, örneğin ‘bit konumu’ yerine ‘Liste menüsü’. Listelenen tüm fare tıklamalarının sol fare düğmesi olduğunu da unutmayın.

Yazılım test otomasyon araçları
Test otomasyon araçları
Yazılım test otomasyonu nedir
Test otomasyon Eğitimi
Manuel test ve otomasyon test
Otomasyon testi Nedir
Test otomasyon Çeşitleri
Test otomasyonu

Manuel Test Süreci

Yukarıdaki örnekte az önce manuel olarak gerçekleştirdiğimiz test durumu, şimdi bir tekrar yakalama aracı kullanarak otomatikleştirmeye çalışacağımız test durumudur. Tek bir test senaryosunu otomatikleştirmek için harcanan çabanın miktarı birçok şeye bağlıdır ve büyük ölçüde değişir.

Deneyimli otomatörler, genellikle testi manuel olarak çalıştırmak için gereken çabanın 2 ila 10 katı gerektiğini bildirir ve ara sıra raporlar bunun manuel test çabasının 30 katına kadar çıktığını söyler.

Bu nedenle, manuel olarak yarım saat süren bir test senaryosunun otomatikleştirilmesi 1 ila 5 saat arasında sürebilir, ancak 15 saate kadar da sürebilir. Otomatikleştirmeye başladığınızda, bir testi otomatikleştirmenin, manuel olarak çalıştırmaya göre en az beş kat daha uzun sürmesini bekleyin.

Bir test senaryosunu otomatikleştirmek için gereken çaba miktarını etkileyen şeylerden bazıları şunlardır:

» Kullanılan araç. Araçlar, otomatikleştirilmiş testler oluşturmayı kolaylaştırmak için tasarlanmış çeşitli kolaylıklar ve özellikler sağlar ve test uzmanlarının kayıt sırasında testin yeniden oynatılırken nasıl davranması gerektiği konusunda daha fazla belirlemesine giderek daha fazla olanak tanır.

« Test otomasyonuna yaklaşım. Otomatikleştirilmiş testler oluşturmak için kullanabileceğimiz birkaç farklı yaklaşım vardır, ancak çoğu kişinin kullandığı ilk yaklaşım manuel olarak gerçekleştirilen testi kaydetmek ve ardından bu kaydı yeniden oynatmaktır.

Diğer yaklaşımlar, kaydedilen komut dosyalarını değiştirmek veya komut dosyalarını manuel olarak hazırlamak için ek çaba gerektirir. Bu başlangıçta daha uzun sürse de, fikir yeni testlerin uygulanmasını kolaylaştırmak ve bakım maliyetlerini azaltmaktır.

» Test otomatının deneyim düzeyi. Açıkçası, bir test aracını kullanmaya çok aşina olan kişiler, onu daha hızlı ve daha az hatayla kullanabilecektir. Ayrıca iyi çalışmayan uygulamalardan kaçınabilmeli ve işe yarayanlara konsantre olabilmelidirler.

” Çevre. Test edilecek yazılımın, test için tam olarak çoğaltılmasının zor olduğu belirli ortamlarda çalıştığı durumlarda, testi otomatikleştirmek daha zor olabilir. Örneğin, gömülü yazılımlar ve gerçek zamanlı yazılımlar, ticari olarak temin edilemeyen özel araçlar veya özellikler gerektirebileceğinden özellikle zahmetlidir.

» Test edilen yazılım. Toplu programlar gibi kullanıcı etkileşimi olmayan yazılım uygulamalarının testlerinin otomatikleştirilmesi, yürütüldükleri ortamın yeniden üretilebilmesi koşuluyla çok daha kolaydır. Bunun nedeni, kullanıcı etkileşiminin ‘programlanmış’ olması gerektiğidir ve bu çok fazla iş gerektirebilir.

Bu kayıt altına alınabilse de uzun vadede uygun maliyetli bir çözümle sonuçlanmamaktadır. Bir toplu programın kullanıcı etkileşimi yoktur, ancak çağrıldığında veya yürütme sırasında dosyalardan veya veritabanlarından okunduğunda kendisine iletilen bilgilerle denetlenir.

Testi ve özellikle otomatik testi daha zor hale getirebilen yazılım uygulamalarının birçok yönü de vardır. Yazılım uygulamalarını tasarlarken dikkate alınması gereken birçok test sorunu vardır.

Ve genellikle, otomatikleştirme testini yapacak veya bozacak olan, yazılımın kendisinin tasarımıdır.

• Mevcut test süreci. Testi otomatikleştirirken, açıklandığı gibi test sürecini oluşturan beş aktiviteden bazılarını (test koşullarının belirlenmesi, test durumlarının tasarımı, testleri oluşturma, yürütme ve beklenen sonuçların gerçek sonuçlarla karşılaştırılması) otomatik hale getiriyoruz. Bunun sonuçları bir sonraki tartışma noktamız.

Mevcut test sürecinin, testi otomatikleştirmek için gereken çaba üzerindeki etkisi çok büyüktür. Test senaryoları belgelenmemişse ancak test uzmanları bunları gerektiği gibi oluşturuyorsa, test senaryolarının otomatikleştirilmesi, bunların tasarlanmasını da içerecektir. Diğer uçta ise, test durumları her girdi ve karşılaştırma not edilecek şekilde çok ayrıntılı olarak belgelenirse, bunları otomatikleştirmek daha az çaba gerektirecektir.

Aşağıdaki alt bölümlerde, test sürecinin üç geniş kategorisini açıklıyoruz: test senaryolarının tasarlanmadığı veya belgelenmediği geçici test, test senaryolarının belgelendiği ancak tüm detayların belirtilmediği belirsiz manuel komut dosyaları ve her girdinin ve karşılaştırmanın not edildiği ayrıntılı kılavuz metinleri söz konusudur. Kendi test süreçleriniz, aşağı yukarı bu kategorilerin bir veya daha fazlasına uymalıdır.

The post Test Otomasyonunun Tekrarı first appeared on Akademi Delisi (Tez Yaptırma).