Yazılım Testine Genel Bakış

Yazılım Testi, yazılımın kullanıcılardan toplanan gereksinimlere ve sistem özelliklerine göre değerlendirilmesidir. Test, yazılım geliştirme yaşam döngüsünde aşama düzeyinde veya program kodunda modül düzeyinde gerçekleştirilir. Yazılım testi, Doğrulama ve Doğrulamadan oluşur.

Yazılım Doğrulaması

Doğrulama, yazılımın kullanıcı gereksinimlerini karşılayıp karşılamadığını inceleme sürecidir. SDLC'nin sonunda gerçekleştirilir. Yazılım, yapıldığı gereksinimlere uyuyorsa, doğrulanır.

Doğrulama, geliştirilmekte olan ürünün kullanıcı gereksinimlerine uygun olmasını sağlar.
Doğrulama, şu soruyu yanıtlar - "Bu yazılımdan kullanıcının tüm ihtiyaçlarını karşılayan ürünü geliştiriyor muyuz?".
Doğrulama, kullanıcı gereksinimlerini vurgular.

Yazılım Doğrulaması

Doğrulama, yazılımın iş gereksinimlerini karşılayıp karşılamadığını onaylama sürecidir ve uygun şartnamelere ve metodolojilere bağlı kalarak geliştirilir.

Doğrulama, geliştirilmekte olan ürünün tasarım özelliklerine uygun olmasını sağlar.
Doğrulama şu soruyu yanıtlıyor: "Bu ürünü tüm tasarım özelliklerini sıkı bir şekilde takip ederek mi geliştiriyoruz?"
Doğrulamalar tasarım ve sistem özelliklerine odaklanır.

Testin hedefi -

Errors- Bunlar geliştiriciler tarafından yapılan gerçek kodlama hatalarıdır. Ayrıca yazılımın çıktısında farklılık olması ve istenilen çıktı hata olarak değerlendirilmektedir.
Fault- Hata oluştuğunda hata oluşur. Hata olarak da bilinen bir hata, sistemin başarısız olmasına neden olabilecek bir hatanın sonucudur.
Failure - Başarısızlığın, sistemin istenen görevi yerine getirememesi olduğu söylenir. Arıza, sistemde arıza olduğunda ortaya çıkar.

Manuel ve Otomatikleştirilmiş Test

Test manuel olarak veya otomatik bir test aracı kullanılarak yapılabilir:

Manual- Bu test, otomatik test araçlarının yardımı olmadan gerçekleştirilir. Yazılım test cihazı, kodun farklı bölümleri ve seviyeleri için test senaryoları hazırlar, testleri yürütür ve sonucu yöneticiye bildirir.

Manuel test, zaman ve kaynak tüketir. Test uzmanının doğru test senaryolarının kullanılıp kullanılmadığını onaylaması gerekir. Testin büyük bölümü manuel testi içerir.
AutomatedBu test, otomatik test araçlarının yardımıyla yapılan bir test prosedürüdür. Manuel test ile ilgili sınırlamalar, otomatik test araçları kullanılarak aşılabilir.

Bir web sayfasının Internet Explorer'da açılıp açılamayacağını kontrol etmesi gerekir. Bu, manuel test ile kolayca yapılabilir. Ancak web sunucusunun 1 milyon kullanıcının yükünü kaldırıp kaldırmadığını kontrol etmek için manuel olarak test etmek oldukça imkansızdır.

Test uzmanının yük testi, stres testi, regresyon testi yapmasına yardımcı olan yazılım ve donanım araçları vardır.

Test Yaklaşımları

Testler iki yaklaşıma göre yapılabilir -

İşlevsellik testi
Uygulama testi

İşlevsellik, söz konusu gerçek uygulama dikkate alınmadan test edildiğinde, kara kutu testi olarak bilinir. Diğer taraf, yalnızca işlevselliğin test edildiği değil, aynı zamanda uygulanma biçiminin de analiz edildiği beyaz kutu testi olarak bilinir.

Kapsamlı testler, mükemmel bir test için istenen en iyi yöntemdir. Giriş ve çıkış değerleri aralığındaki her bir olası değer test edilir. Değer aralığı büyükse gerçek dünya senaryosunda her bir değeri test etmek mümkün değildir.

Kara kutu testi

Programın işlevselliğini test etmek için yapılır. Aynı zamanda 'Davranışsal' test olarak da adlandırılır. Bu durumda test cihazı, bir dizi giriş değerine ve ilgili istenen sonuçlara sahiptir. Girdi sağlandığında, çıktı istenen sonuçlarla eşleşirse, program 'tamam' olarak test edilir, aksi halde sorunludur.

