Sunum yükleniyor. Lütfen bekleyiniz

Sunum yükleniyor. Lütfen bekleyiniz

1. Yazılım Mimarileri Dersi 2 3 Asagıdan Yukarıya Tümlestirme.

Benzer bir sunumlar


... konulu sunumlar: "1. Yazılım Mimarileri Dersi 2 3 Asagıdan Yukarıya Tümlestirme."— Sunum transkripti:

1 1

2 Yazılım Mimarileri Dersi 2

3 3 Asagıdan Yukarıya Tümlestirme

4 Yazılım olu ş turan birimlerin denetim sıradüzeni içinde, birimler ya derinlik tabanlıya da geni ş lik tabanlı olarak tümle ş tirilirler. 4 Yazılım Mimarileri Önce ana denetim biriminin testi yapılır, sonra ona en yakın düzeydeki birimlerden biri ile beraber test yapılır.

5 5 Bir sonraki a ş amada aynı düzeydeki bir ba ş ka birimin testi yapılır; ya da aynı birimin bir alt düzeydeki birimle tümle ş tirmesi ve testi yapılır. Yazılım Mimarileri Bu i ş lemler sırasında tümle ş tirmesi daha sonra yapılacak olan birimin geçici olarak yerine geçecek ş ekilde basit kod parçaları veya sürücüler kullanılır.

6 Yukarıdan a ş a ğ ı tümle ş tirme stratejisinin en büyük sorunu geçici yazılım birimlerinin (stub) uygun ş ekilde hazırlanmasıdır. 6 Yazılım Mimarileri Gerekli tüm testleri yapabilmek için oldukça yetenekli kod parçalarının geli ş tirilmesi gereklidir. Bu nedenle yeterli veri giri ş çıkı ş ını sa ğ layabilecek kod geli ş tirilmeli ya da ayrıntılı testler sonraya ertelenmelidir.

7 Yukarıdan Aşagıya Tümlestirme 7

8 Alt düzey birimler birle ş tirilerek kümeler haline getirilir. Bu stratejide tümle ş tirme atomik birimlerin çalı ş tırılıp test edilmesiyle ba ş lar. Bu küme, test, senaryosu gere ğ ince geli ş tirilen bir sürücü ana programla veri giri ş /çıkı ş ı bakımından test edilir. 8 Yazılım Mimarileri

9 Daha sonra sürücü programlar ayrılarak yazılım paketinin yapısı içerisinde bulunan bu kümelerin birle ş tirilmesinden olu ş an daha üst düzeyde yeni kümeler meydana getirilir. Benzer ş ekilde, di ğ er alt düzey birimlerde kümeler halinde test edilir. 9 Yazılım Mimarileri

10 Bu kümeler de yine sürücü programlarla test edilir. Bu ş ekilde en üstte bulunan ana birime kadar ula ş ılır. Tümle ş tirme üst düzeylere do ğ ru çıktıkça test sürücülerine olan gereksinim azalır. Bu stratejinin en büyük sorunu da tümle ş tirme sonuçlanmadan önce ana yazılım paketini olu ş turmanın mümkün olmamasıdır. 10 Yazılım Mimarileri

11 Hangi stratejinin seçilecegi yazılımın özelligine yazılım gelistirme deneyimlerine ve bazen de proje planlamasına baglıdır. 11 Yazılım Mimarileri

12 Yeterlilik Testleri 12

13 Yazılım yeterlilik (qualification) testi, ço ğ u zaman do ğ rulama (verification) ve geçerleme (validation) konusunun bir parçası olarak degerlendirilir. Tümle ş tirme testinden sonra yazılım büyük ölçüde kusurlarından arındırılmı ş, ara yüzleri dogru çalı ş ır hale gelmi ş tir. 13 Yazılım Mimarileri

14 Bundan sonra bir dizi test daha yapılır. I ş te bunlar yeterlilik testleridir. Ço ğ u zaman bu testlerin ne oldu ğ u sorusu akla gelir. En yaygın yanıt, mü ş terinin umdu ğ u ş ekilde çalı ş manın saglanması ve bunun gönderilmesidir. Mü ş teriyi memnun edebilecek çalı ş ma ş ekli Sistem isterleri belirtimi belgesinde tanımlanır. 14 Yazılım Mimarileri

15 Sistem özel­liklerini tanımlayan bu belirtim belgesi aynı zamanda geçerleme ilkelerini anlatan bir bölüme sahiptir. İş te bu bölümden test yordamları ve senaryolar türetilir. Benzer ş ekilde, yazılım isterleri de Yazılım İ sterleri Belirtimi belgesinde tanımlanır. 15 Yazılım Mimarileri

16 Dogrulama 16

17 Do ğ rulama (verifıcation), bir yazılım ürününün belirli i ş levleri do ğ ru olarak gerçekle ş tirdi ğ inden emin olmak için yapılanların tümüne verilen addır. 17 Yazılım Mimarileri

