Yazılım testi metodolojisi ve uygulaması. Yazılım testi türleri. Tam liste

Yazılım testi (SW), koddaki ortadan kaldırılması gereken kusurları, kusurları ve hataları ortaya çıkarır. Yazılımın işlevselliğini ve doğruluğunu analiz yoluyla değerlendirme süreci olarak da tanımlanabilir. Yazılım ürünlerinin ana entegrasyon ve test yöntemleri, uygulamaların kalitesini garanti eder ve spesifikasyonun, tasarımın ve kodun kontrol edilmesinden, güvenilirliğin değerlendirilmesinden, doğrulama ve doğrulamadan oluşur.

yöntemler

Yazılım testinin temel amacı, dikkatli bir şekilde kontrol edilen koşullarda uygulamalarda sistematik olarak hata ayıklayarak, bunların eksiksizliğini ve doğruluğunu belirleyerek ve ayrıca gizli hataları tespit ederek bir yazılım paketinin kalitesini doğrulamaktır.

Metotlar statik ve dinamik olarak ikiye ayrılabilir.

İlki, gayri resmi, kontrol ve teknik emsal incelemesi, teftiş, gözden geçirme, denetim ve veri akışı ve kontrolünün statik analizini içerir.

Dinamik teknikler aşağıdaki gibidir:

1. Beyaz kutu testi. Bu, bir programın iç mantığının ve yapısının ayrıntılı bir çalışmasıdır. Bu, kaynak kodu hakkında bilgi gerektirir.
2. Kara kutu testi. Bu teknik, uygulamanın iç işleyişi hakkında herhangi bir bilgi gerektirmez. Sistemin yalnızca iç mantıksal yapısıyla bağlantılı olmayan veya çok az ilgisi olan ana yönleri dikkate alınır.
3. Gri kutu yöntemi.Önceki iki yaklaşımı birleştirir. Uygulamanın dahili işleyişi hakkında sınırlı bilgi ile hata ayıklama, sistemin temel yönleri bilgisi ile birleştirilir.

Şeffaf test

Beyaz kutu yöntemi, prosedürel bir projenin kontrol yapısının test komut dosyalarını kullanır. Bu teknik, bir yazılım parçasının iç işleyişini analiz ederek zayıf kod yönetimi gibi uygulama hatalarını ortaya çıkarır. Bu test yöntemleri entegrasyon, birim ve sistem seviyelerinde uygulanabilir. Test eden kişinin kaynak koduna erişimi olmalı ve bunu hangi bloğun uygunsuz davrandığını bulmak için kullanmalıdır.

Programların beyaz kutu testi aşağıdaki avantajlara sahiptir:

• fazladan satırları silerken gizli koddaki bir hatayı belirlemenizi sağlar;
• yan etkileri kullanma olasılığı;
• maksimum kapsama, bir test komut dosyası yazılarak elde edilir.

Dezavantajları:

• nitelikli bir hata ayıklayıcı gerektiren yüksek maliyetli bir süreç;
• olası tüm gizli hataların kapsamlı bir şekilde kontrol edilmesi çok zor olduğundan, birçok yol keşfedilmemiş kalacaktır;
• eksik kodun bir kısmı fark edilmeyecektir.

Beyaz kutu testi bazen şeffaf veya açık kutu testi, yapısal test, mantıksal test ve kaynak koduna, mimariye ve mantığa dayalı test olarak adlandırılır.

Ana çeşitler:

1) akış kontrol testi - program kontrol akışını model olarak kullanan ve daha basit yolları daha az karmaşık olanlara tercih eden yapısal bir strateji;

2) dallara ayrılan hata ayıklama, birleşik çözümü de içeren her bir kontrol ifadesinin her bir seçeneğini (doğru veya yanlış) incelemeyi amaçlar;

3) test edenin, bir temel yürütme yolları kümesini izole etmek için bir prosedürel projenin mantıksal karmaşıklığının bir ölçüsünü oluşturmasına izin veren ana yolun test edilmesi;

4) veri akışının kontrol edilmesi - grafiğe program değişkenlerinin beyanı ve kullanımı hakkında bilgi ekleyerek kontrol akışını incelemek için bir strateji;

5) Döngü testi - tamamen döngüsel prosedürlerin doğru yürütülmesine odaklanmıştır.

davranışsal hata ayıklama

Kara kutu testi, yazılımı bir "kara kutu" olarak ele alır - programın iç işleyişi hakkındaki bilgiler dikkate alınmaz, ancak sistemin yalnızca ana yönleri kontrol edilir. Bu durumda, test cihazının kaynak koduna erişmeden sistem mimarisini bilmesi gerekir.

Bu yaklaşımın avantajları:

• büyük bir kod segmenti için verimlilik;
• test cihazı tarafından algı kolaylığı;
• kullanıcının bakış açısı geliştiricinin bakış açısından açıkça ayrılmıştır (programcı ve test edici birbirinden bağımsızdır);
• daha hızlı test oluşturma.

Programların kara kutu testi aşağıdaki dezavantajlara sahiptir:

• aslında, sınırlı kapsama ile sonuçlanan belirli sayıda test senaryosu yürütülür;
• net bir spesifikasyonun olmaması, test senaryoları geliştirmeyi zorlaştırır;
• düşük verimlilik.

Bu tekniğin diğer isimleri davranışsal, opak, işlevsel testler ve kapalı kutu hata ayıklamadır.

1) program modülünün giriş verileri ayrı bölümlere ayrıldığından, test verileri kümesini azaltabilen eşdeğer bölümleme;

2) kenar analizi, sınırların veya aşırı sınır değerlerinin kontrolüne odaklanır - minimumlar, maksimumlar, hatalı ve tipik değerler;

3) fuzzing - otomatik veya yarı otomatik modda bozuk veya yarı bozuk veri girerek uygulama hatalarını aramak için kullanılır;

4) neden-sonuç ilişkilerinin grafikleri - grafikler oluşturmaya ve bir eylem ile nedenleri arasında bir bağlantı kurmaya dayanan bir teknik: özdeşlik, olumsuzlama, mantıksal VEYA ve mantıksal VE - neden ve sonuç arasındaki karşılıklı bağımlılığı ifade eden dört ana sembol;

5) kapsamlı bir keşif kapsamının ötesinde, nispeten küçük bir girdi alanına sahip problemlere uygulanan ortogonal dizilerin doğrulanması;

6) tüm çiftlerin testi - her bir giriş parametresi çiftinin olası tüm ayrı kombinasyonlarını içeren test değerleri kümesi olan bir teknik;

Kara kutu testi: örnekler

Teknik, spesifikasyonlara, belgelere ve yazılım veya sistem arayüzü açıklamalarına dayanmaktadır. Ayrıca, yazılımın beklenen davranışını temsil eden modeller (resmi veya gayri resmi) kullanmak mümkündür.

Tipik olarak, bu hata ayıklama yöntemi kullanıcı arayüzleri için kullanılır ve ekrandan, raporlardan veya çıktılardan veri girerek ve sonuçları toplayarak uygulama ile etkileşim kurmayı gerektirir.

Böylece test cihazı, giriş yoluyla, anahtarlar, düğmeler veya diğer arayüzler üzerinde hareket ederek yazılımla etkileşime girer. Giriş verilerinin seçimi, girildikleri sıra veya eylem sırası, aşağıdaki örnekte görülebileceği gibi, çok sayıda kombinasyona yol açabilir.

4 onay kutusu ve zamanı saniye cinsinden ayarlayan bir açma / kapama alanı için tüm olası değerleri kontrol etmek için kaç test yapılması gerekiyor? İlk bakışta hesaplama basittir: İki olası duruma sahip 4 alan - 24 = 16, 00 ile 99 arasındaki olası konum sayısı, yani 1600 olası test ile çarpılması gerekir.

Ancak bu hesaplama yanlıştır: iki konumlu bir alanın boşluk da içerebileceğini yani iki alfanümerik konumdan oluştuğunu ve alfabe karakterleri, özel karakterler, boşluklar vb. içerebileceğini belirleyebiliriz. 16 bitlik bir bilgisayarsa, her konum için 216 = 65 536 seçenek elde ederiz, bu da 4 294 967 296 test durumuyla sonuçlanır, bu da bayraklar için 16 kombinasyonla çarpılması gerekir, bu da toplam 68 719 476 736 verir. saniyede 1 test hızında, toplam test süresi 2.177.5 yıl olacaktır. 32 veya 64 bit sistemler için süre daha da uzundur.

Bu nedenle bu süreyi kabul edilebilir bir değere indirmek gerekli hale gelmektedir. Bu nedenle, test kapsamını azaltmadan test vakalarının sayısını azaltmak için teknikler uygulanmalıdır.

eşdeğer bölüm

Eşdeğer bölümleme, yazılımda bulunan giriş veya çıkış değerleri, karakter, sayısal vb. herhangi bir değişkene uygulanabilen basit bir tekniktir. Bir eşdeğer bölümdeki tüm verilerin aynı şekilde işleneceği ilkesine dayanır. ve bunlar tarafından aynı talimatlar.

Test sırasında, tanımlanan her eşdeğer bölümden bir temsilci seçilir. Bu, komut ve işlev kapsamını kaybetmeden olası test senaryolarının sayısını sistematik olarak azaltmanıza olanak tanır.

Bu bölümün bir başka sonucu, farklı değişkenler arasındaki kombinasyon patlamasının azalması ve test durumlarının buna bağlı azalmasıdır.

Örneğin (1 / x) 1/2, üç veri dizisi, üç eşdeğer bölüm kullanır:

1. Tüm pozitif sayılar aynı şekilde ele alınacak ve doğru sonuçlar vermelidir.

2. Tüm negatif sayılar aynı şekilde ve aynı sonuçla ele alınacaktır. Bu yanlıştır, çünkü negatif bir sayının kökü sanaldır.

3. Sıfır ayrı olarak işlenecek ve sıfıra bölme hatası verecektir. Bu tek anlam bölümüdür.

Böylece, biri tek bir anlama gelen üç farklı bölüm görüyoruz. Güvenilir sonuçlar veren bir “doğru” bölüm ve yanlış sonuçlar veren iki “yanlış” bölüm vardır.

Kenar analizi

Eşdeğer bir bölümün sınırlarındaki veri işleme, beklenenden farklı şekilde gerçekleştirilebilir. Sınır değerleri keşfetmek, bu tür alanlarda yazılım davranışını analiz etmenin iyi bilinen bir yoludur. Bu teknik, aşağıdaki hataları belirlemenizi sağlar:

• ilişkisel operatörlerin kötüye kullanılması (<,>, =, ≠, ≥, ≤);
• tek hatalar;
• döngüler ve yinelemelerdeki problemler,
• bilgileri depolamak için kullanılan değişkenlerin yanlış türleri veya boyutları;
• veriler ve değişken türleri ile ilgili yapay kısıtlamalar.

Yarı şeffaf test

Gri kutu yöntemi, beyaz ve siyah yöntemleri birleştirerek karmaşık bir sistemin tüm seviyelerine odaklanmanıza izin vererek testin kapsamını artırır.

Bu tekniği kullanırken, test cihazı, test değerlerini tasarlamak için dahili veri yapıları ve algoritmalar hakkında bilgi sahibi olmalıdır. Gri kutu test tekniklerine örnekler:

• mimari model;
• Birleşik Modelleme Dili (UML);
• durum modeli (durum makinesi).

Test senaryolarını geliştirmek için gri kutu yönteminde, modül kodları beyaz teknikte incelenir ve asıl test, siyah teknikte program arayüzlerinde gerçekleştirilir.

Bu tür test yöntemleri aşağıdaki avantajlara sahiptir:

