| Test Belgesi | ||
Önder TUNÇALP Öz Test Planı Proje hedefleri doğrultusunda yazılımın test edilebilirliğini bir checklist halinde genelde bazı karakteristiklerin izlenmesi olarak ele alınmıştır. Bunlar; Operasyonelik (işleyen), Görünürlük, Denetlenebilirlik, Ayrıştırılabilirlik, Basitlik, Dengelilik, Anlaşılabilirlik olabilir. Netice olarak tunç/dükkan projesinin yönetimi sözkonusudur. Burada tunç/dükkan projesi yazılım problemlerinde ve üretiminde ölçüm veya test yapmakla ortaya çıkması istenen işlevin ne kadar zaman ve işgücüne mal olabileceğini kestirmeye yaramaktadır. Böylece proje yönetilebilir kılınmaktadır. Derslerde de değinildiği gibi kullanıcı istek ve ihtiyaçlarının öngörülmesi çok zor olduğu görülmüştür. İstek ile ihtiyaçlar her an değişmektedir. Tunç/dükkan projesiyle www ortamında bir inşaat malzemeleri e-ticareti hedeflenmektedir. Klasik anlamda bu piyasada her türden piyasa esnafı, bayilikleri teşkilatlı veya teşkilatsız olarak bu piyasa ortamında faaliyet halindedir. Tunç/dükkan var olan bu ilişkiler içinde kendine en uygun ve saygın bir yeri hizmet ve güvenilirlikte rekabet ederek var olabilir. Projenin en somut hedefi ve güvenilen noktası www ortamının sağladığı olanaklar ile yukarıda özetlenen karekteristiklerin denenmesi ile elde edilecek güven duygusudur. Ayrıca bu aktivitenin daha çok kullanıcının www ortamındaki arama ve mukayese etme gayretine bağlı olduğu hususu çok açıktır. Teste dair aşağıda daha kapsamlı bilgi verilmiştir. Test Edilecek Modül Gruplarının (Prosedürünün) Tarifi Kullanıcı arayüzü çatısını bir önceki raporumuzda tunç/dükkan bağlantısı olarak ham bir şekilde görebilirsiniz. Kullanıcı arayüzünden gelişen veri akışı altarayüzlerle tesis edilen altbağlantılar şeklindedir. Yukarıda açıklanan (ara ve alt) yüzler ile bağlantılar sıcak ve arkadaşça bir ortamda interaktif tutulmaya çalışılacaktır. Bu ortam tutarsa, yenikullanıcılar giderek tescilli kullanıcılar haline gelecek ve Login isimleri, gelişen bayilikler "agent communication source" java appletleri olarak java paketi içinden tesis edilecektir. Böylece tunç/dükkan vitrini zamanla ikiye ayrılarak "yenikullanıcılar.html" ve "kayıtlıkullanıcılar.html" olarak ikiye ayrılacaktır. Buraya kadar "Black Box" testleri ile fonksiyonel ve operasyonel olarak arayüzler test edilmekte verimlilik sağlanmaktadır. Login ismi ile ikinci.html ye daha hızlı girilip alışverişi hemen gerçekleştirmek mümkün olabilmektedir. Aynı işlem bayi ve bayiliklikler için de geçerlidir. Yeni bayilik ve tesis edilmiş bayilik olarak. Böylece yenilerin tunç/dükkanı tanımak için geçirdikleri zamanı tescilliler tasarruf etmiş ve canları sıkılmadan, direk amaçlarına ulaşmış olmaktadırlar. Burada mantıksal testler ön plana çıkmakta "White Box" testleri ve Akış Diyagram ve Patikalarının izlendiği testler kullanılmaktadır. Tunç/dükkan başlangıç olarak vitrin ve yeni kullanıcılar, yeni bayiler ile işe koyulmaktadır. Yani bu arayüzler ile başlayıp, bilahare diğer arayüzleri tesis edecektir. Burada amaç kompleks yani karmaşıklıktan basit yöne bir kaçışın bilerek tercih edilmesidir. Proje tutunarak gün be gün kompleks/karmaşık ilişkilere doğru adım adım gelişecektir. Bu aşamada önceki raporlardan bu yana bazı problemler ortaya çıkmıştır. Özellikle güvenlik problemlerini çözme hususu da başlangıçta bilerek karmaşıklıktan kaçınmak üzere bir süre kontrollu bir ihmale uğrayacaktır. Bu sırada işlem güvenliği açısından basit anlamda eksiklik e-mail yoluyla teyit yani test yöntemi olarak sağlanacaktır. Daha sonra tescilli kullanıcıların belirmesi ve artması ile güvenlik problemlerinin çözümü CGİ programlama ile C kullanılarak halledilecek ve böylece yetkili (tescilli) kılınmamış kullanıcıların önemli alış-veriş dosyalarına girmeleri önlenmiş olacaktır. Java appletleri ile tunç/dükkan çevre imkanları çelişkisi nedeniyle CGİ ve C tercih edilmiştir. Arzu edilen çevre esnekliği bulunabilirse aynı işlemler Java ile de yapılmak istenmektedir. Gerçek Test Sonuçları Yapılan testler ile bir çok hata giderilmiş olup halen de devam etmektedir. Netice olarak yazımı bitirilen arayüz altbağlantıları yada modüllerin işlerliği teste tutulmakta işlevleri ve yukarıdaki karakteristikleri yerine getirdiği görülerek bütünleştirilmektedir. Daha sonra da bütünü beraber test edilmektedir. Bütünleştirme ve test işlemlerinin içiçe yapılması hata ve sistem karışıklığını en aza indirmektedir. Başlangıçtan bu yana izlenen döngü Kodlama, Test, Bütünleştirme, Test ve tekrar Kodlama olarak sunumdan hatta İde-A'dan sonrada devam edecektir. Test işlemleri; Birim testi (soyutlanmış yapıtaşlarının doğru çalışması için yapılmakta), Modül testi (bütünleşen yapıtaşlarının denenmesi), Alt-Sistem testi (bütünleşen modüllerin bağımsız testleri neticesinde arayüz hataları ortaya çıkmakta ve arayüz hatalarına yönelik testler yapılmaktadır), Sistem testi (üst düzey bileşenleri,linkler ve etkileşimlerden çıkacak hatalardan arınılıyor ve ihtiyaçların doğru yorumlandığı mantık testleri yapılıyor). ALFA TESTİ yani KABUL TESTİ tunç/dükkan proje sisteminin son testi olacak ileride sistemin BETA TESTİ kullanıcı testi olarak görülmesi amaçlanmaktadır. Sisteme yapılan her eklemeden sonra aynı sırada tüm testler tekrar tekrar yapılmakta ve hata nispeti azalan bir eğridedir. Çünkü ekleme neticesinde yapılan bütünleştirme sonrasında zincirleme etkiler ortaya çıkmaktadır. Bağımlılığın fazla olduğu modüllerde yapılan testler sonrasında hata sayısında azalma beklenirken artışlar gözlenmiştir. Buralarda bazı kabuller yapılarak bilerek dahil eden ihmal kabülleri yapılmıştır ki buna referanslar obtimizasyon yapma gereği diyolar. Böylece hatalar azalan bir trende girmiştir. Ayrıca ihtiyaç belirtiminin denendiği Geçerlilik testi ve ihtiyaçların doğru uygulamasının denendiği Sağlama testide yapılmaktadır. Hata neticelerine dair somut gösterge sunum aşamasında belli olacaktır.
|