Kullanıcı:Nesrindag9/deneme tahtası

Yazılım geliştirme süreci

Etkinlikler ve adımlar

Gereksinimler | Mimari | Tasarım | Yaşama geçirme | Sınama | Konuşlanma

Modeller

Agile | Cleanroom | Iterative | RAD | RUP | Spiral | Waterfall | XP | Scrum

Supporting disciplines

Configuration management | Documentation | Software quality assurance (SQA) | Project management | User experience design

Bu makale, yazılım testinde yararlı olan bir dizi taktiği tartışmaktadır. Yazılım kalite güvencesine (genellikle kalite güvencesi olarak bilinir ve geleneksel olarak "QA" kısaltmasıyla anılır) ve genel olarak test yönteminin uygulanmasına (genellikle sadece "test" veya bazen "geliştirici testi" olarak adlandırılır) yönelik taktik yaklaşımların kapsamlı bir listesi olarak hazırlanmıştır.

Kurulum Testi

Kurulum testi, sistemin doğru bir şekilde yüklendiğini ve gerçek müşteri donanımında çalıştığını garanti eder.

Kutu Yaklaşımı

Yazılım test yöntemleri geleneksel olarak beyaz kutu testi ve kara kutu testi olarak ikiye ayrılır. Bu iki yaklaşım, bir test mühendisinin test senaryolarını tasarlarken aldığı bakış açısını tanımlamak için kullanılır.

Beyaz Kutu Testi

Beyaz kutu testi (aynı zamanda açık kutu testi, cam kutu testi, şeffaf kutu testi ve yapısal test olarak da bilinir, kaynak kodu görerek yapılır) bir programın işlevselliğinden ziyade, iç yapısını veya çalışma şeklini test eder. Beyaz kutu testinde, sistemin içsel bir perspektifi ve programlama becerileri kullanılarak test senaryoları tasarlanır. Test yapan kişi, kod içerisindeki yolları çalıştırmak ve uygun çıktıları belirlemek için girdiler seçer. Bu, devre üzerindeki düğümleri test etmeye, örneğin devre içi test (ICT) yapmaya benzer.

Beyaz kutu testi, yazılım test sürecinin birim, entegrasyon ve sistem seviyelerinde uygulanabilse de, genellikle birim seviyesinde yapılır. Birim içindeki yolları, entegrasyon sırasında birimler arasındaki yolları ve sistem seviyesindeki bir test sırasında alt sistemler arasındaki yolları test edebilir. Bu test tasarımı yöntemi birçok hata veya problemi ortaya çıkarabilse de, uygulanmamış kısımları veya eksik gereksinimleri tespit edemeyebilir.

Beyaz kutu testinde kullanılan teknikler şunlardır:

• API testi – uygulamanın genel ve özel API'ler (uygulama programlama arayüzleri) kullanılarak test edilmesi
• Kod kapsamı – kod kapsamının bazı ölçütlerini karşılamak için testler oluşturma (örneğin, test tasarımcısı programdaki tüm ifadelerin en az bir kez yürütülmesini sağlayacak testler oluşturabilir)
• Hata enjeksiyon yöntemleri – test stratejilerinin etkinliğini ölçmek için kasıtlı olarak hatalar eklemek
• Mutasyon test yöntemleri
• Statik test yöntemleri

Kod kapsama araçları, siyah kutu testleri de dahil olmak üzere herhangi bir yöntemle oluşturulmuş bir test setinin tamamlanma derecesini değerlendirebilir. Bu, yazılım ekibinin nadiren test edilen sistem parçalarını incelemesine olanak tanır ve en önemli işlev noktalarının test edildiğinden emin olmasını sağlar.Kod kapsama, bir yazılım metriği olarak şu şekilde yüzde olarak raporlanabilir:

• Fonksiyon kapsama, yürütülen fonksiyonlar hakkında rapor veren kapsama türüdür.
• İfade kapsama, testi tamamlamak için yürütülen satır sayısı hakkında rapor veren kapsama türüdür.
• Karar kapsama, belirli bir testin hem Doğru hem de Yanlış dalının yürütülüp yürütülmediği hakkında rapor veren kapsama türüdür.

%100 ifade kapsaması, tüm kod yollarının veya dallarının (kontrol akışı açısından) en az bir kez yürütüldüğünü garanti eder. Bu, doğru işlevselliğin sağlanmasında faydalıdır, ancak aynı kodun farklı girdileri doğru veya yanlış bir şekilde işleyebilmesi nedeniyle yeterli değildir.

Siyah kutu testi

Black box diagram