• beyaz ve kara kutu tekniklerinin avantajlarının bir kombinasyonu;
• test cihazı, kaynak kodundan ziyade arayüze ve işlevsel spesifikasyona güvenir;
• hata ayıklayıcı mükemmel test komut dosyaları oluşturabilir;
• doğrulama, programın tasarımcısı değil, kullanıcının bakış açısından gerçekleştirilir;
• özel test tasarımlarının oluşturulması;
• nesnellik.

Dezavantajları:

• kaynak koduna erişim olmadığı için test kapsamı sınırlıdır;
• dağıtılmış uygulamalardaki kusurları tespit etmenin karmaşıklığı;
• birçok yol keşfedilmemiş kalır;
• yazılım geliştiricisi kontrolü zaten yaptıysa, daha fazla araştırma gereksiz olabilir.

Gri kutu tekniğinin diğer bir adı da yarı saydam hata ayıklamadır.

1) ortogonal dizi - tüm olası kombinasyonların bir alt kümesini kullanarak;

2) program durumu verilerini kullanarak matris hata ayıklaması;

3) yazılımda yeni değişiklikler yapıldığında gerçekleştirilen;

4) sağlam bir uygulamanın tasarımını ve mimarisini analiz eden bir şablon testi.

yazılım testi

Tüm dinamik yöntemlerin kullanılması, geliştirilecek, uygulanacak ve çalıştırılacak testlerin sayısında kombinatoryal bir patlama ile sonuçlanır. Her teknik, sınırlamaları akılda tutularak pragmatik olarak kullanılmalıdır.

Tek bir doğru yöntem yoktur, yalnızca belirli bir bağlama en uygun olanlar vardır. Yapısal teknikler, işe yaramaz veya kötü niyetli kod bulmanıza yardımcı olabilir, ancak bunlar karmaşıktır ve büyük programlara uygulanamaz. Spesifikasyona dayalı yöntemler, eksik kodu tam olarak tespit edebilen tek yöntemlerdir, ancak dışarıdakileri tanımlayamazlar. Bazı teknikler, belirli bir test düzeyi, hata türü veya bağlam için diğerlerinden daha uygundur.

Aşağıda, üç dinamik test tekniği arasındaki temel farklar yer almaktadır - üç yazılım hata ayıklama biçimi arasında bir karşılaştırma tablosu verilmiştir.

Bakış açısı	Kara kutu yöntemi	gri kutu yöntemi	Beyaz kutu yöntemi
Programın bileşimi hakkında bilgilerin mevcudiyeti	Sadece temel yönler analiz edilir	Programın iç yapısı hakkında kısmi bilgi	Kaynak koduna tam erişim
Program parçalanması
Kim hata ayıklıyor?	Son kullanıcılar, test kullanıcıları ve geliştiriciler	Son kullanıcılar, hata ayıklayıcılar ve geliştiriciler	Geliştiriciler ve test kullanıcıları
	Test, harici anormal durumlara dayanır.	Veritabanı diyagramları, veri akış diyagramları, dahili durumlar, algoritma ve mimari bilgisi	İç yapı tam olarak biliniyor
Kapsam	En az kapsamlı ve zaman alıcı		Potansiyel olarak en kapsamlısı. Zaman tükeniyor
Veri ve iç sınırlar	Yalnızca deneme yanılma yoluyla hata ayıklama	Biliniyorsa veri alanları ve dahili sınırlar kontrol edilebilir	Veri Alanlarının ve Dahili Sınırların Daha İyi Test Edilmesi
Algoritma Test Edilebilirliği

Otomasyon

Yazılım ürünleri için otomatikleştirilmiş test yöntemleri, teknik ortam veya yazılım bağlamından bağımsız olarak doğrulama sürecini büyük ölçüde basitleştirir. İki durumda kullanılırlar:

1) testçinin daha önemli noktalara konsantre olması için zaman kazanmak için birkaç bin satırlık dosyaları karşılaştırmak gibi sıkıcı, tekrarlayan veya titiz görevlerin yürütülmesini otomatikleştirmek;

2) Saniyenin yüzde biri olarak ölçülebilen, performansı test etme veya yanıt sürelerini analiz etme gibi insanlar tarafından kolayca gerçekleştirilemeyen görevleri gerçekleştirmek veya izlemek.

Test araçları farklı şekillerde sınıflandırılabilir. Aşağıdaki bölüm, destekledikleri görevlere dayanmaktadır:

• proje, sürüm oluşturma, yapılandırma yönetimi, risk analizi, test izleme, hatalar, kusurlar ve raporlama araçları için destek içeren test yönetimi;
• gereksinimleri ve spesifikasyonları depolamayı, eksiksizlik ve belirsizlik açısından kontrol etmeyi, önceliklerini ve her testin izlenebilirliğini içeren gereksinim yönetimi;
• akış ve görevlerin izlenmesi, yorumların kaydedilmesi ve saklanması, kusurların ve planlı düzeltmelerin saptanması, kontrol listelerine ve kurallara bağlantıların yönetilmesi, kaynak belgeler ve kod arasındaki ilişkinin izlenmesi, kusurların saptanması ile statik analiz, kodlama standartlarına uygunluğun sağlanması dahil olmak üzere kritik inceleme ve statik analiz , yapıların ve bağımlılıklarının analizi, kod ve mimarinin metrik parametrelerinin hesaplanması. Ayrıca derleyiciler, bağlantı çözümleyicileri ve çapraz bağlantı oluşturucular kullanılır;
• iş davranışını modellemek ve oluşturulan modelleri doğrulamak için araçlar içeren modelleme;
• testlerin geliştirilmesi, koşullara ve kullanıcı arayüzüne, modellere ve koda dayalı olarak beklenen verilerin oluşturulmasını, bunların dosya ve veritabanlarını oluşturma veya değiştirme yönetimini, mesajları, yönetim kurallarına dayalı veri doğrulamasını, koşul ve risk istatistiklerinin analizini sağlar;
• başarılı ve başarısız testleri belirlemeye yardımcı olmak için karşılaştırıcıları kullanan grafik kullanıcı arayüzü, API, komut satırları aracılığıyla veri girerek kritik taramalar;
• deterministik çıktının bir alt kümesine dayalı donanım simülatörleri, terminal öykünücüleri, cep telefonları veya ağ ekipmanı, eksik bileşenleri sahte sürücü modülleriyle değiştirerek dilleri, işletim sistemini ve donanımı kontrol etmek için ortamlar dahil olmak üzere eksik donanım veya yazılımı değiştirmenize olanak tanıyan hata ayıklama ortamları için destek , vb. ve ayrıca işletim sistemi isteklerini engellemek ve değiştirmek, CPU, RAM, ROM veya ağ sınırlamalarını simüle etmek için araçlar;
• veri dosyalarının, veritabanlarının karşılaştırılması, dinamik ve toplu karşılaştırma dahil olmak üzere test sırasında ve sonrasında beklenen sonuçların doğrulanması, otomatik "kahinler";
• bellek sızıntılarını ve yanlış yönetimini yerelleştirmek için kapsam ölçümü, simüle edilmiş yük koşulları altında sistem davranışını değerlendirmek, büyümesinin gerçekçi senaryolarına dayalı olarak uygulama, veritabanı, ağ veya sunucu yükü oluşturmak, sistem kaynaklarını ölçmek, analiz etmek, kontrol etmek ve raporlamak için;
• güvenlik;
• performans testi, yük testi ve dinamik analiz;
• yazım ve sözdizimi denetimi, ağ güvenliği, tüm sayfaların bir web sitesinde bulunması ve daha fazlası dahil olmak üzere diğer araçlar.

Perspektif

Yazılım endüstrisindeki trendler değiştikçe hata ayıklama süreci de değişebilir. Hizmet Odaklı Mimari (SOA), kablosuz teknolojiler, mobil hizmetler vb. gibi yazılım ürünlerini test etmek için mevcut yeni yöntemler, yazılımı test etmek için yeni yollar açmıştır. Önümüzdeki birkaç yıl içinde bu sektörde beklenen değişikliklerden bazıları aşağıda listelenmiştir:

• test kullanıcıları, geliştiricilerin kodlarını test edebilecekleri hafif modeller sağlayacaktır;
• programları erken bir aşamada görüntülemeyi ve simüle etmeyi içeren test yöntemleri geliştirmek, tutarsızlıkların çoğunu ortadan kaldıracaktır;
• birçok test kancasının varlığı, hata algılama süresini azaltacaktır;
• statik analizör ve algılama araçları daha yaygın olarak kullanılacak;
• spesifikasyon kapsamı, model kapsamı ve kod kapsamı gibi faydalı matrislerin kullanımı projelerin geliştirilmesine rehberlik edecektir;
• kombinatoryal araçlar, test uzmanlarının hata ayıklama alanlarına öncelik vermesini sağlar;
• test uzmanları, yazılım geliştirme süreci boyunca daha görsel ve değerli hizmetler sunacak;
• hata ayıklayıcılar, çeşitli programlama dillerinde yazılmış ve bunlarla etkileşime giren yazılımları test etmek için araçlar ve yöntemler oluşturabilecektir;
• hata ayıklayıcılar daha profesyonel hale gelecek.

Yeni iş odaklı yazılım test yöntemleri yerini alacak, sistemlerle etkileşim şeklimiz ve sağladıkları bilgiler değişecek, riskleri azaltacak ve iş değişikliğinin faydalarını artıracak.

- yazılımdaki (SW) hataları tespit etme süreci. Mevcut yazılım test yöntemleri, özellikle kapalı özel programlarda, tüm kusurları ve hataları açık ve tamamen ortadan kaldırmaya ve analiz edilen programın doğru çalışmasını sağlamaya izin vermez. Bu nedenle, mevcut tüm test yöntemleri, araştırma veya geliştirme altındaki yazılımın resmi olarak test edilmesi süreci içinde çalışır.

Böyle bir resmi inceleme veya doğrulama süreci, kullanılan yöntem açısından herhangi bir kusur olmadığını kanıtlayabilir. (Yani, yazılım yaşam döngüsünün tüm aşamalarında mevcut olan insan faktörünü hesaba katarak, bir yazılım ürününde kusur bulunmadığını doğru bir şekilde belirlemenin veya garanti etmenin hiçbir yolu yoktur).

Yazılım testi ve doğrulaması sorununu çözmek için birçok yaklaşım vardır, ancak karmaşık yazılım ürünlerinin etkin bir şekilde test edilmesi, katı ve net prosedürlerin izlenmesi veya bu tür prosedürlerin oluşturulmasıyla sınırlı olmayan, oldukça yaratıcı bir süreçtir.

Yazılım testi- programın kendisinden bekleneni yapıp yapmadığını belirleme girişimi. Kural olarak, hiçbir test, programın gelecekte çalışacağına dair kesin bir garanti veremez.

Anlaşılır olması için, neredeyse tüm ticari yazılım satıcıları ürünlerindeki hataları düzeltir.

Örneğin: Microsoft Corporation, işletim sistemleri için Hizmet Paketleri yayınlar. Oyun geliştiricileri, ürünleri için düzenli olarak yamalar yayınlar. Çoğu yazılım geliştirici, hataları düzelttikten sonra programlarının güncellenmiş (yeni) bir sürümünü yayınlar.

Yazılım testi

Test türlerini sınıflandırmanın geleneksel olduğu birkaç işaret vardır. Aşağıdaki işaretler genellikle ayırt edilir:

Test nesnesine göre:

• Fonksiyonel test
• Stres testi
  • Performans testi (performans / stres testi)
  • Stabilite / yük testi
• Kullanılabilirlik testi
• kullanıcı arayüzü testi
• Güvenlik testi
• Yerelleştirme testi
• Uyumluluk testi

Sistem bilgisi:

• Kara kutu testi
• Beyaz kutu testi
• Gri kutu testi

Otomasyon derecesine göre:

