Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software/Yazılım Test

378 views

Published on

Yazılım geliştirme sürecinde testin yerinin ve öneminin ne olduğu/olması gerektiğine dair konuları içerir.

Published in: Software
  • Be the first to comment

Software/Yazılım Test

  1. 1. APPLICATION TEST ddemirel/20171123
  2. 2. Test Nedir?  Bir sistemin ya da birimin, belirli şartları yerine getirip getirmediğini bulmak niyetiyle değerlendirilmesi işlemidir.  Bir uygulamada var olan özellikler ile olması gereken özellikleri analiz etmeyi sağlar.
  3. 3. Testleri Kimler Yapar?  Yazılımcı  Yazılım Destek/Test Personeli  Proje Yöneticisi  Son Kullnıcı
  4. 4. Teste Ne Zaman Başlarsınız? >>  Testlere erken başlanılması son kullanıcıya teslim edilen yazılımın hatasız olmasını sağlar, yeniden düzenleme işlemleri için gereken zamanı ve maliyeti azaltır.  Testler yazılım geliştirme yaşam döngüsünün bir aşaması olan «gereksinimleri toplama» aşamasında başlayabilir ve bu yazılımın teslimine kadar devam edebilir.
  5. 5. Teste Ne Zaman Başlarsınız?  İhtiyaçların toplanması aşamasında gereksinimlerin analizi ve doğrulanması da test olarak kabul edilir.  Tasarım aşamasında tasarımın gözden geçirilmesi de test olarak kabul edilir.  Kodun tamamlanmasından sonra geliştirici tarafından yapılan kontroller de test olarak kabul edilir.
  6. 6. Testler Ne Zaman Bitirilir?  Testin sonsuz bir süreç olduğu ve hiç kimsenin bir yazılımın %100 test edildiğini iddia edememesi nedeniyle, testi ne zaman durduracağınızı belirlemek zordur.  Aşağıdaki hususlar göz önüne alınarak buna karar verilebilir;  Belirlenen test case’lerin başarılı çalıştırılmasının tamamlanması  Belirli bir noktaya kadar fonksiyonel testlerin tamamlanması  Hata sayısının belirli bir seviyenin altına inmesi ve yüksek öncelikli hata tespit edilmemesi  Yönetim kararı
  7. 7. Testler İle İlgili Bazı Doğru Bilinen Yanlışlar
  8. 8. Test Süreci Çok Maliyetlidir  Yazılımı geliştirirken yapılan test için ödediğiniz bedel, bakım ve düzeltme aşamasında ödediğiniz bedelden daha azdır.  Erken yapılan testler zaman ve maliyet açısından tasarruf sağlar, ancak test edilmeden maliyeti düşürmeye çalışmak uygulamanın yanlış geliştirilmesi ile ürünün işe yaramaz hale gelmesini sağlar.
  9. 9. Test Yapmak Zaman Kaybıdır  SDLC Aşamaları gerçekleşirken, test yapmak zaman kaybı değildir.  Bununla birlikte test aşamasında hataların tespit edilip düzeltilmesi zaman alan fakat üretken bir faaliyettir.
  10. 10. Sadece Tamamlanmış Ürünler Test Edilebilir  Test yapmak source code’a bağlıdır fakat müşteri isteklerinin gözden geçirilmesi ve test planlarının oluşturulması source koddan bağımsızdır.  Ancak iterative veya incremental SDLC yaklaşımı testlerin projeninin tamamının bitmesinden bağımsız olarak yürütülmesini kolaylaştırır.
  11. 11. Tümüyle Test Etmek Mümkündür  Müşteri ya da test eden kişilerin eksiksiz testin mümkün olduğunu düşünmesi bir sorun haline gelebilir. Tüm durumların ele alınmış olması mümkündür fakat eksiksiz test edilmesi asla gerçekleşemez.  SDLC sürecinde hiç test edilmeyen senaryolar olabilir. Bu durum proje kullanıma başlandığında ortaya çıkabilir.
  12. 12. Test Edilmiş Yazılım Hatasızdır  Bu müşterilerin, proje yöneticilerinin ve diğer yöneticilerin inandığı ortak bir yanılgıdır.  Uygulamayı mükemmel bir test sürecinden geçirseniz bile kimse uygulamanın %100 hatasız olduğunu iddia edemez.
  13. 13. Kusurlar, Test Yapan Kişilerden Kaynaklanmaktadır  Testler tamamlandıktan sonra bile uygulamada kalan hatalar için test yapan kişileri suçlamak doğru bir yaklaşım değildir.  Bu durum zaman, maliyet ve gereksinimleri değiştiren kısıtlara bağlıdır.  Bununla birlikte, test stratejisi hataların test ekibi tarafından kaçırılmasına neden olabilir.
  14. 14. Test Yapanlar Ürünün Kalitesinden Sorumludur  Uygulamanın kalitesinden sadece test yapanların ve test ekibinin sorumlu olması çok yaygın bir yanılgıdır.  Test yapanların sorumluluğu hataların belirlenmesini sağlamak ve bunun ilgililere bildirmektir. Hataların düzeltilip düzeltilmeyeceği kararını vermezler.  Projenin zamanında tamamlanması test ekibi üzerinde fazlaca baskıya sebep olur. Çünkü oluşan herhangi bir hatadan sorumlu tutulabilirler.
  15. 15. Test Otomasyonu Zaman Maliyetini Düşürmek İçin Mümkün Olan Her Yerde Kullanılabilir  Test otomasyonunun test zamanlarını azalttığı doğrudur, fakat yazılım geliştirme aşamasında herhangi bir zamanda test otomasyonuna başlamak mümkün değildir.  Test otomasyonu, uygulama manuel test edilip belirli bir kararlılığa ulaştığında başlatılır. Gereksinimler değişmeye devam ederse test otomasyonu kullanılamaz hale gelir.
  16. 16. Herhangi Birisi Uygulama Testi Yapabilir  IT sektörünün dışındaki kişiler, testlerin herhangi birisi tarafından yapılabileceğini düşünürler. Hatta test yapma işinin yaratıcılık gerektiren bir iş olmadığını da düşünürler.  Fakat testçiler bunun bir safsata olduğunu çok iyi bilirler. Alternatif senaryoları düşünerek, uygulamayı hataya düşürecek durumları ortaya çıkarmak uygulamayı geliştiren/tasarlayan kişiler tarafından yapılamaz.
  17. 17. Kalite Güvence(QA), Kalite Kontrol(QC), Test Bu konular her ne kadar bir araya gelmiş ve bir dereceye kadar aynı faaliyetler olarak görülse de belirgin farklılıkları vardır.
  18. 18. Kalite Güvence(QA), Kalite Kontrol(QC), Test Kalite Güvence Kalite Kontrol Test KG geliştirilmesi yapılmış yazılımların doğruluğuna ve amaçlanan gerekliliklere bağlı olarak süreçlerin, prosedürlerin ve standartların uygulanmasını sağlayan faaliyetleri içerir. Belgelenmiş gereksinimlerle ilgili olarak gelişmiş yazılımın doğrulanmasını sağlar. Yazılımdaki hataların tanımlanmasını sağlayan faaliyettir.
  19. 19. Kalite Güvence(QA), Kalite Kontrol(QC), Test Kalite Güvence Kalite Kontrol Test Sistem üzerinde fiili test yapmak yerine süreçlere ve prosedürlere odaklanır. Müşteri gereksinimlerinin doğru tanımlanıp tanımlanmadığını kontrol eder. Tanımlanan prosedürlerin uygulanması yoluyla hata / eksikleri tespit etmek amacıyla testleri yapar. Gerçek teste odaklanır. Süreç odaklıdır. Prosedürleri doğrulamaya odaklanır. Sürecin işlemesinde oluşacak hataları önlemeye odaklanır.
  20. 20. Kalite Güvence(QA), Kalite Kontrol(QC), Test Kalite Güvence Kalite Kontrol Test Software Test Life Cycle(STLC)’nin bir alt kümesidir. KG’nin bir alt kümesidir. KK’ün bir alt kümesidir.
  21. 21. Test Çeşitleri  Functional Test : Yazılımın belirtilen müşteri gereksinimleri karşılayıp karşılamadığını tespit etmeyi sağlar.  Unit Test  Source kodun belirli bölümlerini test etme yöntemidir.  Integration Test  Uygulamanın birleşik bölümlerinin birlikte doğru şekilde çalışıp çalışmadığını test etme yöntemidir.  System Test  Sistemin tümünü test etmeyi hedefler, tüm sistemin istenen kalite standartına uygun olup olmadığını kontrol etmeyi sağlar.  Regression Test  Sistemde yapılan bir geliştirmenin ya da hata gidermenin sistemin çalışan diğer bölümlerinde bir hataya sebep olup olmadığını anlamayı sağlayan test yöntemidir.  Acceptance Test  Yapılan geliştirmenin istenen özelliklere uygun olup olmadığını, müşterinin gereksinimlerini karşılayıp karşılamadığını tespit edildiği test yöntemidir.  Alpha Test  Geliştiriciler ve QA ekipleri için ilk test aşamasıdır. Unit test, integration test ve system test alfa testi olarak tanımlanabilir. Test edilecek konular; Yazım hataları, bozuk bağlantılar, kötü yönlendirmeler vb.  Beta Test  Yayın öncesi test olarak adlandırılabilir. Uygulamayı kullanacak kitleden bir örnek kitle testi yapar. Yayın öncesi gerçek kullanıcıların beklentilerini tespit etmeyi sağlar. Yazılımın kalitesini istenen düzeye çekmeyi hedefler.
  22. 22. Test Çeşitleri  Non-Functional Test  Performans Test : Yazılımdaki oluşabilecek tıkanıklığı veya performans sorununu tespit etmeyi sağlar.  Hata sebepleri; Ağ gecikmesi, client sayısı, db transaction sayısı, load balancing problemi, veri işleme  Performans testi; hız(response time), kapasite, stabilite ve ölçeklenebilirlik açısından önemli ve zorunludur.  Load Test  Bu test normal ve yoğun zamanlarda yazılımın maks. kapasitesini ve davranışını tespit etmeyi sağlar.  Stress Test  Anormal koşullar altında yazılımın davranışını test etmeyi sağlar. Örneğin db bağlantısının kesilmesi veya limitlerin ötesinde bir yük uygulamak gibi durumlar olabilir. Bu testin amacı yükü sisteme uygulayarak yazılımın kırılma noktasını belirlemektir. Bu test; ağ bağlantılarını rastgele kapatarak yada yeniden başlatarak, veritabanını kapatıp açarak veya yazılımın çalıştığı makinada sistem kaynaklarını tüketecek farklı uygulamalar çalıştırılarak yapılabilir.  Usability Test  Kullanılabilirlik testi, kullanıcıların kullanımları ve çalışma şekillerini gözlemleyerek yazılımın daha iyi kullanım kolaylığına sahip olup olmadığını tespit etmeyi sağlar. Yani bir sistemin kullanıcı dostu, öğrenmesi kolay, hatırlanması kolay, kullanılması verimli, tatmin edici ve anlaşılması kolay olup olmadığını anlamayı sağlar. Bu maddelerin sınırlarını çizen bazı ISO standartları ve kalite modelleri mevcuttur(ISO-9126, ISO-9241-11, ISO-13407 ve IEEE).
  23. 23. Test Çeşitleri  Security Test  Uygulamayı güvenlik açısından herhangi bir hataya sahip olup olmadığını test etmeyi sağlar. Aşağıdaki konulara dikkat edilmelidir;  Doğrulama, Yetkilendirme , Giriş kontrolü ve doğrulama, SQL ekleme saldırıları, Enjeksiyon kusurları, Oturum yönetimi sorunları, Siteler arası komut dosyası çalıştırma saldırıları, Dizin traversal saldırıları  Portability Test  Taşınabilirlik testi, yazılımın tekrar kullanılabilirliğini sağlamak amacıyla test edilmesini sağlar. Bu testin temel amacı farklı donanım, işletim sistemi ve browserlarda çalışabilirliğini test etmektir.  Aşağıdaki stratejiler izlenebilir;  Yüklü bir yazılmın bir bilgisayardan farklı bir bilgisayara aktarma  Yazılımı farklı platformlarda çalıştırma
  24. 24. Kaynak  https://www.tutorialspoint.com

×