Siyah kutu testi, yazılımı bir 'siyah kutu' olarak ele alır, iç uygulama hakkında herhangi bir bilgiye sahip olmadan, kaynak kodunu görmeden işlevselliği inceler. Test edenler, yazılımın ne yapması gerektiğini bilirler, ancak nasıl yaptığını bilmezler. Siyah kutu test yöntemleri arasında şunlar yer alır: eşdeğerlik bölümlendirmesi, sınır değer analizi, tüm çiftler testi, durum geçiş tabloları, karar tablosu testi, bulanıklık testi, model tabanlı test, kullanım durumu testi, keşif testi ve spesifikasyon tabanlı test.

Spesifikasyon tabanlı test, yazılımın uygulanabilir gereksinimlere göre işlevselliğini test etmeyi amaçlar. Bu seviyedeki testler genellikle test eden kişiye sağlanması gereken kapsamlı test senaryolarını gerektirir; böylece test eden kişi, belirli bir girdi için çıkış değerinin (veya davranışının) test senaryosunda belirtilen beklenen değerle 'aynı olup olmadığını' doğrulayabilir. Test senaryoları, uygulamanın ne yapması gerektiği yani spesifikasyonlar ve gereksinimler etrafında oluşturulur. Bu testler, test senaryolarını türetmek için yazılımın dış tanımlarını, spesifikasyonları, gereksinimleri ve tasarımları kullanır. Bu testler işlevsel veya işlevsel olmayan olabilir, ancak genellikle işlevseldir.

Spesifikasyon tabanlı test, doğru işlevselliği sağlamak için gerekli olabilir, ancak karmaşık veya yüksek riskli durumlara karşı koruma sağlamak için yeterli değildir.

Siyah kutu tekniğinin bir avantajı, herhangi bir programlama bilgisi gerektirmemesidir. Programcıların sahip olduğu önyargılar ne olursa olsun, test eden kişi muhtemelen farklı bir önyargı setine sahiptir ve işlevselliğin farklı alanlarına vurgu yapabilir. Öte yandan, siyah kutu testinin 'fener olmadan karanlık bir labirentte yürümek gibi' olduğu söylenmiştir. Kaynak kodunu incelemedikleri için, bir test eden kişi bazen sadece bir test senaryosuyla kontrol edilebilecek bir şeyi kontrol etmek için birçok test senaryosu yazabilir veya programın bazı bölümlerini test etmeden bırakabilir.

Bu test yöntemi, yazılım testinin tüm seviyelerine: birim, entegrasyon, sistem ve kabul testine uygulanabilir. Genellikle, daha yüksek seviyelerdeki testlerin çoğunu, hatta hepsini kapsar, ancak birim testlerinde de baskın olabilir.

Görsel test

Görsel testin amacı, yazılım hatası meydana geldiği anda geliştiricilere neler olduğunu inceleme yeteneği sağlamaktır. Bu, verilerin geliştiricinin ihtiyaç duyduğu bilgiyi kolayca bulabileceği şekilde sunulması ve bilginin net bir şekilde ifade edilmesiyle gerçekleştirilir.

Görsel testin temelinde, bir problemi (veya bir test hatasını) sadece tarif etmek yerine birine göstermek, netlik ve anlayışı büyük ölçüde artırır fikri yer almaktadır. Bu nedenle görsel test, tüm test sürecinin kaydedilmesini gerektirir; bu, test sisteminde meydana gelen her şeyi video formatında yakalamayı içerir. Çıktı videoları, görüntü içinde görüntü (picture-in-picture) web kamerası aracılığıyla gerçek zamanlı test eden girişi ve mikrofonlardan alınan sesli yorumlarla desteklenir.

Görsel test, bir dizi avantaj sunar. Test edenler, problemi (ve ona neden olan olayları) geliştiriciye gösterebildiği için iletişimin kalitesi büyük ölçüde artar; bu da durumu sadece tarif etmekten çok daha etkilidir ve birçok durumda test hatalarını tekrarlama ihtiyacı ortadan kalkar. Geliştirici, bir test hatasıyla ilgili ihtiyaç duyduğu tüm kanıtlara sahip olacak ve bunun yerine hatanın nedenine ve nasıl düzeltileceğine odaklanabilecektir.

Görsel test, yazılım geliştirmede çevik yöntemlerin uygulandığı ortamlara özellikle uygundur, çünkü çevik yöntemler test edenler ile geliştiriciler arasında daha fazla iletişim ve küçük ekipler içinde iş birliği gerektirir.

özel testler ve keşifsel testler, yazılım bütünlüğünü kontrol etmek için önemli metodolojilerdir, çünkü uygulanmaları için daha az hazırlık süresi gerektirir ve önemli hatalar hızlı bir şekilde bulunabilir. Ad hoc testinde, testin doğaçlama ve anlık bir şekilde gerçekleştirildiği durumlarda, bir test aracının sistemde meydana gelen her şeyi görsel olarak kaydetme yeteneği, hatayı bulmak için atılan adımların belgelenmesi açısından çok önemlidir.