• Manuel test
• Otomatik test
• Yarı otomatik test

Bileşenlerin izolasyon derecesine göre:

• Bileşen / birim testi
• Entegrasyon testi
• Sistem testi (sistem / uçtan uca test)

Test zamanına kadar:

• Alfa testi
  • Duman testi
  • Yeni özellik testi
  • Gerileme testi
  • Kabul testleri
• Beta testi

Senaryoların pozitifliğine göre:

• pozitif test
• Negatif test

Test için hazırlık derecesine göre:

• Dokümantasyon testi (resmi test)
• Ed Hawk (sezgisel) testi (ad hoc testi)

Test seviyeleri

• Birim testi(birim testi) - test için mümkün olan minimum bileşen, örneğin ayrı bir sınıf veya fonksiyon test edilir. Birim testi genellikle yazılım geliştiriciler tarafından yapılır.
• Entegrasyon testi- bileşenler ve alt sistemler arasındaki arayüzler test edilir. Bu aşamada bir zaman rezervi varsa, sonraki alt sistemlerin kademeli olarak bağlanmasıyla test yinelemeli olarak gerçekleştirilir.
• Sistem testi- entegre sistem, gerekliliklere uygunluğu açısından test edilir.
  • Alfa testi, kurum içi geliştiriciler tarafından sistemle gerçek çalışmanın veya potansiyel kullanıcılar / müşteri tarafından sistemle gerçek çalışmanın bir taklididir. Çoğu zaman, alfa testi ürün geliştirme aşamasında erken yapılır, ancak bazı durumlarda bitmiş ürüne dahili kabul testi olarak uygulanabilir. Bazen alfa testi, bir hata ayıklayıcı altında veya bulunan hataları hızlı bir şekilde belirlemenize yardımcı olan bir ortam kullanılarak yapılır. Bulunan hatalar, yazılımın kullanılacağı ortama benzer bir ortamda ek araştırma için test kullanıcılarına iletilebilir.
  • Beta testi - bazı durumlarda, ürünün daha az hata içermesini sağlamak için belirli bir grup kişiye sınırlı işlevselliğe veya çalışma süresine sahip bir sürüm dağıtılır. Bazen, gelecekteki kullanıcılardan bir ürün hakkında geri bildirim almak için beta testi yapılır.

Genellikle ücretsiz / açık kaynaklı yazılımlar için Alfa test aşaması, kodun işlevsel içeriğini karakterize eder ve Beta test aşaması, hata düzeltme aşamasını karakterize eder. Aynı zamanda, kural olarak, geliştirmenin her aşamasında, son kullanıcılar için ara iş sonuçları mevcuttur.

Beyaz kutu ve kara kutu testi

Test uzmanları (yazılım ve bazı donanımlar) terminolojisinde, "beyaz kutu testi" ve "kara kutu testi" ifadeleri, test geliştiricisinin test edilen yazılımın kaynak koduna erişip erişemediğini veya testin test yoluyla gerçekleştirilip gerçekleştirilmediğini ifade eder. test edilen birim tarafından sağlanan kullanıcı arayüzü veya API.

Beyaz bir kutuyu test ederken (eng. beyaz kutu testi, ayrıca söyle - şeffaf kutu), test geliştiricisi programların kaynak koduna erişebilir ve test edilen yazılımın kitaplıklarına bağlı kod yazabilir. Bu, birim testi için tipiktir. birim testi), sistemin yalnızca belirli bölümlerinin test edildiği. Yapının bileşenlerinin belirli bir ölçüde işlevsel ve kararlı olmasını sağlar. Beyaz kutu testi, kod kapsamı ölçümlerini kullanır.

Bir kara kutuyu test ederken, test kullanıcısı yazılıma yalnızca müşteri veya kullanıcı ile aynı arabirimler aracılığıyla veya başka bir bilgisayarın veya başka bir işlemin test için sisteme bağlanmasına izin veren harici arabirimler aracılığıyla erişebilir. Örneğin, bir test modülü, bir süreç etkileşim mekanizması kullanarak test edilen bir programdaki tuşlara veya fare düğmelerine sanal olarak basabilir, her şeyin doğru gittiğinden, bu olayların gerçek tuş ve fare tıklamalarıyla aynı yanıta neden olduğundan emin olabilir. Tipik olarak, kara kutu testi, sistem gereksinimlerini tanımlayan spesifikasyonlar veya diğer belgeler kullanılarak gerçekleştirilir. Kural olarak, bu tür testlerde kapsam kriteri, girdi veri yapısının kapsamından, gereksinimlerin kapsamından ve modelin kapsamından (model tabanlı testte) oluşur.

Alfa ve beta testi, yayın öncesi aşamalara (ve ayrıca dolaylı olarak test topluluğunun boyutuna ve test yöntemlerindeki sınırlamalara) atıfta bulunurken, beyaz kutu ve kara kutu testi, testçinin hedefe ulaşma yollarını ifade eder.

Beta testi genellikle kara kutu tekniğiyle sınırlıdır (ancak testçilerin düzenli bir kısmı genellikle beyaz kutuyu beta testiyle paralel olarak test etmeye devam eder). Bu nedenle, "beta" terimi, programın durumunu ("alfa"dan daha yakın bir sürüm) gösterebilir veya belirli bir testçi grubunu ve bu grup tarafından yürütülen süreci gösterebilir. Bu nedenle, yazılım zaten "beta" (aşama) olmasına rağmen, test cihazı beyaz kutuyu test etmeye devam edebilir, ancak bu durumda "beta"nın (grup / süreç) bir parçası değildir.

Statik ve dinamik test

Yukarıda açıklanan teknikler - beyaz kutu testi ve kara kutu testi - kodun yürütüldüğünü varsayar ve fark yalnızca test edenin sahip olduğu bilgilerdedir. Her iki durumda da dinamik test.

Statik test sırasında program kodu yürütülmez - program, manuel olarak okunan veya özel araçlar tarafından analiz edilen kaynak kodu temelinde analiz edilir. Bazı durumlarda, analiz edilen kaynak kod değil, ara koddur (bayt kodu veya MSIL kodu gibi).

Ayrıca statik test, gereksinimlerin, spesifikasyonların ve belgelerin test edilmesini içerir.

Gerileme testi

Programın sonraki sürümünde değişiklik yaptıktan sonra, regresyon testleri, yapılan değişikliklerin uygulamanın geri kalan işlevselliğinin performansını etkilemediğini doğrular. Regresyon testi hem manuel olarak hem de test otomasyonu yoluyla yapılabilir.

Test komut dosyaları

Test kullanıcıları birim, sistem ve regresyon testi için test komut dosyaları yazar ve kullanır. En yüksek arıza riski ve bu riskin bir problem haline gelme olasılığı en yüksek olan modüller için test scriptleri yazılmalıdır.

Kod kapsamı

Kod kapsamı esasen beyaz kutu testidir. Test edilen yazılım, özel ayarlar veya kitaplıklar ile derlenir ve/veya özel bir ortamda başlatılır, bunun sonucunda kullanılan (yürütülen) her program işlevi için bu işlevin kaynak kodundaki konumu belirlenir. Bu süreç, tasarımcıların ve kalite güvence uzmanlarının, normal çalışmada nadiren veya hiç kullanılmayan (hata işleme kodu gibi) sistem parçalarını belirlemelerine olanak tanır. Bu, testçilerin en önemli modları test etmeye yönlendirilmesine olanak tanır.

Test kullanıcıları, kod kapsamını önemli özelliklere genişletecek testler veya test verileri geliştirmek için bir kod kapsamı testinin sonuçlarını kullanabilir.

Tipik olarak, kod kapsamı elde etmek için kullanılan araçlar ve kitaplıklar, yazılımın normal çalışması için kabul edilemez olan önemli performans ve/veya bellek harcamaları gerektirir. Bu nedenle sadece laboratuvar koşullarında kullanılabilirler.

Test odaklı geliştirme

(test odaklı geliştirme), bir programın veya parçasının birim testlerinin programın kendisinden önce yazıldığı (test-ilk geliştirme) ve özünde onun gelişimini kontrol ettiği bir programlama tekniğidir. Aşırı programlamanın ana uygulamalarından biridir.

Tek bir programcı, ilk önce çalışabilirliğini kontrol etmeden tamamlanmış bir kod parçası üzerindeki çalışmayı dikkate almaz. Ancak, kodunuzu test ediyorsanız, bu testleriniz olduğu anlamına gelmez.

Ölçek kodun işlevselliğini onaylamanıza veya reddetmenize izin veren bir prosedürdür. Bir programcı, geliştirdiği kodun işlevselliğini kontrol ettiğinde, testi manuel olarak yapar. Bu bağlamda, bir test iki aşamadan oluşur: kodun uyarılması ve çalışmasının sonuçlarının kontrol edilmesi. Otomatik bir test farklı şekilde gerçekleştirilir: bir programcı yerine, bilgisayar kodu uyarır ve sonuçları kontrol eder, bu da testin sonucunu ekranda gösterir: kod çalışır veya kod çalışmaz.

Test Odaklı Geliştirme (TDD), otomatik testlerin düzenlenmesi ve belirli test becerilerinin geliştirilmesiyle ilgili soruların yanıtlarını sağlar.

"Çalışan temiz kod" - Bu kısa ama özlü ifade, test odaklı uygulama geliştirmenin tüm noktasıdır. İşe yarayan temiz kod, çabalamaya değer bir hedeftir ve bunun iyi bir nedeni vardır:

Geliştirici, kodun kendisine öğrettiği dersleri öğrenme şansına sahiptir. Aklına gelen ilk fikri kullanırsa, ikinci, daha iyi fikri uygulama şansı olmayacaktır.

Takım arkadaşları geliştiriciye güvenebilir ve sırayla onlara güvenebilir.

Bir geliştiricinin böyle bir kod yazması daha hoştur.

Ancak, çalışan temiz kodu nasıl elde edebiliriz? Birçok güç bunu başarmamızı engelliyor ve bazen çalışan kodu bile alamıyoruz. Bir çok problemden kurtulmak için otomatik testlere dayalı kod geliştireceğiz. Bu programlama tarzına test odaklı geliştirme denir. Bu tekniğin bir parçası olarak:

Sadece otomatik kod çalışmadığında yeni kod yazarız.

Çoğaltmayı kaldırın.

Bu tür iki basit kural, aslında birçok teknik anlamı olan karmaşık bireysel ve grup davranışları üretir:

Kodu tasarlarken, sürekli çalıştırıyor ve nasıl çalıştığı hakkında bir fikir ediniyoruz, bu da doğru kararları vermemize yardımcı oluyor.

Başka birinin bizim için test yazmasını bekleyemediğimiz için kendi testlerimizi kendimiz yazıyoruz.

IDE'mizin küçük kod değişikliklerine hızlı tepki vermesi gerekiyor.

Programın mimarisi, birbirine gevşek bir şekilde bağlanmış, kodun test edilmesini kolaylaştıracak şekilde, sıkı bir şekilde bağlanmış birçok bileşenin kullanımına dayanmalıdır.

Bahsedilen iki TDD kuralı, programlama adımlarının sırasını belirler:

Kırmızı - Çalışmayan ve hatta derlemeyen küçük bir test yazın.

Yeşil - Tasarım ve kod temizliğini düşünmeden testi mümkün olduğunca hızlı çalıştırın. Testin çalışması için yeterli kodu yazın.

Yeniden Düzenleme - Kodunuzdaki tüm yinelemeleri kaldırın.

Geliştiriciler, TDD'de uzmanlaştıktan sonra, kendilerini eskisinden çok daha fazla test yazarken ve daha önce anlamsız görünebilecek küçük adımlarla ilerlerken bulurlar.

