Yazılım Testi - Hızlı Kılavuz

Test Nedir?

Test, belirtilen gereksinimleri karşılayıp karşılamadığını bulmak amacıyla bir sistemi veya bileşenlerini değerlendirme sürecidir. Basit bir deyişle, test, gerçek gereksinimlerin aksine herhangi bir boşluk, hata veya eksik gereksinimleri belirlemek için bir sistemi yürütmektir.

ANSI / IEEE 1059 standardına göre, Test şu şekilde tanımlanabilir: - Mevcut ve gerekli koşullar (yani kusurlar / hatalar / hatalar) arasındaki farkları tespit etmek ve yazılım öğesinin özelliklerini değerlendirmek için bir yazılım öğesini analiz etme süreci.

Kim Test Ediyor?

Sürece ve projenin / projelerin ilgili paydaşlarına bağlıdır. BT endüstrisinde, büyük şirketler, geliştirilen yazılımı verilen gereksinimler bağlamında değerlendirme sorumluluklarına sahip bir ekibe sahiptir. Dahası, geliştiriciler ayrıcaUnit Testing. Çoğu durumda, aşağıdaki profesyoneller kendi kapasiteleri dahilinde bir sistemin test edilmesine katılırlar -

• Yazılım Test Cihazı
• Yazılım geliştirici
• Proje Lideri / Yöneticisi
• Son kullanıcı

Farklı şirketler, Yazılım Test Cihazı, Yazılım Kalite Güvence Mühendisi, Kalite Güvence Analisti vb.

Yazılımı çevrimi sırasında herhangi bir zamanda test etmek mümkün değildir. Sonraki iki bölüm, SDLC sırasında testin ne zaman başlatılması gerektiğini ve ne zaman biteceğini belirtir.

Teste Ne Zaman Başlamalı?

Teste erken başlamak, müşteriye teslim edilen hatasız yazılımın yeniden işlenmesi ve üretilmesi için maliyet ve süreyi azaltır. Ancak Yazılım Geliştirme Yaşam Döngüsünde (SDLC) test, Gereksinim Toplama aşamasından başlatılabilir ve yazılımın dağıtımına kadar devam edebilir.

Aynı zamanda kullanılan geliştirme modeline de bağlıdır. Örneğin, Şelale modelinde, test aşamasında resmi test yapılır; ancak artımlı modelde test, her artım / yineleme sonunda gerçekleştirilir ve sonunda tüm uygulama test edilir.

Test, SDLC'nin her aşamasında farklı formlarda yapılır -

• İhtiyaç toplama aşamasında, ihtiyaçların analizi ve doğrulanması da test olarak kabul edilir.

• Tasarımı iyileştirmek amacıyla tasarımın tasarım aşamasında gözden geçirilmesi de test olarak kabul edilir.

• Kodun tamamlanmasının ardından bir geliştirici tarafından gerçekleştirilen testler de test olarak kategorize edilir.

Testi Ne Zaman Durdurmalı?

Testin ne zaman durdurulacağını belirlemek zordur çünkü test hiç bitmeyen bir süreçtir ve hiç kimse bir yazılımın% 100 test edildiğini iddia edemez. Test sürecini durdurmak için aşağıdaki hususlar dikkate alınmalıdır -

• Test Son Tarihleri

• Test senaryosunun yürütülmesinin tamamlanması

• İşlevsel ve kod kapsamının belirli bir noktaya kadar tamamlanması

• Hata oranı belirli bir seviyenin altına düşer ve yüksek öncelikli hata tespit edilmez

• Yönetim kararı

Doğrulama ve Doğrulama

Bu iki terim, onları birbirinin yerine kullanan çoğu insan için çok kafa karıştırıcıdır. Aşağıdaki tablo, doğrulama ve doğrulama arasındaki farkları vurgulamaktadır.

Sr.No.	Doğrulama	Doğrulama
1	Doğrulama şu endişeyi giderir: "Doğru inşa ediyor musunuz?"	Doğrulama şu endişeyi giderir: "Doğru şeyi mi inşa ediyorsunuz?"
2	Yazılım sisteminin tüm işlevselliği karşılamasını sağlar.	İşlevlerin amaçlanan davranışı karşılamasını sağlar.
3	Doğrulama önce gerçekleşir ve dokümantasyon, kod, vb. İçin kontrol içerir.	Doğrulama, doğrulamadan sonra gerçekleşir ve esas olarak tüm ürünün kontrolünü içerir.
4	Geliştiriciler tarafından yapılır.	Test kullanıcıları tarafından yapılır.
5	Bir yazılımı doğrulamak için incelemelerin, izlenecek yolların ve incelemelerin toplanmasını içerdiği için statik etkinlikleri vardır.	Yazılımın ihtiyaçlara göre çalıştırılmasını içerdiği için dinamik faaliyetlere sahiptir.
6	Bu nesnel bir süreçtir ve bir yazılımı doğrulamak için sübjektif bir karara gerek yoktur.	Öznel bir süreçtir ve bir yazılımın ne kadar iyi çalıştığına dair öznel kararları içerir.

Aşağıda, yazılım testi ile ilgili en yaygın efsanelerden bazıları verilmiştir.

Efsane 1: Test Etmek Çok Pahalıdır

Reality- Yazılım geliştirme sırasında test için daha az ödeyin veya daha sonra bakım veya düzeltme için daha fazla ödeyin. Erken test, birçok açıdan hem zamandan hem de maliyetten tasarruf sağlar, ancak test yapmadan maliyeti düşürmek, bir yazılım uygulamasının yanlış tasarlanmasına ve ürünün kullanılmamasına neden olabilir.

Efsane 2: Test Etmek Zaman Alır

Reality- SDLC aşamaları sırasında test asla zaman alıcı bir süreç değildir. Bununla birlikte, uygun test sırasında tespit edilen hataların teşhisi ve düzeltilmesi, zaman alıcı ancak verimli bir faaliyettir.

Efsane 3: Yalnızca Tam Geliştirilmiş Ürünler Test Edilir

Reality- Şüphesiz test, kaynak koda bağlıdır, ancak gereksinimleri gözden geçirmek ve test senaryoları geliştirmek, geliştirilen koddan bağımsızdır. Bununla birlikte, bir geliştirme yaşam döngüsü modeli olarak yinelemeli veya artımlı yaklaşım, testin tamamen geliştirilmiş yazılım üzerindeki bağımlılığını azaltabilir.

Efsane 4: Eksiksiz Test Mümkün

