Test otomasyon

Yazılım test etmede, test otomasyonu önceden tahmin edilmiş sonuçlarla gerçek sonuçların karşılaştırılması ve testlerin koşulmasını kontrol etmek için(test edilmiş yazılımdan farklı olan) belirli yazılımın kullanılmasıdır. Test otomasyonu tekrar eden fakat çoktan test etme süreçlerinde yer almış gerekli testlerin otomatikleştirebilir veya manuel olarak koşulmasının zor olacağı testleri de içerebilir. Test otomasyonları sürekli paket dağıtımı veya sürekli test etme için kritik öneme sahiptir.

Genişletilmiş düşük-seviye arayüz regresyon test etme benzeri yazılım test etme görevleri, gibi görevleri manuel olarak gerçekleştirmek zahmetli olabilir veya çok zaman alabilir. Ek olarak, manuel yaklaşım bazı kesin kusurları ortaya çıkartmada her zaman etkili olmayabilir. Test otomasyonu bu tip kusurları bulmada etkili test etme tiplerini mümkün kılar. Bir kez otomatikleşitirlmiş testler geliştirildiğinde çabucak ve tekrarlı bir şekilde çalıştırılabilir. Çoğu kez, sürdürülebilirlik sürecinin uzun olduğu yazılım ürünlerinin regresyon testlerinde maliyet etkili bir metot olabilir.Uygulamanın yaşam süreci üzerinde küçük bir ekleme bile önceden çalışmakta olan özelliklerinin bozulmasına yol açabilir. Birçok test otomasyon yaklaşımı vardır bununla birlikte aşağıdakiler geniş alanda kullanılan genel yaklaşımlardır:

• Grafiksel kullanıcı arayüzü test etme. Bu test etme yapısı fare tıklaması, klvye tuşlaması gibi kullanıcı arayüzü olaylarını üretebilir ve kullanıcı arayüzündeki değişiklikleri programın doğru davranışlar ürettiğini gerçeklemek için gözlemleyebilir.
• Api Test etme. Bu test etme yapısı test altındaki davranışı gerçeklemek için uygulamaya özel bir programlama arayüzü kullanır. Tipik olarak API test etme uygulamayla beraber kullanıcı arayüzünü bütünüyle ele alır. Çeşitli girdi argümanlarıyla sonucun doğruluğunu gerçeklemek için genel bir arayüz üzerinden, Sınıfları, modülleri veya kütüphaneleri test edebilir.

Test otomasyon araçları pahalı olabilir ve genellikle manuel test etme ile birlikte işletilir. Test otomasyonu uzun dönem içinde maliyet-etkin olabilir özellikle tekrar eden resgresyon testlerinde kullanıldığında maliyet etkilidir.

Test mühendisliği veya Yazılım test teminatı otomatikleştirilmiş test etmede, kişi yazılım kodlama yeteneğine sahip olmalıdır çünkü test hususları kaynak kod biçiminde yani çalıştırıldığında testin bir parçası olan (assertions) sonuçlara göre çıktı üreten biçimde yazılır.

Test hususlarını otomatik olarak üretmenin bir yolu test hususu üretimi için sistemin modelini kullanarak model tabanlı test etmeyi kullanmaktır, fakat araştırma alternatif metodolojiler üzerinde devam etmektedir. Bazı test hususlarında model tabanlı yaklaşım düz yazı İngilizcesindeki otomatikleştirilmiş iş test hususlarını oluşturmak için teknik olmayan kullanıcılara imkân tanır böylece birden fazla işletim sisteminde, tarayıcılarda ve akıllı cihazlarda test hususlarını çalıştırmak için herhangi bir programalama becerisi gerekmez. Gerçekten otomasyon ihtiyacı test etme veya geliştirme de önemli kararlar olsa bile, otomatikleştirmeyi yapacak takım Ne otomatikleştirilir, ne zaman otomatikleştirilir sorularının cevabını bilmelidir. Otomasyon için ürünün doğru özelliklerini seçmek geniş çapta otomasyonun başarısını belirler. Stabil olmayan veya sürekli değişen özelliklerin otomasyonundan kaçınılması gerekmektedir.