Bu test yönteminde kodun tasarımı ve yapısı test uzmanı tarafından bilinmez ve test mühendisleri ve son kullanıcılar bu testi yazılım üzerinde gerçekleştirir.

Kara kutu test teknikleri:

Equivalence class- Girdi benzer sınıflara ayrılmıştır. Bir sınıfın bir öğesi testi geçerse, tüm sınıfın geçtiği varsayılır.
Boundary values- Giriş, yüksek ve düşük son değerlere bölünmüştür. Bu değerler testi geçerse, aradaki tüm değerlerin de geçebileceği varsayılır.
Cause-effect graphing- Önceki her iki yöntemde de, bir seferde yalnızca bir giriş değeri test edilir. Neden (girdi) - Etki (çıktı), girdi değerlerinin kombinasyonlarının sistematik bir şekilde test edildiği bir test tekniğidir.
Pair-wise Testing- Yazılımın davranışı birden çok parametreye bağlıdır. İkili testte, birden fazla parametre farklı değerleri için çift olarak test edilir.
State-based testing- Sistem, giriş sağlandığında durumunu değiştirir. Bu sistemler durumlarına ve girdilerine göre test edilir.

Beyaz kutu testi

Kod verimliliğini veya yapısını iyileştirmek için programı ve uygulamasını test etmek için yapılır. Aynı zamanda 'Yapısal' test olarak da bilinir.

Bu test yönteminde, kodun tasarımı ve yapısı test eden tarafından bilinir. Kodun programcıları bu testi kod üzerinde gerçekleştirir.

Aşağıda bazı Beyaz kutu test teknikleri verilmiştir:

Control-flow testing- Kontrol akışı testinin amacı, tüm ifadeleri ve şube koşullarını kapsayan test senaryoları oluşturmaktır. Şube koşullarının hem doğru hem de yanlış olduğu test edilir, böylece tüm ifadeler kapsanabilir.
Data-flow testing- Bu test tekniği, programda yer alan tüm veri değişkenlerini kapsamayı vurgular. Değişkenlerin nerede bildirildiğini ve tanımlandığını ve nerede kullanıldığını veya değiştirildiğini test eder.

Test Seviyeleri

Testin kendisi çeşitli SDLC seviyelerinde tanımlanabilir. Test süreci, yazılım geliştirmeye paralel olarak çalışır. Bir sonraki aşamaya geçmeden önce, bir aşama test edilir, doğrulanır ve doğrulanır.

Yazılımda gizli hata veya sorun kalmadığından emin olmak için ayrı ayrı test yapılır. Yazılım çeşitli düzeylerde test edilmiştir -

Birim Testi

Kodlama sırasında, programcı hatasız olup olmadığını anlamak için o program birimi üzerinde bazı testler yapar. Test, beyaz kutu test yaklaşımı altında gerçekleştirilir. Birim testi, geliştiricilerin programın ayrı birimlerinin gereksinime göre çalıştığına ve hatasız olduğuna karar vermelerine yardımcı olur.

Entegrasyon Testi

Yazılım birimleri ayrı ayrı iyi çalışıyor olsa bile, bir araya getirilirse birimlerin de hatasız çalışıp çalışmayacağını bulma ihtiyacı vardır. Örneğin, bağımsız değişken aktarma ve veri güncelleme vb.

Sistem Testi

Yazılım, ürün olarak derlenir ve daha sonra bir bütün olarak test edilir. Bu, aşağıdaki testlerden biri veya daha fazlası kullanılarak gerçekleştirilebilir:

Functionality testing - Yazılımın tüm işlevlerini ihtiyaca göre test eder.
Performance testing- Bu test, yazılımın ne kadar verimli olduğunu kanıtlıyor. Yazılımın istenen görevi yapmak için harcadığı ortalama süre ve etkinliği test eder. Performans testi, yazılımın çeşitli ortam koşullarında yüksek kullanıcı ve veri yüküne maruz bırakıldığı yük testi ve stres testi yoluyla yapılır.
Security & Portability - Bu testler, yazılımın çeşitli platformlarda çalışması amaçlandığında ve kişi sayısı tarafından erişildiğinde yapılır.

Kabul testleri