Reality- Bir müşteri veya test uzmanı, eksiksiz testin mümkün olduğunu düşündüğünde sorun olur. Tüm yolların ekip tarafından test edilmiş olması mümkündür, ancak tam bir testin gerçekleşmesi asla mümkün değildir. Yazılım geliştirme yaşam döngüsü boyunca test ekibi veya müşteri tarafından hiçbir zaman yürütülmeyen ve proje dağıtıldıktan sonra yürütülebilecek bazı senaryolar olabilir.

Efsane 5: Test Edilmiş Bir Yazılım Hatasızdır

Reality - Bu, müşterilerin, proje yöneticilerinin ve yönetim ekibinin inandığı çok yaygın bir efsanedir. Mükemmel test becerilerine sahip bir test cihazı uygulamayı test etse bile, hiç kimse bir yazılım uygulamasının% 100 hatasız olduğunu kesin olarak iddia edemez. .

Efsane 6: Kaçırılan Kusurlar Testçilerden kaynaklanır

Reality- Test gerçekleştirildikten sonra bile uygulamada kalan hatalar için test uzmanlarını suçlamak doğru bir yaklaşım değildir. Bu efsane, Kısıtlamaları değiştiren Zaman, Maliyet ve Gereksinimler ile ilgilidir. Ancak test stratejisi, test ekibi tarafından hataların gözden kaçırılmasına da neden olabilir.

Efsane 7: Ürün Kalitesinden Test Uzmanları Sorumludur

Reality- Ürün kalitesinden yalnızca test uzmanlarının veya test ekibinin sorumlu olması gerektiği çok yaygın bir yanlış yorumlamadır. Test uzmanlarının sorumlulukları, paydaşlara hataların tanımlanmasını içerir ve ardından hatayı düzeltip düzeltmeyecekleri veya yazılımı serbest bırakacakları kendi kararlarıdır. Yazılımın o anda piyasaya sürülmesi, herhangi bir hata için suçlanacaklarından, test uzmanlarına daha fazla baskı uygular.

Efsane 8: Test Otomasyonu, Zamanı Azaltmak için mümkün olan her yerde kullanılmalıdır

Reality- Evet, Test Otomasyonunun test süresini kısalttığı doğrudur, ancak yazılım geliştirme sırasında herhangi bir zamanda test otomasyonunu başlatmak mümkün değildir. Test otomatı, yazılım manuel olarak test edildiğinde ve bir dereceye kadar kararlı olduğunda başlatılmalıdır. Dahası, gereksinimler değişmeye devam ederse test otomasyonu asla kullanılamaz.

Efsane 9: Bir Yazılım Uygulamasını Herkes Test Edebilir

Reality- BT endüstrisinin dışındaki insanlar, herhangi birinin bir yazılımı test edebileceğini ve test etmenin yaratıcı bir iş olmadığını düşünüyor ve hatta buna inanıyor. Ancak testçiler bunun bir efsane olduğunu çok iyi biliyorlar. Alternatif senaryolar düşünerek, potansiyel hataları keşfetmek amacıyla bir yazılımı çökertmeye çalışmak, onu geliştiren kişi için mümkün değildir.

Efsane 10: Bir Test Uzmanının tek Görevi Hataları Bulmaktır

Reality- Bir yazılımdaki hataları bulmak, test uzmanlarının görevidir, ancak aynı zamanda, belirli bir yazılımın alan uzmanlarıdırlar. Geliştiriciler yalnızca kendilerine atanan belirli bileşen veya alandan sorumludur, ancak test uzmanları yazılımın genel işleyişini, bağımlılıkların neler olduğunu ve bir modülün başka bir modül üzerindeki etkilerini anlar.

Test, Kalite Güvencesi ve Kalite Kontrolü

Kalite Güvencesi, Kalite Kontrol ve Test arasındaki farkları tespit etmeye gelince çoğu insanın kafası karışır. Birbirleriyle ilişkili olmalarına ve bir dereceye kadar aynı faaliyetler olarak düşünülebilirler, ancak onları ayıran ayırt edici noktalar vardır. Aşağıdaki tablo, Kalite Güvencesi, Kalite Kontrol ve Testi ayıran noktaları listelemektedir.

Kalite güvencesi	Kalite kontrol	Test yapmak
QA, geliştirilen yazılımın ve amaçlanan gereksinimlerin doğrulanması bağlamında süreçlerin, prosedürlerin ve standartların uygulanmasını sağlayan faaliyetleri içerir.	Belgelenmiş (veya bazı durumlarda değil) gereksinimlere göre geliştirilmiş bir yazılımın doğrulanmasını sağlayan faaliyetleri içerir.	Bir yazılımdaki hataların / hataların / kusurların tanımlanmasını sağlayan faaliyetleri içerir.
Sistemde gerçek testler yapmak yerine süreçlere ve prosedürlere odaklanır.	Prosedürlerin ve işlemlerin uygulanması yoluyla hatayı / kusuru tespit etmek amacıyla yazılımı çalıştırarak gerçek testlere odaklanır.	Gerçek testlere odaklanır.
Süreç odaklı faaliyetler.	Ürün odaklı faaliyetler.	Ürün odaklı faaliyetler.
Önleyici faaliyetler.	Düzeltici bir süreçtir.	Önleyici bir süreçtir.
Yazılım Test Yaşam Döngüsünün (STLC) bir alt kümesidir.	QC, Kalite Güvencesinin alt kümesi olarak düşünülebilir.	Test, Kalite Kontrolün alt kümesidir.

Denetim ve Muayene

Audit- Bir organizasyon veya ekip içerisinde gerçek test sürecinin nasıl yürütüldüğünü belirlemeye yönelik sistematik bir süreçtir. Genellikle, bir yazılımın test edilmesi sırasında dahil olan süreçlerin bağımsız bir incelemesidir. IEEE'ye göre, kuruluşların uyguladığı ve takip ettiği belgelenmiş süreçlerin bir incelemesidir. Denetim türleri arasında Yasal Uygunluk Denetimi, İç Denetim ve Sistem Denetimi yer alır.

Inspection- Herhangi bir yapının herhangi bir hatayı veya boşluğu belirleyerek resmi veya gayri resmi teknik incelemelerini içeren resmi bir tekniktir. IEEE94'e göre denetim, yazılım gereksinimlerinin, tasarımlarının veya kodlarının, hataları, geliştirme standartları ihlallerini ve diğer sorunları tespit etmek için yazar dışındaki bir kişi veya grup tarafından ayrıntılı olarak incelendiği resmi bir değerlendirme tekniğidir.