18 Dogrulama sürecinde bu isler yapılmalıdır ; 18 Yazılım geli ş tirme süreci izlenirken belirlenen isterler arasında uyumsuzluk varsa, üst düzey isterden alt düzey isterin türetilmesi sırasında bir hata yapılmı ş sa, sonuçta gerçekle ş tirimi yapılan ürün asıl tanımlanan üründen farklı olabilir. Yazılım Mimarileri

19 Sözle ş me Do ğ rulaması : Geli ş tirici ile mü ş teri arasında yapılan sözle ş me a ş a ğ ıdaki kıstaslara göre do ğ rulanmalıdır. Geli ş tirici tüm isterleri kar ş ılayabilece ğ i güvenini vermektedir. 19 Yazılım Mimarileri

20 İ sterler tutarlı olup kullanıcı gereksinimlerini kapsamaktadır. İ sterlere yapılacak de ğ i ş iklikleri ve ortaya çıkabilecek problemleri kontrol edebilmek üzere yordamlar öngörülmü ş tür. Taraflar arasında, sahiplik, garanti, telif hakları ve gizlilik gibi konuları da içerecek ş ekilde i ş birli ğ i ve temas noktalan için yordamlar öngörülmü ş tür. 20 Yazılım Mimarileri

21 Süreç Do ğ rulaması : Süreç a ş a ğ ıda listelenen kıstaslara göre do ğ rulanmalıdır: Proje planlamaları yeterli ve takvime uygundur. 21 Yazılım Mimarileri

22 22 Proje için seçilen süreçler yeterlidir, planlandı ğ ı ş ekilde yürütülmektedir ve sözle ş meye uygundur. Proje süreçleri için seçilmi ş standartlar, yordamlar ve ortamlar yeterlidir. Proje personeli sa ğ lanmı ş ve sözle ş me gereklerine göre e ğ itilmi ş tir. Yazılım Mimarileri

23 İ sterler Do ğ rulaması : İ sterler a ş a ğ ıda belirtilen kıstaslara göre do ğ rulanmalıdır. Sistem isterleri tutarlı, gerçekle ş tirilebilir ve test edilebilir durumdadırlar. Sistem isterleri tutarlı, gerçekle ş tirilebilir ve test edilebilir durumdadırlar. 23 Yazılım Mimarileri

24 Sistem isterleri tasarım ölçütlerine uygun ş ekilde donanım ö ğ elerine, yazılımı ö ğ elerine ve el i ş lemlerine atanmı ş tır. Yazılım isterleri tutarlı, gerçekle ş tirilebilir ve test edilebilir durumda olup sistem isterlerine uymaktadır. Emniyet, güvenlik ve kritik durumlarla ilgili yazılım isterleri do ğ rudur. Emniyet, güvenlik ve kritik durumlarla ilgili yazılım isterleri do ğ rudur. 24 Yazılım Mimarileri

25 Tasarım Do ğ rulaması : Tasarını a ş a ğ ıda belirtilen kıstaslara göre do ğ rulanmalıdır. Tasarım isterlere göre tutarlıdır ve izlenebilir durumdadır. 25 Yazılım Mimarileri

26 Tasarım, olayların, girdilerin, ara yüzlerin, mantık akı ş ının uygun dizili ş ­lerini, zaman ve büyüklük tahsislerini, hata tanımlarını, hataya dayanıklı­lı ğ ı ve geri kazanmayı gerçekle ş tirmektedir. Seçilen tasarım isterlerden türetilebilmektedir. Tasarım, emniyet, güvenlik ve di ğ er kritik durumlarla ilgili isterleri gerçekle ş tirmektedir. 26 Yazılım Mimarileri

27 Kod Do ğ rulaması : Yazılan kaynak kod a ş a ğ ıda belirtilen kıstaslara göre do ğ rulanmalıdır. Kod tasarıma ve isterlere göre izlenebilir türetilebilir ve test edilebilir. Kod tasarıma ve isterlere göre izlenebilir türetilebilir ve test edilebilir. 27 Yazılım Mimarileri

28 Kod tasarım ve isterlere göre gerekirse yeniden yazılabilir. Kod, do ğ ru ve kodlama standartlarına uygun durumdadır. Kod, emniyet, güvenlik ve di ğ er kritik durumlarla ilgili isterleri gerçekle ş ­tirmektedir. Kod, emniyet, güvenlik ve di ğ er kritik durumlarla ilgili isterleri gerçekle ş ­tirmektedir. Kod, yazan ki ş iden ba ş kası tarafından rahatça okunabilir, anla ş ılabilir. Kod, yazan ki ş iden ba ş kası tarafından rahatça okunabilir, anla ş ılabilir. 28 Yazılım Mimarileri