Görsel test, müşteri kabul ve kullanılabilirlik testlerinde tanınmaya başlıyor, çünkü bu test, geliştirme sürecine dahil olan birçok birey tarafından kullanılabilir. Müşteri için, ayrıntılı hata raporları ve geri bildirim sağlamak kolaylaşır ve program kullanıcıları için görsel test, ekran üzerindeki kullanıcı eylemlerini, ayrıca ses ve görüntülerini kaydederek yazılım hatası anında geliştiricilere tam bir görünüm sunabilir.

Daha detaylı bilgi için: Graphical user interface testing

Gri kutu testi

Gri kutu testi, testleri tasarlamak amacıyla iç veri yapıları ve algoritmalar hakkında bilgi sahibi olmayı içerir, ancak bu testler kullanıcı veya siyah kutu düzeyinde yürütülür. Test edenin, yazılımın kaynak koduna tam erişime sahip olması gerekmez. Girdi verilerini manipüle etmek ve çıktıyı biçimlendirmek gri kutu testi olarak sayılmaz, çünkü girdi ve çıktı, test ettiğimiz sistem olarak adlandırdığımız 'siyah kutunun' dışında net bir şekilde yer alır. Bu ayrım, iki farklı geliştirici tarafından yazılan iki kod modülü arasında entegrasyon testi yaparken özellikle önemlidir; burada yalnızca arayüzler test için açığa çıkar.

Ancak, bir arka uç veri deposunu (örneğin bir veritabanı veya bir günlük dosyası) değiştirmeyi gerektiren testler gri kutu testi olarak kabul edilir, çünkü kullanıcı normal üretim işlemlerinde genellikle veri deposunu değiştirme yeteneğine sahip değildir. Gri kutu testi ayrıca, örneğin, sınır değerleri veya hata mesajlarını belirlemek için tersine mühendisliği yapmayı da içerebilir.

Yazılımın nasıl çalıştığına dair temel kavramları bilmek, test edenin yazılımı dışarıdan test ederken daha iyi bilgiye dayalı test seçimleri yapmasını sağlar. Genellikle, bir gri kutu test edicisinin, bir veritabanına beslemek gibi faaliyetlerle izole bir test ortamı kurmasına izin verilir. Test eden, veritabanına karşı SQL ifadeleri çalıştırma gibi belirli işlemler gerçekleştirdikten sonra test edilen ürünün durumunu gözlemleyebilir ve ardından beklenen değişikliklerin yansıtıldığından emin olmak için sorgular çalıştırabilir. Gri kutu testi, sınırlı bilgilere dayanarak akıllı test senaryoları uygular. Bu durum, özellikle veri türü yönetimi, istisna işleme gibi konularda geçerlidir.

Otomatik test

Pek çok programlama grubu, özellikle test odaklı geliştirme test odaklı geliştirmeyi kullanan gruplar, otomatik testlere giderek daha fazla bağımlı hale geliyor. Test yazmak için birçok çerçeve bulunmaktadır ve sürekli entegrasyon yazılımı, kod bir sürüm kontrol sistemine her kontrol edildiğinde testleri otomatik olarak çalıştıracaktır.

Otomasyon, bir insanın yapabileceği her şeyi (ve bunu yapmanın düşündüğü tüm yolları) yeniden üretemezken, regresyon testi için oldukça faydalı olabilir. Ancak, gerçekten faydalı olabilmesi için iyi geliştirilmiş bir test paketine ihtiyaç duyar.

Otomatik test araçları

Program testi ve hata tespiti, test araçları ve hata ayıklayıcılar ile önemli ölçüde desteklenebilir. Test/hata ayıklama araçları şunları içerebilir:

• Program monitörleri, program kodunun tam veya kısmi izlenmesine izin verir ve şunları içerir:
  • Talimat seti simülatörü, tam talimat düzeyinde izleme ve izleme olanakları sağlar.
  • Hypervisor, program kodunun yürütülmesi üzerinde tam kontrol sağlar ve şunları içerir:
  • Program animasyonu, kaynak düzeyinde veya makine kodunda adım adım yürütme ve koşullu kesme noktasınasağlamaktadır.
  • Kod kapsamı raporları