Resmi teftiş toplantıları şu süreçleri içerebilir: Planlama, Genel Bakış Hazırlığı, Teftiş Toplantısı, Yeniden Çalışma ve Takip.

Test ve Hata Ayıklama

Testing- Bir yazılımdaki hatayı / hatayı / kusuru düzeltmeden tanımlamayı içerir. Normalde kalite güvence geçmişine sahip profesyoneller, hataların tespit edilmesinde yer alır. Test, test aşamasında gerçekleştirilir.

Debugging- Sorunların / hataların tanımlanmasını, izole edilmesini ve düzeltilmesini içerir. Yazılımı kodlayan geliştiriciler, kodda bir hatayla karşılaştıklarında hata ayıklama gerçekleştirirler. Hata ayıklama, Beyaz Kutu Testinin veya Birim Testinin bir parçasıdır. Hata ayıklama, geliştirme aşamasında Birim Testi yapılırken veya bildirilen hataları giderirken aşamalar halinde gerçekleştirilebilir.

Dünyanın dört bir yanındaki birçok kuruluş, yazılımlarının kalite ihtiyaçlarını iyileştirmek için farklı standartlar geliştirir ve uygular. Bu bölüm, Kalite Güvencesi ve Test ile ilgili yaygın olarak kullanılan bazı standartları kısaca açıklamaktadır.

ISO / IEC 9126

Bu standart, bir yazılım uygulamasının kalitesini belirlemek için aşağıdaki hususları ele alır:

• Kalite modeli
• Dış ölçümler
• Dahili ölçümler
• Kullanımda kalite ölçütleri

Bu standart, aşağıdakiler gibi herhangi bir yazılım için bazı kalite nitelikleri sunar:

• Functionality
• Reliability
• Usability
• Efficiency
• Maintainability
• Portability

Yukarıda belirtilen kalite nitelikleri, standardı ayrıntılı olarak incelediğinizde çalışabileceğiniz alt faktörlere ayrılmıştır.

ISO / IEC 9241-11

Bu standardın 11. Bölümü, bir ürünün, belirli bir kullanım bağlamında Etkililik, Verimlilik ve Memnuniyet ile belirlenen hedeflere ulaşmak için belirli kullanıcılar tarafından ne ölçüde kullanılabileceği ile ilgilidir.

Bu standart, kullanılabilirlik bileşenlerini ve bunlar arasındaki ilişkiyi tanımlayan bir çerçeve önermiştir. Bu standartta kullanılabilirlik, kullanıcı performansı ve memnuniyeti açısından ele alınmıştır. ISO 9241-11'e göre, kullanılabilirlik kullanım bağlamına bağlıdır ve kullanılabilirlik düzeyi bağlam değiştikçe değişecektir.

ISO / IEC 25000: 2005

ISO / IEC 25000: 2005, genellikle Yazılım Kalitesi Gereksinimleri ve Değerlendirmesi (SQuaRE) için yönergeler sağlayan standart olarak bilinir. Bu standart, yazılım kalite gereksinimleri ve bunların değerlendirilmesiyle ilgili sürecin organize edilmesine ve iyileştirilmesine yardımcı olur. Gerçekte, ISO-25000, iki eski ISO standardının, yani ISO-9126 ve ISO-14598'in yerini alır.

SQuaRE aşağıdaki gibi alt bölümlere ayrılmıştır:

• ISO 2500n - Kalite Yönetimi Bölümü
• ISO 2501n - Kalite Modeli Bölümü
• ISO 2502n - Kalite Ölçüm Bölümü
• ISO 2503n - Kalite Gereksinimleri Bölümü
• ISO 2504n - Kalite Değerlendirme Bölümü

SQuaRE'nin ana içeriği:

• Terimler ve tanımlar
• Referans Modelleri
• Genel Rehber
• Bireysel bölüm kılavuzları
• Gereksinim Mühendisliği ile ilgili standart (yani şartname, planlama, ölçme ve değerlendirme süreci)

ISO / IEC 12119

Bu standart, müşteriye teslim edilen yazılım paketleri ile ilgilidir. Müşterinin üretim sürecine odaklanmıyor veya onunla ilgilenmiyor. Ana içerikler aşağıdaki öğelerle ilgilidir -

• Yazılım paketleri için gereksinimler kümesi.
• Teslim edilen bir yazılım paketini belirtilen gereksinimlere göre test etmek için talimatlar.

Çeşitli

Kalite Güvencesi ve Test süreçleriyle ilgili diğer standartlardan bazıları aşağıda belirtilmiştir -

Sr.No	Standart ve Açıklama
1	IEEE 829 Yazılım testinin farklı aşamalarında kullanılan belgelerin biçimi için bir standart.
2	IEEE 1061 Kalite gereksinimlerini belirlemek, süreci ve yazılım kalite ölçütlerinin ürününü tanımlamak, uygulamak, analiz etmek ve doğrulamak için bir metodoloji.
3	IEEE 1059 Yazılım Doğrulama ve Doğrulama Planları Kılavuzu.
4	IEEE 1008 Birim testi için bir standart.
5	IEEE 1012 Yazılım Doğrulama ve Doğrulama için bir standart.
6	IEEE 1028 Yazılım incelemeleri için bir standart.
7	IEEE 1044 Yazılım anormalliklerinin sınıflandırılması için bir standart.
8	IEEE 1044-1 Yazılım anormalliklerinin sınıflandırılması için bir kılavuz.
9	IEEE 830 Sistem gereksinimleri spesifikasyonlarını geliştirmek için bir kılavuz.
10	IEEE 730 Yazılım kalite güvence planları için bir standart.
11	IEEE 1061 Yazılım kalitesi ölçümleri ve metodolojisi için bir standart.
12	IEEE 12207 Yazılım yaşam döngüsü süreçleri ve yaşam döngüsü verileri için bir standart.
13	BS 7925-1 Yazılım testinde kullanılan bir terim sözlüğü.
14	BS 7925-2 Yazılım bileşen testi için bir standart.

Bu bölüm, SDLC sırasında bir yazılımı test etmek için kullanılabilecek farklı test türlerini açıklamaktadır.

Manuel Test

Manuel test, bir yazılımı manuel olarak, yani herhangi bir otomatik araç veya komut dosyası kullanmadan test etmeyi içerir. Bu türde, test uzmanı bir son kullanıcının rolünü üstlenir ve herhangi bir beklenmedik davranışı veya hatayı belirlemek için yazılımı test eder. Manuel test için birim testi, entegrasyon testi, sistem testi ve kullanıcı kabul testi gibi farklı aşamalar vardır.

