www.fatihkabakci.com

Personal Website and Computer Science TUR EN

YAZILIM TEST MUHENDISLIGI

YAZILIM TEST MUHENDISLIGI
Last update: 6/25/2015 10:07:00 AM

Çözümleyen: Fatih KABAKCI

Bölüm 1 - Yazılım Mühendisliği ve Yazılım Testleri

1.1) Müşteriye teslim edilen bir yazılımın veya yazılım ile çözülmesi gereken bir problemin, doğru zamanda, doğru maliyet ile, beklentileri karşılayan, verimli çalışan bir üretmektir. Yazılım mühendisliği bir yazılımın ortaya çıkmasından, analizine, tasarımına, üretimine, testine ve bakımını kadar olan geçen tüm süreçlerde aktif rol oynayan ve yöneten bir mühendislik dalıdır. Gereksinim belirtimlerinin hazırlanması, tasarım kalıplarının yapılması, birim testlerinin hazırlanması, proje yönetimi gibi örnekler yazılım mühendisliği işleri arasında örnek gösterilebilir.

1.2) Bir yazılımın ortaya çıkmasından, analizine, tasarımına, üretimine, testine ve bakımını kadar olan geçen tüm süreçleri kapsayan bir disiplindir.

Problem Tanımı: Müşteriden gelen veya ortaya çıkan bir problemin tespit edilme sürecidir.
Analiz: Problemin masaya yatırılarak detaylandırıldığı bir süreçtir. Burada problem ilk olarak yazılım ile çözülebilir mi bu araştırılır. Beklentiler ve gereksinimler analiz edilmeye çalışır. Problemin konusu ile alakalı bilir kişilere danışılıp sektör araştırması yapılır. Kullanıcı, sistem ve yazılım gereksinimleri analiz edilerek belirtimler hazırlanır.
Tasarım: Varlığı ve oluşumu iyice anlaşılmış olan problemin çözüm tasarımının yapıldığı bir süreçtir. Burada sistem ve yazılım tasarımları gerçekleştirilir.
Kodlama: Tasarım aşamasında çözüm algoritmaları kurulan yazılımın fiziksel inşası bu süreçte gerçekleştirilir.
Test: Yazılımın hatalarının ortaya çıkartılmasını denetleyen test aşamaları bu süreçte işletilir.
Yayma ve Bakım: Yazılımın müşteriye doğru bir şekilde teslim edilmesi, ve yazılımın yaşatılması bu süreç ile başlatılır.

1.3) Bir yazılımı bakımı(maintenance) 4 şekilde yapılır.

Uyarlanabilen Bakım (Adaptive): Değişen hardware ve yazılım ortamındaki değişikler ile başa çıkabilmek adına yapılan yazılımı adapte edici bir bakım tipidir.

İyileştirici Bakım(Perfective): Yazılıma yeni özelliklerin eklendiği veya değişen kullanıcı gereksinimlerine karşılık yazılımı daha iyi kılan bir bakım tipidir.

Düzeltici Bakım(Corrective): Yazılımdaki mevcut hataları gidermeye çalışan bir bakım tipidir.

Önleyici Bakım(Preventive): Gelecekteki problemler için yazılımın güvenilirliğini, kodun yapısallığı ve performansını sürdürmeye çalışan bir tipidir.

1.4) Analiz - Tasarım - Kodlama - Test - Yayım süreçlerini ardışık ve detaylı olarak işleyerek, dökümante eden yöntemdir. Bu yöntemde gereksinimler net ve belli olmalıdır. Aksi halde ileride çıkacak problemlerde geri dönüşler zor ve maliyetli olur. Ayrıca yazılımın fiziksel inşası bu yöntemde çok sonralarda yapılmaya başlar. Bu durumda da başta gözden kaçan gereksinimler geliştirmeye büyük zarar verir.

1.5) Yazılım odaklı, bireyin sorumluluk alabildiği, takım oyununu destekleyen, dökümana gerektiğinde başvuran, müşteri ile iletişimi birebir sağlayan, hareketli ve hızlı yazılım geliştirmeyi amaçlayan bir kavramdır. Agile Manifesto aşağıdaki 4 ilkeden oluşur.