xUnit yapısı(mesala JUnit ve NUnit) gibi yapıların yazılım geliştirmesinde büyüyen bir trend olduğunu görmekteyiz, bu yapılar çeşitli koşullar altında kodun belirli bölümlerinin beklendiği gibi çalıştığını belirlemek için birim testlerin yürütümünü gerçekleştirir. Test hususları programın beklendiği gibi çalıştığını doğrulamak için programda yürütülmesi gereken testleri içerir. Birim test etme kullanan Test otomasyonu çoğunlukla çevik yazılım geliştirmede(Test driven development olarak da bilinir.) kullanılan anahtar bir özelliktir. Birim tesleri kod yazılmadan önce fonksiyonelliği tanımlamak için yazılır. Bununla birlikte bu birim testleri geliştirilir ve kodlama evresinde iken genişletilir. Sadece tüm istenen özellikler için tüm testler geçtiğinde kod tamamlanmış olarak düşünülebilir. Bunu destekleyen fikir manuel keşif ile test edilen konudan daha az maliyetli ve daha güvenilir bir yazılım üretilmesidir. Daha güvenilir olduğu düşünüldü çünkü kod kapsamı daha iyi ve şelale yazılım geliştirme sürecindeki gibi kodlamanın sonunda bir kez çalıştırılmasından her geliştirme evresinde sürekli çalıştırılması daha iyidir. Geliştiriciler değişiklik yaptıklarında hemen kusuru keşfederler ve kusuru düzeltmek daha az maliyetlidir. Son olarak kod iyileştirme konusunda, kodu daha az veya hiç kod duplikasyonu olmadan taşınmasında daha güvenlidir fakat yeni kusurlar bulmak daha az olasıdır.

Çoğu test otomasyonu aracı kullanıcı aksiyonlarını etkileşimli olarak kaydetmek ve birden çok kez tekrarlamak için kullanıcılara kayıt ve yeniden oynatma özellikleri sağlar. Bu yaklaşımın avantajı çok az yazılım geliştirme gerektirir ya da hiç gerektirmez. Bu yaklaşım güvenilirlik ve sürdürülebilirlik problemlerinin birçoğunu ortaya çıkarır. Bir butonu etiketleme veya diğer bir pencereye taşıma testin kaydını gerektirebilir. Kayıt ve yeniden oynatma genellikle istem dışı aktiviteler veya doğru olmayan bazı aktivitelerinde kayıtlarını ekler.

Web sitelerini test etmek için bu tip araçlar bir alternatiftir. Burada arayüz web sayfasıdır, bununla bilrikte bu gibi yapılar HTML yi yorumladığı için tamamen farklı tekniklerden yararlanabilir ve Windows API olayları yerine DOM olaylarını dinleyebilir. Başlıksız tarayıcılar veya Selenium Web Driver tabanlı çözümler bu amaç için normal bir şekilde kullanılabilir. Bu tip test otomasyon aracının diğer bir çeşidi mobil uygulamaları test etmek için olan araçlardır. Bu tip araçlar farklı boyutlarda, çözünürlükte ve işletim sistemlerine sahip olan mobil telefonlarda çok kullanışlıdır. Bu çeşit için bir yapı(Calabash frameworkü) mobil cihazlarda aksiyonları örneklemek için ve aksiyonların sonuçlarını toplamak için kullanılabilir. Diğer bir çeşit script-less test otomasyon aracıdır ve kayıt, yeniden oynatma kullanmaz fakat Application Under Test(AUT)(Test altındaki uygulama) için bir model inşa eder ve sonra kullanıcının basitçe test parametrelerini ve koşullarını düzenleyerek test hususlarını oluşturmasını sağlar. Bu herhangi bir script becerisi gerektirmez fakat script yaklaşımının tüm esnekliğine ve gücüne sahiptir. Test hususu sürdürülebilirliği kolaydır çünkü hiçbir kod sürdürülebilirliği ve yazılım nesnesinin değişitirilmesi gerekliliği yoktur ve değiştirildiğinde kolayca öğrenilebilir ve eklenilebilir. Herhangi bir GUI tabanlı yazılım uygulamasına uygulanabilir. Problem AUT(Test altındaki uygulama) değiştiğinde sürekli olarak onarılması gereken test scriptin kullanılarak AUT gerçekleştiriminin yapılmasıdır.