Testi çalıştırarak, testin şimdi ve sonsuza kadar çalıştığını biliyoruz. İşi tamamlamaya, test çalışmadan öncekinden bir adım daha yakınız. Bundan sonra ikinci testi çalıştırıyoruz, ardından üçüncü, dördüncü vb. Programcının karşılaştığı problem ne kadar karmaşıksa, her testin kapsaması gereken işlevsellik o kadar az olur.

Kesinlikle (en azından şimdilik) tek başına testlerle çözülemeyecek sorunlar var. Özellikle TDD, geliştirilen kodun veri güvenliği ve süreçler arası etkileşim alanında yeterliliğinin mekanik olarak gösterilmesine izin vermemektedir. Elbette güvenlik, hatasız olması gereken koda dayanır, ancak aynı zamanda veri koruma prosedürlerine insan katılımına da dayanır. İnce süreçler arası iletişim sorunları, yalnızca bazı kodlar çalıştırılarak güvenle yeniden üretilemez.

Birim Testi Terminolojisi

• Test Odaklı Geliştirme- ilgili sınıflar veya modüller yazılmadan önce bile birim testlerinin yazılmasını ve otomatikleştirilmesini içeren bir yazılım geliştirme süreci. Bu, herhangi bir yazılım parçasının tüm sorumluluklarının kodlanmadan önce tanımlanmasını sağlar.

• Birim testleri- Birim Testleri, Programlama Testleri, Geliştirici Testleri - bireysel sınıfların, bileşenlerin, uygulama modüllerinin işlevselliğini kontrol eden testler. Bu testler, son müşteri veya alan uzmanı tarafından görülmez. Genellikle fonksiyonel testlerden sonra yazmaya başlarlar.

• Yeşil / Kırmızı şerit- birim testlerini yürütmek için birçok grafik ortam, yürütülen testlerin sonucunu, tüm testler başarılıysa yeşil, hatalar varsa kırmızı renkli bir çizgi olarak görüntüler.

• Mock, MockObjects- gerçek nesneler gibi davranabilen otomatik olarak oluşturulan taslaklar. Sahtelerin davranışı doğrudan hamur içinde kontrol edilebilir. Sahteler, test edilen kodun bunları beklendiği gibi kullanıp kullanmadığını ek kontroller yapabilir.

• Ünite testi- uygulamanın küçük bir bölümünün davranışını kontrol eden bir test. Bu bölüm bir sınıf, bir yöntem veya bir tür mimari çözümü uygulayan bir sınıflar kümesi olabilir ve bu çözümün çalıştığından emin olmak için test edilmesi gerekir.

• Test - TestCase- bir sınıfı test etmek için tasarlanmış bir dizi test yöntemi (xUnit ortamında). Tipik olarak TestCase, adı önek testiyle başlayan yöntemlerden oluşur. Bu tür her yöntem, test edilen sınıfın herhangi bir anını test eder. Kabul testinde TestCase, müşteri için değerin bir işlevini test eden bir dizi komuttur.

• Armatür - Armatür- test yönteminin başarılı bir şekilde yürütülmesi için gerekli olan test ortamının durumu. Bazı nesneler, veritabanının durumu, belirli dosyaların varlığı vb. Fikstür, testin testSomething (TestCase) gibi bir yönteme yapılan her çağrıdan önce setUp () yönteminde oluşturulur ve test yönteminin yürütülmesini bitirdikten sonra yırtma () içinde kaldırılır.

• Kontrol - İddia- Test edilen kodun gerçek durumunu beklenen kodla kontrol etmek için tasarlanmış TestCase sınıfının bir yöntemi.

Test Paketi Terminolojisi

• Test paketi - TestSuite- bir yazılım sisteminin herhangi bir büyük varlığını test etmek için tasarlanmış bir dizi test. SimpleTest, TestSuite kavramına neredeyse eşdeğer olan TestGroup kavramına sahiptir. Bazen TestSuite, "uygulama için mevcut olan tüm testler" anlamına gelir.

Kabul Testi Terminolojisi

• Kabul (fonksiyonel) testleri - Müşteri testleri, Kabul testleri- müşterinin gereksinimlerine uygunluk için uygulamanın işlevselliğini kontrol eden testler. Kabul testlerinin, uygulamanın uygulama detayları hakkında hiçbir şey bilmesine gerek yoktur. Kabul Testleri, Extreme Programming (XP) metodolojisini kullanırken ToR'nin yerini alır.

• Regresyon testleri- sistemin davranışının değişmediğini doğrulayan testler. Aslında, çoğu regresyon testi, sistemin işlevselliğinin yanlışlıkla değiştirilmemesini sağlayan belirli bir test paketine (RegressionTestSuite) dahil edilen birim veya işlevsel testlerdir.

Andrey Kolesov

Genel yazılım geliştirme sürecinde test etmenin öneminden bahsetmek pek mantıklı değil çünkü uygulama yaşam döngüsünün her aşamasının uygulanmasının yüksek kaliteli bir yazılım ürününün ortaya çıkması için bir ön koşul olduğu uzun zamandır biliniyor. Ancak, her tür işin eşitliği hakkında sözler söyledikten sonra, şunu kabul etmek gerekir: tüm yazılım geliştirme tarihi boyunca - ve 50 yıldan fazladır - testler, en çok zaman alan bir üvey kız rolünü oynamıştır- tüketen, rutin ve prestijli olmayan işler *. Örnekler için çok uzağa gitmeye gerek yok: geliştiricilerin telif hakları kanunla güvence altına alınmıştır ve istendiğinde isimleri kolayca tanınabilir. Ve uygulamaları test edenler hakkında ne biliyoruz ve bu, ortalama olarak yazılım oluşturma maliyetinin yaklaşık üçte birini oluşturuyor olmalarına rağmen?

Bununla birlikte, durum son zamanlarda gözle görülür şekilde değişti ve burada iki ana eğilim ayırt edilebilir. Birincisi, özellikle özel otomasyon araçlarının kullanımıyla birlikte endüstriyel test yöntemlerine duyulan ihtiyaç konusunda artan bir anlayış var. İkinci olarak, dış kaynak kullanımı modelini kullanmak da dahil olmak üzere, genel iş organizasyonu açısından bu işleri gerçekleştirme maliyetlerini optimize etmek için fırsatlar aranmaktadır.

Paradoksal bir duruma dikkat edilmelidir: yazılım tasarımı ve kodlama üzerine çok sayıda metodolojik literatür ve kursla, test etme ve hata ayıklama için neredeyse tamamen malzeme yokluğu vardır! Yazılım geliştirme üzerine kitap yazan tanınmış Amerikalı yazar John Robbins'in dediği gibi: "Özel bir eğitim almış olsanız bile, bahse girerim hata ayıklama konusunda özel bir kursla hiç karşılaşmamışsınızdır" (bkz. PC Week / RE, # 9/2004, s. 61).

Bununla birlikte, durum biraz değişiyor; bunlardan biri, Moskova'nın desteğiyle Aplana şirketi tarafından Şubat ayı sonunda Moskova'da düzenlenen "Kurumsal sistemlerin geliştirilmesi ve bakımı sırasında test süreçlerinin etkili organizasyonu" pratik seminerlerinde kanıtlanmıştır. IBM'in ofisi. Konunun o kadar alakalı olduğu ortaya çıktı ki, IBM Teknoloji Merkezi herkesi bir günde ağırlayamadı, bu yüzden seminerin iki kez yapılması gerekiyordu. Başlangıçta, etkinlik kurumların BT departmanlarına odaklandı ve kendi kurum içi geliştirmelerine öncülük etti, ancak özel ve çoğaltılmış yazılım yaratıcıları olan uzman firmalar da buna büyük ilgi gösterdi. Seminerlere kurumsal ve departman geliştirme ve uygulama merkezlerinin yanı sıra BT şirketlerinden toplam 80'den fazla yönetici ve uzman katıldı.

Her ne kadar IBM Rational ürünleri bir araç tabanı olarak kullanılmış olsa da, seminerin ana odak noktasının, genel yazılım geliştirme süreci ve genel olarak işletmelerin iş işleyişi bağlamında test etmenin organizasyonel ve metodolojik konuları olduğu vurgulanmalıdır. Birçok yönden, uzmanların bu etkinliğe aktif katılımını önceden belirleyen bu yaklaşımdı.

Test organizasyonunun özellikleri

Her şeyden önce, test konularının teknik özelliklerin geliştirilmesinden uygulamaların bakımına kadar tüm yazılım yaşam döngüsü bağlamında ele alınması gerektiği unutulmamalıdır. Bildiğiniz gibi test, endüstriyel kullanımdan önce yazılımdaki hataları (hataları) tespit etmeye yönelik bir prosedürdür. Açıkçası, bu tür çalışmaların zahmeti, görünümlerinin ana nedenlerini açıkça vurgulamanın gerekli olduğu hataların sayısı ile ilgilidir:

• tüm geliştirme sürecinin yetersiz organizasyonel, metodolojik ve teknik desteği;
• proje yürütme için sıkı son tarihler;
• projenin karmaşıklığı, çok sayıda gereksinim ve çalışma sürecindeki değişiklikleri;
• geliştiricilerin yetersiz nitelikleri.

Bir önemli nokta daha var. Test, sırayla, hata ayıklamanın yalnızca bir parçasıdır - yazılım çalışır duruma yazıldıktan sonra ince ayar yapma süreci. Bu süreç iki ana prosedürü içerir: hata tespiti (test) ve nedenlerinin araştırılması ve ortadan kaldırılması. Ancak, bu çalışmaların tüm olası karşılıklı ilişkileri dikkate alındığında bile (örneğin, hataların nedenlerini bulmak özel ek testler gerektirir), testin yazılım yaşam döngüsünün oldukça özerk, bağımsız bir aşaması olduğu vurgulanmalıdır. Aynı zamanda geliştirme kalitesini iyileştirmenin (uygulamadaki hata sayısı ile ters orantılıdır) doğrudan hataları ortadan kaldırma maliyetini azalttığını ancak test hacmini çok fazla etkilemediğini vurguluyoruz: her durumda ve tercihen "tamamen" gerçekleştirilir.

Test organizasyonu ve metodolojisinin büyük ölçüde geliştirme amacına bağlı olduğu da açıktır: kutulu bir ürün, özel bir proje veya şirket içi bir proje. Ve burada, seminerlerin öncelikle müşterilerin BT departmanlarının geliştiricilerine yönelik olduğu gerçeğine bir kez daha dikkat etmeye değer. Bunun açıklaması basittir: ilk olarak, bu tür şirketlerde ve uzmanlaşmış bilişim firmalarında gerçekleştirilen geliştirmelerin hacmi en azından orantılıdır; ikinci olarak, birkaç nedenden dolayı, kurum içi projelerin uygulanmasındaki test görevleri oldukça spesifik ve çok alakalıdır.

BT departmanlarındaki test prosedürlerinin özelliklerinden bahsetmişken, muhtemelen üç ana, çok çelişkili yönü ayırt etmek gerekir.

1. Test kapsamı çok geniştir. Gerçek şu ki, şirket içi gelişmeler söz konusu olduğunda, değişiklikler çok sık yapılır (seminerin birçok katılımcısı, müşteri departmanlarının talebi üzerine sürekli bir ayarlama akışından bahsetti). Ancak, bildiğiniz gibi, yazılım geliştirmenin klasik kuralı şöyle der: bir kod satırını değiştirmek, tüm test döngüsünü tekrarlamayı gerektirir.
2. Kulağa ne kadar alaycı gelse de, geliştiriciler genellikle işletime aktarılan yazılımdaki hataların sayısını azaltmakla ilgilenmezler. Şirketlerin yönetimi, BT departmanının çalışmalarını, her şeyden önce, bütçe dahilinde (zaman ve para) tutma kabiliyetine göre değerlendirir ve işletim programlarının sorunları onlar için çok daha az endişe vericidir. Bu nedenle, test hacimlerindeki artışın, yönetimden uygun kaynaklar tahsis edilmeden BT departmanının maliyetlerini artırdığı ortaya çıkıyor **.
3. Yüksek kaliteli testler yapmak, uygun profilde uzmanlar ve araçlar gerektirir. Ve 2. noktadan itibaren, BT departmanlarının kendi test edici gruplarını tutmasının kârsız olduğu sonucu çıkıyor.