Süreçler ve araçlardan ziyade bireyler ve etkileşimlere
Kapsamlı dökümantasyondan ziyade çalışan yazılıma
Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine
Bir plana bağlı kalmaktan ziyade değişime karşılık vermeye
değer vermeye kanaat getirdik.

1.6) Adaptive software development (ASD), Agile modeling, Agile Unified Process (AUP), Dynamic systems development method (DSDM), Extreme programming (XP), Feature-driven development (FDD), Scrum agile metodoloji türleri olarak bilinir. Bir önceki soruda açıklandığı gibi müşteri ve çalışanlar arasında hızlı etkileşim sağlayan, çalışan yazılımı süreçlere tercih eden bir yazılım geliştirme süreç modelidir. Genelde bu stratejiyi uygulayan projeler, takımlara bölünür. Her takım story adı verilen iş parçacıklarını teslim alarak iterasyon adımlarını uygular. Her bir iterasyon tamamlandığı anda müşteriye yapılan online veya canlı demolar ile bir sonraki iterasyon planları belirlenir.

1.7) Araştırmacı(explatory) ve Atılabilir(throwaway) olarak iki çeşittir. Bu modelde yazılım ilk etapta hızlı bir tasarım ile müşteriye sunulur. Gereksinimler yakalanmaya çalışılarak ilk etapta gösterilen yazılımın bir sonraki örneği oluşturulur. Bu durum müşteri tamam diyene kadar devam eder. Yazılım gittikçe evrimleşerek son halini alır.

1.8) Yazılım ihtiyacının kendisidir. Problemler belirlenir. Kullanıcı, yazılım ve sistem perspektifi açısından masaya yatırılır ve yazılım belirtimleri ortaya çıkarılır.

1.9) Sistemi ihtiva eden mimari, kullanıcı erişim panelini temsil eden arayüz, yazılımın arka tarafta kullandığı iş mantığını oluşturan bileşen, yazılım içinde modellenen ve tasarlananveri yapısı ve algoritma tasarım sürecinin elementlerini oluşturur.

1.10) Belirlenen ihtiyaçların karşılayıp karşılamadığını test eden bir yöntemdir. Bu yöntemde proje ile paralel yürütülen gözden geçirme ve sürüm sonrası yazılım testleri uygulanır.

1.11) Projenin gereksinim, tasarım, kod ve test durumlarının gözden geçirilmesidir.

1.12) Projenin takvim ve ekonomik bazda yönetim tarafından yapılan gözden geçirmelerdir.

Bölüm 2 - Genel Bilgiler

2.1) Therac-25 Tedavi cihazında, hastaya yüksek dozda defalarca radyasyon verilmesi ve bu hatanın hastanın ölümüne yol açması. Hata operatörün cihaza yanlış sırada komut vermesinden dolayı yaşanmıştır.

Bir başka örnekte Arienne 5 füze faciası verilebilir. Füze kalktıktan sonra infilak etmiştir. Bunun sebebi de yazılım içerisinde tanımlanmış bir değişkenin taşma sonucunda yazılımı kararsız bir yapıya geçirmesi olmuştur. Taşma, bir değişkenin bellekte kapsaması gereken aralığın dışında bir değer alması sonucu meydana gelir. Örneğin C dilinde char tipli bir değişkene 128 değeri verildiğinde taşma meydana gelir. Çünkü bu dilde char değer aralığı -128 +127 arasındadır.

2.2) Yeterli sayıda test işlemininin yapılamamış olmasıdır. Test stratejisinin doğru bir şekilde uygulanmayışı da örnek olarak gösterilebilir.

2.3) Bir yazılımın gereksinimleri sonucunda beklentileri karşılayıp karşılamadığını denetlemek ve yazılım içerisindeki hataları tespit ederek ortaya çıkarma işlemine denir.

2.4) Günün sonunda yazılımın hatalarından arındırılmış, müşteri gereksinimlerini sağlayan bir ürün ortaya koyma amaçlanır.

2.5) Bir yazılım özelliklerine göre uygulanacak test tiplerinin ve seviyelerinin tanımlanmasına ve sürecin işletilmesine denir.