• Biçimlendirilmiş döküm veya sembolik hata ayıklama, hata durumunda veya seçilen noktalarda program değişkenlerinin incelenmesine olanak tanıyan araçlardır.
• Otomatik işlevsel GUI (Grafiksel Kullanıcı Arayüzü) test araçları, GUI üzerinden sistem düzeyinde testleri tekrarlamak için kullanılır.
• Karşılaştırma standartları, çalışma zamanı performans karşılaştırmalarının yapılmasına olanak tanır.
• Performans analizi (veya profil oluşturma araçları), yoğun noktaları ve kaynak kullanımını vurgulamaya yardımcı olabilir.

Bu özelliklerin bazıları, tek bir bileşik araç veya Entegre Geliştirme Ortamında (IDE) içine entegre edilebilir.

Otomatik teste uygulanan uygulama katmanlarının soyutlanması

Genellikle dört tanınan test seviyesi vardır: birim testi, entegrasyon testi, bileşen arayüz testi ve sistem testi. Testler, sıklıkla yazılım geliştirme sürecinde eklenme yerlerine veya testin spesifiklik seviyesine göre gruplandırılır. SWEBOK kılavuzunda tanımlanan geliştirme sürecindeki ana seviyeler, test hedefine göre ayrılan birim, entegrasyon ve sistem testidir; belirli bir süreç modelini ima etmez. Other test levels are classified by the testing objective.

Müşteriler perspektifinden iki farklı test seviyesi vardır: düşük seviyeli test (LLT) ve yüksek seviyeli test (HLT). LLT, yazılım uygulamasının veya ürününün farklı seviyedeki bileşenleri için bir test grubudur. HLT ise, tüm yazılım uygulaması veya ürünü için bir test grubudur.

Birim testi

Birim testi, genellikle işlev düzeyinde, belirli bir kod bölümünün işlevselliğini doğrulayan testlere atıfta bulunur. Nesne yönelimli bir ortamda, bu genellikle sınıf düzeyindedir ve minimum birim testleri, yapıcılar (constructors) ve yıkıcılar (destructors) içerir.

Bu tür testler genellikle geliştiriciler tarafından kod üzerinde çalışırken (beyaz kutu tarzında) yazılır, böylece belirli bir işlevin beklendiği gibi çalıştığından emin olurlar. Bir işlevin, köşe durumlarını veya kod içindeki diğer dalları yakalamak için birden fazla testi olabilir. Birim testi tek başına bir yazılım parçasının işlevselliğini doğrulamaz; bunun yerine, yazılımın yapı taşlarının birbirinden bağımsız olarak çalıştığından emin olmak için kullanılır.

"Geliştirme testi", yazılım geliştirme sürecinde, yazılım geliştirme risklerini, zamanını ve maliyetlerini azaltmak amacıyla geniş bir hata önleme ve tespit stratejileri yelpazesesinin senkronize uygulanmasını içeren bir süreçtir. Yazılım geliştirici veya mühendis tarafından, yazılım geliştirme yaşam döngüsünün inşa aşamasında gerçekleştirilir. Geleneksel kalite güvencesi (QA) odaklarını değiştirmek yerine, bunları tamamlar. Geliştirme testi, kodun QA'ya aktarılmadan önce inşa hatalarını ortadan kaldırmayı amaçlar; bu strateji, elde edilen yazılımın kalitesini artırmayı ve genel geliştirme ile QA sürecinin verimliliğini yükseltmeyi hedefler.

Kuruluşun yazılım geliştirme beklentilerine bağlı olarak, geliştirme testi statik kod analizi, veri akışı analizi, ölçüm analizi, akran kod incelemeleri, kod kapsamı analizi ve diğer yazılım doğrulama uygulamalarını içerebilir.

Entegrasyon testi

Entegrasyon testi, yazılım tasarımına karşı bileşenler arasındaki arayüzleri doğrulamayı amaçlayan her türlü yazılım testidir. Yazılım bileşenleri, yinelemeli bir şekilde veya hepsi bir arada ('büyük patlama') entegre edilebilir. Normalde, ilk yöntem daha iyi bir uygulama olarak kabul edilir çünkü arayüz sorunlarının daha hızlı bir şekilde tespit edilmesini ve düzeltilmesini sağlar.

Entegrasyon testi, entegre bileşenler (modüller) arasındaki arayüzlerde ve etkileşimlerdeki hataları ortaya çıkarmayı amaçlar. Mimari tasarımın unsurlarına karşılık gelen, test edilen yazılım bileşenlerinin giderek daha büyük grupları entegre edilip test edilerek yazılım bir sistem olarak çalışana kadar devam eder.

Bileşen arayüz testi

