Arayüz Tabanlı Test Oluşturma
![Ticari Yazılım Geliştirme](https://akademidelisi.net/wp-content/uploads/2023/02/al.jpeg)
Arayüz Tabanlı Test Oluşturma
Gösterilen arabirim tabanlı bir test girdi oluşturma aracı, GUI veya web uygulaması gibi iyi tanımlanmış bazı arabirimlere dayalı testler oluşturabilen bir araçtır. Bir ekran çeşitli menüler, düğmeler ve onay kutuları içeriyorsa, bir araç her birini ziyaret eden bir test durumu oluşturabilir.
Örneğin, bir araç, bir onay kutusunun işaretlendiğinde içinde artı işareti olduğunu ve işaretlenmediğinde boş olduğunu test edebilir (benzer şekilde temel testler, diğer grafiksel etkileşimcilerde otomatikleştirilebilir). Diğer örnekler, her bir alanı seçmeyi ve Yardım’ın çalışıp çalışmadığını görmeyi, yalnızca görüntülenen tüm alanlardaki verileri düzenlemeyi denemeyi, yardım metninde ve göstergelerde yazım denetimi gerçekleştirmeyi ve her menü öğesi seçildiğinde bir şeyin açılıp açılmadığını kontrol etmeyi içerir.
Benzer bir işlev, internet ve intranet sayfalarını test etmek için kullanılan araçlarda bulunur. Araç, bir World Wide Web sayfasındaki her bir bağlantıyı etkinleştirebilir ve ardından aynısını, bağlantılı sayfaların her biri için yinelemeli olarak yapabilir.
Arayüz tabanlı bir yaklaşım, bazı kusur türlerinin tanımlanmasında yararlıdır (örneğin, çalışmayan web sayfası bağlantıları tanımlanabilir). Beklenen bir sonuç kısmen üretilebilir, ancak yalnızca çok genel anlamda ve yalnızca olumsuz olarak, yani bir bağlantı olmalıdır (doğru sonuç), kırık değil (yanlış sonuç). Bu tür otomatik test oluşturma, size çalışan bağlantıların gerçekten doğru yere bağlı olup olmadığını söyleyemez.
Dolayısıyla bu yaklaşım, test girdileri (araç tarafından tanımlanan her arayüz öğesi için bir test) üreterek test tasarım etkinliğinin bölümlerini gerçekleştirebilir ve bazı hataların tanımlanmasını sağlayan kısmi bir kehanet olabilir. ‘Yoklama’ testini gerçekleştirmede, yani orada olması gereken her şeyin orada olup olmadığını kontrol etmede çok yararlı olabilir. Bu tür testleri manuel olarak yapmak sıkıcıdır, ancak genellikle kapsamlı bir şekilde yapmak çok önemlidir.
Bu tür araç desteği muhtemelen gelecekte artacaktır ve test uzmanlarını sıkıcı görevlerden kurtarmaya yardımcı olabilir, böylece entelektüel test faaliyetlerini gerçekleştirmek için daha fazla zamanları olur.
Spesifikasyona Dayalı Test Oluşturma
Spesifikasyon tabanlı test araçları, spesifikasyonun araç tarafından analiz edilebilecek bir formda olması koşuluyla, test girdileri ve ayrıca beklenen çıktılar üretebilir. Bu, Şekil 1.8’de gösterilmiştir. Spesifikasyon, iş kuralları gibi yapılandırılmış doğal dil yapıları içerebilir veya durumlar ve geçişler gibi teknik veriler içerebilir. Araçlar, yeterince titiz olmaları halinde, testleri nesne yönelimli belirtimlerden türetebilirler. Bu nedenle, bu araçların bir test kehaneti vardır.
Örneğin, bir giriş alanı için izin verilen aralıklar titizlikle tanımlanmışsa, bir araç geçerli ve geçersiz denklik sınıflarında örnek değerlerin yanı sıra sınır değerleri de oluşturabilir.
Spesifikasyona dayalı bazı araçlar, yapılandırılmış İngilizce spesifikasyonlardan veya neden-sonuç grafiklerinden testler türetebilir. Bu, belirsizlikler ve eksiklikler gibi bazı spesifikasyon kusurlarını tanımlayabilir.
Spesifikasyona dayalı bir yaklaşımın bir yararı, testlerin yazılımın ne yaptığından çok ne yapması gerektiğine bakmasıdır, ancak mevcut araç tarafından incelenebilir spesifikasyonun yalnızca sınırlı kapsamı dahilindedir.
Bir spesifikasyondan test senaryoları türetmek ne kadar sıkıcı olursa, bu tür bir araç için potansiyel o kadar yüksek olur. Beklenen sonuçlar, saklanan spesifikasyonun gerçekten doğru olduğu varsayılarak, spesifikasyonda saklanırsa üretilebilir.
Otomatik test senaryosu oluşturmanın faydalarının özeti:
» her menü öğesinin etkinleştirilmesi veya bilinen veri aralıklarından sınır değerlerinin hesaplanması gibi test senaryosu tasarımının sıkıcı yönlerini otomatikleştirir;
« kaynaklarına (kod, arayüz veya spesifikasyon) göre eksiksiz bir test senaryoları seti oluşturabilir;
» eksik bağlantılar, çalışmayan pencere öğeleri veya saklanan bir belirtime uymayan yazılım gibi bazı kusur türlerini tanımlayabilir.
Arayüz programlama
Arayüz kullanma
Kullanıcı arayüzü oluşturma
Kullanıcı arayüzü Örnekleri
Programlama Arayüzü Nedir
Arayüz interface Nedir
GUI tasarımı
C# interface Örnekleri
Otomatik test durumu oluşturmanın sınırlamalarının özeti:
• kod tabanlı yöntemler beklenen sonuçları üretmez;
• arayüz tabanlı yöntemler yalnızca kısmen beklenen sonuçları üretebilir;
« kod tabanlı ve arayüz tabanlı yöntemler belirtimi bulamıyor.
» Spesifikasyona dayalı yöntemler, spesifikasyonun kalitesine bağlıdır;
» tüm yöntemler, çalıştırmanın pratik olması için çok fazla test oluşturabilir;
» Testlere öncelik vermek, üretilen testlerin kullanışlılığını değerlendirmek ve hiçbir araç tarafından üretilemeyecek testleri düşünmek için hala insan uzmanlığına ihtiyaç vardır.
Bizim iddiamız, testin entelektüel kısmının otomasyonunun yapılmasının çok daha zor olduğu ve testin daha bürokratik kısmının otomasyonu kadar tam olarak yapılamayacağıdır. Bu kitabın geri kalanında ‘otomatik yazılım testi’nden bahsettiğimizde, test tasarımının veya test girdilerinin oluşturulmasının otomasyonunu değil, test yürütme ve karşılaştırma faaliyetlerinin otomasyonunu kastediyoruz.
Yazılım Testini Otomatikleştirmenin Sınırlamaları
Tüm iyi şeylerde olduğu gibi, hiçbir şey bedelsiz gelmez. Otomatik test her derde deva değildir ve başarabilecekleri konusunda sınırlamalar vardır.
Tüm test faaliyetlerini veya tüm testleri otomatikleştirmek mümkün değildir ve istenmez. Her zaman manuel olarak yapılması otomatik olmaktan çok daha kolay olan veya otomatikleştirilmesi ekonomik olmayacak kadar zor olan bazı testler olacaktır.
Muhtemelen otomatikleştirilmemesi gereken testler şunları içerir:
» Nadiren çalıştırılan testler. Örneğin, bir test yılda yalnızca bir kez yapılıyorsa, o testi otomatikleştirmeye muhtemelen değmez;
» yazılımın çok değişken olduğu yerler. Örneğin, kullanıcı arabirimi ve işlevsellik bir sürümden diğerine tanınamayacak kadar değişirse, otomatikleştirilmiş testleri buna karşılık gelecek şekilde değiştirme çabasının maliyet etkin olması muhtemel değildir;
• sonucun bir insan tarafından kolayca doğrulandığı, ancak otomatikleştirmenin imkansız değilse bile zor olduğu testler; örneğin, bir renk şemasının uygunluğu, bir ekran düzeninin estetik çekiciliği veya belirli bir ekran nesnesi seçildiğinde doğru sesin çalınıp çalınmadığı;
• bir kartı bir kart okuyucusundan geçirmek, bazı ekipmanların bağlantısını kesmek, gücü kapatıp açmak gibi fiziksel etkileşimi içeren testler.
Tüm manuel testler otomatikleştirilmemelidir, yalnızca en iyileri veya en sık yeniden çalıştırılacak olanlar. İyi bir test stratejisi, en azından ilk başta en iyi şekilde manuel olarak yapılan bazı keşif veya yanal testleri1 de içerecektir. Yazılım kararsız olduğunda, manuel test kusurları çok hızlı bir şekilde bulacaktır.
Arayüz interface Nedir Arayüz kullanma Arayüz programlama C# interface Örnekleri GUI tasarımı Kullanıcı arayüzü oluşturma Kullanıcı arayüzü Örnekleri Programlama Arayüzü Nedir