Genel test soruları

Etkinliğin programı, hem test süreçlerini organize etmenin metodolojik yönlerini hem de bunların uygulanması için pratik önerileri içeriyordu. Bir bütün olarak ana fikir oldukça açık görünüyor: Yazılım testinin kalitesinin iyileştirilmesi, uygulanması için makul bir maliyet seviyesini korurken, bu işleri gerçekleştirmenin modern endüstriyel yöntemleri (organizasyonel ve teknik) yoluyla sağlanmalıdır.

Aplana şirket uzmanlarının bir dizi raporunda, özellikle, yazılım projelerini uygulama maliyetini nasıl azaltabileceğinize (en uygun ekipman konfigürasyonunu seçmek dahil) ve iş risklerini nasıl azaltabileceğinize dair gerçek örneklerle desteklenen tipik durumlardan bahsettiler. test süreçlerini uygun şekilde organize etmek ve uygun otomatik araçları kullanmak.

Makalenin kapsamı, belirli araçların kullanımı ile ilgili konuların ayrıntılı olarak ortaya konulmasına izin vermemektedir. Test problemlerinin sınıflandırılmasıyla ilgili bazı genel konuları ele almak şimdi daha faydalı görünüyor. Raporlardan birinde tartışıldılar, ancak bana göründüğü gibi bazı önemli noktalara değinilmedi. Bu nedenle, seminerde söz alan uzmanların görüşlerine dayalı olarak aşağıda görüşlerimi aktaracağım.

Test, tasarımdan sınırsız uzun çalışma aşamasına kadar tüm yazılım yaşam döngüsüne nüfuz eder. Bu çalışmalar doğrudan gereksinimler ve değişiklik yönetimi görevleriyle ilgilidir, çünkü test etmenin amacı tam olarak programların belirtilen gereksinimleri karşıladığından emin olma fırsatıdır.

Test, adım adım bir süreçtir. Muhtemelen, programın performansının kontrolünü, kodun doğrudan yazılması sırasında (programcının kendisi tarafından) ve ana kodlama aşamasının tamamlanmasından sonra (büyük olasılıkla özel testçiler tarafından) ayırmak mantıklıdır. Burada programlamanın altın kuralını hatırlayabilirsiniz: her 20-30 satırlık bir kod yazmak (özellikle eksiksiz prosedürler, fonksiyonlar), en azından bazı temel modlarda performanslarının kontrolü ile birlikte yapılmalıdır. Aynı zamanda, kodlama sırasında ve tamamlandıktan sonra test etmedeki önemli bir farkı vurgulamak gerekir: ilk durumda, programı yazmaya (ve diğer test senaryolarını başlatmaya) ancak hatayı giderdikten sonra devam etmeniz önerilir; ikincisinde, basit bir taahhütle bir dizi metnin toplu olarak yürütülmesi gerçekleştirilir.

Test aynı zamanda yinelemeli bir süreçtir. Her bir hatayı tespit edip düzelttikten sonra, programın çalıştığından emin olmak için testlerin tekrarlanması zorunludur. Ayrıca, tespit edilen bir sorunun nedenini belirlemek için özel ek testler gerekebilir. Aynı zamanda, Profesör Edszher Dijkstroy'un 1972'de yaptığı temel sonucu her zaman hatırlamalıyız: "Test programları hataların varlığının kanıtı olabilir, ancak onların yokluğunu asla kanıtlayamaz!"

Aşağıdaki ana özelliklere göre çeşitli test türleri sınıflandırılabilir (her ne kadar herhangi bir sınıflandırma oldukça keyfi olsa da).

Fonksiyonel ve stres testi. İlk türdeki işler geleneksel olarak sınıflandırılabilir - yazılımın işlevsel gereksinimlere uygunluğunun kontrol edilmesi ***. Son yıllarda, geliştirilmekte olan bir ürünün çeşitli yazılım ve donanım platformları, uygulamalar vb. ile uyumluluğunu analiz etmek gibi nispeten yeni görevlerin önemi belirgin şekilde artmıştır. program kodundaki darboğazların belirlenmesi, kaynak sızıntılarının tespiti vb.

Bileşen ve entegrasyon testi. Açıkçası, ilk test türü, geliştirmenin daha önceki aşamalarında (bitmiş modüller oluşturuldukça), ikincisi - son aşamada gerçekleştirilir. Temel farkları, bileşenin esas olarak "beyaz kutu" yöntemlerine (programın iç mantığı ve yapısı dikkate alınarak) ve entegrasyon - "kara kutu" yöntemlerine (yalnızca harici bilgi birikimi) dayandığı gerçeğinde yatmaktadır. özellikler). Buna göre, ilk durumda test çalışmasının önemli bir kısmı, ikincisinde bağımsız test uzmanlarına yazılım tasarımcılarına ve geliştiricilerine düşer.

Manuel ve otomatik test. Projenin karmaşıklığı arttıkça, otomatik yöntemlerle (komut dosyaları, simülatörler vb. kullanılarak) çözülen görevlerin payı giderek artıyor. Yük testi problemlerinin ezici çoğunluğu, yalnızca onların yardımıyla çözülebilir.

Mevcut sistem konfigürasyonunun test edilmesi ve olası gelişimini hesaba katarak test edilmesi muhtemelen mantıklıdır. Gelecekteki olası sorunların analizi, günümüzde çoğunlukla ölçeklendirme görevleriyle, örneğin kullanıcı sayısındaki artışın bir sonucu olarak sistem üzerindeki yükün artmasıyla ilişkilendirilmektedir. Tabii ki, burada, özellikle platformu değiştirme beklentileri olmak üzere daha geniş bir konu yelpazesini aklınızda tutmanız gerekir. Aynı zamanda, ölçeklendirme değerlendirmesinin yalnızca gerçek bir uygulamayı test ederek değil, aynı zamanda genel yazılım yapısı düzeyinde sistem modelleme yöntemleriyle de (bir şey unutulmuş) yapılabileceğini (ve yapılması gerektiğini) vurgulamak isterim. son yıllarda bu yaklaşım hakkında!).

Sorunu çözme - test merkezleri

Daha önce de belirtildiği gibi, metodoloji ve organizasyonel bileşen, soruların test edilmesinde lider bir rol oynamaktadır. Araç setine gelince, bu süreçteki rolü ikincildir ve test görevlerini otomatikleştirmek için bir veya başka bir ürünün seçimi, projenin hedeflerine ve özelliklerine, mevcut müşteri tercihlerine ve bütçeye bağlı olarak zaten belirlenir. IBM Rational, Mercury, Segue, Compuware'in lider olduğu bir dizi otomatik test aracı artık piyasada sunulmaktadır.

Seminer çerçevesinde, Aplana uzmanları, artık Rus geliştiriciler arasında önemli ölçüde kabul görmüş olan IBM Rational test araçları örneğini kullanarak otomatik test olanaklarını inceledi ("IBM Rational Metodolojisi ve Araç Takımı" kenar çubuğuna bakın). Kurumsal düzeyde yazılım oluşturmada kullanımlarına ilişkin çeşitli senaryolar da tartışıldı. Spesifik yazılım ürünleri arasında günümüzün en popüler sistemi olan IBM Rational Robot'a özel önem verildi.

Bununla birlikte, doğru yöntem ve araçları kullanmak önemli olmakla birlikte, geliştirme sürecinin genel yapısında test çalışmasının genel konumunu değiştirmek belki daha acildir. Bu, özellikle, testi kurum içi düzeyde veya dış kaynak kullanımı modunda uygulanan ayrı bir hizmete ayırma ihtiyacını ifade eder.

Özel yazılım geliştirme konusunda uzmanlaşan Aplana, kendi tecrübesiyle böyle bir yaklaşıma duyulan ihtiyacı fark etti. Şirket, genel kabul görmüş kalite yönetim standartlarına uygun olarak, bir yıl önce Test Merkezine dönüştürülen ve sadece kendi iç sorunlarının çözümünü sağlamakla kalmayıp aynı zamanda dış kuruluşlara da hizmet veren kendi servisini oluşturmuştur.

Seminerde ayrı bir sunum, Test Merkezi ile müşteri etkileşimi modellerine ve belirli projelerin değerlendirilmesine ayrıldı ve dinleyicilerin tepkisine bakılırsa, bu tür teklifler birçok kişinin ilgisini çekti. Ve bu tesadüf değil, çünkü test hizmetlerinin dış kaynak kullanımı hala oldukça yeni. Olası ana etkileşim modellerini listeleyelim:

• Merkezin standında veya müşterinin yerinde eksiksiz bir yazılım testi yelpazesi veya bireysel aşamalarının gerçekleştirilmesi;
• organizasyon içindeki test süreçlerinin organizasyonu hakkında müşterilere danışmanlık ve eğitim;
• üçüncü taraf şirketler tarafından yürütülen testlerin denetimi;
• test için teknik ve yazılım kaynaklarının dış kaynak kullanımı.

Sonuç olarak, ilginç bir anı daha belirtmekte fayda var: Seminerler düzenledikten sonra, Aplana şirketi ülkemizde yazılım geliştirme alanında yeni bir hizmet türünün tanıtımını fiilen duyuran ilk şirketlerden biriydi. Öte yandan, öncüler kendilerini çoğu zaman ikircikli bir konumda bulurlar. Yani bu seminerde: sadece potansiyel müşterilere değil, aynı zamanda rakiplere de ücretsiz bir danışmanlık ve eğitim kursu verilmeliydi ...

* Test konularının önemini unutmadan, modern yazılım geliştirme yöntemlerinin klasiklerinden biri olan Hollandalı profesör Edsger Dijkstra'nın geçen yüzyılın 60'lı yıllarının sonlarında, yapılandırılmış programlama yöntemlerini uygulama ihtiyacını doğruladığını ve kesin olarak ilerlediğini hatırlamalıyız. test için işçilik maliyetlerini düşürme görevinden ...

** Testin özgünlüğü, tamamlanması için oldukça resmi kriterlere sahip olan diğer yazılım geliştirme aşamalarının aksine, genel durumda bu sürecin sonsuz olması gerçeğinde yatmaktadır. Sonuçta, bildiğiniz gibi, "bulunan her son hata aslında sondan bir önceki hatadır." Gereken gerçek test miktarını doğru bir şekilde belirlemek, ayrı bir zor iştir.

*** Testten bahsetmişken, yazılım doğrulamasının (doğruluğu kontrol etmek için sistematik bir prosedür) öneminden de bahsetmek gerekir. Bu kavramlar arasındaki ince fark, testin elde edilen sonuçları referansla karşılaştırma yeteneğine dayanmasıdır. Bununla birlikte, referans verisi olmadığında oldukça büyük bir problem sınıfı vardır. Böyle bir seçeneğin klasik bir örneği, iş uygulamalarıyla uğraşırken benzer durumlar ortaya çıksa da, on binlerce diferansiyel denklemin çözümüyle karmaşık matematiksel modellerin oluşturulmasıdır. Bu durumda, kullanıcının programın gerçekten doğru çalıştığına (%100 olmasa bile) güven duyması için yazılıma ek işlevler eklemek ve özel çalışmalar yapmak gerekir.

IBM Rational metodolojisi ve araç takımı