Test uzmanları, testin eksiksiz olduğundan emin olmak için bir yazılımı test etmek için test planları, test senaryoları veya test senaryoları kullanır. Manuel test aynı zamanda keşif testini de içerir, çünkü test uzmanları yazılımı içindeki hataları belirlemek için araştırır.

Otomasyon Testi

Test Otomasyonu olarak da bilinen otomasyon testi, test uzmanının komut dosyaları yazması ve ürünü test etmek için başka bir yazılım kullanmasıdır. Bu süreç, manuel bir sürecin otomasyonunu içerir. Otomasyon Testi, manuel, hızlı ve tekrar tekrar gerçekleştirilen test senaryolarını yeniden çalıştırmak için kullanılır.

Regresyon testinin yanı sıra, otomasyon testi de uygulamayı yük, performans ve stres açısından test etmek için kullanılır. Manuel teste kıyasla test kapsamını artırır, doğruluğu artırır ve zamandan ve paradan tasarruf sağlar.

Neyi Otomatikleştirmeli?

Bir yazılımda her şeyi otomatikleştirmek mümkün değildir. Kullanıcıların giriş formu veya kayıt formları gibi işlem yapabileceği alanlar, çok sayıda kullanıcının aynı anda yazılıma erişebileceği her alan otomatikleştirilmelidir.

Ayrıca, tüm GUI öğeleri, veritabanları ile bağlantılar, alan doğrulamaları, vb. Manuel işlem otomatikleştirilerek verimli bir şekilde test edilebilir.

Ne Zaman Otomatikleştirilmeli?

Test Otomasyonu, bir yazılımın aşağıdaki yönleri dikkate alınarak kullanılmalıdır -

• Büyük ve kritik projeler
• Aynı alanların sık sık test edilmesini gerektiren projeler
• Sık değişmeyen gereksinimler
• Birçok sanal kullanıcı ile yük ve performans için uygulamaya erişim
• Manuel teste göre kararlı yazılım
• Zamanın mevcudiyeti

Nasıl Otomatikleştirilir?

Otomasyon, VB komut dosyası oluşturma ve otomatikleştirilmiş bir yazılım uygulaması gibi destekleyici bir bilgisayar dili kullanılarak yapılır. Otomasyon komut dosyalarını yazmak için kullanılabilecek birçok araç vardır. Araçlardan bahsetmeden önce, test sürecini otomatikleştirmek için kullanılabilecek süreci tanımlayalım -

• Otomasyon için bir yazılım içindeki alanları belirleme
• Test otomasyonu için uygun aracın seçimi
• Test komut dosyaları yazma
• Test giysilerinin geliştirilmesi
• Komut dosyalarının yürütülmesi
• Sonuç raporları oluşturun
• Olası hataları veya performans sorunlarını belirleyin

Yazılım Test Araçları

Otomasyon testi için aşağıdaki araçlar kullanılabilir -

• HP Hızlı Test Uzmanı
• Selenium
• IBM Rational Functional Tester
• SilkTest
• TestComplete
• Her Yerde Test Etme
• WinRunner
• LoadRunner
• Visual Studio Test Uzmanı
• WATIR

Yazılım testi için kullanılabilecek farklı yöntemler vardır. Bu bölüm, mevcut yöntemleri kısaca açıklamaktadır.

Kara Kutu Testi

Uygulamanın iç işleyişi hakkında herhangi bir bilgiye sahip olmadan test etme tekniğine kara kutu testi denir. Test cihazı sistem mimarisinden habersizdir ve kaynak koduna erişimi yoktur. Tipik olarak, bir kara kutu testi gerçekleştirirken, bir test cihazı, girişlerin nasıl ve nerede çalışıldığını bilmeden girişler sağlayarak ve çıktıları inceleyerek sistemin kullanıcı arayüzüyle etkileşime girer.

Aşağıdaki tablo kara kutu testinin avantajlarını ve dezavantajlarını listeler.

Avantajlar	Dezavantajları
Büyük kod segmentleri için çok uygun ve verimli.	Sınırlı kapsam, çünkü yalnızca seçilmiş sayıda test senaryosu gerçekten gerçekleştirilmektedir.
Kod erişimi gerekli değildir.	Test yapanın bir uygulama hakkında yalnızca sınırlı bilgiye sahip olması nedeniyle yetersiz test.
Görünür şekilde tanımlanmış roller aracılığıyla kullanıcının bakış açısını geliştiricinin bakış açısından açıkça ayırır.	Kör kapsama, çünkü test uzmanı belirli kod segmentlerini veya hataya açık alanları hedefleyemez.
Orta düzeyde vasıflı çok sayıda test görevlisi, uygulama, programlama dili veya işletim sistemleri hakkında bilgi sahibi olmadan uygulamayı test edebilir.	Test senaryolarının tasarlanması zordur.

Beyaz Kutu Testi

Beyaz kutu testi, kodun iç mantığının ve yapısının ayrıntılı bir incelemesidir. Beyaz kutu testi de denirglass testing veya open-box testing. Gerçekleştirmek içinwhite-box Bir uygulama üzerinde test yaparken, test uzmanının kodun dahili işleyişini bilmesi gerekir.

Test edenin kaynak kodun içine bakması ve kodun hangi biriminin / parçasının uygunsuz şekilde davrandığını bulması gerekir.

Aşağıdaki tablo, beyaz kutu testinin avantaj ve dezavantajlarını listelemektedir.

Avantajlar	Dezavantajları
Test uzmanı kaynak kodu bilgisine sahip olduğundan, hangi tür verilerin uygulamanın etkili bir şekilde test edilmesine yardımcı olabileceğini bulmak çok kolay hale gelir.	Beyaz kutu testi yapmak için yetenekli bir test uzmanına ihtiyaç duyulduğu için maliyetler artar.
Kodu optimize etmeye yardımcı olur.	Bazen birçok yol test edilmeyeceğinden, sorun yaratabilecek gizli hataları bulmak için her köşeye ve köşeye bakmak imkansızdır.
Gizli kusurlara neden olabilecek ekstra kod satırları kaldırılabilir.	Kod çözümleyicileri ve hata ayıklama araçları gibi özel araçlar gerektirdiğinden beyaz kutu testini sürdürmek zordur.
Test uzmanının kod hakkındaki bilgisi sayesinde, test senaryosu yazımı sırasında maksimum kapsama elde edilir.

Gri Kutu Testi

Gri kutu testi, bir uygulamanın dahili çalışmaları hakkında sınırlı bilgiye sahip olarak uygulamayı test etmek için kullanılan bir tekniktir. Yazılım testinde ifade, ne kadar çok bilirseniz, bir uygulamayı test ederken o kadar çok ağırlık taşır.

