Daha önce artık yavaşyavaş otomasyon yazılarıda yazacağımızı belirtmiştik kısmet banaymış .
Öncelikle basit bir örnek olarak Loginle başlayalım .
Basitce qtp yi açıp yeni test ve recordtusuna basdıkdan sonra explorer la testroot’u login olduğunuzda expert view da atacağı kayıt aşağıdaki gibi olacaktır;
Browser(“Error”).Navigate “http://www.testroot.com/”
Browser(“Error”).Page(“Yazılım Test & Kalite”).Link(“Giriş”).Click
Browser(“Error”).Page(“TestRoot › Giriş”).WebEdit(“log”).Set “User” ( user bilgisi )
Browser(“Error”).Page(“TestRoot › Giriş”).WebEdit(“pwd”).SetSecure “şifre” ( değeri qtp şifrelenmiş şekilde atıyor)
Browser(“Error”).Page(“TestRoot › Giriş”).WebButton(“Giriş”).Click
Peki bu yeterli mi ?
Çok komplike bir siteminiz yoksa sizde uğraşmak istemiyorsanız yeterli. Ancak bu test fonksiyon haline getirip diğer testleriniz için çağırmak istiyorsanız performans ve değişkenler ile bu yapıyı parametrik hala getirmeniz gerekiyor.
Peki bununasıl yaparız?
devamını oku…
Birazda düşünce tekniği olarak bahsetmek istiyorum…
Genel olarak yapılmaya çalışan uygulamalar verilerin birbiri üzerine ilişkilenmesi üzerine kuruludur. Örneğin bu blogda herhangi bir yazı yayınamak için öncelikle kullanıcı kaydı yapılması gerekmektedir. Bu veri tanımlandıkdan sonra yazı yayımlanabilir.
Burda dikkat çekmek istediğim nokta bu temel akış uzerindeki silme ve güncelleme işlemleridir. Genede “Türk Yazılım Yönteminde” genel olarak silme fonksiyonu ilk kez gerçekleştirildiğinde ilişkili diğer veri yapıları gözetilmez. Sildim gitti usuludur. Test açısından temel akışın işlerliğindense silme/güncelleme fonksiyonlarının uyumlu işlemesi daha önemlidir . Örneğin kullanıcı silindiğinde yazdığı yazılar , yaptığı yorumlara ne olacak ?
Hiyerarşik bir veri sisteminde yapılan değişiklilerin üst seviyedeki ilişkili verilere etkileri bence en çok başımıza iş çıkartan durumlardır. Kendi gözlemim olarak hataların %30 bu gibi nedenlerden kaynaklanmakta. tabi Development kısmınada pek suç atamak lazım genellikle bu durumların detayları analizde atlanır.
Yine oldukca baş ağrıtan konulardan biri, bir uygulamanın search /arama özelliğinin testi.
Öncelikle neleri test edebileceğimizi tanımlamamız gerekiyor. Öncelikle uygulamaya özel bir arama özelliğiyse( örneğin bir fiyat aralığı arama özeliği) bu konuların belirlenmesi gerekiyor. Daha sonra aşağıdaki başlıkları göz önünde bulundurulması gerekli.
Arama otorunun doğrululuğu belirlenen kritere göre ürün database’indeki eşleşen kayıtları tam ve doğru olarak getirmesidir.
Bunu için 2 yöntem kullanılabilir
- Karşılaştırma
User interfacede yapılan sorguyu direk olarak databse de yapılan sorgu sonuclarıyla karşılaştırma.
2. Tutarlılık
Eklenen kayıtlarla sorgu sonuclarınızında artması gerekiyor. bir data seti oluşturup , databade verileri ekleyerek sorgu sonuclarınında arttığını görmeniz gerekmekte.
Arama sonuclarını kabul edilebilir zaman aralıklarında döndürülmesi gereklidir. Bu zaman gereksinime göre değişebilir. Performans testi yaparak bu zamanın uygun değerlere çekilmesi gereklidir.
Bu oldukca göz ardı edilen bir konudur.Arama özelliğinin hassasiyeti yapılan sorgulama soncunda sadece istenilen sonuçları getirmesindeki başarısıdır. Örneğin İpod touch aradığınızda sadece beklediğiniz ürünleri getirmesi , “ipod kılıfı , araba şarjı vs… ” sonucların getirilmemesi yada arka sıralara atılmasıdır. Tabiki bu user ın girdiği keyword lerin detayı, searc edilecek database deki verilerin temizliği, uygulamanın kendine has özelliklerine göre değişir. Dolayısıyla test konusunda biraz kafa yormanız gerekecekdir.
Son Yorumlar