Bileşen arayüz testi uygulaması, bu birimler arasındaki tam entegrasyon testinin ötesinde, çeşitli birimler veya alt sistem bileşenleri arasında iletilen verilerin işlenmesini kontrol etmek için kullanılabilir. Geçen veriler 'mesaj paketleri' olarak düşünülebilir ve bir birimden üretilen veriler için aralık veya veri türleri kontrol edilebilir ve başka bir birime geçmeden önce geçerliliği test edilebilir. Arayüz testinin bir seçeneği, iletilen veri öğelerinin ayrı bir günlük dosyasını tutmaktır; genellikle analiz için zaman damgası kaydedilir ve bu sayede birimler arasında günler veya haftalar boyunca iletilen binlerce veri durumu incelenebilir. Testler, bazı aşırı veri değerlerinin işlenmesini kontrol etmeyi içerebilirken, diğer arayüz değişkenleri normal değerler olarak iletilebilir. Arayüzdeki alışılmadık veri değerleri, bir sonraki birimde beklenmeyen performansı açıklamaya yardımcı olabilir. Bileşen arayüz testi, bir alt sistem bileşeninin yalnızca ilgili eylemlerinin ötesinde, veri değerlerine odaklanan bir kara kutu testinin, testinin bir varyasyonudur.

Sistem testi

Sistem testi, tamamen entegre bir sistemi test ederek sistemin gereksinimlerini karşıladığını doğrular. Örneğin, bir sistem testi, bir giriş arayüzünü test etmeyi, ardından bir kayıt oluşturmayı ve düzenlemeyi, sonuçları göndermeyi veya yazdırmayı, ardından kayıtların özet işlenmesini veya silinmesini (veya arşivlenmesini) ve son olarak çıkışı (logoff) içerebilir.

Operasyonel kabul testi

Operasyonel kabul, bir ürün, hizmet veya sistemin operasyonel hazır olduğunu (ön sürüm) belirlemek amacıyla kalite yönetim sisteminin bir parçası olarak kullanılır. OAT, yazılım geliştirme ve yazılım bakımı projelerinde yaygın olarak kullanılan bir tür işlevsel olmayan yazılım testidir. Bu tür test, desteklenecek sistemin operasyonel olarak hazır olup olmadığına ve/veya üretim ortamının bir parçası haline gelmesine odaklanır. Bu nedenle, operasyonel hazırlık testi (ORT) veya Operasyonel hazırlık ve güvence (OR&A) testi olarak da bilinir. OAT içindeki işlevsel testler, sistemin işlevsel olmayan yönlerini doğrulamak için gereken testlerle sınırlıdır.

Ayrıca, yazılım testleri, sistemin taşınabilirliğini sağlamakla birlikte beklendiği gibi çalıştığından emin olmalı; ayrıca, işletim ortamını zarar vermemeli veya kısmen bozarak o ortam içindeki diğer süreçlerin çalışmaz hale gelmesine neden olmamalıdır.

Uyumluluk testi

Yazılım hatalarının (gerçek veya algılanan) yaygın bir nedeni, diğer uygulama yazılımlarıyla işletim sistemleriyle (veya işletim sistemi sürümleriyle, eski veya yeni) veya orijinalden büyük ölçüde farklı hedef ortamlarla uyumsuzluğudur(compatibility). (Örneğin, masaüstünde çalıştırılması amaçlanan bir terminal veya GUIuygulamasının şimdi bir web uygulaması haline gelmesi gerektiğinde, bu durum geçerlidir ve uygulamanın bir web tarayıcısında render edilmesi gerekmektedir.) geriye dönük uyumluluğun eksikliği durumunda, bu durum, programcıların yazılımı yalnızca hedef ortamın en son sürümünde geliştirip test etmesinden kaynaklanabilir; bu da tüm kullanıcıların çalıştırmadığı bir sürüm olabilir. Bu, en son çalışmanın, hedef ortamın daha önceki sürümlerinde veya önceki sürümlerin kullanabildiği daha eski donanımlarda çalışmamasına neden olan istenmeyen bir sonuç doğurur. Bazen bu tür sorunlar, işletim sistemi işlevselliğini ayrı bir program modülüne veya kütüphaneye proaktif olarak soyutlanmasıyla düzeltilebilir.

Smoke ve sağlamlık testi

Sağlamlık testi, daha fazla test yapmanın mantıklı olup olmadığını belirler.

Smoke testi,, yazılımı çalıştırmak için minimum denemelerden oluşur ve yazılımın çalışmasını tamamen engelleyecek temel sorunların olup olmadığını belirlemek için tasarlanmıştır. Bu tür testler, derleme doğrulama testi olarak da kullanılabilir.

Regresyon testi