2.6) Çalıştığım şirket içerisinde partneri olduğumuz bir şirketin yazılımını icra etmeyiz. Yazılım ürünü sürümler dahilinde hazırlanmakta. Şu aşamada 3. Sürüm tespit edilen tüm hataların çözümüyle tamamlandı ve müşteriye tespit edildi. Sürüm açısından ele alınacak olursa yazılım başarılı bir şekilde hazırlanmıştır. Bunun kriteri olarak da müşteriden ya da yazılım test ekibinden bir hata raporlanmaması, ayrıca mevcut bir performans kaybının yaşanmaması gösterilebilir.

2.7) Üniversite otomasyonu başarısız kalmıştır. Çünkü Üniversitenin kurulduğu yıldan beri ilgili otomasyon ürünü kullanılmaktayken 2016 yılı itibariyle değiştirileceği açıklanmıştı. Bunun sebebi olarak da, otomasyonun verimli olmadığı, eksiklerinin bulunduğu ifade edilmişti. Buda göstermekteydi ki, üniversite sistemi oturmaya başlamasıyla birlikte eski otomasyonun bir takım ihtiyaçlara cevap veremeyecek hale gelmesiydi.

2.8) Ülkemizde yankı bulmuş bir felaket yaşanmamıştır. Çünkü yazılım sistemleri yeni yeni önem kazanmaya başlamıştır..

Bölüm 3 - Test Süreci ve Yönetimi

3.1) Yazılımın planlama aşamasında kesin olarak belirlenen gereksinimler ile birlikte başlar.

3.2) Öncelikle yazılım planlama aşamasında ortaya çıkarılan gereksinimlerin doğruluğu ve test edilebilirliği denetlenir ve test plan hazırlanır. Yazılımın tasarım aşamasında test stratejileri belirlenir. Kodlama aşamasında, yazılımcıların hazırladığı birim testlerini(unit test) denetler ve test labını kurar. Test aşaması esas testlerin fiili olarak yoğunlukla yapıldığı aşamadır. Burada kabul, sistem ve entegrasyon testlerinin tümü yapılır. Hatalar raporlanır ve takip edilir. Yazılım bakımı devam ederken hataların çözümü, tekrarlama testleri devam eder.

3.3) Test süreci planlama evresiyle başlar. Bu aşamada öncelikle bir test plan çıkartılır. Bu test plan testin amacı, süresi, test edilecek modülleri, laboratuvar ve testlerin dağıtımı gibi bilgiler içerir. Yazılım geliştirme sürecinde hazırlanan sistem, yazılım ve müşteri gereksinimleri doğrultusunda test planı bu evrede yapılır. Tasarım evresinde yapılacak test stratejileri belirlenir. Bu kapsamda hangi testlerin yapılacağı(testcase belirleme), hangi test yöntemlerinin kullanılacağı, testlerin hangi laboratuvarda yapılacağı gibi yordamlar tasarlanır. Test koşma evresinde tasarlanan tüm testcaseler belirlenen bir laboratuvarda koşturulur. Koşturulan testlerin hata raporlama süreci başlar. Hatalar yazılım ekiplerine raporlanarak bildirilir. Bu hataların çözümü ile hata ya çözülür ya da çözülene kadar bekletilir.

Test Process

3.4) Test plan için iki türlü yapılır. Ya sistem, yazılım ve müşteri taraflı yapılan gereksinimlerin ayrı ayrı tanımlandığı her bir test plan olarak yapılır ya da tüm planlama sürecini içine alan tek bir test plan hazırlanır.

3.5) Öncelikle amaçlar belirlenir. Yapılacak testlerin neden yapılması gerektiği, hangi birimlere etki ettiği ve kısıtlamalar ifade edilir. Ardından bir strateji belirlenir. Testcase senaryoları çıkarılır ve testlerin hangi yöntem ve araçlarla yapılacağı belirlenir. Laboratuvar ortamı ve gerekli ise ilave yazılım tanımlamaları yapılır. Testler Test Mühendisleri arasında paylaştırılır. Takvim belirlenir ve süreç kontrol edilir.

3.6) Tasarım aşamasında laboratuvar ortamını kurulması, testcase senaryolarının çıkarılması ve test yöntemlerinin belirlenmesi yapılır.