Yazılım müşteriye teslim edilmeye hazır olduğunda, kullanıcı etkileşimi ve yanıt için test edildiği son test aşamasından geçmelidir. Bu önemlidir, çünkü yazılım tüm kullanıcı gereksinimlerini karşılasa bile ve kullanıcı görünüşünden veya çalışmasından hoşlanmasa bile reddedilebilir.

Alpha testing- Geliştirici ekibi, sistemi çalışma ortamında kullanılıyormuş gibi kullanarak alfa testi gerçekleştirir. Kullanıcının yazılımdaki bazı eylemlere nasıl tepki vereceğini ve sistemin girdilere nasıl yanıt vermesi gerektiğini bulmaya çalışırlar.
Beta testing- Yazılım dahili olarak test edildikten sonra sadece test amacıyla kendi üretim ortamlarında kullanmaları için kullanıcılara teslim edilir. Bu henüz teslim edilen ürün değil. Geliştiriciler, bu aşamadaki kullanıcıların, katılmak için atlanan küçük problemler getirmesini bekliyorlar.

Gerileme testi

Bir yazılım ürünü yeni kod, özellik veya işlevle güncellendiğinde, eklenen kodun herhangi bir olumsuz etkisi olup olmadığını tespit etmek için kapsamlı bir şekilde test edilir. Bu, regresyon testi olarak bilinir.

Test Belgeleri

Test belgeleri farklı aşamalarda hazırlanır -

Testten Önce

Test, test senaryolarının oluşturulmasıyla başlar. Referans için aşağıdaki belgeler gereklidir -

SRS document - İşlevsel Gereksinimler belgesi
Test Policy document - Bu, ürünü piyasaya sürmeden önce ne kadar test yapılması gerektiğini açıklar.
Test Strategy document - Bu, test ekibinin, sorumluluk matrisinin ve test yöneticisi ve test mühendisinin hakları / sorumluluğunun ayrıntılı yönlerinden bahseder.
Traceability Matrix document- Bu, gereksinim toplama süreciyle ilgili SDLC belgesidir. Yeni gereksinimler geldikçe bu matrise eklenirler. Bu matrisler, test uzmanlarının gereksinim kaynağını bilmelerine yardımcı olur. İleri ve geri izlenebilirler.

Test Edilirken

Test başlatılırken ve yapılırken aşağıdaki belgeler gerekli olabilir:

Test Case document- Bu belge, yapılması gereken testlerin listesini içerir. Birim test planı, Entegrasyon test planı, Sistem test planı ve Kabul test planını içerir.
Test description - Bu belge, tüm test senaryolarının ve bunların yürütülmesine yönelik prosedürlerin ayrıntılı bir açıklamasıdır.
Test case report - Bu belge, testin sonucu olarak test senaryosu raporunu içerir.
Test logs - Bu belge, her test durumu raporu için test günlüklerini içerir.

Testten Sonra

Aşağıdaki belgeler testten sonra oluşturulabilir:

Test summary- Bu test özeti, tüm test raporlarının ve günlüklerinin toplu analizidir. Yazılımın başlatılmaya hazır olup olmadığını özetler ve sonuca varır. Yazılım, başlatılmaya hazırsa sürüm kontrol sistemi altında yayınlanır.

Test, Kalite Kontrol, Kalite Güvencesi ve Denetime Karşı

Yazılım testinin yazılım kalite güvencesi, yazılım kalite kontrolü ve yazılım denetiminden farklı olduğunu anlamamız gerekir.

Software quality assurance- Tüm önlemlerin organizasyon standartlarına göre alınmasını sağlayan yazılım geliştirme süreç izleme araçlarıdır. Bu izleme, uygun yazılım geliştirme yöntemlerinin izlendiğinden emin olmak için yapılır.
Software quality control- Bu, yazılım ürününün kalitesini korumak için bir sistemdir. Kuruluşun iyi niyetini artıran, yazılım ürününün işlevsel ve işlevsel olmayan yönlerini içerebilir. Bu sistem, müşterinin ihtiyaçları için kaliteli ürün almasını ve ürünün 'kullanıma uygun' olarak onaylanmasını sağlar.
Software audit- Bu, kuruluş tarafından yazılımı geliştirmek için kullanılan prosedürün bir incelemesidir. Geliştirme ekibinden bağımsız bir denetçi ekibi, SDLC'nin yazılım sürecini, prosedürünü, gereksinimlerini ve diğer yönlerini inceler. Yazılım denetiminin amacı, hem yazılımın hem de geliştirme sürecinin standartlara, kurallara ve düzenlemelere uygunluğunu kontrol etmektir.