Yazılım geliştirmenin genel metodolojisi Rational Unified Process, oldukça geniş bir dizi test türünü ayırt eder (şekle bakın). Belli bir konvansiyonel dereceyle aşağıdaki gibi bölünebilirler: Fonksiyonel test veri bütünlüğü testi; farklı platformlarda test etme (Konfigürasyon testi); Yük devretme ve kurtarma testi; erişim testi (Güvenlik testi); kurulum testi; kullanıcı arayüzü testi yük testi performans profili oluşturma; İş döngüsü testi; büyük bir kullanıcı yükü altında test etme (Stres testi); büyük miktarda veri üzerinde test etme (Hacim testi). Bu sorunları çözmek için aşağıdaki temel araçlar sunulmaktadır: IBM Rational TestManager - Test Yönetimi IBM Rational PurifyPlus (Purify, PureCoverage, Quantify) - RunTime modunda sistem çalışmasının analizi; IBM Rational Robot - işlevsellik ve yük testi; IBM Rational TestFactory - Test oluşturma otomasyonu; IBM Rational XDE Tester - Java ve web uygulamalarının işlevsel testi. İki listeyi karşılaştırarak, her ürünün çeşitli test türlerini kapsadığını görebilirsiniz. İşte bu araçların kısa bir açıklaması. IBM Rational TestManager Testin tüm aşamalarında çok önemlidir, ekibe tek bir gösterge panosu kullanarak testleri planlamak, tasarlamak, yürütmek ve analiz etmek için ortak araçlar sağlar. Bu ürün, daha iyi sürüm kontrolü sağlayan kendi veri deposuna sahiptir. Çoğu çalışma zamanı test platformu desteklenebilirken, kendi API'sine sahip herhangi bir yazılım test aracının tek bir sisteme entegre edilmesi zor değildir. IBM Rational PurifyPlus Visual C/C++, C#, VB, VB .NET, Java, Java .NET kullanılarak geliştirilen uygulama ve bileşenlerin gerçek zamanlı analizi için tasarlanmış üç araç içerir. Purify, hatanın kaynağını ve konumunu vurgulayarak bellekle ilgili hataların otomatik olarak algılanmasını sağlar. Kaynak kodu mevcutsa, doğrudan Purify'dan yama yapılabilir. Patentli Nesne Kodu Ekleme teknolojisi, yalnızca kaynak kodda değil, aynı zamanda ikili program bileşenlerinde (DLL, COM / DCOM nesneleri, ODBC) bellek erişim hatalarının tespit edilmesini sağlar. PureCoverage, test edilmemiş kodu otomatik olarak algılamak için bir araçtır. Quantify, kaynak kodu olsun veya olmasın uygulamalardaki ve bileşenlerdeki darboğazları belirleyerek performans değerlendirmeleri gerçekleştirir. Yerleşik veri analizi araçları, farklı kod varyantları için test çalıştırmalarının sonuçlarını karşılaştırmanıza yardımcı olur. IBM Rasyonel Robotu- İnternet uygulamaları, ERP sistemleri ve istemci-sunucu çözümlerinin otomatik testlerini oluşturmak, değiştirmek ve yürütmek için bir araç. Çeşitli geliştirme araçlarını kullanarak uygulamalar oluştururken nesne düzeyinde destek sağlar. SQABAsic ortamında, VB ile sözdizimsel olarak uyumlu işlevsel test komut dosyaları oluşturulur; yerleşik düzenleyici, test komut dosyalarını gerekli prosedürler ve mantıksal koşullarla genişletmenize olanak tanır. Çeşitli yazılım nesneleri için özel testler oluşturmak mümkündür. Komut dosyaları oluşturmak için kendi C benzeri dili kullanılır. IBM Rational TestFactory- güvenilirlik kusurlarını belirlemek için çalışan uygulamanın kapsamlı bir analizi yoluyla test komut dosyalarının otomatik olarak oluşturulması için bir araç. Programların çok sayıda yürütme yolu olduğundan, zorluk, uygulamanın tam işlevselliğini minimum sayıda adımda doğrulayan testler oluşturmaktır. IBM Rational XDE Test Cihazı- Java uygulamalarını (J2EE, J2SE, SWT, AWT / JFC) ve Web uygulamalarını (HTML, DHTML, XML, JavaScript, Java uygulamaları) test etmek için özel bir araç. Metin komut dosyaları Java ile yazılmıştır, ScriptAssure teknolojisi dinamik verilerin doğrulanmasını sağlar. Test ortamı, aracı WebSphere Studio ve Rational XDE Developer'a yerleştirme yeteneğiyle Eclipse kabuğunda uygulanır.

Er ya da geç, şu ya da bu yazılımı kullanan birçok kuruluş, test sürecini düzenleme ihtiyacına gelir. Genellikle birkaç nedeni vardır, ya yazılımının hemen test edilmesini gerektiren bir başlangıçtır ya da yönetim, işletme, destek, geliştirme ve şirkete dahil olabilecek herkes tarafından test edilmesine ek olarak, hala profesyonellere ihtiyaç duyduğunu anlamaya başlar. diğer tüm insanları boşaltacak test uzmanları. normal bir test anlayışına sahip değiller. Ve bu andan itibaren, mevcut çalışanlardan birinin test departmanı başkanı pozisyonuna atanması için geleneksel görevimiz başlıyor. Mesela işte sana tarla, ekmek... Ama nasıl, ne yapacağın önemli değil, departman olmalı ve sonuç getirmeli. Elbette her şey her zaman bu kadar kötü olmuyor, birileri hala bu pozisyon için yetkin test uzmanları arıyor ama yine de bu aşamada henüz bir test süreci yok ve oluşturulması gerekiyor.

Ve çoğu zaman, birçok yönetici sistematik olarak değil, seçici olarak bir test süreci oluşturmaya başlar. Ancak aynı zamanda sistematik bir yaklaşım olmadan sadece en iyi uygulamaları ortadan kaldırarak test sürecini düzenlerseniz, böyle bir süreç ne bir ayda ne bir yılda olumlu sonuçlar getirmez.

Sanırım birçok kişi, test süreci en başından doğru organize edilmezse, daha sonra değiştirmenin son derece zor olacağını biliyor. Bu nedenle, test sürecini nasıl düzgün bir şekilde organize edeceğinizi belirlemeniz mi gerekiyor?

Test sürecini düzenlemeye nereden başlamalı?

Test sürecini organize etmede 11 ana kriteri vurgularım:

1. Test hedefleri ve kapsamı
2. Emretmek
3. Kontrol
4. İletişim ve etkileşim
5. test metodolojisi
6. Sürecin dokümantasyonu
7. Risklerin yönetimi
8. Proses ölçümü
9. enstrümanlar
10. Test ortamları
11. Süreç geliştirme

Test sürecini eşit bir şekilde geliştirmenizi sağlayan tüm bu kriterlerin yerine getirilmesi, kısa sürede test sürecinin olumlu sonuçlar getireceği seviyeye ulaşmanızı sağlar.

Bu nedenle, test sürecini organize etme görevi ile karşı karşıya kalan herhangi bir yönetici aşağıdaki soruları sormalıdır:

• Neden teste ihtiyacımız var?
• Test yapmak için ne yapmamız gerekiyor?
• Hangi süreçlerin resmileştirilmesi veya oluşturulması gerekiyor?
• Nasıl ve neyi test etmeliyiz?

Ancak bu soruların cevaplarını aldıktan sonra standartlara geçmeye başlayabiliriz.

Bir süreç oluşturmaya başlamadan önce gerçekten öğrenilmesi gereken aşağıdaki standartları vurguluyorum:

• ISO 29119
• IEEE 829 \ 1008
• TPI Sonraki ve TM Haritası
• ISTQB

Doğal olarak standartlarda belirtilen uygulamaların tam olarak kullanılması mümkün değildir. Herhangi bir standart, test sürecinizin ihtiyaçlarına uyacak şekilde özelleştirilmelidir, çünkü standart uygulamalarının düşüncesizce uygulanması olumsuz sonuçlara yol açabilir, çünkü test süreciniz iş gereksinimlerini karşılamayacaktır.

Herhangi bir BT süreci her zaman işletmenin ihtiyaçlarını karşılamalıdır!

Bir test süreci oluşturmak için ana kriterleri analiz edeceğiz.

Test hedefleri ve kapsamı

Testin amacı, kusurları tespit etmek, yazılımın belirtilen gereksinimlerle uyumluluğunu kontrol etmek ve ilgili tüm taraflara kusurlar hakkında geri bildirimde bulunmaktır.

Bu, test sürecinin ortak bir hedefidir, ancak kuruluşun iş gereksinimleri tarafından yönlendirilen hedefler de olabilir. Örneğin, Merkez Bankası'nın çeşitli gereksinimlerinin zamanında yerine getirilmesi bankalar için tipiktir, bu nedenle genel test amacına ek olarak, kritik görevler için gerekli kalitede test yapma zamanlaması da eklenir.

Test alanından bahsetmişken, tam olarak neyi test edeceğimizi çok iyi anlamamız gerekiyor. Bunlar sistemler, bileşenler, iş süreçleri olabilir. Bunu anlamak için iki soruyu cevaplamanız yeterli:

• Ne test edilmelidir?
• Neyi test edeceğiz?

Çoğu zaman, neyin test edilmesi gerekiyor ve neyin çok farklı olacağı. Test sürecinizin yeteneklerine bağlıdır. “Ne yapmalı” genellikle işletme ve yönetim tarafından belirlenir, bu nedenle iyi bir lider her zaman test etmek için “neye ihtiyaç duyduğunu” anlamalıdır. Söylediği gibi: "İki tavşanı kovalarsan bir tane bile yakalayamazsın", burada da öyle. Ekibinizle gerçekten test edebileceğiniz şeyleri niteliksel olarak test etmek, işletmenin istediği her şeyi kapmak ve hiçbir şey için zamanında olmamak ve hatta kritik kusurları gözden kaçırmaktan her zaman daha iyidir.

Ekip ve yönetim

Ekip, test sürecinin en önemli parçasıdır. Ekip olmadan, lider olarak hiçbir şey yapamazsınız. Ekip oluşturmaya yönelik genellikle birkaç yaklaşım vardır:

Araçlar ve altyapı

Aletsiz bir test süreci nedir? El emeği uğruna el emeği ortaya çıkıyor 🙂 Birçoğunuz Word belgelerinde test senaryoları yazmayı, Excel'de grafikler ve diyagramlar oluşturmayı sık sık duymuşsunuzdur. Ancak, pazar bize HP ALM, MS TFS, TestRail, TestLink, JIRA Zephyr ve diğerleri gibi hazır test yönetimi ürünleri sunuyorsa, bu çabalar neden boşa harcansın?
Bu nedenle, test sürecini düzenlemeye başladıysanız, bu süreci uygun ve etkili hale getirin. Uygun bitmiş ürün formlarında test senaryoları yazın, araçları bir görev yönetim sistemiyle entegre edin, özelleştirin, vb.

Bir araç seçimine yaklaşırken her zaman şunu anlamalısınız:

• Hangi görevleri gerçekleştirmeyi planlıyorsunuz?
• Alet bütçeniz nedir?

Bu soruların cevaplarını aldıktan sonra, sizin için en uygun test araçlarını belirleyebilecek ve muhtemelen kendinizinkini geliştirebileceksiniz.

Test yönetim araçlarına ek olarak, test araçları ayrıca şunları içerir:

• Hata ve görev yönetim sistemi (test yönetim sistemine dahil edilebilir)
• Destekleyici araçlar (ekran görüntüleri, günlükleri kaldırma, veritabanlarıyla çalışma, XML için SOUP UI vb. için)
• Otomasyon araçları (, Selenyum vb.)
• Bilgi yönetim sistemleri (bir wiki motorunda)