29 Tümle ş tirme Do ğ rulaması : Tümle ş tirme a ş a ğ ıda belirtilen kıstaslara göre do ğ rulanmalıdır. Her yazılım ö ğ esinin bile ş enleri ve birimleri ö ğ eyle tam ve do ğ ru olarak tümle ş tirilmektedir. 29 Yazılım Mimarileri

30 Tümle ş tirme i ş leri belirli bir tümle ş tirme planına uygun olarak yapılmaktadır. Sistemin donanım ö ğ eleri, yazılım ö ğ eleri ve el i ş lemleri sistemler tam ve do ğ ru olarak tümle ş tirilmektedir. 30 Yazılım Mimarileri

31 Belgelendirme Do ğ rulaması : Belgelendirme a ş a ğ ıda belirtilen kıstaslara göre do ğ rulanmalıdır: Belgelendirme yeterli, uygun, tanı, anla ş ılabilir ve tutarlıdır. Belgelendirme hazırlıkları takvime uygundur; bir gecikme nedeni olmaz. 31 Yazılım Mimarileri

32 32 Belgelerin düzenle ş im yönetimi, sürüm, baskı ve da ğ ıtım denetimi belirlenmi ş yordamlara göre yapılmaktadır. Belgeler gizlilik derecelerine uygun ş ekilde saklanmaktadırlar. Yazılım Mimarileri

33 Geçerleme 33

34 Geçerleme (validation), yani geçerli kılma ya da sa ğ lama, kullanıcı gerek­sinimleri kar ş ılayan do ğ ru ürünün üretilip üretilmedi ğ inin sınanmasıdır. Geçerleme yazılımın do ğ ru amaç için geli ş tirildi ğ inin gerçek ortamda denenerek do ğ rulu ğ una kanaat getirilmesi demektir. Bunun yanında, yazılımın i ş levleri kadar iç özelliklerinin ve niteli ğ inin de arzu edilen düzeyde olup olmadı ğ ının denetlenmesini içerir. 34 Yazılım Mimarileri

35 Geçerleme süreci iki etkinlik içerir. Süreç gerçekle ş tirimi ve geçerleme. Bunlardan süreç gerçekle ş tirimi sırasında, proje için geçerlemenin gerekip gerekmedi ğ i ve ne kadar ba ğ ımsız gruplarca yapılaca ğ ı belirlenir. 35 Yazılım Mimarileri

36 Geçerleme uygulanacak ö ğ elerin, yapılacak i ş lerin ve testlerin, özkaynakların, sorumlulukların, takvimin ve raporlama yordamlarının tanımlandı ğ ı bir geçerleme planı hazırlanır ve uygulamaya konur. Geçerleme uygulanacak ö ğ elerin, yapılacak i ş lerin ve testlerin, özkaynakların, sorumlulukların, takvimin ve raporlama yordamlarının tanımlandı ğ ı bir geçerleme planı hazırlanır ve uygulamaya konur. 36 Yazılım Mimarileri

37 Genellikle her test için üç sonuçtan biri elde edilir: Ba ş arı, kısmen ba ş arı veya ba ş arısızlık. Tabii ki ba ş arı durumu hem geli ş tirici hem de mü ş teri için arzu edilen sonuçtur. Do ğ rulama i ş leminde ise, test isterleri, test senaryoları, sonuçları de ğ erlendirmek için test belirtimleri hazırlanır. 37 Yazılım Mimarileri

38 Kısmen ba ş arı, belirlenen kusurların kısa sürede giderilebilecek cinsten olması durumunda geçerlidir. 38 Yazılım Mimarileri

39 Ba ş arısızlık, belirlenen kusurlar belirtilen süre içerisinde giderilemez. 39 Yazılım Mimarileri

40 Rastgele Testler 40

41 Örne ğ in, çok miktarda kullanıcı girdisi gerektiren bir yazılım, tüm i ş levleri normal yapıyor olsa da, olu ş ması son derece dü ş ük bir olasılı ğ a sahip tu ş kombinasyonlarından birinde hataya neden olabilir. 41 Yazılım Mimarileri

42 Kullanıcının belirli bir sırayı takip ederek veri giri ş i yapması beklenirken, bir kullanıcının de ğ i ş ik bir sıra takip etmesi sistemi olumsuz etkileyebilir. 42 Yazılım Mimarileri

43 İş te böyle önceden tahmin edilemeyen durumları gerçekle ş tirebilmek için yazılım test personeli veya kullanıcılar sistem üzerinde rasgele hareketlerle testler yapabilirler. 43 Yazılım Mimarileri

44 Yordamları resmi olarak tanımlanmı ş testlerden ba ş arıyla geçen pek çok sistem bu tür testlerde ba ş arısızlı ğ a u ğ rayabilir. Ancak, önemli olan, ortaya çıkması olası her hatayı sistemi kullanıma vermeden önce yakalamak ve gidermektir. 44 Yazılım Mimarileri