3.7) Tescaselerin run edilmesi için girdi üreten yazılımlar, logger programları, simulatör araçları ve stub gibi diğer araçlar kullanılır.

3.8) Testcase, bir modülün test edilecek özelliğini belirten en küçük test bileşenidir.

3.9) Bir testcase aşağıdaki kavramları tanımlar.

Testcase
- ID
- Amacı
- Kısıtları
- Girdiler
- Beklenen sonuç
- Gerçek sonuç
- Yazılım sürümü
- Laboratuvar ortamı

3.10) Genel bilgi, testin nasıl icra edileceği, testin beklenen sonucu ile gerçek sonucu ve bu bağlamda testin PASS veya FAIL olma durumu testcase' i oluşturan bölümler arasında yer alır. Genel bilgi testcase'i tanımlayan unique bir numara, isim ve ilk koşullar ile ilgili tanımlamalar içerir. Testin icra edilmesi ise, bir testcase' in adım adım nasıl koşulacağını ve kısıtlarını açıklar. Test sonuçları ise beklenen ile tespit edilen sonuçların belirtilmesiyle, testcase' in başarılı olma ya da olmama gibi hükmünü içerir.

3.11) Tek veya birlikte koşulan testlerin koşturulması için direktiflerin bulunduğu belge olarak tanımlanır.

3.12) Laboratuvar ortamının ve ilave yazılım araçlarının kurulması. Testin yapılıp hata raporlarının yazılım birimlerine raporlanması. Gelen çözüm sonunda testin aynı kriterler altında yeniden yapılması ve sonucun bildirilmesi. Test PASS ise hatanın kapatılması. Aksi halde yeniden yazılım birimlerine gönderilmesi.

3.13) Bir testcase' in durumu(state) aşağıdaki kavramlardan biri ile ilişkili olabilir.

On Going, testin devam ettiğini belirtir.
Blocked, testin bir nedenden ötürü bloklandığını ifade eder.
Cancelled, testin iptal edildiğini belirtir.
Deferred, testin bir sebepten ötürü ertelendiğini ifade eder.
Passed, testin başarılı bir şekilde sonuçlandığını ifade eder.
Failed, testin başarısız bir şekilde sonuçlandığını ifade eder.
Not Run, test işleminin henüz başlamadığını ifade eder.

3.14) Hata Test Mühendisi tarafından tespit edilir ve yazılım birimlerine raporlanır. Yazılım birimi başındaki sorumlu kişiler bu hatanın hangi yazılım modülü ile ilintili olduğunu değerlendirir ve hata modülünü ilglili yazılım birimine raporlar. Yazılım birimi bu hatayı çözer ve yeniden test işlemi için Test Mühendisine yönlendirir. Test Mühendisi aynı testi yeniden yaparak sonuca göre ya hatayı kapatır ya da geri gönderir.

Software Error Life Cycle

3.15) Hata raporları hatanın adı, beklenen ile gerçekleşen sonuçlar, yazılım yükü, önceliği, hatanın nasıl ortaya çıktığı ve tarihi gibi bilgiler içerir.

3.16) Hata seviyeleri(severity) aşağıdaki kavramlar ile ifade edilir.

Software Defect Severity

Critical:, testleri bloklayan ve müşteriye teslim edilemeyecek bir yazılım hatasını tanımlar.
Major:, testleri bloklamayan ancak müşteriye teslim edilemeyecek bir yazılım hatasını tanımlar.
Moderate:, müşteriye teslim edilebilir fakat riskli olabilecek bir yazılım hatasını tanımlar.
Minor:, önceliği düşük ve zararı olmayan bir yazılım hatasını tanımlar.
Cosmetic:, sonraki evrelerde yapılabilecek iyileştirmeler ile ilgili olan yazılım hataları ve eksikleri olarak tanımlanır.

Bölüm 4 - Yazılım Test Düzeyleri

4.1)

  1. Birim(Unit) Testi
  2. Entegrasyon(Integration) Testi
  3. Sistem(System) Testi
  4. Kabul(Acceptance) Testi