Şimdi biraz altyapıdan bahsedelim. Hikayemin mevcut bağlamında, test ortamlarını kastediyorum.

Hemen hemen her kuruluşta, özellikle kuruluş büyükse ve playmarket için mobil uygulamalar geliştirmiyorsa, test için bir test ortamına/ortamlarına ihtiyacınız olacaktır. Test ortamlarında sistem entegrasyonunun kapasitesi ve kapsamı, test kapsamına bağlı olarak değişebilir.

Varsayılan olarak, aşağıdaki test ortamı türlerini ayırt ederim:

• Geliştirme ortamı (test ortamı olarak sınıflandırılabilir mi? Ama yine de)
• Sistem test ortamı (bir veya birkaç sistem konuşlandırılabilir, bir bileşen ciddi güç gerektirmez)
• Entegrasyon ortamı (uçtan uca iş süreçlerinin sağlığını test etmek için tam teşekküllü entegrasyon ortamı)
• Çarşamba (ana gereksinim, kapasitelerin savaş devresine karşılık gelmesidir)
• ProdLike / PreProd ortamı (bitmiş test edilmiş yapı hatalarını ayıklamak, kurulum testi yapmak için ortam)

Bu kadar çok sayıda test ortamını organize etme yeteneği, bunları üst üste bindirerek test çalışması gerçekleştirmenize ve böylece paralel olarak, ancak farklı test aşamalarında gidebilen değişikliklerin (sürümler, sprintler) sayısını artırmanıza olanak tanır.

Süreç geliştirme

“Herhangi bir süreç, ne olursa olsun, her zaman sürekli iyileştirilmelidir” gibi bir cümleyi çok sık söylüyorum ve çok sık “Neden, sürecimiz çok iyi çalışıyor” sözünü duyuyorum.

Ama durum böyle değil. Test sürecini neden sürekli iyileştirmemiz gerekiyor:

1. Testin amaçları aynı olamaz, pazarın dikte ettiği işin ihtiyaçlarına bağlı olarak sürekli değişiyorlar.

2. BT alanı sürekli gelişmektedir. Yeni teknoloji yaklaşımları gelir ve her zaman test sürecini iyileştirmesine izin verilir.

Dedikleri gibi, mükemmelliğin sınırı yoktur!

Peki, nasıl geliştirilir, standart Demming döngüsüdür.

Planlandı - Yapıldı - Analiz Edildi - Düzeltildi

Sonuç olarak, doğru olanın mümkün olan en kısa sürede amaçlarını ve hedeflerini çözen gerçekten etkili bir test süreci oluşturmasına izin verdiğini söyleyeceğim.

Yazılım testi (SW), koddaki ortadan kaldırılması gereken kusurları, kusurları ve hataları ortaya çıkarır. Yazılımın işlevselliğini ve doğruluğunu analiz yoluyla değerlendirme süreci olarak da tanımlanabilir. Yazılım ürünlerinin ana entegrasyon ve test yöntemleri, uygulamaların kalitesini garanti eder ve spesifikasyonun, tasarımın ve kodun kontrol edilmesinden, güvenilirliğin değerlendirilmesinden, doğrulama ve doğrulamadan oluşur.

yöntemler

Yazılım testinin temel amacı, dikkatli bir şekilde kontrol edilen koşullarda uygulamalarda sistematik olarak hata ayıklayarak, bunların eksiksizliğini ve doğruluğunu belirleyerek ve ayrıca gizli hataları tespit ederek bir yazılım paketinin kalitesini doğrulamaktır.

Metotlar statik ve dinamik olarak ikiye ayrılabilir.

İlki, gayri resmi, kontrol ve teknik emsal incelemesi, teftiş, gözden geçirme, denetim ve veri akışı ve kontrolünün statik analizini içerir.

Dinamik teknikler aşağıdaki gibidir:

1. Beyaz kutu testi. Bu, bir programın iç mantığının ve yapısının ayrıntılı bir çalışmasıdır. Bu, kaynak kodu hakkında bilgi gerektirir.
2. Kara kutu testi. Bu teknik, uygulamanın iç işleyişi hakkında herhangi bir bilgi gerektirmez. Sistemin yalnızca iç mantıksal yapısıyla bağlantılı olmayan veya çok az ilgisi olan ana yönleri dikkate alınır.
3. Gri kutu yöntemi.Önceki iki yaklaşımı birleştirir. Uygulamanın dahili işleyişi hakkında sınırlı bilgi ile hata ayıklama, sistemin temel yönleri bilgisi ile birleştirilir.

Şeffaf test

Beyaz kutu yöntemi, prosedürel bir projenin kontrol yapısının test komut dosyalarını kullanır. Bu teknik, bir yazılım parçasının iç işleyişini analiz ederek zayıf kod yönetimi gibi uygulama hatalarını ortaya çıkarır. Bu test yöntemleri entegrasyon, birim ve sistem seviyelerinde uygulanabilir. Test eden kişinin kaynak koduna erişimi olmalı ve bunu hangi bloğun uygunsuz davrandığını bulmak için kullanmalıdır.

Programların beyaz kutu testi aşağıdaki avantajlara sahiptir:

• fazladan satırları silerken gizli koddaki bir hatayı belirlemenizi sağlar;
• yan etkileri kullanma olasılığı;
• maksimum kapsama, bir test komut dosyası yazılarak elde edilir.

Dezavantajları:

• nitelikli bir hata ayıklayıcı gerektiren yüksek maliyetli bir süreç;
• olası tüm gizli hataların kapsamlı bir şekilde kontrol edilmesi çok zor olduğundan, birçok yol keşfedilmemiş kalacaktır;
• eksik kodun bir kısmı fark edilmeyecektir.

Beyaz kutu testi bazen şeffaf veya açık kutu testi, yapısal test, mantıksal test ve kaynak koduna, mimariye ve mantığa dayalı test olarak adlandırılır.

Ana çeşitler:

1) akış kontrol testi - program kontrol akışını model olarak kullanan ve daha basit yolları daha az karmaşık olanlara tercih eden yapısal bir strateji;

2) dallara ayrılan hata ayıklama, birleşik çözümü de içeren her bir kontrol ifadesinin her bir seçeneğini (doğru veya yanlış) incelemeyi amaçlar;

3) test edenin, bir temel yürütme yolları kümesini izole etmek için bir prosedürel projenin mantıksal karmaşıklığının bir ölçüsünü oluşturmasına izin veren ana yolun test edilmesi;

4) veri akışının kontrol edilmesi - grafiğe program değişkenlerinin beyanı ve kullanımı hakkında bilgi ekleyerek kontrol akışını incelemek için bir strateji;

5) Döngü testi - tamamen döngüsel prosedürlerin doğru yürütülmesine odaklanmıştır.

davranışsal hata ayıklama

Kara kutu testi, yazılımı bir "kara kutu" olarak ele alır - programın iç işleyişi hakkındaki bilgiler dikkate alınmaz, ancak sistemin yalnızca ana yönleri kontrol edilir. Bu durumda, test cihazının kaynak koduna erişmeden sistem mimarisini bilmesi gerekir.

Bu yaklaşımın avantajları:

• büyük bir kod segmenti için verimlilik;
• test cihazı tarafından algı kolaylığı;
• kullanıcının bakış açısı geliştiricinin bakış açısından açıkça ayrılmıştır (programcı ve test edici birbirinden bağımsızdır);
• daha hızlı test oluşturma.

Programların kara kutu testi aşağıdaki dezavantajlara sahiptir:

• aslında, sınırlı kapsama ile sonuçlanan belirli sayıda test senaryosu yürütülür;
• net bir spesifikasyonun olmaması, test senaryoları geliştirmeyi zorlaştırır;
• düşük verimlilik.

Bu tekniğin diğer isimleri davranışsal, opak, işlevsel testler ve kapalı kutu hata ayıklamadır.

1) program modülünün giriş verileri ayrı bölümlere ayrıldığından, test verileri kümesini azaltabilen eşdeğer bölümleme;

2) kenar analizi, sınırların veya aşırı sınır değerlerinin kontrolüne odaklanır - minimumlar, maksimumlar, hatalı ve tipik değerler;

3) fuzzing - otomatik veya yarı otomatik modda bozuk veya yarı bozuk veri girerek uygulama hatalarını aramak için kullanılır;

4) neden-sonuç ilişkilerinin grafikleri - grafikler oluşturmaya ve bir eylem ile nedenleri arasında bir bağlantı kurmaya dayanan bir teknik: özdeşlik, olumsuzlama, mantıksal VEYA ve mantıksal VE - neden ve sonuç arasındaki karşılıklı bağımlılığı ifade eden dört ana sembol;

5) kapsamlı bir keşif kapsamının ötesinde, nispeten küçük bir girdi alanına sahip problemlere uygulanan ortogonal dizilerin doğrulanması;

6) tüm çiftlerin testi - her bir giriş parametresi çiftinin olası tüm ayrı kombinasyonlarını içeren test değerleri kümesi olan bir teknik;

Kara kutu testi: örnekler

Teknik, spesifikasyonlara, belgelere ve yazılım veya sistem arayüzü açıklamalarına dayanmaktadır. Ayrıca, yazılımın beklenen davranışını temsil eden modeller (resmi veya gayri resmi) kullanmak mümkündür.

Tipik olarak, bu hata ayıklama yöntemi kullanıcı arayüzleri için kullanılır ve ekrandan, raporlardan veya çıktılardan veri girerek ve sonuçları toplayarak uygulama ile etkileşim kurmayı gerektirir.

Böylece test cihazı, giriş yoluyla, anahtarlar, düğmeler veya diğer arayüzler üzerinde hareket ederek yazılımla etkileşime girer. Giriş verilerinin seçimi, girildikleri sıra veya eylem sırası, aşağıdaki örnekte görülebileceği gibi, çok sayıda kombinasyona yol açabilir.

4 onay kutusu ve zamanı saniye cinsinden ayarlayan bir açma / kapama alanı için tüm olası değerleri kontrol etmek için kaç test yapılması gerekiyor? İlk bakışta hesaplama basittir: İki olası duruma sahip 4 alan - 24 = 16, 00 ile 99 arasındaki olası konum sayısı, yani 1600 olası test ile çarpılması gerekir.

Ancak bu hesaplama yanlıştır: iki konumlu bir alanın boşluk da içerebileceğini yani iki alfanümerik konumdan oluştuğunu ve alfabe karakterleri, özel karakterler, boşluklar vb. içerebileceğini belirleyebiliriz. 16 bitlik bir bilgisayarsa, her konum için 216 = 65 536 seçenek elde ederiz, bu da 4 294 967 296 test durumuyla sonuçlanır, bu da bayraklar için 16 kombinasyonla çarpılması gerekir, bu da toplam 68 719 476 736 verir. saniyede 1 test hızında, toplam test süresi 2.177.5 yıl olacaktır. 32 veya 64 bit sistemler için süre daha da uzundur.

Bu nedenle bu süreyi kabul edilebilir bir değere indirmek gerekli hale gelmektedir. Bu nedenle, test kapsamını azaltmadan test vakalarının sayısını azaltmak için teknikler uygulanmalıdır.

eşdeğer bölüm

Eşdeğer bölümleme, yazılımda bulunan giriş veya çıkış değerleri, karakter, sayısal vb. herhangi bir değişkene uygulanabilen basit bir tekniktir. Bir eşdeğer bölümdeki tüm verilerin aynı şekilde işleneceği ilkesine dayanır. ve bunlar tarafından aynı talimatlar.

Test sırasında, tanımlanan her eşdeğer bölümden bir temsilci seçilir. Bu, komut ve işlev kapsamını kaybetmeden olası test senaryolarının sayısını sistematik olarak azaltmanıza olanak tanır.