45 Sistem Testi

46 46 Yazılım hiçbir zaman kendi ba ş ına bir sistem degildir. Sistemin ancak bir parçasıdır. SISTEM TESTI Yazılım Mimarileri

47 Her yazılım belli bir donanım üzerinde çalı ş ır bir takım alt sistemlerle tümle ş ir. Topladı ğ ı bilgileri i ş leyerek sonuçları sergiler yada do ğ rudan bir donanımı kumanda eder. Topladı ğ ı bilgileri i ş leyerek sonuçları sergiler yada do ğ rudan bir donanımı kumanda eder. 47 SISTEM TESTI Yazılım Mimarileri

48 Hem yazılım hemde donanımı kapsayan bu testlerin öncesinde de hata bulma ve sistemi deneme amacıyla hazırlık testleri yapılır. Testlerin ş ekilleri uygulama alanlarına göre farklılık göstersede hem donanım hemde yazılım bile ş enlerini kapsayan sistem testleri tümle ş tirme ve do ğ rulama amacıyla yapılır. 48 SISTEM TESTI Yazılım Mimarileri

49 Sistem testleri sırasında kar ş ıla ş ılan en büyük sorun bir hata ortaya çıktı ğ ında sistemi olu ş turan bile ş enlerin üreticilerinin birbirlerini kusurlu üretimle suçlamaları hatanın kendilerinde olmadı ğ ını savunmalarıdır. Özellikle büyük sistemlerde tümle ş tirme testlerinde daha az hatayla kar ş ıla ş ılır. 49 SISTEM TESTI Yazılım Mimarileri

50 Yazılım geli ş tirici kendi paketlerinin geli ş tirme ortamında do ğ ru çalı ş tı ğ ını savunurken donanım bile ş enlerinden birinin üreticisi di ğ er bile ş enin kendi çalı ş masını etkiledi ğ ini iddia edebilir. 50 SISTEM TESTI Yazılım Mimarileri

51 Bu tür tartı ş malar basit bir soketin yerine oturmamı ş olmasının belirlenmesiyle sonlanabilir veya kar ş ılıklı suçlamalarla devam edebilir. 51 SISTEM TESTI Yazılım Mimarileri

52 Oysa kısır tartı ş malar yerine yapılması gereken donanım mühendisleri için tüm ba ğ lantıları ve donanımları kontrol etmek yazılım mühendisleri içinde gerekli testleri yapmak ve hata arama yollarına gitmektir. 52 SISTEM TESTI Yazılım Mimarileri

53 Sistem düzeyindede çe ş itli testler yapılmı ş tır. Bu testlerin neler olabilce ğ ine bakalım ; 53 SISTEM TESTI Yazılım Mimarileri

54 Yükleme Testi

55 Her bilgisayar sistemi belirli tür ve miktarda veriyi i ş lemek ve bunlara göre ba ş ka veriler üretmek üzere tasarlanır. Gerçek zamanlı sistemler ve kontrol sistemleri daha çok belirli kesmelere kar ş ı bir i ş lem yaparak belirli bir tepkide bulunurlar. 55 YÜKLEME TESTI Yazılım Mimarileri

56 Veri tabanı yönetim sistemleri ise çok miktarda veriyi saklamak, bunlar üzerinde sorgulama yapma ve rapor üretme gibi i ş levlerde yürütülür. İş te bu tür yo ğ un veri akı ş ına sahip sistemler için yükleme testleri yapılır.(LOAD TEST) 56 YÜKLEME TESTI Yazılım Mimarileri

57 Bu testler sistemin sınırlarını zorlayarak en fazla ne kadar veri i ş leme kapasitesi oldu ğ unu belirlemek ve ne gibi sonuçlar sergileyece ğ ini kontrol etmek amacıyla yapılır. 57 YÜKLEME TESTI Yazılım Mimarileri

58 Germe Testi

59 Ancak bu testler her ş eyin normal oldu ğ u durumlarda en ideal ko ş ullarda yapılır. Hatta bazı durumlarda isterlerde belirtilen de ğ erlerin de üzerine çıkılarak kaldırılabilecek en fazla yükün ne olabilece ğ i ara ş tırılır. 59 GERME TESTI Yazılım Mimarileri

60 Bir yazılım bile ş eni tek ba ş ına test edildi ğ inde normal çalı ş ıyorken tümle ş tirildi ğ i sistemin di ğ er bile ş enleriyle beraber normal çalı ş ması mümkün olmayabilir. Bu kusurun bulunması ve düzeltilmesi tümle ş tirme sırasında yapılabilir. 60 GERME TESTI Yazılım Mimarileri

61 Bu amaçla yapılabilecek testler ş unlardır ; Birde normal olmayan ko ş ullar olu ş turuldu ğ unda hem yazılım hemde donanım ne ş ekilde davranaca ğ ını görmek üzere germe testleri yapılmalıdır. 61 GERME TESTI Yazılım Mimarileri