4.2) Metot, fonksiyon, prosedür gibi kod parçalarının yazılım gereksinimlerini beklenildiği gibi karşılayıp karşılamadığını göstermek için yazılım geliştiriciler tarafından yapılan testlerdir. Testcase senaryoları oluşturularak, belirli girdi tipleri dahilinde ilgili kod parçalarının tüm satırlarının kapsanması hedeflenir.

4.3) Kabarcık Sıralama(Bubble Sort) algoritmasını göz önünde bulunduralım. Bu algoritma basitçe en büyük sayısal değerli elemanı komşu elemanlarıyla kıyaslayarak listenin sonuna atarak işlem yapan bir sıralama algoritmasıdır. Bu algoritma da en büyük eleman dizinin başında, sonunda, arada bir yerde olma durumuna göre bir birim testi(unit test) hazırlanabilir. Ayrıca sıralama yapılacak dizi hali hazırda sıralı olabilir, ters sırada olabilir veya tüm elemanları aynı olabilir. Bu gibi koşullar altında her bir senaryo için testcase hazırlanarak koşturulur.

4.4) Linear Search(Doğrusal - Ardışık Arama) algoritması basitçe bir dizi içerisindeki elemanlara baştan sona kadar teker teker bakarak, aranan elemanı bulmaya yarayan bir arama algoritmasıdır. Burada aranacak eleman, dizinin başında, ortasında(arada), sonunda veya dizide hiç bulunmama durumuna göre birim testleri hazırlanabilir. Her bir senaryo için testcase hazırlanarak koşturulur. Örneğin 8 12 90 13 2 7 sayılar dizisi olsun. Biz bu dizide 8' tam sayısını aramak istediğimiz bir senaryoya testcase1 adını verelim. 90 sayısı için testcase2, 7 sayısı için testcase3 ve 44 sayısı içinde testcase4 adını verelim. Tüm bu testleri ayrı ayrı koşturarak unit testleri hazırlayabiliriz.

4.5) Yazılım modülleri birlikte değerlendirilerek yapılan testlere denir. Big Bang, Top - Down, Bottom - Up ve Sandwich/Hybrid gibi teknikler kullanılarak gerçekleştirilir.

4.6) Sistem gereksinimlerine göre oluşturulan yazılımın güvenlik, performans gibi etmenler dahilinde yapılan test işlemlerine denir. Stres, performans, konfigürasyon, recovery gibi test adımlarından oluşur.

4.7) Müşteri gereksinimlerini doğrulamak için yapılan testlerdir. Müşteri gereksinimlerinin doğrulanması, daha önceden karşılaşılmamış olan hataların tespiti gibi durumları içerir.

4.8)

  • Müşteri gereksimleri belirlenir.
  • Acceptance test planları yapılır ve senaryolar çıkarılır.
  • Test ortamı hazırlanır ve testler koşturulur.
  • Sonuçlar raporlanır ve müşteriye sunulur.

Bölüm 5 - Yazılım Test Teknikleri

5.1) Black box, white box ve gray box testleri olarak 3 çeşittir. Black box testinde yazılımı test eden kişiler test mühendisleridir ve kaynak kod bilinmeksizin bu testler yapılır. White box testinde kaynak kod bilinerek testler yapılır ve bu testler genelde yazılım mühendisleri tarafından gerçekleştirilir. Gray box testinde ise bu iki test türünün karması yapılır. Koda göre gereksinim oluşturularak testler girdiler altında gerçeklenir.

5.2) Kaynak kod bilinmeksizin, test mühendisleri tarafından yapılan testlerdir. Kullanıcı gözüyle sistem hiç bir ön yargı olmaksızın test edilir.

5.3) Sınır değer hataları, veritabanı hataları, arayüz hataları tespit edilebilir.

5.4) Yazılım testçiler ile hızlı bir şekilde yapılabilir. Kaynak kodların bilinmesine ve sistemin tanınmasına gerek duyulmaz. Bir nevi kullanıcı gözüyle test yapılır. Yazılımın bazı kod parçaları test edilmeyebilir. Tam kapsama olmaz.

5.5) Girdiler rastgele seçilmelidir. Sınır değerler mutlaka test edilmelidir. 0 test edilmelidir. Stres testi uygulanmalıdır ve her bir gereksinim için bir testcase yazılmalıdır.