Bir sistemin etki alanında uzmanlaşmak, test uzmanına her zaman sınırlı alan bilgisine sahip biri üzerinde bir avantaj sağlar. Test uzmanının yalnızca uygulamanın kullanıcı arayüzünü test ettiği kara kutu testinin aksine; gri kutu testinde, test uzmanı tasarım belgelerine ve veri tabanına erişebilir. Bu bilgiye sahip olan bir test uzmanı, bir test planı yaparken daha iyi test verileri ve test senaryoları hazırlayabilir.

Avantajlar	Dezavantajları
Mümkün olan her yerde kara kutu ve beyaz kutu testinin birleşik faydalarını sunar.	Kaynak koduna erişim mevcut olmadığından, kodun üzerinden geçme ve test kapsamı sınırlıdır.
Gri kutu test ediciler kaynak koduna güvenmez; bunun yerine arayüz tanımına ve fonksiyonel spesifikasyonlara güvenirler.	Yazılım tasarımcısı halihazırda bir test senaryosu çalıştırdıysa testler gereksiz olabilir.
Mevcut sınırlı bilgilere dayanarak, bir gri kutu test cihazı, özellikle iletişim protokolleri ve veri tipi işleme etrafında mükemmel test senaryoları tasarlayabilir.	Olası her girdi akışını test etmek gerçekçi değildir çünkü mantıksız bir zaman alır; bu nedenle, birçok program yolu test edilmeyecektir.
Test, tasarımcının değil kullanıcının bakış açısından yapılır.

Test Yöntemlerinin Karşılaştırması

Aşağıdaki tablo kara kutu testi, gri kutu testi ve beyaz kutu testini farklılaştıran noktaları listeler.

Kara Kutu Testi	Gri Kutu Testi	Beyaz Kutu Testi
Bir uygulamanın dahili işleyişinin bilinmesine gerek yoktur.	Test uzmanı, uygulamanın dahili işleyişi hakkında sınırlı bilgiye sahiptir.	Test cihazı, uygulamanın dahili işleyişiyle ilgili tam bilgiye sahiptir.
Kapalı kutu testi, veriye dayalı test veya işlevsel test olarak da bilinir.	Aynı zamanda yarı saydam test olarak da bilinir, çünkü test eden kişi uygulamanın iç kısımları hakkında sınırlı bilgiye sahiptir.	Açık kutu testi, yapısal test veya kod tabanlı test olarak da bilinir.
Son kullanıcılar ve ayrıca testçiler ve geliştiriciler tarafından gerçekleştirilir.	Son kullanıcılar ve ayrıca testçiler ve geliştiriciler tarafından gerçekleştirilir.	Normalde testçiler ve geliştiriciler tarafından yapılır.
Test, dış beklentilere dayalıdır - Uygulamanın dahili davranışı bilinmemektedir.	Test, üst düzey veritabanı diyagramları ve veri akış şemaları temelinde yapılır.	Dahili çalışmalar tam olarak bilinir ve test cihazı test verilerini buna göre tasarlayabilir.
Kapsamlıdır ve en az zaman alır.	Kısmen zaman alıcı ve kapsamlı.	En kapsamlı ve zaman alan test türü.
Algoritma testi için uygun değildir.	Algoritma testi için uygun değildir.	Algoritma testi için uygundur.
Bu sadece deneme yanılma yöntemi ile yapılabilir.	Veri alanları ve iç sınırlar, biliniyorsa test edilebilir.	Veri alanları ve iç sınırlar daha iyi test edilebilir.

Test sürecinde farklı seviyeler vardır. Bu bölümde, bu seviyeler hakkında kısa bir açıklama verilmektedir.

Test seviyeleri, yazılım testi yapılırken kullanılabilecek farklı metodolojileri içerir. Yazılım testinin ana seviyeleri şunlardır:

• Fonksiyonel test

• İşlevsel Olmayan Test

Fonksiyonel test

Bu, test edilecek yazılımın teknik özelliklerine dayanan bir tür kara kutu testidir. Uygulama girdi sağlanarak test edilir ve daha sonra amaçlanan işlevselliğe uyması gereken sonuçlar incelenir. Bir yazılımın işlevsel testi, sistemin belirtilen gereksinimlere uygunluğunu değerlendirmek için eksiksiz, entegre bir sistem üzerinde gerçekleştirilir.

Bir uygulamayı işlevsellik açısından test ederken dahil olan beş adım vardır.

Adımlar	Açıklama
ben	Amaçlanan uygulamanın gerçekleştirmesi amaçlanan işlevselliğin belirlenmesi.
II	Uygulamanın özelliklerine göre test verilerinin oluşturulması.
III	Çıktı, test verilerine ve uygulamanın özelliklerine dayanır.
IV	Test senaryolarının yazılması ve test senaryolarının yürütülmesi.
V	Gerçek ve beklenen sonuçların yürütülen test senaryolarına göre karşılaştırılması.

Etkili bir test uygulaması, her kuruluşun test politikalarına uygulanan yukarıdaki adımları görecek ve bu nedenle, kuruluşun yazılım kalitesi söz konusu olduğunda en katı standartları sürdürmesini sağlayacaktır.

Birim Testi

Bu tür testler, test senaryolarını resmi olarak yürütmek için kurulum test ekibine teslim edilmeden önce geliştiriciler tarafından gerçekleştirilir. Birim testi, ilgili geliştiriciler tarafından kaynak kodu atanmış alanların ayrı birimleri üzerinde gerçekleştirilir. Geliştiriciler, kalite güvence ekibinin test verilerinden farklı test verilerini kullanır.

Birim testinin amacı, programın her bir bölümünü izole etmek ve tek tek parçaların gereksinimler ve işlevsellik açısından doğru olduğunu göstermektir.

Birim Testinin Sınırlamaları

Test, bir uygulamadaki her bir hatayı yakalayamaz. Her yazılım uygulamasında her yürütme yolunu değerlendirmek imkansızdır. Aynı durum birim testinde de geçerlidir.

Bir geliştiricinin bir kaynak kodunu doğrulamak için kullanabileceği senaryo ve test verilerinin sayısında bir sınır vardır. Tüm seçenekleri tükettikten sonra, birim testini durdurup kod segmentini diğer birimlerle birleştirmekten başka seçenek yoktur.

Entegrasyon Testi