Regresyon testi, büyük bir kod değişikliği sonrası hataları bulmaya odaklanır. Özellikle eski hataların geri gelmesi gibi bozulmuş veya kaybolmuş özellikler gibi yazılım gerilemelerini ortaya çıkarmayı amaçlar. Bu tür regresyonlar, yazılım işlevselliğinin daha önce doğru çalıştığı durumların, artık istenildiği gibi çalışmamaya başlaması durumunda meydana gelir. Genellikle regresyonlar, program değişikliklerinin beklenmeyen bir sonucu olarak ortaya çıkar; yeni geliştirilen yazılım bileşeni, daha önce mevcut olan kodla çakıştığında oluşur. Regresyon testinin yaygın yöntemleri arasında, önceki test vakalarının yeniden çalıştırılması ve daha önce düzeltilmiş hataların tekrar ortaya çıkıp çıkmadığının kontrol edilmesi bulunmaktadır. Testlerin derinliği, sürüm sürecinin aşamasına ve eklenen özelliklerin riskine bağlıdır. Değişiklikler, sürümün sonlarına doğru eklenmiş veya riskli olarak değerlendirilmişse, testler tamamen kapsamlı olabilir; eğer değişiklikler sürümün başında yapılmış veya düşük riskli olarak değerlendiriliyorsa, her bir özellik için yalnızca pozitif testlerden oluşan çok yüzeysel testler yapılabilir. Regresyon testi, önceki yazılım özelliklerindeki çok sayıda ayrıntının kontrol edilmesi nedeniyle genellikle ticari yazılım geliştirmedeki en büyük test çabasıdır ve hatta önceki işlevselliğin hala desteklendiğinden emin olmak için yeni tasarımın parçalarını test etmek amacıyla bazı eski test durumları kullanılarak yeni yazılım bile geliştirilebilir.

Kabul testi

Kabul testi iki anlamına gelebilir:

1. Smoke testi, yeni bir sürümü ana test sürecine dahil etmeden önce, yani entegrasyon veya regresyondan öncesinde kabul testi olarak kullanılır.
2. Müşteri tarafından, genellikle kendi laboratuvar ortamlarında kendi donanımları üzerinde gerçekleştirilen kabul testine kullanıcı kabul testi (UAT) denir. Kabul testi, geliştirme sürecinin herhangi iki aşaması arasındaki devretme sürecinin bir parçası olarak da yapılabilir.

Alfa testi

Alfa testi, potansiyel kullanıcılar/müşteriler veya bağımsız bir test ekibi tarafından geliştiricilerin sitesinde gerçekleştirilen simüle edilmiş veya gerçek operasyonel testlerdir. Alfa testi, yazılımın beta testine geçmeden önce, genellikle raf ürünleri için iç kabul testi şeklinde kullanılır.

Beta testi

Beta testi, alfa testinden sonra gelir ve bir tür harici kullanıcı kabul testi bir biçimi olarak değerlendirilebilir. Beta sürümleri olarak bilinen yazılım versiyonları, beta tester olarak adlandırılan programlama ekibinin dışındaki sınırlı bir kitleye sunulur. Yazılım, ürünün daha az hata veya kusur içermesini sağlamak için daha fazla test yapılabilmesi amacıyla insan gruplarına dağıtılır. Beta sürümleri, geri bildirim alanını maksimum sayıda gelecekteki kullanıcıya genişletmek ve değeri daha erken sunmak için halka açık hale getirilebilir; bu süre uzatılabilir veya sınırsız bir süre ( sürekli beta ) olarak devam edebilir.

Fonksiyonel Test vs. Fonksiyonel Olmayan Test

Fonksiyonel test, kodun belirli bir eylemini veya işlevini doğrulayan faaliyetleri ifade eder. Bu testler genellikle kod gereksinimleri belgelerinde yer alır; ancak bazı geliştirme metodolojileri, kullanım senaryoları veya kullanıcı hikayeleri üzerinden çalışır. Fonksiyonel testler, genellikle "kullanıcı bunu yapabilir mi?" veya "bu belirli özellik çalışıyor mu?" sorularını yanıtlamaya odaklanır.

Fonksiyonel olmayan test, yazılımın belirli bir işlev veya kullanıcı eylemiyle doğrudan ilişkili olmayan yönlerini ifade eder; örneğin, ölçeklenebilirlik veya diğer performans, belirli kısıtlamalar altındaki davranış veya güvenlik gibi. Bu testler, aşırı ölçeklenebilirlik veya performansın dengesiz çalışmaya neden olduğu kırılma noktasını belirler. Fonksiyonel olmayan gereksinimler genellikle ürünün kalitesini yansıtan gereksinimlerdir ve özellikle kullanıcıların uygunluk perspektifinde önem taşır.

Sürekli Test