62 Yüksek hacim ve hızda veri giri ş i olu ş turmak.  Sistemi normal olmayan miktarda zorlamak amacıyla yapılan testler ; 62 GERME TESTI Yazılım Mimarileri

63 63 Beklenenden çok daha yüksek frekansta kesmeler olu ş turmak. Beklenen ve kullanımdan çok daha fazla bellek ve i ş lemci gücü gerektirecek durumlar olu ş turmak. GERME TESTI Yazılım Mimarileri

64  Sistem donanımlarının bir kısmının çökmesi durumunda geri kalan bile ş enlerin çalı ş mayı sürdürebilme durumları testi.  Isletim sistemini zorlayarak çökertmeye yönelik testler. 64 GERME TESTI Yazılım Mimarileri

65 65  Sistemin kaldırabilecegi en fazla yük durumunda ani etkilere verilecek tepki süresini ölçmek üzere yapılan testler. GERME TESTI Yazılım Mimarileri

66 Geri Kazanma Testi

67 Donanım hatası olu ş tu ğ unda eger yedekleme amaçlı fazladan donanım bulunuyorsa bu donanım otomatik olarak devreye girebilir. Bilgisayar sistemlerinin ço ğ undan bir hata durumunda kendini toplayarak tekrar çalı ş maya devam etmesi beklenir. 67 GERI KAZANMA TESTI Yazılım Mimarileri

68 Hataya dayalı yazılım ise herhangi bir nedenle bütünüyle çökmemek üzere kendi ba ş latılarak eski durumuna gelmesi saglanır. Bazı durumlarda donanım yedeklemesi yanında yazılım yedeklemesi yapılır veya hataya dayanıklı yazılım kullanılır. 68 GERI KAZANMA TESTI Yazılım Mimarileri

69 Aksi taktirde ekonomik kayıplar hatta can kayıpları meydana gelebilir. Bu yöntemlerle geri kazanma (recovery) belirli bir süre içinde yapılmak zorundadır. 69 GERI KAZANMA TESTI Yazılım Mimarileri

70 Geri kazanım testi öncesi yazılımın sonrada donanımı çesitli olası sekillerde bilinçli bir sekilde çökerterek sistemin kendini tekrar toplama denenmesi, isterlerin dogrulanması amacıyla yapılır. 70 GERI KAZANMA TESTI Yazılım Mimarileri

71 Bu kapsamda genelde su testler yapılır ; Çökme sırasında kaybolması olası verilerin tekrar alınması veya üretilmesi. Yedekli donanım mimarisinde asıl çalı ş an donanımın devreden çıkarılması halinde yedek donanım kesintisiz çalı ş maya devam etmesi. (hot swapping) 71 GERI KAZANMA TESTI Yazılım Mimarileri

72 Emniyet Testi

73 Örne ğ in önemli öz kaynakları denetleyen sistemler sa ğ lık alanındaki sistemler uçu ş seyir sistemleri askeri amaçlı sistemler geli ş tirilirken mutlaka emniyet ön planda tutulmalıdır. Bazı bilgisayarlı sistemler uygulama özelliklerine göre emniyetli olarak çalı ş mak zorundadır. 73 EMNIYET TESTI Yazılım Mimarileri

74 Bu gibi durumlar önceden belirlenmeli ve önlemler alınmalıdır bu amaçla su testler yapılmalıdır ; Bir yazılım hatası nedeniyle o anda istenmeyen bir durumun bir i ş in yapılmasını engelleyebilmektedir. 74 EMNIYET TESTI Yazılım Mimarileri

75 Bir yazılım veya donanım kusuru olu ş tu ğ unda sistemin yerine getirmesi gereken ana i ş levde tehlike olu ş turabilecek durum olu ş up olu ş madı ğ ının testi. 75 EMNIYET TESTI Yazılım Mimarileri

76 76 Uç noktalardaki emniyet gereksinimleri için tasarım sırasında alınmı ş donanım veya yazılım düzeneklerinin testi.(donanım kilidi özel anahtar kullanımı, yazılımda ş ifre sorulması, merkezi kilit sistemi gibi ) EMNIYET TESTI Yazılım Mimarileri

77 Örnegin bir banka yazılımı binlerce müsterinin hesaplarını tutar. Bazı bilgisayarlar hassas veya çok özel bilgileri islerler. 77 EMNIYET TESTI Yazılım Mimarileri

78 Bu amaçla bilgisayar saldırganları(hacker) veya virüsler çok büyük tehlike olusturur. Bir sosyal güvenlik sistemi yazılımı yüzbinlerce milyonlarca kisinin özel kayıtlarını tutar. 78 EMNIYET TESTI Yazılım Mimarileri

