Sayfa 65

Bu yazımızda son yıllarda giderek önemi artan yazılım doğrulama konusuna giriş yapacağız. Yazılım testi konusundaki temel problemlerden ve tekniklerden bahsedeceğiz.

Yazılım Doğrulama nedir.

Bu konuda pek çok değişik tanım bulmak mümkün. Bazı tanımlar işin teknik tarafına yoğunlaşırken, kimi tanımlar ise konunun yönetimsel tarafına değiniyor. İki örnek tanıma bakalım.

Yazılım Doğrulama bir programın spesifikasyonlarında anlatıldığı şekilde davranıp davranmadığını sınama aktivitesidir.

Yazılım Doğrulama, bir yazılım projesinin zamanında ve bütçe dahilinde, ölçülebilir olarak hedeflenen spesifikasyonlara doğru ilerlemesini sağlayan aktiviteler bütünüdür.

Her iki tanımda da ortak olan bazı öğeler olduğunu görebilirsiniz. Dikkatinizi çekmesi gereken belki de en önemli nokta test edilen programın bir spesifikasyonu olması gerektiği. Yani doğrulamayı yapan kişilerin programı neye göre doğruladıklarını bilmeleri gerekir. Programın ne yapmayı vaad ettiğini bilmeden, vaad ettiği şeyi yapıp yapmadığını doğrulamak mümkün değildir. Spesifikasyonlara bundan sonra kısaca Spek diyeceğiz.

Doğrulama Türleri

Yazılım doğrulama çabası farklı türlerde testlerin yapılmasıyla yürütülür. Değişik amaçları olan farklı türlerde testler programınızın farklı yönlerden doğrulanmasına yardımcı olur ve kalitesinin artmasını sağlar

Kapalı Kutu Testleri

Eğer yazdığınız yazılımı kapalı bir kutu olarak düşünür ve sadece Spekte belirtilen davranışları test etmeye çalışırsanız kapalı kutu testleri yapıyorsunuz demektir. Genelde kapalı kutu testleri, sadece test edilen yazılımın arayüzünü kullanarak sisteme çeşitli girdiler verip, sistemin beklenen şekilde davranıp davranmadığına bakarlar. Bu arayüz bir programında penceredeki düğmeler, text alanları vs olabilir. Bir konsol programında verilen opsiyonlar olabilir. Bir kütüphane için API olabilir. Eğer programınız harddiskten bir data dosyası kullanıyorsa o dosya olabilir. Veya Network haberleşmesi yapan bir programa gelen network paketleri de "arayüz"deki girdiler olabilir. Kapalı kutu testi yaparken hep böyle girdiler hazırlayıp sisteme verir, ve sistemin verdiği cevaba bakarız. Bu girdileri hazırlarken nelere dikkat etmemiz gerektiğine birazdan değineceğiz.

Şeffaf kutu testleri

Çoğu zaman sadece kapalı kutu testleri yapmak yeterli olmayacaktır. Özellikle programınız dar bir arayüze sahip olmasına karşin çok karmaşık işlemler yapıyorsa (ki çoğu zaman programlarımızı tasarlarken böyle olmasını hedefleriz) mutlaka şeffaf kutu testleri de yapmak gerekir. Bu testleri hazırlarken sisteminizin içinde yer alan algoritmaları saklanan bilgileri vs dikkate alarak hareket edersiniz. Bunun nasıl olduğunu da birazdan anlatacağız.

Zorlayıcı Testler

Özellikle projeniz bir miktar ilerledikten sonra, yazdığınız programın ağır yükler altında nasıl davrandığını görmek isteyebilirsiniz. Örneğin network üzerinden çalışan bir sunucunun, çok fazla sayıda istemci olduğunda nasıl davrandığını test etmek, veya bir data dosyasını inceleyen programınıza devasa büyüklükte dosyalar vermek, bu sınıfa giren testlerdir. Bu yazımızda bu testlere değinmeyeceğiz.

Performans testleri

Çoğu zaman speklere programınızın performansı ile ilgili vaatler konabilir. Örneğin programın yakalamayı hedeflediği frame rate veya kullanıcının düğmeye basması ile ekrana menünün çıkması arasındaki maksimum süre gibi hedefler olabilir. Bazı sistemlerde bunlar hayati önem de taşıyabilir. Bu yüzden programın performans hedeflerini tutturabildiğini doğrulamak için çeşitli testler yapılabilir. Bu testler genellikle sistemde bulunan çeşitli zamanlayıcıları kullanarak, iki olay arasındaki zaman farkını ölçüp istenen değerin altında kalıp kalmadığını kontrol ederler.

Hataların

geri gelmesini önleme testleri

Çok önemli bir test grubu da budur. Genelde programın geliştirme aşamalarında pekçok hata ortaya çıkar. Bulunan hatalar geliştiriciler tarafından giderilmeye çalışılır. Fakat çok sık yaşanan bir problem, bazı hataların düzeltilmesine rağmen tekrar tekrar su yüzüne çıkmasıdır.

Bunun sebebi genellikle, bir geliştiricinin bir hatayı düzeltirken, daha önce yapılan bir düzeltmeyi bozabilmesi ve eski bugların yeniden ortaya çıkmasına sebep olmasıdır.

Bu yüzden, genellikle düzeltilen her hata için, o düzeltmeyi doğrulayan bir test hazırlanır. Ardından bu test, böyle diğer bütün testlerle beraber grup olarak periyodik aralıklarla çalıştırılır. Genellikle bir grup testin her gün çalıştırılması otomatize edilir. Böylece eğer bir geliştirici kodda yanlışlıkla eski bir hatayı geri getirecek bir değişiklik yaparsa, bu durum hemen bir gün içinde otomatik testlerce yakalanır. Böylece projenin hep ileri doğru gitmesi sağlanır.

Veri Bozma Testleri

Son olarak değineceğimiz test türü de veri bozma testleri. Bu testlerle, genelde bir programın girdi olarak aldığı veriler rastgele veya belli kurallara bağlı olarak bilinçli olarak bozulur ve sisteme verilir. Sistemin bu koşullarda, bozuk veriyi zarif bir şekilde (yani göçmeden) reddetmesi veya bazı küçük hataları düzeltebilmesi isteniyor olabilir. Bu konuda beklentiler her ne ise (bu beklentiler de spekte olmalı), bu beklentilerin gerçekleşip gerçekleşmediği de bu testlerle sınanabilir.