Sürekli test, yazılım teslimat sürecinin bir parçası olarak otomatik testlerin yürütülmesi sürecidir; bu, bir yazılım sürüm adayının iş riskleri hakkında anında geri bildirim almak için kullanılır. Sürekli test, işlevsel gereksinimlerin hem de işlevsel olmayan gereksinimlerin doğrulanmasını içerir; test kapsamı, alt düzey gereksinimlerin veya kullanıcı hikayelerinin doğrulanmasından, genel iş hedefleriyle ilişkili sistem gereksinimlerinin değerlendirilmesine kadar uzanır.

Yıkıcı Test

Yıkıcı test, yazılımın veya bir alt sistemin başarısız olmasını sağlamaya yönelik bir çabadır. Yazılımın, geçersiz veya beklenmedik girişler aldığında bile düzgün çalıştığını doğrulayarak, giriş doğrulama ve hata yönetimi rutinlerinin sağlamlığını belirler. Bulanıklaştırma biçimindeki yazılım hata enjeksiyonu, arıza testinin bir örneğidir. Yazılım hata enjeksiyon sayfasından çeşitli ticari işlevsel olmayan test araçlarına bağlantılar verilmiştir; ayrıca yıkıcı test gerçekleştiren çok sayıda açık kaynaklı ve ücretsiz yazılım aracı da mevcuttur.

Daha fazla bilgi: Exception handling ve Recovery testing

Yazılım Performans Testi

Performans testi, genellikle bir sistemin veya alt sistemin belirli bir yük altında yanıt verme süresi ve stabilite açısından nasıl performans gösterdiğini belirlemek amacıyla gerçekleştirilir. Ayrıca, sistemin ölçeklenebilirliği, güvenilirliği ve kaynak kullanımı gibi diğer kalite özelliklerini incelemek, ölçmek, doğrulamak veya onaylamak için de kullanılabilir.

Yük testi, sistemin belirli bir yük altında (ister büyük veri miktarları ister çok sayıda kullanıcı olsun) çalışmaya devam edebilmesini test etmeye odaklanır. Bu genellikle yazılım ölçeklenebilirliği olarak adlandırılır. İlgili yük testi etkinliği, fonksiyonel olmayan bir aktivite olarak gerçekleştirildiğinde genellikle dayanıklılık testi (endurance testing) olarak anılır. Hacim testi, yazılım işlevlerini belirli bileşenlerin (örneğin bir dosya veya veritabanı) boyutunun radikal bir şekilde arttığı durumlarda test etme yöntemidir. Stres testi, beklenmedik veya nadir yükler altında güvenilirliği test etmenin bir yoludur. Stabilite testi (genellikle yük veya dayanıklılık testi olarak adlandırılır), yazılımın kabul edilebilir bir süre içinde ya da üzerinde sürekli olarak iyi çalışıp çalışmadığını kontrol eder.

Performans testinin belirli hedefleri konusunda pek az fikir birliği vardır. Yük testi, performans testi, ölçeklenebilirlik testi ve hacim testi terimleri genellikle birbirinin yerine kullanılır.

Gerçek zamanlı yazılım sistemlerinin katı zamanlama kısıtlamaları vardır. Zamanlama kısıtlamalarının karşılanıp karşılanmadığını test etmek için gerçek zamanlı test kullanılır.

Kullanılabilirlik Testi

Kullanılabilirlik testi, kullanıcı arayüzünün kullanımı ve anlaşılması kolay olup olmadığını kontrol etmektir. Esas olarak uygulamanın kullanımı ile ilgilidir.

Erişilebilirlik testi

Erişilebilirlik testi, aşağıdaki gibi standartlara uyumu içerebilir:

• 1990 Engelli Amerikalılar Yasası
• 1973 Rehabilitasyon Yasası'nın 508. Bölüm Değişikliği
• Dünya Çapında Ağ Konsorsiyumu'nun (W3C) Web Erişilebilirliği Girişimi (WAI)

Güvenlik testi

Gizli verileri işleyen yazılımlar için güvenlik testi(Security testing), hackerlar(hackers) tarafından gerçekleştirilen sistem ihlallerini(system intrusion) önlemek amacıyla hayati önem taşır.

Uluslararası Standardizasyon Örgütü (ISO), bunu "bir test nesnesinin ve ilgili veri ile bilgilerin, yetkisiz kişilerin veya sistemlerin bunları kullanmasını, okumasını veya değiştirmesini engelleyecek şekilde korunma derecesini değerlendirmek amacıyla gerçekleştirilen bir test türü" olarak tanımlar.

Uluslararasılaştırma ve Yerelleştirme Testi

Yazılımın uluslararasılaştırılma ve yerelleştirilme genel yeteneği, gerçek bir çeviriye gerek kalmadan, sözde yerelleştirme kullanılarak otomatik olarak test edilebilir. Uygulamanın yeni bir dile çevrildikten veya yeni bir kültüre (örneğin farklı para birimleri veya saat dilimleri) uyarlandıktan sonra bile çalışmaya devam ettiğini doğrulayacaktır.

