Microsoft Visual Studio 2008 Load Agent ile Distributed Load Test
Daha önce performans testlerinden bahsederken Microsoft’un Visual Studio Team Edition’dan söz etmiştik. Bu yazılım sayesinde uygulamalarınızın üzerinde yük (load) test gerçekleştirebiliyorsunuz.
Programın çalışma mantığından kısaca bahsedelim;
Öncelikle test edeceğiniz senaryoyu oluşturuyorsunuz. Bunun için yapmanız gereken tek şey senaryonuzu browser üz bir kere kaydetmeniz. Daha sonra kaydettiğiniz bu senaryoyu belirli kullanıcı sayısı ve süreler ile tekrar tekrar oynatıyorsunuz. Bu durum uygulamanız üzerinde bir yük oluşmasına sebep oluyor. Testler sırasında da uygulamanın çalıştığı makina üzerindeki performans verileri alınıyor. Tüm bu sonuçlar test programınızın test database ine yazılıyor.
Programın çalışma mantığı basit gibi görünse de aslında herbir process üzerinde çalıştığı makinanın kaynaklarını tüketiyor. Bu durum sağlıklı sonuçlar almanızı engelliyor. Microsoft bu durum için test aracına ek bir yazılım öneriyor. Bu yazılım sayesinde “distributed load test” dediğimiz yapıyı oluşturuyoruz. Distributed yapısı aşağıdaki gibidir;
En üstteki ana makina üzerinde Visual Studio Team System 2008 ve SQL Server yüklü olduğunu görüyoruz. Bu durumda testlerin ve senaryoların oluştutulması, testin başlatılması ve test sonuçlarının kaydedilmesi burada gerçekleşir. Bunun dışındaki tüm işlemleri alttaki zone lar yapar. Zone lar ile ana makina controller tarafından brbirine bağlanmıştır. Controller makinası agentlardan aldığı test datalarını ana makinaya ulaştırır. Eğer testlerinizi tek bir lokasyondan yapıyorsanız controller anamakina üzerinde olabilir. Birden fazla lokasyon kullanıyorsanız bu durumda herbir lokasyon için bir controller makinasının olması gerekir. Sistemin en altında bulunan agentlar sanal kullanıcıların yaratılmasını sağlar. Bu şekilde sadece sanal kullanıcı ürettikleri için testler hem daha doğru hemde yüksek kullanıcı sayılarına çıkmanızı sağlar.
Agent makinalarının donanımsal özellikleri ve sayıları çoğaldıkça sanal kullanıcı sayısı da artar. Örneğin agent olarak çift çekirdekli laptoplar kullandığınızda çıkacağınız maksimum kullanıcı sayısı ortalama 200 iken, dört çekirdekli bir server kullandığınızda bu sayı 1000 civarında olabilir. Planlamalar sırasında bütün bu yapıyı düşünmeniz gerekir.
Bu sistemi kurmamızı sağlayan test aracı yani Microsoft Visual Studio 2008 Load Agent için ayrı lisanslama yapılmaktadır. Fakat şu adresten 90 günlük deneme sürümünü indirebilirsiniz.
Bir sonraki yazımda bu aracın kurulumundan bahsedeceğim.
Visual Studio Team Test Repository Değişimi
Visual Studio Team Test edition kurulumunda load test sonuçlarının tutulduğu database’i lokaldeki SQLExpress içerisinde tutar. Burada iki türlü sıkıntı yaşanabilir. Birincisi çoğu developer SQLExpress yerine SQLServer kullanmayı tercih eder. Bu yüzden Visual Studio kurulumunda gelen SQLExress i kurmazlar. Diğer bir sıkıntı siz load test sonuçlarınızı lokaldeki makinanız yerine bir server da tutmak isteyebilirsiniz. Her iki durum için aşağıdaki işlemleri yapmanız gerekmektedir.
1- Öncelikle Visual Studio command line’ı açmamız gerekiyor;
cd n:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE
2- Daha sonra aşağıdaki komutu çalıştırıyoruz;
Sqlcmd -s SERVERNAME -u USERNAME -p PASSWORD -i loadtestresultsrepository.sql
(SERVERNAME kısmına server’ın ismi, USERNAME kısmına sql server kullanıcısı ve PASSWORD kısmına da kullanıcı parolası girilir. Sql server ınız Windows Authentication modunda çalışıyorsa username ve password kısımlarını girmeniz gerekmez.)
3- Bu işlemin ardından ilgili server da test database iniz oluşmuş olur. Daha sonra Visual Studio Team Edition’da Test menüsünün altındaki Administer Test Controllers kısmında ilgili server ve database seçilir.
Artık tüm test sonuçları seçtiğiniz test database inde tutulacaktır.
In: Yazılım · Tagged with: load test, visual studio team system
Windows Service Pack Blocker Tool Kit
Windows işletim sistemleri ile çalışıyorsanız güncellemeler sizi epey oyalıyordur. Özelikle sistemlerinizin kurulu olduğu serverlarda bu güncellemeleri daha da önem taşıyor. Çünkü yapılan güncellemelerin bazıları sisteminizin çalışmasını engelleyebiliyor.
Bir diğer önemli nokta da otomatik olarak yapılan güncellemeler. Microsoft bu durumdan şikayetler almış olmalı ki Windows Service Pack Blocker Tool Ki’i çıkardılar. Bu araç sayesinde güncellemelerin yüklenmesi önleniyor.
Bu aracı aşağıdaki işletim sistemlerinde kullanabilirsiniz;
- Microsoft XP SP3
- Microsoft Vista SP1 & SP2
- Windows Server 2008 SP2
Windows Service Pack blocker Tool Kit’i şu adresten indirebilirsiniz.
In: Haberler, Operating Systems · Tagged with: microsoft, Windows
Fonksiyonel Test (Kara Kutu Test Teknikleri) (2)
Bir önceki yazıda use case / test case dökümanları ve kullanıcı navigasyon testlerinden bahsetmiştim. Bu yazıda kara kuru (black box) fonksiyonel test teknikleri ile devam ediyoruz.
Geçiş ekranı testleri: Bu testler sırasında sayfaların üzerindeki aksiyon butonları kontrol edilir. Örneğin kullanıcı adı ve parolayı girdikten sonra “Giriş” butonuna basarsak sistemin bizi login olduğumuz sayfaya yönlendirmesini bekleriz. Diğerlerinde olduğu gibi bu testlere de başlamadan uygulamada ekran geçişi yaratacak tüm bileşenleri tespit edip bu bileşenler kullanıldığında ne gibi aksiyonlar alınacağını belirlememiz gerekir.
Data akış testleri: Bu testler birbiriyle etkileşimli olan sayfalar arasındaki geçişlerde yapılır. Aşağıda 4 sayfadan oluşan profil oluturma uygulaması ile ilgili örneğe göz atarsak;
Sayfa Yapılacak İşlem Beklenen Sonuç 1 Kullanıcı ad-soyad, email bilgilerini girer, devam butonuna basar Bir sonraki sayfaya geçilir. Bir sonraki sayfada ad-soyad ve email bilgileri read only olarak gelir. 2 Kullanıcı adres, telefon bilgilerini girer, devam butonuna basar Bir sonraki sayfaya geçilir. Girilen tüm değerler read only olarak görülür. 3 Kullanıcı özgeçmiş bilgilerini girer, kaydet butonuna basar Profiliniz oluşturulmuştur sayfasına yönlendirilir
Yukarıdaki örnekte görüldüğü gibi data akış testlerinde, bir sonraki sayfaya geçildiğinde önceden girilen bilgilerin kaybolmaması kontrolleri yapılır.
Rapor ekranı testleri: Rapor ekranları web sayfalarındaki arama sonuç sayfaları gibi düşünülebilir. Burada kontrol etmemiz gereken şey yaptığımız sorgu sonucu doğru sonuçların getirilmesidir.
Rapor akış testleri: Bu da arama sonuç sayfaları gibi düşünülebilir. Rapor ekranı testlerinden farklı olarak burada sonuçlar için birtakım öntanımlı seçimler yapılır. Örneğin detaylı arama sayfalarında aramanızı daha spesifik olarak yapmanız için sizlerden birtakım ekstra tanımlamalar istenir. Burada önemli olan yapılan bu tanımlar ile ilgili doğru sonuçların getirilmesidir.
Veritabanı yaratma / güncelleme / silme testleri: Bu testleri uygulamanızın ana veritabanı testleri olarak düşünmeyin. Burada anlatılmak istenen şey kullanıcının veritabanı üzerinde yapacağı değişikliklerin test edilmesidir. Bu testlere başlamadan önce mutlaka uygulama üzerindeki hangi adımların veritabanında nasıl değişiklikler yaratacağının belirlenmesidir.
Regression testleri: Genel bir kavram olan regression testleri basit anlamıyla, bulunan tüm hataların düzeltildikten sonra tekrar test edilmesidir. Regression testlerinde bulunan hata ile ilgili aynı senaryo test edilmelidir. Bunun yanında en önemli konulardan biri regression testleri sırasında side effect lerin de kontrol edilmesidir. Bir hata çözülürken onun etkileşimli olduğu diğer hatayı da tetikleyebilir. Buna dikkat etmek gerekir.
Bir sonraki yazıda fonksiyonel testlerde beyaz kutu (white box) test teknikleri ile devam edeceğiz.
In: Yazılım Test · Tagged with: black box, fonksiyonel
Fonksiyonel Test (Kara Kutu Test Teknikleri) (1)
Adım adım test çeşitlerini anlatmaya devam ediyoruz. Bu yazıda Fonksiyonel testleri anlatmaya çalışacağım. Fonksiyonel testlerin temel amacı, uygulamanın ihtiyaçları tam olarak karşılayıp karşılamadığının belirlenmesidir.
Fonksiyonel testler birçok test tekniğinden oluşur. Bu test teknikleri ilk olarak kara kutu (black box) ve beyaz kutu (white box) olarak ikiye ayrılır. Bu yazıda fonksiyonel testlerin kara kutu sınıfına ait tekniklerden bahsedeceğim.
Herşeyden önce yapmamız gereken ilk şey test edeceğimiz uygulama içerisindeki fonksiyonları parçalamak olmalıdır. Örneğin bir web sayfasını test ederken login, logout, arama, navigasyon… gibi fonksiyonları ayrı ayrı test etmemiz bize hataların yerini bulmamızda daha kolaylık sağlayacaktır.
Use case / test case dökümanları: Testler sırasında en çok kullandığımız bu dökümanlar, fonksiyonların belirli durumlarda nasıl davranacağını belirler. Bu dökümanlar hazırlanırken beklenen sonuçların da belirtilmesi gerekir. Örnek olarak aşağıdaki “login fonksiyonu” test caselerine göz atalım;
# Adım Beklenen Sonuç 1 Login butonuna basılır Login ekranı gelir 2 Email adresi yazılır Sadece email formatı kabul edilir 3 Parola girilir Girilen karakterler göserilmez 4 Onay butonuna basılır Email adresi ve parola uyumlu ise login işlemi gerçekleştirilir. Uyumsuz ise hata verilir.
Uygulamamızdaki tüm fonksiyonlar için buna benzer testcase ler yazabiliriz. Buradaki amaç oluşabilecek bütün durumların kontrol edilmesini sağlamaktır. Yukarıda gördüğünüz gibi login fonksiyonunu test ederken aynı zamanda email adresinin valid olması, parola alanında girilen karakterlerin gösterilmemesi, yanlış girilen email veya parola da sayfada uyarı verilmesini de test ediyoruz.
Kullanıcı navigasyon testleri: Uygulamayı kullanan kullanıcılar için iki tip ekran vardır. Bunlar navigasyon ve transaction ekranlarıdır. Navigasyon ekranları uygulama tarafından kullanıcıyı yönlendiren ekranlardır. Örneğin bir sitede dolaşırken login gerektiren bir fonksiyonu cağırdık. Bu durumda bizim login olabileceğimiz bir sayfaya yönlenmemiz gerekmektedir. Navigasyon testlerine başlamadan önce uygulamadaki tüm ekranların hangi durumlarda nasıl davranacağının belirlememiz gerekir. Örnek olarak aşağıdaki durumlara göz atalım;
# Sayfa Beklenen Sonuç 1 Anasayfa Anonim kullanıcı 2 Anasayfa > Email butonu Kullanıcı anonim ise login sayfasına yönlendirilir. Değilse Email sayfasına yönlendirilir. 3 Anasayfa > Haberler Kullanıcı anonim ise haberler sayfasına, loginse kişiselleştirilmiş haber sayfasına yönlendirilir.
Yukarıdaki örnekte görüldüğü gibi her sayfa,anonim ve login olan kullanıcılarda farklılık göstermektedir. Testlere başlamadan önce bu tip bir dökümanın hazırlanması burada oluşacak hataların tespiti için çok önemlidir.
Bir sonraki yazıda kara kutu tekniklerine devam edeceğiz. Şimdilik hoşçakalın…
In: Yazılım Test · Tagged with: black box, fonksiyonel, navigasyon, test, test case
Proje Dökümanları ve Statik Test
Daha önce sizlere 4 test stratejisinden bahsetmiştim. Bu yazıda onlardan biri olan statik testi detaylandırmaya çalışacağım;
Yazılım projelerinde en önemli konulardan biri de dökümantasyondur. Proje döküman ile başlayıp, döküman ile biter. Daha önce yazılım projelerindeki hataların %85inin dizayn aşamasında gerçekleştiğinden bahsetmiştik. Bu aşamada hazırlanan dökümanların da çok dikkatli hazırlanması gerekir. Statik testler bu dökümanların kontrol edilmesini sağlar.
Bununla beraber yazılım projelerinde sadece dizayn aşamasında döküman yazılmaz. Projenin hemen hemen her aşamasında yazılması gereken belirili dökümanlar vardır. Bunlar;
1. Proje yönetim dökümanları
a. Gereksinim dökümanı
b. Proje planı
2. Development dökümanları
a. Proje dökümanı
b. Veri modeli dökümanı
c. Veritabanı dökümanı
d. Teknoloji dökümanı
e. Data-flow diyagramları
f. Proje kodları
3. Test dökümanları
a. Test plan dökümanı
b. Test case dökümanı
c. Test durum dökümanı
4. Kurulum dökümaları
a. Kurulum dökümanı
b. Operasyon ve yönetim dökümanı
5. Son kullanıcı dökümanları
a. Kullanıcı klavuzu
b. Yardım ekranları
Statik testler tüm bu dökümanların kontrol edilmesinden oluşur. Kontroller sırasında bilginin doğruluğundan, döküman düzenine kadar birçok konuda testler yapılır.
In: Yazılım Test · Tagged with: static test, test
Test Plan Dökümanı
Daha önceki yazılarımda teste hazırlık sürecinin öneminden bahsetmiştim. Teste hazırlık sürecinde ne kadar iyi hazırlanırsanız, testleriniz de o derece başarılı olur. Bu yazıda teste hazırlık sürecinin en önemli çıktılarından biri olan test planı dökümanından bahsedeceğim.
Test plan dökümanı, yazılım projelerinin iş planı dökümanı gibidir. Test projesinin nasıl ilerleyeceği, hangi fazlarda nelerin yapılacağından bahseder. Test plan dökümanında olması gereken başlıklara göz atalım;
- Proje tanımı: Bu kısımda test edilecek proje tanıtılır
- Test ekibi görev ve sorumlulukları: Test projesinde yer alacak olan kullanıcıların görev ve sorumlulukları belirtilir. (Buradaki yazıdan görev ve sorumluluklara bakabilirsiniz.)
- Test edilecek iş gereksinimleri: Yazılım projelerinde müşterilerin istekleri genelde fonksiyonel ve iş kurallarından oluşur. Bunların ayrı ayrı değerlerdirilmesi gerekir. Bu kısımda iş gereksinimleri listelenir.
- Test edilecek fonksiyonlar
- Test edilmeyecek fonksiyonlar: Projelerde geliştirilen bazı fonksiyonların test edilmesi mümkün olmayabilir. Veya başka bir fonksiyona bağlı olabilir. Bunların da nedenleri ile belirtilmesi gerekir.
- Riskler: Daha önce bahsettiğimiz FMEA analizi sonucunda bulunan riskler ve ağırlık değerleri burada lsitelenir.
- Uygulanacak test tipleri: Herbir fonksiyon, iş gereksinimi ve risk için uygulanacak test tipi burada belirtilir. Genellikle tablolama yöntemi kullanılır. Örneğin;
Item No
Test1
Test2
Test3
Test4
F1
+
+
-
+
BR1
-
+
-
-
R1
+
+
+
-
- Kullanılacak test araçları: Hata takip aracı, otomasyon araçları gibi test projesinde kullanılacak tüm araçlar burada listenenir.
- Görev ve zamanlamalar: Oluşturulan task list ve kimler tarafından yapılacağı burada listelenir.
- Test sonlandırma kriterleri: Test projesinin bitimi için geçerli olacak kriterler listelenir.
In: Yazılım Test · Tagged with: test, test plan, test süreci
Performans Göstergeleri
Yazıya başlamadan önce kısa süre içerisinde Visual Studio 2008 Team System performans tester ile ilgili webcast in müjdesini vereyim. Bu yazı bir bakıma performans testine hazırlık olarak düşünülebilir. Performans testlerinin genel amacı, uygulama üzerinde belirli kullanıcı sayılarında sistemin nasıl davrandığını görmektir. Bu değerlendirmeleri de performans göstergelerini inceleyerek yapabilirsiniz.
Performans göstergelerini tip olarak 3’e ayırabiliriz.
Temel Performans Göstergeleri : Bunlar her performans ölçümlemesinde mutlaka ölçülmesi gereken göstergelerdir. Bunlarda herhangibir sorun hissedildiğinde detay performans göstergelerine başvurmak gerekir.
Detay Performans Göstergeleri : Bunlar belli sorunlar karşısında sorunu teşhis etmek için kullanılır.
Temel Performans Göstergeleri Bu gösterge tüm sunucuların tüm işlemcileri için bakılır. Eğer işlemcinin kullanımı %100’e yaklaşıyorsa, işlemci bottleneck oluşturuyor olabilir.
Eğer işlemci üzerinde yoğun bir kullanım varsa, bunun nedeni o sunucuda birden fazla proses’in aynı anda çalışması olabilir. Bu durumda web , servis veya veritabanının ayrı makinalarda çalıştırılması bir çözüm olabilir.
Bu göstergenin yüksek değerleri göstermesi durumunda Process %Processor Time göstergesine bakılarak, yoğunluğun hangi prosesten kaynaklandığı bulunabilir.
Processor – % Processor Time
Memory – Available Mbytes
Tüm sunucular için bakmak gerekir.
Bu gösterge, sunucu üzerinde ki hafızanın yeterli olup olmadığını gösterir. Bu göstergenin sürekli sıfıra yaklaşıyor durumda olması, hafızanın yeterli olmadığını ve sürekli paging yapıldığını gösterir. Bu durum Memory Pages/sec göstergesinden de izlenebilir.
Bu gösterge Performance Monitor’den izlenebileceği gibi task manager’daki “Available Physical Memory” kısmından da görülebilir. Göstergenin düşük olması durumunda Task Manager / Processes kısmında hangi uygulamanın yüksek hafıza kullandığı tesbit edilir.
Physical Disc – %Idle Time
Tüm sunucular için bakmak gerekir.
Bu gösterge, diskin zamanın ne kadarlık bir kısmında boş kaldığını gösterir.
Birden fazla disk varsa her disk için bakmak gerekir.
Eğer bu gösterge sürekli sıfıra yaklaşıyorsa, disk üzerinde bir “bottleneck” oluşmuş olabilir. Bu durum Avg.Disc Queue Length göstergesiyle de teyit edilebilir.
Physical Disc – Avg.Disc Queue Length
Tüm sunuculardaki tüm diskler için ayrı ayrı bakmak gerekir. Bu gösterge, diskin kuyruk uzunluğunu gösterir. Diskin kuyruk uzunluğu, devamlı sıfırdan büyükse, disk’te bottleneck vardır. Bu durum Disc %Idle Time göstergesi ile de teyit edilebilir.
Disk üzerinde bottleneck tesbit edilirse, ilk olarak bunun paging işlemlerinden kaynaklanıp kaynaklanmadığına bakılmalıdır. Bunun için Memory Pages/sec ve Memory Available Mbytes göstergeleri kontrol edilir.
Problem diskin yavaş olmasından kaynaklanıyor da olabilir. Bunun için Physical Disc – Disc Bytes/sec , Phiysical Disc Read Bytes/sec, Physical Disc-Write Bytes/sec göstergelerine bakılabilir. Eğer problem diskin yavaş olması ise, disk sisteminin değiştirilmesi (yeni disk alınması vs) önerilebilir. Ya da, eğer makine üzerinde iki tane disk controller var ise, bunlar arasında bir “load balancing” çözümü yapılabilir. Örneğin database’lerin farklı disklere koyulması ya da bir database’in tablolarının farklı disklere koyulması gibi.
Diske yazmalar Netflow proseslerden mi yoksa makine da çalışan diğer proseslerden mi bunu anlamak gerekir. Bunun için Process- IO Data Bytes/sec göstergesine bakılabilir. Hem Netflow prosesleri , hem de diğer prosesler bu gösterge kullanılarak kontrol edilebilir.
ASP.NET – Request Queued
Microsoft IIS içinde çalışan aspnet_wp prosesi gelen request’leri thread’lere atar. Tek CPU’lu bir Web server’da normal olarak aynı anda 10 tane thread çalışıyor olabilir. 10 tane thread’din kaldıramadığından fazla request geldiği zaman, bunu “request queue” ya atar. Request queue’nun uzunluğu Web Server’ın gelen request’lere ne kadar hızlı cevap verdiğine dair bir göstergedir.
Detay Performans Göstergeleri
Process – %Processor Time
Belli bir proses’in CPU’yu ne kadar kullandığını gösterir. Processor %Processor Time göstergesinin yüksek çıkması durumunda bu göstergeye bakılabilir. İlk olarak Netflow ile ilgili proseslere bakılabilir. Netflow ile ilgili prosesler
1. SQL Server (sqlserv.exe): Veritabanı prosesi. Eğer yüksek çıkıyorsa yükü yaratanın, Netflow veritabanı mı yoksa sunucu üzerinde kurulu diğer veritabanları mı olduğuna bakmak gerekir. SqlServer’ın processor time’ının yüksek çıkmasının nedenlerini araştırmak için SqlProfiler kullanılır. SqlProfiler açılarak en yüksek CPU’yu kullanan query’lere bakılır. Bunlarla ilgili bir problem varsa, bu query’lerde revizyona gidilir.
2. aspnet_wp.exe: Web server tarafında çalışan ASP.NET prosesi. Web server’da işlemci kullanımının yoğun olması durumunda bakılır. Aspnet_wp prosesin yüksek çıkmasının sebebi web sunucusunda farklı web site’lar olması da olabilir.
3. NetflowService.exe: Servis tarafında çalışan proses.
Memory – Pages/sec
Hafıza yetersizliği durumunda makinanın saniyede kaç paging işlemi yaptığını gösterir. Memory Availiable Mbytes göstergesinin düşük çıkması durumunda, paging işleminden dolayı makinanın yavaş çalıştığını göstermek için kullanılır.
Eğer bu gösterge yüksek çıkıyorsa (10 pages/sec gibi) , fakat Memory Available Mbytes göstergesi normalse, bilgisayarda bir hafıza yetersizliği yoktur. Problem bir aplikasyonun yeterli hafıza olduğu halde, page okumasından kaynaklanıyor olabilir.
Process – Working Set
Herhangibir prosesin ne kadar fiziksel hafıza kullanıdığını gösterir. Bu değere Task Manager Process’tan da ulaşılabilir. Fazla hafıza kullanan prosesin tesbiti için kullanılır.
Physical Disc – Disk Bytes/sec
Hard diske saniyede yazılan byte miktarını gösterir. Physical Disc – %Idle Time göstergesi sıfır olduğunda, diskin kapasitesini belirler.
Physical Disc – Disk Read Bytes/sec
Hard diske saniyede yazılan byte miktarını gösterir. Physical Disc – %Idle Time göstergesi sıfır olduğunda, diskin okuma kapasitesini gösterir.
Physical Disc – Disk Write Bytes/sec
Hard diske saniyede yazılan byte miktarını gösterir. Physical Disc – %Idle Time göstergesi sıfır olduğunda, diskin yazma kapasitesini gösterir.
Process – IO Data Bytes/sec
Bir prosesin byte olarak saniyede yaptığı IO sayısı. Hangi proseslerin çok IO yaptığına bakılarak, disk veya Network üzerinde ki bottleneck’in sebebi anlaşılabilir.
In: Yazılım Test · Tagged with: performance, test
Test stratejileri
Daha önce yazılım projelerindeki test süreçlerinden bahsetmiştik. Dikkat ettiyseniz test sürecinin en önemli parçası testin hazırlık aşamasıdır. Bir projeyi başarılı bir şekilde test etmek için hazırlık aşamasında planlamanızın iyi olması gerekir.
Planlamanın iyi olması da o proje için seçilecek olan stratejilere bağlıdır. Test planlaması satranç gibidir. Eğer işin başında iyi bir stratejiniz varsa mutlaka başarılı olursunuz.
Tabii bu stratejilerin seçilmesinde geliştirilecek olan uygulamanın özellikleri büyük önem taşır. Bir test projesini planlamaya başlamadan önce neyi test edeceğinizi iyice öğrenmeniz gerekir.
Geliştirilecek olan uygulamada hangi teknolojiler kullanılacak? Uygulamanın hedef kitlesi kim? Uygulamayı kaç kişi kullanacak? Bütün bu soruların cevaplarını bilmeniz sizin en doğru stratejiyi seçmenizi sağlayacaktır.
Örneğin bir web uygulaması geliştiriyorsunuz. Uygulamayı kullanacak olan hedef kitleniz internet ile fazla haşır neşir olmayan, bilgisayarda sadece basit fonksiyonları kullanan kişiler olsun. Siz bu projeyi test ederken öncelikli olarak arayüze önem vermeniz gerekir. Çünkü hedef kitle göz önüne alındığında basit bir arayüz kullanılmalı, karışık fonksiyonlardan kaçınılmalıdır.
Lafı fazla uzatmadan asıl konuya gelelim. Yazılım projelerinde uygulanacak dört strateji vardır;
- Statik testler,
- Beyaz kutu (white box) test tekniği
- Kara kutu (black box) test tekniği,
- Performans testi.
Aşağıda detayları anlatılan stratejileri kullanmanız tamamen test edilecek olan projenin boyutuna bağlıdır.
Statik testler : Yazılım projelerindeki hataların %85’i dizayn aşamasında gerçekleşir. Hatta bu hataların çoğu hem projenizi hemde uygulamanızı ciddi şekilde etkiler. Dizayn aşamasında alınan kararları etkileyen en önemli unsur dökümantasyondur. Bi rproje dökümantasyon ile başlayıp, dökümantasyon ile sonlanır.
Statik testler bu noktada devreye girer. Projenin başlangıç aşamasından itibaren hazırlanan dökümanların tester tarafından incelenmesi proje başında birtakım problemlerin çözülmesini sağladığı gibi, tester’ın proje hakkında detaylı bilgiye sahip olmasını sağlar.
Beyaz Kutu (white box) test tekniği : Beyaz kutu test tekniğinin en genel tabiri kod testidir. Yani projenin hem kaynak kodu, hemde derlenmiş kodu test edilir. Yalnız burada projenin kodlarının da test edilebilir şekilde yazılması gerekmektedir. Bu konu ile ilgili ilerleyen günlerde daha detaylı yazılar bulacaksınız.
Kara Kutu (black box) test tekniği : Tester’lar arasında en sık kullanılan teknik olan kara kutu test tekniği adından da anlaşılacağı gibi uygulamanın sadece derlenmiş kodu üzerinden test edilmesi olarak bilinir. Fonksiyonel testler, uç nokta test tekniği, use case testleri kara kutu test tekniğinin başlıca konuları arasındadır.
Performans testi : Performans test tekniği ile geliştirilen uygulamanıın gerek kod gerekse işleyişinin performansının ölçülmesidir. Otomasyon araçları sayesinde bir sql sorgusunun performansından, tüm uygulamanın performansına kadar ölçümler yapılabilir.
İlerleyen yazılarda tüm tekniklerin detaylarına yer verilecektir…
Şimdilik hoşçakalın.
In: Yazılım Test · Tagged with: black box, performance, static, test, white box
Testin Önemi ve Test ekibi
Bir test uzmanı test ekibi cümlesi kulağıma hep hoş gelmiştir. Nedenini test uzmanı olan arkadaşlarım anlamıştır herhalde. Test birimleri yazılım firmalarında son birkaç senedir oluşmaya başladı. Test için ayrı birilerinin şirketlerde çalışması maliyetleri arttıran bir durum. Ama artan bu maliyetlerin yanına şirketlerin kazançları eklendiğinde durum farklılaşıyor.
Test ekibinin önemini anlatmaya başlamadan önce testin önemini aşağıdaki örnekle çok daha iyi anlacağımızı düşünüyorum;
Projenin development aşamasında bulunan hatanın maliyeti: 5 TL
Müşterinin bulduğu hatanın maliyeti (müşteri memnuniyeti göz önüne alınırsa: 20 TLTest uzmanının projeye maliyeti: 500 TL
Uygulamada çıkan toplam hata sayısı: 100
Bu hataların test uzmanı tarafından bulunması: (5*100)+500 = 1000 TL
Bu hataların müşteri tarafından bulunması: (20*100) = 2000 TL
Görüldüğü gibi bir projede test uzmanı 100 hata bulduğunda şirkete maliyeti 1000 TL iken müşterinin hataları bulması ile oluşan maliyet 2000 TL. Demek istediğim test her ne kadar firmalar için “lüks” sayılsa da uzun vadede getirileri çok yüksek.
Bir diğer önemli konu da test ekibi. Bir test uzmanı ne kadar tecrübeli olursa olsun test ettiği projede gözünden kaçacak hatalar hep olacaktır. Bu durum insanın doğasından kaynaklanmaktadır. Gerçek hayattaki tecrübelerinin testlerinize her zaman yansır.
Bununla beraber test bir takım ve plan işidir. Eğer siz takımızdaki kişileri iyi planlarsanız, hataların kaçma olasılığını da o kadar azaltmış olursunuz.
Yazılım ekiplerinde olduğu gibi test ekiplerinde çeşitli gruplar vardır. Bunlar QA, lead tester, teknik tester, arayüz tester, performans tester, security tester.
QA, şirket içi ve şirket dışı tüm faaliyetleri denetler. Aynı zamanda test ekibinin en üst seviyesidir. QA genellikle süreçlerin düzgün işlemesi için gerekli kontrolleri sağlar. Lead tester, test ekibinin yöneticisidir. Tüm ekibi korrdine eder, test plan dökümanında yazılan adımları kontrol eder, dökümantasyonu sağlar. Aynı zamanda diğer ekip arkadaşlarına da her konuda danışmanlık yapar.
Teknik tester diğer test ekibindeki kişilere göre kodlama yeteneği daha fazla olan kişidir. Kod testlerini gerçekleştirir. Arayüz testçisi genellikle web tabanlı projelerde görev alır. Usability konusunda bilgili olması gerekir. Performans tester uygulamanın performans testleri sırasında görev alır. Security tester uygulamalardaki güvenlik testlerini gerçekleştirir.
Yukarıda bahsedilen tester tipleri ayrı kişiler olabileceği gibi aynı kişi de olabilir. Burada önemli olan projelerde bu görevleri kimlerin yerine getireceğinin belirlenmesidir.
In: Yazılım · Tagged with: test, test süreci