79 Ş ifrelerden ba ş layan ve her türlü giri ş yöntemini deneyen bir testçi tarafından denenmesi. Bu tür tehlikelere açık olan sistemler için bu güvenlik testleri yapılmalıdır ; Yetkisiz giri ş denemelerini fark etme giri ş imciyi bir tuza ğ a çekme, oyalama ve kimli ğ ini tespit etmeye yönelik testler. 79 EMNIYET TESTI Yazılım Mimarileri

80 Uzman testçi kullanılarak sistemin zayıf noktalarının kullanıma sunmadan önce bulmaya yönelik gerçek ortamda fakat kontrollü olarak yapılan testlerdir. Normal olmayan bir giri ş in fark edilmesi ve raporlama testi. 80 EMNIYET TESTI Yazılım Mimarileri

81 Başarım Testi

82 Yazılımın yürütme anındaki ba ş arımı geli ş tirme sırasında uygulanan tekniklere ve tasarıma ba ğ lı oldu ğ u kadar üzerinde çalı ş tı ğ ı donanıma da ba ğ lıdır. Her bilgisayar sistemi için en önemli genel isteklerden biri ba ş arım yani performanstır. 82 BASARIM TESTI Yazılım Mimarileri

83 Bu isterlerin uygun bir ş ekilde kar ş ılanıp kar ş ılanmadı ğ ını görmek için tümle ş tirilen yazılım ve donanımın üzerinde ba ş arım testleri yapılır. Ancak bütün olarak geli ş tirilen sistemlerin en son ba ş arımları özel olarak test edilmeli ve uygulama alanının özelliklerine göre uygun bir düzeyde tutulmaya çalı ş ılmalıdır. 83 BASARIM TESTI Yazılım Mimarileri

84 Ba ş arım testleri bazen germe testleri ile beraber yapılır. Böyle durumları belirlemek ve ba ş arım derecesini ölçmek için çe ş itli araç ve gereçler kullanılır. 84 BASARIM TESTI Yazılım Mimarileri

85 Örne ğ in bir verinin sisteme giri ş anı ile çıkı ş anı arasındaki zaman farkının ölçülmesi toplam bilgi i ş leme yetene ğ ini ölçmek üzere bilgi i ş leme ö ğ elerinin sayılması gibi testler yapılır. 85 BASARIM TESTI Yazılım Mimarileri

86 Bu fonksiyon ile sistemin hangi yükte uygun ba ş arımla çalı ş tı ğ ı belirlenir ve daha fazla yükte nasıl yava ş laca ğ ı konusunda kullanıcı uyarılır. 86 BASARIM TESTI Yazılım Mimarileri

87 Kabul Testi

88 Sistem testleri bilgisayar tabanlı sistemin bir bütün olarak denenmesi verilen i ş levleri ba ş arıyla yerine getirip getirmediginin test edilmesi amacıyla yapılır. 88 KABUL TESTI Yazılım Mimarileri

89 Sistemin büyüklü ğ ü büyüklü ğ ü ve uygulama alanının özelli ğ i özelli ğ i yapılacak sistem testlerinin geni ş li ğ i maliyeti ve süresini etkileyen en büyük unsurlardır. Sistemin kabulüne etki eden testler genellikle üç a ş amada a ş amada gerçekle ş tirilir. 89 KABUL TESTI Yazılım Mimarileri

90 Üretim Hattı Kullanım Hattı Denemeler

91 Üretim Hattı

92 Üretim hattı testleri üreticinin kendi tesislerinde tanımlanmı ş bir test donanımı üzerinde yazılımı yapay verilere sınamaya dayanır. 92 URETIM HATTI TESTI Yazılım Mimarileri

93 Bazen bu testlere fabrika kabul testleri veya fabrika yeterlilik testleri denir. Örnek sistem olarak bir binanın ısıtma sistemini ele alalım bu sistemde bulunan ısı algılayıcıları ısıtıcıları ve havalandırıcılar i ş letmen tarafından ayarlanan sıcaklık de ğ erini korumaya çalı ş ırlar. 93 URETIM HATTI TESTI Yazılım Mimarileri

94 Bu testi geçen donanım ögesi seri halde üretilebilir demektir ve her birine ayrı ayrı fabrika testi uygulanır. Özelliklede seri halde üretilen donanımlara uygulanan bir test türüde ilk Örnek Kabul Testidir. 94 URETIM HATTI TESTI Yazılım Mimarileri

95 Kullanım Hattı Testi

96 Sistemin kullanılaca ğ ı yerde gerçek donanıma yüklenmi ş yazılımla ve gerçek verilerle yapılan sınamalara Kullanım Hattı Testleri di ğ er bir de ğ i ş le de Yerle ş ke Testleri denir. Biraz önceki sıcaklık kontrol sistemi binaya monte edildikten sonra elektriksel olarak tüm ba ğ lantıların do ğ ru olarak yapıldı ğ ı test edilir. 96 KULLANIM HATTI TESTI Yazılım Mimarileri