5.6) Kaynak kod bilinerek yapılan test tekniğidir. Genelde maliyeti azaltmak adına yazılım mühendisleri tarafından yapılmalıdır.

5.7) Unit test, statik ve dinamik kod analizleri, statement coverage, branch coverage ve path coverage white box test tipleri olarak bilinir.

5.8) Kodda bulunan mantıksal hatalar, ölü kodlar, gereksinim hataları kolaylıkla tespit edilir. Testleri test mühendisleri yapacaksa kodun onlara anlatılması ve kullandırılması zaman kaybı yaratabilir ve maliyeti arttırır.

5.9) Hem white box hem de black box testlerinin birlikte kullanılmasıyla yapılan testlerdir. Kaynak kodun bilinmesine göre test gereksinimleri çıkarılır. Bu gereksinimler belirli girdilere göre test edilerek çıktılar değerlendirilir.

Bölüm 6 - Yazılım Test Türleri

6.1) Statik ve Dinamik olmak üzere 2 türdür. Statik test türünde yazılım çalıştırılmadan önce, yapılan testleri içerir. Dinamik test türünde ise yazılım çalıştırıldıktan sonra yapılan testleri içerir.

6.2) Kodun çalıştırılmadan önce yapısal olarak incelendiği test türüdür.

6.3) İleri ki aşamalarda çıkacak olan hataları önceden farketmek için yapılan çalışmalardır. Yönetimsel, teknik, denetleme, inceleme ve kod geçişleri gözden geçirme bileşenleri olarak bilinir.

6.4) 5 adet gözden geçirme yapılır. Bunlar yönetim katının perspektifi ile yapılan, projenin planı ve takviminin nasıl gittiğinin denetlendiği yönetimsel gözden geçirme, proje mimarları tarafından teknik olarak gidişatın denetlendiği teknik gözden geçirme, süreçlerin ve proje gereksinimlerinin denetlendiği denetleme gözden geçirme, kodların, tasarımların ve standartların denetlendiği inceleme gözden geçirme ve son olarak yazılımın iyileştirilmesi adına yapılan denetlemeler olan kod geçişleri gözden geçirme olarak 5 şekilde gerçekleştirilir.

6.5) İlk olarak gözden geçirilecek faaliyetlerin planlaması yapılır. Ardından bu planlama ilgili proje takımına bildirilir ve anlatılır. Bilgilendirilen takım üyelerinin ger biri görev dağılımı eşliğinde hazırlık yapar. Belirli bir yetkinliğe ulaşan her bir takım üyesi bir yerde toplanarak iletişim kurar, toplantı yapılır. Toplantı sonrasında ortaya çıkarılan hataların çözüme gidildiği tekrar çalışma süreci başlatılır. Süreç sonunda izleme faaliyetleri başlatılarak hedeflenen tüm amaçlar ve çözümler tek tek denetlenir.

6.6) Yazılım çalıştırılmadan önce kodun içerdiği, hataları ortaya çıkarmak için yapılan testlere denir.

Context-Sensitive Interprocedural Analysis
Data Flow Analysis
Pointer Analysis
False Path Pruning
Function Value Analysis

gibi tekniklerin bütününü oluşturur.

6.7) Sistemin çalıştırılması ile verilerin tutarlılığı, güvenilirliği gibi etmenler açısından yapılan testlere denir. Performans, uyumluluk, yükleme, stres, uygunluk, işlevsel, keşif, yineleme, duman, sürüm doğrulama, geri alma ve güvenlik testleri gibi tekniklerin bütününü oluşturur.

Bölüm 7 - Test Belgelendirmesi

7.1) Test belirtimleri, test koşturma ve test raporlama olmak üzere 3 sınıfta tanımlar. Testlerin amacı, ne zaman ve kimler tarafından hangi testlerin icra edileceği gibi bilgiler belirtim belgelerinde yer alır. Test koşturma test loglarını toplama ve belgelendirme sürecidir. Test raporlama ise testlerin sonuçlarını derleyen belgeler bütünüdür.