Gerçek dillerdeki çevirilerin de test edilmesi gerekmektedir. Olası yerelleştirme hataları şunları içerebilir:

• Yazılım genellikle bağlamdan bağımsız olarak bir dizi dizeyi çevirerek yerelleştirilir ve çevirmen, belirsiz bir kaynak dizesi için yanlış bir çeviri seçebilir.
• Teknik terimler, proje birkaç kişi tarafından doğru koordinasyon olmadan veya çevirmen dikkatsizse tutarsız hale gelebilir.
• Kelime kelime yapılan çeviriler, hedef dilde uygunsuz, yapay veya çok teknik görünebilir.
• Orijinal dildeki bazı mesajlar, kaynak kodda sabit olarak bırakılabilir.
• Bazı mesajlar, çalışma zamanında otomatik olarak oluşturulabilir ve sonuçta ortaya çıkan dize dil bilgisel olarak hatalı, işlevsel olarak yanlış, yanıltıcı veya kafa karıştırıcı olabilir.
• Yazılım, kaynak dilin klavye düzeninde herhangi bir işlevi olmayan, ancak hedef dilin düzeninde karakter yazmak için kullanılan bir klavye kısayolu kullanabilir.
• Yazılım, hedef dilinkarakter kodlamasını desteklemiyor olabilir.
• Kaynak dilde uygun olan fontlar ve font boyutları, hedef dilde uygun olmayabilir; örneğin, CJK karakterleri, font çok küçükse okunamaz hale gelebilir.
• Hedef dildeki bir dize, yazılımın işleyebileceğinden daha uzun olabilir. Bu, dizeyi kullanıcının göremeyeceği şekilde kısmen görünmez hale getirebilir veya yazılımın çökmesine veya işlevsiz hale gelmesine neden olabilir.
• Yazılım, çift yönlü metin okumak veya yazmak için doğru desteklemeyi sağlamıyor olabilir.
• Yazılım, yerelleştirilmemiş metin içeren görüntüleri görüntüleyebilir.
• Yerelleştirilmiş işletim sistemleri farklı adlandırılmış sistem yapılandırma dosyalarına ve ortam değişkenlerine ve tarih ve para birimi için farklı biçimlere sahip olabilir.

Geliştirme testi

Birim testi, yazılım geliştirme sürecidir ve yazılım geliştirme risklerini, zamanını ve maliyetlerini azaltmak amacıyla geniş bir hata önleme ve tespit stratejilerinin senkronize bir şekilde uygulanmasını içerir. Yazılım geliştiricisi veya mühendisi tarafından yazılım geliştirme yaşam döngüsünün inşa aşaması sırasında gerçekleştirilir. Geleneksel kalite güvence (QA) odaklarını değiştirmek yerine, bunları tamamlar. Birim testi, kodun QA'ya terfi etmeden önce inşa hatalarını ortadan kaldırmayı amaçlar; bu strateji, sonuçta ortaya çıkan yazılımın kalitesini artırmayı ve genel geliştirme ve QA sürecinin verimliliğini artırmayı hedefler.

Kuruluşun yazılım geliştirmeye ilişkin beklentilerine bağlı olarak, Geliştirme Testi statik kod analizi, veri akışı analizi, ölçüm analizi, akran kod incelemeleri, birim testi, kod kapsamı analizi, izlenebilirlik ve diğer yazılım doğrulama uygulamalarını içerebilir.

A/B testi

A/B testi, temelde iki çıktının karşılaştırılmasıdır; genellikle yalnızca bir değişkenin değiştiği durumlarda uygulanır: bir test çalıştırılır, bir şey değiştirilir, test tekrar çalıştırılır ve sonuçlar karşılaştırılır. Bu yöntem, daha küçük ölçekli durumlarda daha faydalı olsa da, herhangi bir programın ince ayarını yapmak için oldukça etkilidir. Daha karmaşık projelerde ise çok değişkenli testler (multivariant testing) gerçekleştirilebilir.

Eşzamanlı Test

Eşzamanlı testlerde, stres testi veya tüy testinin aksine, normal girdiyle ve normal çalışma koşullarında sürekli çalışırken performansa odaklanılır. Bellek sızıntılarının yanı sıra temel hataları da bu yöntemle bulmak daha kolaydır.

Uyum testi veya Tür testi

Yazılım testinde, uyum testi bir ürünün belirlenen standartlara göre performans gösterip göstermediğini doğrular. Örneğin, derleyiciler, o dil için tanınmış standartları karşılayıp karşılamadığını belirlemek amacıyla kapsamlı bir şekilde test edilir.