Entegrasyon testi, bir uygulamanın birleşik parçalarının doğru çalışıp çalışmadığını belirlemek için test edilmesi olarak tanımlanır. Entegrasyon testi iki şekilde yapılabilir: Aşağıdan yukarıya entegrasyon testi ve Yukarıdan aşağıya entegrasyon testi.

Sr.No.	Entegrasyon Test Yöntemi
1	Bottom-up integration Bu test, birim testiyle başlar, ardından modül veya yapı adı verilen kademeli olarak daha yüksek seviyeli birim kombinasyonlarının testleriyle başlar.
2	Top-down integration Bu testte, en yüksek seviyeli modüller önce test edilir ve aşamalı olarak daha düşük seviyeli modüller daha sonra test edilir.

Kapsamlı bir yazılım geliştirme ortamında, genellikle önce aşağıdan yukarıya test yapılır, ardından yukarıdan aşağıya test yapılır. Süreç, tercihen gerçek durumları taklit etmek için tasarlanmış senaryolarda, eksiksiz uygulamanın birden fazla testiyle sonuçlanır.

Sistem Testi

Sistem testi, sistemi bir bütün olarak test eder. Tüm bileşenler entegre edildikten sonra, uygulama, belirtilen Kalite Standartlarını karşılayıp karşılamadığını görmek için bir bütün olarak titizlikle test edilir. Bu tür testler, uzman bir test ekibi tarafından gerçekleştirilir.

Sistem testi aşağıdaki nedenlerden dolayı önemlidir -

• Sistem testi, uygulamanın bir bütün olarak test edildiği Yazılım Geliştirme Yaşam Döngüsünün ilk adımıdır.

• Uygulama, işlevsel ve teknik özellikleri karşıladığını doğrulamak için kapsamlı bir şekilde test edilir.

• Uygulama, uygulamanın konuşlandırılacağı üretim ortamına çok yakın bir ortamda test edilir.

• Sistem testi, hem iş gereksinimlerini hem de uygulama mimarisini test etmemizi, doğrulamamızı ve doğrulamamızı sağlar.

Gerileme testi

Bir yazılım uygulamasında bir değişiklik yapıldığında, uygulama içindeki diğer alanların bu değişiklikten etkilenmiş olması oldukça olasıdır. Düzeltilen bir hatanın başka bir işlev veya iş kuralı ihlaline yol açmadığını doğrulamak için regresyon testi gerçekleştirilir. Regresyon testinin amacı, hata düzeltmesi gibi bir değişikliğin uygulamada ortaya çıkan başka bir hatayla sonuçlanmamasını sağlamaktır.

Regresyon testi, aşağıdaki nedenlerden dolayı önemlidir -

• Yapılan değişikliklerin olduğu bir uygulamanın test edilmesi gerektiğinde testteki boşlukları en aza indirin.

• Yapılan değişikliklerin uygulamanın başka hiçbir alanını etkilemediğini doğrulamak için yeni değişiklikleri test etmek.

• Uygulamada regresyon testi yapıldığında riskleri azaltır.

• Zaman çizelgelerinden ödün vermeden test kapsamı artırılır.

• Ürünü pazarlamak için hızı artırın.

Kabul testleri

Uygulamanın istenen özellikleri karşılayıp karşılamadığını ve müşterinin gereksinimlerini karşılayıp karşılamadığını ölçecek olan Kalite Güvence Ekibi tarafından yürütüldüğü için bu tartışmasız en önemli test türüdür. QA ekibi, uygulamayı test etmek için kullanılacak bir dizi önceden yazılmış senaryoya ve test senaryolarına sahip olacaktır.

Uygulama hakkında daha fazla fikir paylaşılacak ve doğruluğunu ve projenin başlatılma nedenlerini ölçmek için üzerinde daha fazla test yapılabilecek. Kabul testleri, yalnızca basit yazım hatalarını, yüzeysel hataları veya arayüz boşluklarını belirtmek için değil, aynı zamanda uygulamada sistem çökmelerine veya uygulamada büyük hatalara neden olacak herhangi bir hatayı işaret etmeyi amaçlamaktadır.

Test ekibi, bir uygulama üzerinde kabul testleri yaparak, uygulamanın üretimdeki performansını azaltacaktır. Sistemin kabulü için yasal ve sözleşmeye dayalı gereklilikler de vardır.

Alfa Testi

Bu test, testin ilk aşamasıdır ve ekipler (geliştirici ve QA ekipleri) arasında gerçekleştirilecektir. Bir araya getirildiğinde birim testi, entegrasyon testi ve sistem testi alfa testi olarak bilinir. Bu aşamada, uygulamada aşağıdaki hususlar test edilecektir -

• Yazım hataları

• Bozuk bağlantılar

• Bulutlu Yol Tarifi

• Uygulama, yükleme sürelerini ve herhangi bir gecikme problemini test etmek için en düşük spesifikasyona sahip makinelerde test edilecektir.

Beta testi

Bu test, alfa testi başarıyla gerçekleştirildikten sonra gerçekleştirilir. Beta testinde, hedef kitlenin bir örneği uygulamayı test eder. Beta testi olarak da bilinirpre-release testing. Yazılımın beta test sürümleri, kısmen programa "gerçek dünya" testi vermek ve kısmen de bir sonraki sürümün önizlemesini sağlamak için Web üzerinde geniş bir kitleye ideal olarak dağıtılır. Bu aşamada, izleyiciler aşağıdakileri test edecek -

• Kullanıcılar uygulamayı kuracak, çalıştıracak ve geri bildirimlerini proje ekibine gönderecek.

• Tipografik hatalar, kafa karıştırıcı uygulama akışı ve hatta çökmeler.

• Geri bildirimi alan proje ekibi, yazılımı gerçek kullanıcılara yayınlamadan önce sorunları çözebilir.

• Gerçek kullanıcı sorunlarını çözen ne kadar çok sorunu çözerseniz, uygulamanızın kalitesi o kadar yüksek olacaktır.

• Genel kamuoyuna sunduğunuzda daha kaliteli bir uygulamaya sahip olmak müşteri memnuniyetini artıracaktır.

İşlevsel Olmayan Test

Bu bölüm, bir uygulamanın işlevsel olmayan özelliklerinden test edilmesine dayanmaktadır. İşlevsel olmayan test, bir yazılımı, doğası gereği işlevsel olmayan ancak performans, güvenlik, kullanıcı arayüzü vb. Gibi önemli olan gereksinimlerden test etmeyi içerir.

Önemli ve yaygın olarak kullanılan işlevsel olmayan test türlerinden bazıları aşağıda tartışılmaktadır.

Performans testi