97 Bu durumda sisteme elektrik verilir birimlerin kendi ba ş larına çalı ş tı ğ ı görülür ve üzerlerine yazılım yüklenerek sistemin çevre birimleriyle iyi tümle ş ti ğ i test edilir. Burada Çalı ş maya Hazırlık i ş lemleri yapılır. 97 KULLANIM HATTI TESTI Yazılım Mimarileri

98 Örneğin sıcaklık kontrolü yapılacak bina tam olarak kullanıma açıldığında içeride bulunan personelin aydınlatıcıların ve çalışan diğer cihazların yaydığı ısı sürekli olarak havalandırma sisteminin çalışmasını gerektiriyor olabilir. 98 KULLANIM HATTI TESTI Yazılım Mimarileri

99 Bu durumdaki sistem davranıslarını görmek isterleri test etmek için bir sonraki asama olan deneme testleri yapılır. 99 KULLANIM HATTI TESTI Yazılım Mimarileri

100 Deneme Testi

101 Bu testlerde akla gelebilecek her türlü ola ğ an dı ş ı durumun denenmesine çalı ş ılır. Deneme testleri bir deyi ş le i ş letim testleri uygulama alanında kar ş ıla ş ılması olan durumları gerçek ko ş ullarda denemek için kullanım sırasında gerçek verilerle yapılan testlerdir. 101 DENEME TESTI Yazılım Mimarileri

102 Örnegimizdeki sıcaklık kontrol sisteminin kullanım testi için ortam sıcaklı ğ ının yükselmesi durumunda ısı ölçer algılaması verileri sisteme göndermesi durumudur. 102 DENEME TESTI Yazılım Mimarileri

103 Eger herhangi bir ş ekilde sorun varsa giderilir. 103 DENEME TESTI Yazılım Mimarileri

104 Alfa Ve Beta Testi

105 Yazılım geli ş tiriciler eger uygulama alanına çok hakim de ğ illerse kullanıcı sistemi nasıl kullanaca ğ ı hakkında fazla bir öngörüye sahip olamayabilirler. Kullanıcı kılavuzları yanlı ş anlamı ş olabilir giri ş verileri sistemi çökertecek bir de ğ erde olabilir veya sürekli olarak aynı tür hatalar yaptı ğ ı için belirli i ş levlere ula ş amıyor olabilir. 105 ALFA VE BETA TESTI Yazılım Mimarileri

106 Ancak kullanım sırasında ortaya çıkabilecek bu tür hataları yakalamak üzere belirli bir süre kullanım testleri yapılabilir. 106 ALFA VE BETA TESTI Yazılım Mimarileri

107 Alfa Testi

108 Geli ş tricinin kendi yerinde bir mü ş teri tarafından yapılır. Geli ş tirici bu testleri gözlemleyerek gerçek kullanım hakkında bilgi sahibi olmaya çalı ş ır kusur buldukça not alır ve düzeltme i ş lemi yürütür. 108 ALFA TESTI Yazılım Mimarileri

109 Özellikle cok sayıda pazarlanacak yazılımlarda kullanılır. 109 Alfa testlerinin en önemli özelli ğ i denetim altındaki bir ortama asıl kullanıcılardan biri tarafından yapılıyor olmasıdır. ALFA TESTI Yazılım Mimarileri

110 110 BetaTesti Yazılım Mimarileri

111 Bir yada daha fazla kullanıcının kendi ortamında yapılır.Geli ş tirici genellikle bu testlere katılmaz yalnızca belirli aralıklara sonuçları ve yorumları alır. 111 Yazılım Mimarileri

112 Bu testin özelli ğ i de geli ş tirici tarafından kontrol edilmeyen gerçek uygulama ortamı ko ş ullarında yazılımın denenmesidir. 112 Yazılım Mimarileri

113 113 Kabul Kıstasları Yazılım Mimarileri

114 Her türlü kabul testi mü ş teriye sistemin do ğ ru çalı ş tı ğ ını göstermek için yapılır testler Ço ğ u zaman yüksek maliyet gerektirdi ğ inden ne kadar kapsamlı test istendi ğ i sözle ş mede belirtilmeli ve özel olarak bütçe ayrılmalıdır. 114 Yazılım Mimarileri

115 Aksi taktirde mü ş terinin arzu etti ğ i kadar uzun süre ve ayrıntıda test yapmak fazla maliyete neden olabilir.Öte yandan, yetersiz testler mü ş terinin kullanım sırasında sorunlarla kar ş ıla ş masına ve memnuniyetsizli ğ e yol açar. 115 Yazılım Mimarileri

116 116 Şekilsel Hatalar Yazılım Mimarileri

117 Özellikle kullanıcı arayüzlerinin renk ve ş ekillerinde, yazılarda ve kısaltmalarda, yazı biçimlerinde,hizalamalarda fark edilen hatalardır.Testleri etkilemezler, ancak düzeltilmeleri istenebilir. 117 Yazılım Mimarileri