API test etme GUI tabanlı otomasyon test etmenin oluşturulması ve sürdürülebilirliğinin zorluğu yüzünden yazılım tester ları tarafından kullanılır. Fonksiyonellik, performans ve güvenlik için beklenilenin karşılanıp karşılanmadığını belirlemek için entegrasyon test etmenin bir bölümünde doğrudan APIlerin test edilmesini içerir. API ler GUI ye sahip olmadığından, API test etme mesaj katmanında işletilir. API test etme API hizmetleri uygulamanın mantıksal katmanına temel arayüz olduğundan kritik olarak göz önüne alınır. Çünkü GUI testlerinin yazılım paketlerinin hızlı teslimi ve sürekli değişen çevik yazılım geliştirme konularında sürdürülebilirliği zor olmaktadır.

Yazılım dağıtım sürümüne ilişkin iş riskleri üzerinde anlık geri bildirim sağlamak için yazılım dağıtım iş hattının bir parçası olarak otomatikleşitirilmiş testlerin yürütüm sürecidir. Sürekli test etme için aşağıdan yukarıya gereksinimlerin gerçeklenmesinden veya kullanıcı hikâyelerinin iş hedeflerine ulaşmasıyla ilişkili sistem gereksinimlerinin değerlendirilmesine kadar geniş bir alanda değerlendirilebilir.

Test etme araçları ürün kurulumu, test veri oluşturmasını, GUI etkileşimini, problem tespit etme gibi A dan Z ye tüm testlerin otomatikleştirilmesini gerektirmeyen durumlarda bile otomatikleştirmeye yardımcı olabilir.

Test otomasyon dğünüldüğünde aşağıdaki popüler gereksinimlerin yerine getirilmesi gerekir:

• Platform ve işletim sistemi bağımsızlığı
• Veri sürdürülebilirlik yeteneği(girdi verisi, çıktı verisi, Metadata)
• İyileştirilebilir raporlama(DB Access very tabanı, Cyristal Reports)
• Kolay debug ve loglama.
• Kullanıcı dostu versiyon kontrolü- minimal binary dosyalar.
• Genişletilebilir ve uyarlanabilir (Diğer araçlarla entegre olabilen açık kaynak API ler.)
• Ortak sürücü(mesala java geliştirme ekosistemi, ANT veya Maven ve popular geliştirme ortamları.) Bu testlerin geliştirici iş akışlarıyla entegre edilmesini mümkün kılar.

Test otomasyon yapısı belirli bir ürünün otomasyon kurallarını ayarlayan entegre edilmiş bir sistemdir. Bu sistem fonksiyon kütüphanelerini, test veri kaynaklarını, nesne ayrıntılarını ve çeşitli yeniden kullanılabilir modülleri entegre eder. Bu bileşenler iş süreçlerini temsil etmek için birleştirilmeye ihtiyaç duyan küçük bina blokları gibi davranır. Bu yapı otomasyon için sarf edilen gücü basitleştirir ve test otomasyonuna bir taban sağlar. Otomatik yazılım test etmeye destek sağlayan varsayım, kavramlar ve araçların yapısal(framework) avantajı, sürdürülebilirliğinin düşük maliyetli olmasıdır. Eğer herhangi bir test hususunda değişiklik varsa o zaman sadece test hususu dosyası güncellenmeye ihtiyaç duyar ve sürdüren script ile başlangıç scripti aynı kalır. İdeal olarak uygulamanın değişmesi durumunda scriptin güncellenmeye ihtiyaç duymaması gerekmektedir. Doğru bir yapı(framework)/scripting tekniği seçmek düşük maliyetli sürdürülebilirlikte çok yardımcı olur. Test script yazmaya ilişkin maliyetler, geliştirme ve sürdürülebilirlik için harcanan eforla ilişkilidir. Test otomasyon boyunca kullanılan script yazma yaklaşımları maliyet etkilidir.