Çoğunlukla, bir yazılımdaki hataları bulmaktan ziyade herhangi bir darboğaz veya performans sorununu tanımlamak için kullanılır. Bir yazılımın performansını düşürmeye katkıda bulunan farklı nedenler vardır -

• Ağ gecikmesi

• İstemci tarafı işleme

• Veritabanı işlemi işleme

• Sunucular arasında yük dengeleme

• Veri işleme

Performans testi, aşağıdaki hususlar açısından önemli ve zorunlu test türlerinden biri olarak kabul edilir -

• Hız (yani Tepki Süresi, veri işleme ve erişim)

• Capacity

• Stability

• Scalability

Performans testi, niteliksel veya niceliksel olabilir ve aşağıdaki gibi farklı alt türlere ayrılabilir: Load testing ve Stress testing.

Yük Testi

Bir yazılımın davranışını, yazılımlara erişme ve büyük giriş verilerini kullanma açısından maksimum yük uygulayarak test etme işlemidir. Hem normal hem de pik yük koşullarında yapılabilir. Bu tür testler, yazılımın maksimum kapasitesini ve en yoğun zamandaki davranışını tanımlar.

Çoğu zaman, yük testi, Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test, vb. Gibi otomatik araçlar yardımıyla gerçekleştirilir.

Sanal kullanıcılar (VUsers), otomatik test aracında tanımlanır ve yazılımın yük testini doğrulamak için komut dosyası yürütülür. Gereksinimlere göre kullanıcı sayısı eşzamanlı veya aşamalı olarak artırılabilir veya azaltılabilir.

Stres testi

Stres testi, bir yazılımın davranışını anormal koşullar altında test etmeyi içerir. Örneğin, bazı kaynakların kaldırılmasını veya gerçek yük sınırının ötesinde bir yük uygulamayı içerebilir.

Stres testinin amacı, yükü sisteme uygulayarak ve kırılma noktasını belirlemek için yazılım tarafından kullanılan kaynakları devralarak yazılımı test etmektir. Bu test, aşağıdakiler gibi farklı senaryoları test ederek gerçekleştirilebilir:

• Ağ bağlantı noktalarının rastgele kapatılması veya yeniden başlatılması

• Veritabanını açma veya kapatma

• CPU, bellek, sunucu vb. Kaynakları tüketen farklı süreçleri çalıştırmak

Kullanılabilirlik testi

Kullanılabilirlik testi bir kara kutu tekniğidir ve yazılımdaki hataları ve gelişmeleri, kullanıcıları kullanımları ve çalıştırmaları boyunca gözlemleyerek belirlemek için kullanılır.

Nielsen'e göre kullanılabilirlik beş faktör üzerinden tanımlanabilir, yani kullanım verimliliği, öğrenme yeteneği, hafıza yeteneği, hatalar / güvenlik ve memnuniyet. Ona göre bir ürünün kullanılabilirliği iyi olacak ve sistem yukarıdaki faktörlere sahipse kullanılabilir.

Nigel Bevan ve Macleod, kullanılabilirliğin bir bilgisayar sistemiyle etkileşimlerin sonucu olarak ölçülebilecek kalite gereksinimi olduğunu düşünüyordu. Uygun kaynakların kullanılmasıyla amaçlanan hedeflere etkili bir şekilde ulaşılırsa, bu gereklilik yerine getirilebilir ve son kullanıcı tatmin olur.

Molich, 2000 yılında, kullanıcı dostu bir sistemin aşağıdaki beş hedefi yerine getirmesi gerektiğini belirtti: Öğrenmesi kolay, hatırlaması kolay, kullanımı verimli, kullanımı tatmin edici ve anlaşılması kolay.

Kullanılabilirliğin farklı tanımlarına ek olarak, kullanılabilirliği ISO-9126, ISO-9241-11, ISO-13407 ve IEEE std gibi öznitelikler ve alt öznitelikler şeklinde tanımlayan bazı standartlar ve kalite modelleri ve yöntemleri vardır. 610.12 vb.

Kullanıcı Arayüzü ve Kullanılabilirlik Testi

UI testi, Yazılımın Grafik Kullanıcı Arayüzünün test edilmesini içerir. UI testi, GUI'nin gereksinimlere göre çalışmasını ve renk, hizalama, boyut ve diğer özellikler açısından test edilmesini sağlar.

Öte yandan, kullanılabilirlik testi, kolayca yönetilebilen iyi ve kullanıcı dostu bir GUI sağlar. UI testi, kullanılabilirlik testinin bir alt bölümü olarak düşünülebilir.

Güvenlik Testi

Güvenlik testi, güvenlik ve güvenlik açığı açısından herhangi bir kusur ve boşluğu belirlemek için bir yazılımı test etmeyi içerir. Aşağıda, güvenlik testinin sağlaması gereken ana hususlar listelenmiştir -

• Confidentiality

• Integrity

• Authentication

• Availability

• Authorization

• Non-repudiation

• Yazılım, bilinen ve bilinmeyen güvenlik açıklarına karşı güvenlidir

• Yazılım verileri güvenlidir

• Yazılım tüm güvenlik düzenlemelerine uygundur

• Giriş kontrolü ve doğrulama

• SQL ekleme saldırıları

• Enjeksiyon kusurları

• Oturum yönetimi sorunları

• Siteler arası komut dosyası saldırıları

• Arabellek güvenlik açıklarını taşıyor

• Dizin geçiş saldırıları

Taşınabilirlik Testi

Taşınabilirlik testi, bir yazılımın yeniden kullanılabilirliğini ve başka bir yazılımdan da taşınmasını sağlamak amacıyla test edilmesini içerir. Taşınabilirlik testi için kullanılabilecek stratejiler aşağıdadır -

• Kurulu bir yazılımı bir bilgisayardan diğerine aktarma.

• Yazılımı farklı platformlarda çalıştırmak için yürütülebilir (.exe) oluşturma.

Taşınabilirlik testi, sistem testinin alt bölümlerinden biri olarak düşünülebilir, çünkü bu test türü bir yazılımın farklı ortamlarda kullanımına göre genel testini içerir. Bilgisayar donanımı, işletim sistemleri ve tarayıcılar, taşınabilirlik testinin ana odak noktasıdır. Taşınabilirlik testi için bazı ön koşullar aşağıdaki gibidir -

• Yazılım, taşınabilirlik gereksinimleri göz önünde bulundurularak tasarlanmalı ve kodlanmalıdır.

• İlgili bileşenlerde birim testi yapılmıştır.

• Entegrasyon testi yapıldı.

• Test ortamı oluşturuldu.