7.2) Test plan tanımlayıcı, giriş, test elemanları, test edilecek ve edilmeyecek durumlar, strateji, pass/fail kriterleri, testleri durdurma kriterleri, test çıktıları, test görevleri, çevresel ihtiyaçlar, sorumluluklar, eğitim ihtiyaçları, takvim, riskler ve onayları kapsar.

7.3) Tanımlayıcı, test edilecek özellikler, ayrıntılı yaklaşımlar, testcase tanımları ve pass/fail kriterlerini içerecek şekilde yazılır.

7.4) Tanımlayıcı, özet, farklılıklar, kapsamlı değerlendirme, sonuçların özetlenmesi, değerlendirme, eylemlerinin özetlenmesi ve onayları içerecek şekilde yazılabilir.

Bölüm 8 - Test Yazılım Araçları ve Test Otomasyonu

8.1) 3 şekilde sınıflandırılabilir. Test planlama, kontrol ve raporlama, test hazırlık ve test koşturma yazılımları.

8.2) 3 kategoride incelenir. Test, hata ve konfigürasyon yönetim araçları.

8.3) Matematiksel veya model tabanlı diller kullanılarak geliştirilen yazılımlardır. Z dili buna bir örnektir. Ayrıca testcase yönetim araçları da örnek olarak verilebilir.

8.4) Birim test araçları, işlevsel test araçları, simülatör ve emülatörler, stub ve sürücüler, debugger, kod kapsama ve statik kod analizi araçları bu tür yazılım araçlarıdır.

8.5) Yineleme testlerinin olması, bir testin farklı input sayıda ve türde olması, input ve output' ların kesin olarak belirli olduğu durumlarda kullanılabilir.

8.6)
- Amaç test zamanının kısaltılması mı ? Yoksa maliyeti azaltmak mı ?
- Esas kriterler nelerdir ?
- Çalışılan sektörde bu iş için hangi araçlar kullanılıyor ?
- Bize uygun hangi test otomasyonu olacak ?
- İlgili test otomasyonunun bize maliyeti ve getirisi ne olacak ?

gibi sorulara yanıt verilmelidir.

8.7)
- Test case üreticileri
- Kayıt ve yeniden koşturma araçları
- Test veri üreteçleri
- Yük ve stres yazılımları

şeklinde sınıflandırılabilir.

Dr. Ali Gürbüz' ün hazırladığı bu güzide kitabın tüm soruları cevaplandırılmıştır. Umarım kitabı alan herkese faydalı olur.

Çözümler de eksiklik ya da hata olduğunu düşündüğünüz sorularda lütfen uyarıda bulunuz.

Başarılar

Fatih KABAKCI

There has been no comment yet

Name:


Question/Comment

   Please verify the image




The Topics in Computer Science

Search this site for





 

Software & Algorithms

icon

In mathematics and computer science, an algorithm is a step-by-step procedure for calculations. Algorithms are used for calculation, data processing, and automated reasoning.

Programming Languages

icon

A programming language is a formal constructed language designed to communicate instructions to a machine, particularly a computer. It can be used to create programs to control the behavior of a machine. Java,C, C++,C#

Database

icon

A database is an organized collection of data. The data are typically organized to model aspects of reality in a way that supports processes requiring information.

Hardware

icon

Computer hardware is the collection of physical elements that constitutes a computer system. Computer hardware refers to the physical parts or components of a computer such as the monitor, memory, cpu.

Web Technologies

icon

Web development is a broad term for the work involved in developing a web site for the Internet or an intranet. Html,Css,JavaScript,ASP.Net,PHP are one of the most popular technologies. J2EE,Servlet, JSP,JSF, ASP

Mobile Technologies

icon

Mobile application development is the process by which application software is developed for low-power handheld devices, such as personal digital assistants, enterprise digital assistants or mobile phones. J2ME

Network

icon

A computer network or data network is a telecommunications network that allows computers to exchange data. In computer networks, networked computing devices pass data to each other along data connections.

Operating Systems

icon

An operating system is software that manages computer hardware and software resources and provides common services for computer programs. The OS is an essential component of the system software in a computer system. Linux,Windows

Computer Science

icon

Computer science is the scientific and practical approach to computation and its applications.A computer scientist specializes in the theory of computation and the design of computational systems.