Odukça kullanışlı bir tool, temel olarak TestDirector’de açtığınız bir defect’in , TFS de work item(bug) olarak açılmasını ve defect’in assing edidiği developer’a atanmasını sağlıyor. Tabi defect üzerindeki güncellemelerde senkronize edilebiliyor.
Bu ne işe yararıyacak diye sorarsanız, özellikle konfigürasyon yönetiminde , sadece atanmış work item ı olanlar check out yapabilir yetkilendirmesi yapabilmenizi sağlıyor, aynı zamanda developer’ın ikinci bir tool(TD) kullanmadan defect’leri takibini, üzerindeki update’leri visual studio dan halledebilmesini sağlıycak.
Aşağıdaki linkden trial ı indirilebilir;
http://onroad.juvander.fi/Community/files/
________________________________________
Ürün aşğıdaki sürümleri destekliyor;
• Test Director 8.0
• Quality Center 8.2
• Quality Center 9.0
• Quality Center 9.2
• Team Foundation Server 2005
• Team Foundation Server 2008
Network scan için kullanabileceğini nmap e ait temel komutlar aşağıdaki gibidir;
nmap 192.168.1.1( hedef ip örneği)
detayli çikti:
nmap –v 192.168.1.1
TCP SYN Scan
Nmap –sS 192.168.1.1
TCP Connect Scan
Nmap –sT 192.168.1.1
UDP Port Scan
nmap –sU 192.168.1.1
devamını oku…
Kullanım durumları akışları ile oluşturulan sistem modelinin iş gereksinimine uygunluğunu kontrol etmek, bu akışlardaki tüm olasılıkları incelemek ve birbirleri ile bağımlı akışlardaki oluşabilecek bütün entegrasyon noktalarının iş gereksinimleri ile uygunluğu inceleyerek karşılaşılacak hataları , eksiklerin giderilmesini sağlamak. Bu yöntemle hataların erken tespiti ve test maliyetinin azaltılması ( teste gelecek ürün kalitesinin artırımı) sağlanır.
Ürünü değil de ürün geliştirmesine geçmeden önce ürün modelinden kaynaklanacak hataları gidermek için test bakış açısıyla yapılan gözden geçirmedir.
Açık bir sistemde %100 güvenlik oluşturulamaz, Genel olarak Security testing’i sistemi , saldırı sonucu elde edilebilecek değerin , saldırı sırasında harcanacak maliyetten daha az değerli olduğu konuma getirmek olarak değerlendirebiliriz .
Temel olarak 2 amaca hizmet eder. Yazılım güvenliği ve Network Güvenliği;
Yazılım Güvenliği;
Testler Risk-Based yaklaşımı ile sistemin mimari güvenilirliğine karşı , sistemin güvenliğinin yeterliliğini değerlendirmek amacı ile gerçekleştirilmeli.
Yazılım sürecinde risk noktaları belirlenmeli ve bu noktalara karşı yazılımsal önlemler alınmalıdır.
Örnek:Authentication
Login ve Şifre Değiştir sayfalarının SSL desteği var mı?
Güçlü Şifre Policy’e sahip mi?(Boş Password,Max Password,Min Password,Şifre Karakter,Numerik karışımı)
İlk loginde şifre değiştirmeye zorluyor mu?
Şifre Değiştiriken Eski şifre zorunlu mu?
Remember me özelliği mevcut mu? Mevcutsa şifre nerde saklanıyor?
Remember me isteğinden önce uyarı veriyor mu?
Kayıt İşleminde CAPTCHA sorgulanıyor mu?
devamını oku…
Smoke / sanity test teste gelecek uygulamanın, test edilebilir durumda olup lmadığını anlamak üzere yapılır. Sistemin temel akışlarından bir kaç senaryo seçilir ve execute edilir. Senaryoların başarı oranına göre sistem testine başlanabilir yada yazılım geliştirmesi tamamlanmadığı belirtilerek red edilir.
Bu yöntemle test ekibinin kaynak maliyeti azaltılmasını, Test sürecinde geliştirme yapmak gibi riskli bir durumdan kaçınılmasını sağlar.
Not: İsmin(Smoke) çıkışı; elektronik devrelerin doğru çalışıp çalışmadığı incelenmeden önce devreye elektrik akımı verilir, duman çıkıyorsa doğru çalışıp çalışmadığını kontrol etmeye bile gerek yoktur, tekrar tasarlanır.
Son Yorumlar