Test dokümantasyonu, Yazılımın test edilmesinden önce veya test sırasında geliştirilmesi gereken eserlerin dokümantasyonunu içerir.

Yazılım testi belgeleri, gereken test çabasının, test kapsamının, gereksinim takibinin / takibinin vb. Tahmin edilmesine yardımcı olur. Bu bölüm, aşağıdaki gibi yazılım testiyle ilgili yaygın olarak kullanılan belgelenmiş yapılardan bazılarını açıklamaktadır:

• Test planı
• Test Senaryosu
• Test durumu
• İzlenebilirlik Matrisi

Test planı

Bir test planı, bir uygulamayı test etmek için kullanılacak stratejiyi, kullanılacak kaynakları, testin gerçekleştirileceği test ortamını ve testin sınırlamalarını ve test faaliyetlerinin programını ana hatlarıyla belirtir. Tipik olarak Kalite Güvence Takım Lideri bir Test Planı yazmaktan sorumlu olacaktır.

Bir test planı aşağıdakileri içerir -

• Test Planı belgesine giriş
• Uygulamayı test ederken varsayımlar
• Uygulamanın test edilmesine dahil edilen test senaryolarının listesi
• Test edilecek özelliklerin listesi
• Yazılımı test ederken ne tür bir yaklaşım kullanılmalı
• Test edilmesi gereken çıktıların listesi
• Uygulamayı test etmek için ayrılan kaynaklar
• Test süreci sırasında ortaya çıkan riskler
• Ulaşılması gereken görevler ve kilometre taşları programı

Test Senaryosu

Uygulamada hangi alanın test edileceğini bildiren tek satırlık bir ifadedir. Test senaryoları, tüm süreç akışlarının uçtan uca test edilmesini sağlamak için kullanılır. Bir uygulamanın belirli bir alanı, uygulamanın büyüklüğüne ve karmaşıklığına bağlı olarak bir test senaryosu ile birkaç yüz senaryo arasında olabilir.

'Test senaryosu' ve 'test senaryosu' terimleri birbirinin yerine kullanılır, ancak bir test senaryosunda birkaç adım bulunurken, bir test senaryosu tek bir adıma sahiptir. Bu perspektiften bakıldığında, test senaryoları test senaryolarıdır, ancak birkaç test senaryosunu ve yürütülmeleri gereken sırayı içerirler. Bunun dışında her test, önceki testin çıktısına bağlıdır.

Test durumu

Test senaryoları, test görevleri gerçekleştirilirken kullanılabilecek bir dizi adım, koşul ve girdi içerir. Bu faaliyetin ana amacı, bir yazılımın işlevselliği ve diğer yönleri açısından geçip geçmediğinden emin olmaktır. İşlevsel, negatif, hata, mantıksal test senaryoları, fiziksel test senaryoları, UI test senaryoları gibi birçok test durumu türü vardır.

Ayrıca, bir yazılımın test kapsamını takip etmek için test senaryoları yazılır. Genellikle, test senaryosu yazımı sırasında kullanılabilecek resmi şablonlar yoktur. Bununla birlikte, aşağıdaki bileşenler her zaman mevcuttur ve her test senaryosuna dahil edilir -

• Test senaryosu kimliği
• Ürün modülü
• Ürün Sürümü
• Revizyon Geçmişi
• Purpose
• Assumptions
• Pre-conditions
• Steps
• Beklenen sonuç
• Gerçek sonuç
• Post-conditions

Birçok test senaryosu, tek bir test senaryosundan türetilebilir. Ek olarak, bazen topluca test paketleri olarak bilinen tek bir yazılım için birden çok test senaryosu yazılır.

İzlenebilirlik Matrisi

İzlenebilirlik Matrisi (Gereksinim İzlenebilirlik Matrisi - RTM olarak da bilinir), Yazılım Geliştirme Yaşam Döngüsü sırasında gereksinimleri izlemek için kullanılan bir tablodur. İleriye doğru izleme (yani Gereksinimlerden Tasarım veya Kodlamaya) veya geriye doğru (yani Kodlamadan Gereksinimlere) kullanılabilir. RTM için birçok kullanıcı tanımlı şablon vardır.

RTM belgesindeki her gereksinim, ilgili test senaryosu ile bağlantılıdır, böylece testler belirtilen gereksinimlere göre yapılabilir. Ayrıca, Hata Kimliği de dahil edilir ve ilgili gereksinimleri ve test durumu ile bağlantılıdır. Bu matrisin ana hedefleri şunlardır:

• Yazılımın belirtilen gereksinimlere göre geliştirildiğinden emin olun.
• Herhangi bir hatanın temel nedenini bulmaya yardımcı olur.
• SDLC'nin farklı aşamalarında geliştirilen belgelerin izlenmesine yardımcı olur.

Test için gereken çabaları tahmin etmek, SDLC'deki ana ve önemli görevlerden biridir. Doğru tahmin, yazılımın maksimum kapsama alanıyla test edilmesine yardımcı olur. Bu bölümde, test için gereken çabaları tahmin etmede yararlı olabilecek bazı teknikler açıklanmaktadır.

Fonksiyonel Nokta Analizi

Bu yöntem, aşağıdaki kategorilerdeki yazılımın işlevsel kullanıcı gereksinimlerinin analizine dayanmaktadır -

• Outputs
• Inquiries
• Inputs
• Dahili dosyalar
• Harici dosyalar

Test Noktası Analizi

Bu tahmin süreci, kara kutu veya kabul testi için fonksiyon noktası analizi için kullanılır. Bu yöntemin ana unsurları şunlardır: Boyut, Verimlilik, Strateji, Arayüz, Karmaşıklık ve Tekdüzelik.

Mark-II Yöntemi

Son kullanıcının işlevsel görüşüne dayalı olarak tahminin analiz edilmesi ve ölçülmesi için kullanılan bir tahmin yöntemidir. Mark-II yönteminin prosedürü aşağıdaki gibidir -

• Bakış açısını belirleyin
• Amaç ve sayım türü
• Sayım sınırını tanımlayın
• Mantıksal işlemleri tanımlayın
• Veri varlığı türlerini tanımlayın ve kategorilere ayırın
• Giriş veri öğesi türlerini sayın
• İşlevsel boyutu sayın

Çeşitli

Aşağıdakiler gibi diğer popüler tahmin tekniklerini kullanabilirsiniz:

• Delphi tekniği
• Analoji Temelli Tahmin
• Test Örneği Numaralandırmaya Dayalı Tahmin
• Görev (Etkinlik) Bazlı Tahmin
• IFPUG yöntemi