Bu bölümün bir başka sonucu, farklı değişkenler arasındaki kombinasyon patlamasının azalması ve test durumlarının buna bağlı azalmasıdır.

Örneğin (1 / x) 1/2, üç veri dizisi, üç eşdeğer bölüm kullanır:

1. Tüm pozitif sayılar aynı şekilde ele alınacak ve doğru sonuçlar vermelidir.

2. Tüm negatif sayılar aynı şekilde ve aynı sonuçla ele alınacaktır. Bu yanlıştır, çünkü negatif bir sayının kökü sanaldır.

3. Sıfır ayrı olarak işlenecek ve sıfıra bölme hatası verecektir. Bu tek anlam bölümüdür.

Böylece, biri tek bir anlama gelen üç farklı bölüm görüyoruz. Güvenilir sonuçlar veren bir “doğru” bölüm ve yanlış sonuçlar veren iki “yanlış” bölüm vardır.

Kenar analizi

Eşdeğer bir bölümün sınırlarındaki veri işleme, beklenenden farklı şekilde gerçekleştirilebilir. Sınır değerleri keşfetmek, bu tür alanlarda yazılım davranışını analiz etmenin iyi bilinen bir yoludur. Bu teknik, aşağıdaki hataları belirlemenizi sağlar:

• ilişkisel operatörlerin kötüye kullanılması (<,>, =, ≠, ≥, ≤);
• tek hatalar;
• döngüler ve yinelemelerdeki problemler,
• bilgileri depolamak için kullanılan değişkenlerin yanlış türleri veya boyutları;
• veriler ve değişken türleri ile ilgili yapay kısıtlamalar.

Yarı şeffaf test

Gri kutu yöntemi, beyaz ve siyah yöntemleri birleştirerek karmaşık bir sistemin tüm seviyelerine odaklanmanıza izin vererek testin kapsamını artırır.

Bu tekniği kullanırken, test cihazı, test değerlerini tasarlamak için dahili veri yapıları ve algoritmalar hakkında bilgi sahibi olmalıdır. Gri kutu test tekniklerine örnekler:

• mimari model;
• Birleşik Modelleme Dili (UML);
• durum modeli (durum makinesi).

Test senaryolarını geliştirmek için gri kutu yönteminde, modül kodları beyaz teknikte incelenir ve asıl test, siyah teknikte program arayüzlerinde gerçekleştirilir.

Bu tür test yöntemleri aşağıdaki avantajlara sahiptir:

• beyaz ve kara kutu tekniklerinin avantajlarının bir kombinasyonu;
• test cihazı, kaynak kodundan ziyade arayüze ve işlevsel spesifikasyona güvenir;
• hata ayıklayıcı mükemmel test komut dosyaları oluşturabilir;
• doğrulama, programın tasarımcısı değil, kullanıcının bakış açısından gerçekleştirilir;
• özel test tasarımlarının oluşturulması;
• nesnellik.

Dezavantajları:

• kaynak koduna erişim olmadığı için test kapsamı sınırlıdır;
• dağıtılmış uygulamalardaki kusurları tespit etmenin karmaşıklığı;
• birçok yol keşfedilmemiş kalır;
• yazılım geliştiricisi kontrolü zaten yaptıysa, daha fazla araştırma gereksiz olabilir.

Gri kutu tekniğinin diğer bir adı da yarı saydam hata ayıklamadır.

1) ortogonal dizi - tüm olası kombinasyonların bir alt kümesini kullanarak;

2) program durumu verilerini kullanarak matris hata ayıklaması;

3) yazılımda yeni değişiklikler yapıldığında gerçekleştirilen;

4) sağlam bir uygulamanın tasarımını ve mimarisini analiz eden bir şablon testi.

yazılım testi

Tüm dinamik yöntemlerin kullanılması, geliştirilecek, uygulanacak ve çalıştırılacak testlerin sayısında kombinatoryal bir patlama ile sonuçlanır. Her teknik, sınırlamaları akılda tutularak pragmatik olarak kullanılmalıdır.

Tek bir doğru yöntem yoktur, yalnızca belirli bir bağlama en uygun olanlar vardır. Yapısal teknikler, işe yaramaz veya kötü niyetli kod bulmanıza yardımcı olabilir, ancak bunlar karmaşıktır ve büyük programlara uygulanamaz. Spesifikasyona dayalı yöntemler, eksik kodu tam olarak tespit edebilen tek yöntemlerdir, ancak dışarıdakileri tanımlayamazlar. Bazı teknikler, belirli bir test düzeyi, hata türü veya bağlam için diğerlerinden daha uygundur.

Aşağıda, üç dinamik test tekniği arasındaki temel farklar yer almaktadır - üç yazılım hata ayıklama biçimi arasında bir karşılaştırma tablosu verilmiştir.

Bakış açısı	Kara kutu yöntemi	gri kutu yöntemi	Beyaz kutu yöntemi
Programın bileşimi hakkında bilgilerin mevcudiyeti	Sadece temel yönler analiz edilir	Programın iç yapısı hakkında kısmi bilgi	Kaynak koduna tam erişim
Program parçalanması
Kim hata ayıklıyor?	Son kullanıcılar, test kullanıcıları ve geliştiriciler	Son kullanıcılar, hata ayıklayıcılar ve geliştiriciler	Geliştiriciler ve test kullanıcıları
	Test, harici anormal durumlara dayanır.	Veritabanı diyagramları, veri akış diyagramları, dahili durumlar, algoritma ve mimari bilgisi	İç yapı tam olarak biliniyor
Kapsam	En az kapsamlı ve zaman alıcı		Potansiyel olarak en kapsamlısı. Zaman tükeniyor
Veri ve iç sınırlar	Yalnızca deneme yanılma yoluyla hata ayıklama	Biliniyorsa veri alanları ve dahili sınırlar kontrol edilebilir	Veri Alanlarının ve Dahili Sınırların Daha İyi Test Edilmesi
Algoritma Test Edilebilirliği

Otomasyon

Yazılım ürünleri için otomatikleştirilmiş test yöntemleri, teknik ortam veya yazılım bağlamından bağımsız olarak doğrulama sürecini büyük ölçüde basitleştirir. İki durumda kullanılırlar:

1) testçinin daha önemli noktalara konsantre olması için zaman kazanmak için birkaç bin satırlık dosyaları karşılaştırmak gibi sıkıcı, tekrarlayan veya titiz görevlerin yürütülmesini otomatikleştirmek;

2) Saniyenin yüzde biri olarak ölçülebilen, performansı test etme veya yanıt sürelerini analiz etme gibi insanlar tarafından kolayca gerçekleştirilemeyen görevleri gerçekleştirmek veya izlemek.

Test araçları farklı şekillerde sınıflandırılabilir. Aşağıdaki bölüm, destekledikleri görevlere dayanmaktadır:

• proje, sürüm oluşturma, yapılandırma yönetimi, risk analizi, test izleme, hatalar, kusurlar ve raporlama araçları için destek içeren test yönetimi;
• gereksinimleri ve spesifikasyonları depolamayı, eksiksizlik ve belirsizlik açısından kontrol etmeyi, önceliklerini ve her testin izlenebilirliğini içeren gereksinim yönetimi;
• akış ve görevlerin izlenmesi, yorumların kaydedilmesi ve saklanması, kusurların ve planlı düzeltmelerin saptanması, kontrol listelerine ve kurallara bağlantıların yönetilmesi, kaynak belgeler ve kod arasındaki ilişkinin izlenmesi, kusurların saptanması ile statik analiz, kodlama standartlarına uygunluğun sağlanması dahil olmak üzere kritik inceleme ve statik analiz , yapıların ve bağımlılıklarının analizi, kod ve mimarinin metrik parametrelerinin hesaplanması. Ayrıca derleyiciler, bağlantı çözümleyicileri ve çapraz bağlantı oluşturucular kullanılır;
• iş davranışını modellemek ve oluşturulan modelleri doğrulamak için araçlar içeren modelleme;
• testlerin geliştirilmesi, koşullara ve kullanıcı arayüzüne, modellere ve koda dayalı olarak beklenen verilerin oluşturulmasını, bunların dosya ve veritabanlarını oluşturma veya değiştirme yönetimini, mesajları, yönetim kurallarına dayalı veri doğrulamasını, koşul ve risk istatistiklerinin analizini sağlar;
• başarılı ve başarısız testleri belirlemeye yardımcı olmak için karşılaştırıcıları kullanan grafik kullanıcı arayüzü, API, komut satırları aracılığıyla veri girerek kritik taramalar;
• deterministik çıktının bir alt kümesine dayalı donanım simülatörleri, terminal öykünücüleri, cep telefonları veya ağ ekipmanı, eksik bileşenleri sahte sürücü modülleriyle değiştirerek dilleri, işletim sistemini ve donanımı kontrol etmek için ortamlar dahil olmak üzere eksik donanım veya yazılımı değiştirmenize olanak tanıyan hata ayıklama ortamları için destek , vb. ve ayrıca işletim sistemi isteklerini engellemek ve değiştirmek, CPU, RAM, ROM veya ağ sınırlamalarını simüle etmek için araçlar;
• veri dosyalarının, veritabanlarının karşılaştırılması, dinamik ve toplu karşılaştırma dahil olmak üzere test sırasında ve sonrasında beklenen sonuçların doğrulanması, otomatik "kahinler";
• bellek sızıntılarını ve yanlış yönetimini yerelleştirmek için kapsam ölçümü, simüle edilmiş yük koşulları altında sistem davranışını değerlendirmek, büyümesinin gerçekçi senaryolarına dayalı olarak uygulama, veritabanı, ağ veya sunucu yükü oluşturmak, sistem kaynaklarını ölçmek, analiz etmek, kontrol etmek ve raporlamak için;
• güvenlik;
• performans testi, yük testi ve dinamik analiz;
• yazım ve sözdizimi denetimi, ağ güvenliği, tüm sayfaların bir web sitesinde bulunması ve daha fazlası dahil olmak üzere diğer araçlar.

Perspektif

Yazılım endüstrisindeki trendler değiştikçe hata ayıklama süreci de değişebilir. Hizmet Odaklı Mimari (SOA), kablosuz teknolojiler, mobil hizmetler vb. gibi yazılım ürünlerini test etmek için mevcut yeni yöntemler, yazılımı test etmek için yeni yollar açmıştır. Önümüzdeki birkaç yıl içinde bu sektörde beklenen değişikliklerden bazıları aşağıda listelenmiştir:

• test kullanıcıları, geliştiricilerin kodlarını test edebilecekleri hafif modeller sağlayacaktır;
• programları erken bir aşamada görüntülemeyi ve simüle etmeyi içeren test yöntemleri geliştirmek, tutarsızlıkların çoğunu ortadan kaldıracaktır;
• birçok test kancasının varlığı, hata algılama süresini azaltacaktır;
• statik analizör ve algılama araçları daha yaygın olarak kullanılacak;
• spesifikasyon kapsamı, model kapsamı ve kod kapsamı gibi faydalı matrislerin kullanımı projelerin geliştirilmesine rehberlik edecektir;
• kombinatoryal araçlar, test uzmanlarının hata ayıklama alanlarına öncelik vermesini sağlar;
• test uzmanları, yazılım geliştirme süreci boyunca daha görsel ve değerli hizmetler sunacak;
• hata ayıklayıcılar, çeşitli programlama dillerinde yazılmış ve bunlarla etkileşime giren yazılımları test etmek için araçlar ve yöntemler oluşturabilecektir;
• hata ayıklayıcılar daha profesyonel hale gelecek.

Yeni iş odaklı yazılım test yöntemleri yerini alacak, sistemlerle etkileşim şeklimiz ve sağladıkları bilgiler değişecek, riskleri azaltacak ve iş değişikliğinin faydalarını artıracak.