118 118 Küçük Boyutta Hatalar Yazılım Mimarileri

119 Sistemi tamamen etkilemeyen, giderilmesi kolay olan genellikle kodlama düzeyinde yapılmı ş hatalardır. Gerekirse testler sırasında kod düzeltilip tekrar test edilebilir. 119 Yazılım Mimarileri

120 120 Büyük Boyutta Hatalar Yazılım Mimarileri

121 Önemli miktarda düzeltme gerektiren hatalardır. Geli ş tirme sürecinin bir kısmının tekrarlanması gerekebilir ve teslim süresi uzayabilir. 121 Yazılım Mimarileri

122 122 Test Yönetimi Yazılım Mimarileri

123 Test yönetimi büyük projeler için çok önemlidir O neden proje örgütü içinde mutlaka bir test yöneticisi bulunmalıdır. Bu yönetici altında, mümkünse o projenin geli ş tirme görevlerinde bulunmamı ş ki ş iler görevlendirilmeli ba ğ ımsız bir test grubu olu ş turulmalıdır. 123 Yazılım Mimarileri

124 Bir yazılım ö ğ esinin testine en az a ş a ğ ıdaki personel katılmalıdır: Geli ş tirici ekip lideri ve kodlayıcı Proje yöneticisinin kendisi veya test yöneticisi olarak görevlendirdi ğ i ki ş i 124 Yazılım Mimarileri

125 125 Nitelik Güvence Sorumlusu Yazılım Mimarileri

126 Test Sistemi Yöneticisi Tüm sistemin kabul testlerine ise mü ş teri temsilcisi mutlaka katılmalıdır. Kabul testlerine geli ş tirici ekiplerin katılması zorunlu de ğ ildir, herhangi bir teknik açıklama gerekti ğ inde ça ğ rılmak üzere hazır bulunmaları yeterlidir. 126 Yazılım Mimarileri

127 Proje kapsamında testlerin yapılmasından sonra test sonuçlarının de ğ erlendirimesi için a ş a ğ ıdakiler yapılır. Test sonuçları belgelendirilir ve tüm ilgili taraflara duyurulur. Test sırasında bulunan hatalara bakılarak ürünün nitelik profili de ğ erlendirilir. 127 Yazılım Mimarileri

128 Test sonuçlarına bakarak maliyet ve nitelik tartım çözümlemesi yapılır. İ yile ş tirme seçenekleri için karar verilir Kararla ş tırılan ürün iyile ş tirme i ş leri için görevlendirme yapılır ve geli ş im sonuna kadar izlenir. 128 Yazılım Mimarileri

129 129 Hata Ayıklama Yazılım Mimarileri

130 Bilgisayarlı sistemlerin en büyük sorunlarından biri hata durumunda hangi bile ş enlerin kusurlu oldu ğ unun belirlenmesidir. 130 Yazılım Mimarileri

131 Kusur donanımda olabilece ğ i gibi yazılımdada olabilir hatta yalnızca basit bir kabloda olabilir kusurun yazılımda oldu ğ unun bulunmasından sonra da hatalı çalı ş an yazılımların nerede hata yaptıklarını bulmak yeni bir sorun olarak ortaya çıkar. 131 Yazılım Mimarileri

132 Ne yazık ki günümüzdeki pek çok programlama dili ve derleyicisi yürütme anındaki hataların neden kaynaklandı ğ ını bize net olarak söylememektedir. 132 Yazılım Mimarileri

133 Hata ayıklama süreci test sırasında bulunan hatanın nereden kaynaklandı ğ ını belirlenmesi genellikle geli ş tiricinin deneyimine ba ğ lıdır yeri ve sebebi hemen belirlenmeyen hatanın ara ş tırılması için bir çözümleme yapılması zorunludur. 133 Yazılım Mimarileri

134 Ço ğ u zaman deneme-yanılma yönetimi kullanılarak hatanın giderilmesi bir rastlantıya bırakılır. 134 Yazılım Mimarileri

135 Çözümleme sırasında kesin olduklarından emin olunamayan ş üpheli hata nedenleri için ek testler tasarlanır yeni senaryolar hazırlanır. 135 Yazılım Mimarileri

136 Bu senaryolar çalı ş tırılarak yeni test sonuçları elde edilir ve tekrar çözümleme yapılır bu süreç test sonuçları ba ş arılı bulununcaya kadar devam eder. 136 Yazılım Mimarileri

137 137 Yazılım Mimarileri

138 Ö ğ r. Gör. Mevlüt İ NAN 138 Yazılım Mimarileri


"1. Yazılım Mimarileri Dersi 2 3 Asagıdan Yukarıya Tümlestirme." indir ppt

Benzer bir sunumlar


Google Reklamları