Genel olarak kullanılan çeşitli yapı(framework)/script yazma teknikleri:

1. Liner(yapısal kod, genellikle kayıt ve yeniden oynatma benzeri araçlar tarafından ütretilir.)
2. Yapısal(control yapılarını kullanır-tipik olarak if-else, switch, for, while şart ifadeleri)
3. Data-driven (very veritabanı, word excel türü dosyalar içinde testlerin dışında tutulur.)
4. Anahtar sözcük sürdürülen.
5. Hibrit(2 veya daha fazla örüntünün kullanıldığı.)
6. Çevik otomasyon yapısı(framework)

Test etme yapısı(framework) şunlar için sorumludur:

1. Beklentileri ifade etmek için kullanılacak formatı tanımlamak.
2. Test altındaki uygulamanın sürdürülmesi veya uygulamanın testi için mekanizma oluşturmak.
3. Testlerin koşulması
4. Sonuçların raporlanması.

Test otomasyon arayüzü birden çok test etme araçlarının ve test altındaki uygulamanın Sistem/entegrasyon testi için sağlanan yapının(framework) birlikte çalışabilirliği için tek bir çalışma arayüzü sağlayan platformlardır. Test otomasyon arayüzünün hedefi sürecin işlenmesinde kodlamaya geçmeden iş kriterine testleri eşleyebilmek için basitleştirme sağlamaktır. Test otomasyon arayüzünden test scriptlerinin sürdürülebilirliğinin esnekliğini ve verimliliğini geliştirmesi beklenir.

Test otomasyon arayüzü aşağıdaki ana modülleri içerir:

• Arayüz motoru
• Arayüz ortamı
• Nesne havuzu

Arayüz motorları Arayüz ortamının tepesine inşa edilir. Arayüz motoru bir ayrıştırıcı ve test koşucusu içerir. Ayrıştırıcı belirli script dili içerisindeki nesne havuzundan gelen nesne dosyalarını ayrıştırır. Test koşucusu test koşum takımı kullanarak test scriptlerini çalıştırır.

Nesne havuzları test altındaki uygulamayı keşfeden test etme aracı tarafından tutulan UI/Uygulama nesne verisinin koleksiyonudur

windows ve web otomasyon araçları gibi araçlar özel olarak belirli test ortamlarında çalışmak için tasarlanırlar. Araçlar bir otomasyon süreci için sürücü gibi hizmet ederler. Bununla birlikte bir otomasyon yapısı(framework) belirli bir görevi gerçekleştirmek için değildirler fakat onun yerine belirlenmiş davranışta görev alabilen farklı araçlara çözümler sağlayan bir alt yapıdır. Bu otomasyon mühendisi için ortak bir platform sağlar. Çeşitli yapı(framework) tipleri vardır. Bu yapılar çalıştıkları otomasyon bileşenlerine göre sınıflandırılırlar.: 1- Veri sürdürümlü test etme 2- Modüler sürdürümlü test etme 3- Anahtar sözcük sürdürümlü test etme 4- Hibrit test etme 5- Model tabanlı test etme 6- Kod sürdürümlü test etme 7- Davranış sürdürümlü test etme.

• Çanakkale OnSekiz Mart Üniversitesi Bilgisayar Mühendisliği22 Ekim 2013 tarihinde Wayback Machine sitesinde arşivlendi.