Java ile biraz kurcalamışlığım oldu. junit ile unit testleri hazırlıyorduk Stress testleri ise olasılık tabanlı gerçek kullanıcı gibi çalışan multi-thread çalışan bir bot yazmıştım. 1 exectable 1000 kullanıcıyı simule ediyordu (ama paketler test edilen uygulamaya localhostta çalıştığı için süper hızlı iletildiği için aslında 1000 değil belkide 2000 kişilik bir yük oluşturuyordu). Kendi varsayımım kullanıcının ne yaptığını tam olarak kestiremediğin için olasılıksal olarak kullanıcı hareketlerini simule ettim. Mantık çok basit; 0-100 arasında bir sayı tuttum. 0-10 aralığındaysa (%10 olasılıjkla) A işlemini yap 11-50 aralığındaysa (%40 olasılıkla) B işlemini yap 51-100 aralığındaysa(%50 olasılıkla) C işlemini yap Yapılan işlem karşısında test ettiğim yazılım network pakedi olarak bir cevap gnderdi bana. Gnderdiği cevabın türü de bir sonraki state imi belirlemiş oldu. Yani ilk başta A işlemi seçildiyse, A işleminden sonra 1,2,3 işlem alternatiflerinden birisi olasılıksal olarak yapılmalı. B işlemi seçildiyse 4,5,6 işlem alternatiflerinden irisi olasılıksal olarak yapılmalı. Düşük bir olaslıkla kullanıcı bir üst aksiyona geri dner şeklinde olaya yaklaşırsan botlar fıldır fıldır uygulamada gerçek kullanıcıymış gibi hareket ederler. Sende uygulamanı bu şekilde takip edebilirsin. Bu tarz simulasyonlar sana bir fikir verebilir ANCAK debug versiyon release versiyona gre daha yavaş çalışacaktır bu da debug versiyon ile release arasında farklı davranışlara neden OLABİLİR. zellikle network işlemleri yapıyorsa ve düzgün bir lock mekanizması kullanmadan paketler işleniyorsa debug modda çatır çatır çalışan kod release de unstable bir hal alabilir. O yüzden denemeleri hem debug hem release versiyon üzerinde yapmakta fayda var. Uzun oldu muhtemelen kimse okumayacak ama olsun :D Edit: Szkonusu user interface içeren bir uygulama ise yıllar yıllar nce autoit ile basit scriptler yaparak mouse hareketlerini simule ediyordum. Muhtemelen autoit ile yapılabilecekler almış başını yürümüştür. User interface testi de bu şekilde hazırlanabilir. S2kucuk tarafından 30/Tem/15 00:18 tarihinde düzenlenmiştir

Bir o kadar yapılması gereken işler olduğu gibi yazılımcıya bir o kadar da külfet olan işler bunlar yahu. Çok sinir bozucu. Yapacak birşey yok hocam. Mecbur :D Titanyumun gücü adına!!!

visual studio 2015 ile birlikte bu konuyla ilgili güzel şeyler geldi, anlık bellek, işlemci kullanımını grebiliyorsun, her verinin/değişkenin ne kadar alan kapladığını grebiliyorsun, bir işlemin ne kadar sürdüğünü ms bazında grebiliyorsun anlık olarak.. yle bir tool v. s. yüklemene gerek yok Ülkesini Seven Her Türk Vatandasi, Ülkesinin Sessiz Istilasi'na karsi durmak zorunda.

Merhaba arkadaşlar. Başlıkta belirtmiş olduğum konularda fikirlerinizi almak istiyorum. Yazılım işiyle uğraşan arkadaşlar yaptıkları yazılımların performans, yük ve stres testlerini nasıl yapıyorsunuz acaba? Titanyumun gücü adına!!!

Web servisleri için başka bir server kullanıyorsun. Flood engelini kaldırıyorsun. Biraz log tutuyorsun. Hücum ettiriyorsun. Sonuçları eline alıyorsun. Kod, server, veritabanı analizini yapıyorsun. Server değiştirmek mi kodu optimasyon etmek mi tool mu diye kendine soruyorsun. Hangisi faydalıysa ona yneliyorsun. Sadece bi imza..

En son 5-6 sene nce yük testine dahil olmuştum. Web servis'e load test yapmıştık. Soap UI ile senaryoyu hazırlayıp çalıştırmıştık. Blue Screen of Death

visual studio 2015 ile birlikte bu konuyla ilgili güzel şeyler geldi, anlık bellek, işlemci kullanımını grebiliyorsun, her verinin/değişkenin ne kadar alan kapladığını grebiliyorsun, bir işlemin ne kadar sürdüğünü ms bazında grebiliyorsun anlık olarak.. yle bir tool v. s. yüklemene gerek yok e güzelmiş. 15e geçince kurcalamak lazım bi. .

Bir o kadar yapılması gereken işler olduğu gibi yazılımcıya bir o kadar da külfet olan işler bunlar yahu. Çok sinir bozucu. Bu imzayı her grdüğünüzde 4gb kotanızın 0,00000358559191226959228515625 azalmaktadır. Bilerek ve istenerek bu imza yapılmıştır. Amaç kotanızı smürmektir