Yazılım ürün testi. İçinde başka işlevler kullanan bir işlevin işlevselliği nasıl test edilir? İlgili testleri değiştirin

Bir çökmeden sonra programı yarım saat içinde 18 kez yeniden başlatabilecek ve ancak bundan sonra monitörü doğrudan pencereye atabilecek kadar hoşgörülü olsanız bile, bu programla çalışmanın "çökmemesi" durumunda daha rahat olacağını kabul edeceksiniz. ” .

Geliştirdiğiniz programın çökmesi, donması veya gerekli eylemlerin gerçekleştirilememesi durumlarının çok nadir hale gelmesini nasıl sağlayabilirsiniz?

Kesin cevabı bu soru HAYIR. Ancak yüzyıllar boyunca, en bilge bilim adamları bu konu hakkında yıllarca düşündüler ve tüm program hatalarını ortadan kaldırmazsa, en azından onları ortadan kaldıracak eylem yanılsamasını yaratan bir çare bulmayı başardılar.

Ve bu çarenin adı TEST YAPMAK yazılım ürünü .

Bilge insanlara göre Test, gelişimin kalitesini sağlamanın en köklü yollarından biridir. yazılım ve sete dahildir Etkili araçlar modern sistem Yazılım ürününün kalitesinin sağlanması.

Bir yazılım ürününün kalitesi, ürünün müşterisi, sponsoru, son kullanıcısı, ürün geliştiricileri ve test uzmanları, destek mühendisleri, pazarlamacılar gibi paydaşların bakış açısından ne kadar "iyi" olduğunu belirleyen bir dizi özellik ile karakterize edilir. , eğitim ve satış personeli. Katılımcıların her biri ürünün ne kadar iyi ya da kötü olduğu, yani ürünün kalitesinin ne kadar yüksek olduğu konusunda farklı bir fikre sahip olabilir. Bu nedenle, ürün kalitesini sağlama sorununun belirlenmesi, paydaşların, onların kalite kriterlerinin belirlenmesi ve daha sonra bu kriterleri karşılayan en uygun çözümün bulunması göreviyle sonuçlanır.

Ne zaman ve kim?

Deneyimli geliştiricilere göre, bir yazılım ürününün testi, yaratıldığı andan itibaren gerçekleştirilmelidir. Ancak aynı zamanda deneyimli geliştiricilerin kendileri de testlerde yer almamalıdır çünkü bu kraliyet meselesi değildir. Yazılım ürününün test uzmanı adı verilen özel eğitimli çalışanlar tarafından test edilmesi gerekir, çünkü en deneyimli geliştirici bile en yeni optik cihazları kullansa bile hatasını göremeyecektir.

Ancak tüm geliştiriciler, bir yazılım ürününün amaca göre sınıflandırma açısından test edilmesinin iki sınıfa ayrılması gerektiği konusunda hemfikirdir:

• Fonksiyonel test
• İşlevsel olmayan testler

Fonksiyonel test

İşlevsel test, bir yazılım ürününün, bu ürünün oluşturulmasına ilişkin teknik özelliklerde belirtilen işlevsel gereksinimlere uygunluğunu kontrol etmek anlamına gelir. Basitçe ifade etmek gerekirse fonksiyonel test, yazılım ürününün yapması gereken tüm fonksiyonları yerine getirip getirmediğini kontrol eder.

Sonunda işlevsel testler yapmaya karar verdiniz. Teknik spesifikasyona bakarsınız, işlevsel gereklilikleri okursunuz ve en azından bunların testin yapılabileceği sırayla olmadığını anlarsınız. Başkalarının uzun zaman önce bu tutarsızlığı fark edip bunun nasıl üstesinden gelebileceklerini bulmalarına şaşıracaksınız.

İşlevsel testleri gerçekleştirmek için teknik kontrol departmanı personeli, uygulamanın (API) işlevselliğini test etmek için bir belge programı ve metodoloji geliştiriyor. PMI belgesi, yazılım ürünü test senaryolarının (test senaryolarının) bir listesini içerir. Detaylı Açıklama adımlar. Test senaryosunun her adımı, kullanıcının (test uzmanı) eylemleri ve beklenen sonuçlar (programın bu eylemlere verdiği yanıt) ile karakterize edilir. Test programı ve metodolojisi, yazılım ürününün çalışmasını gerçek modda simüle etmelidir. Bu, test senaryosunun, sistemin gelecekteki kullanıcılarının gerçekleştireceği işlemlerin analizi temelinde oluşturulması gerektiği ve yalnızca geliştiricinin anlayabileceği, yapay olarak derlenmiş bir manipülasyon dizisi olmaması gerektiği anlamına gelir.

Tipik olarak fonksiyonel testler iki seviyede gerçekleştirilir:

• Bileşen (birim) testi. Bir yazılım ürününün ayrı ayrı bileşenlerinin özelliklerine, amaçlarına ve işlevsel özelliklerine odaklanılarak test edilmesi.
• Entegrasyon testi. Bu tip test, bileşen testinden sonra gerçekleştirilir ve çeşitli alt sistemlerin kontrol akışları ve veri alışverişi düzeyinde etkileşimindeki kusurları tanımlamayı amaçlar.

İşlevsel olmayan testler

İşlevsel olmayan test, bir yazılım ürününün ergonomi veya performans gibi niteliklerini değerlendirir.

Bu tür testlerin öneminin açık olduğunu ve gerekçe gerektirmediğini düşünüyorum. Sonuçta herkes, örneğin sistem performansı yeterli değilse, kullanıcıların eylemlerine yanıt almak için yarım gün beklemeleri gerekeceğini ve bunun toplu hazırda bekletme moduna yol açabileceğini anlıyor.

Adından da anlaşılacağı gibi işlevsel olmayan testler, bir yazılım ürününün işlevsel olmayan gereksinimleri karşıladığını doğrular. başvuru şartları yaratılışı için. Fonksiyonel testlerde olduğu gibi, fonksiyonel olmayan testler için de bir test programı ve metodolojisi geliştirilir.

Çevik Çağda Gömülü Yazılım Testi ve Uyumluluk

Endüstri standartlarına uyum, ihmal edebileceğiniz veya sonradan yapabileceğiniz bir şey değildir; gömülü yazılım (yazılım) geliştirme sürecinin ayrılmaz bir parçasıdır. Havacılık elektroniği, otomotiv ve sağlık hizmetleri gibi bazı endüstriler için, karmaşık ve sorunsuz gömülü sistemlerin geliştirilmesinde kalite standartlarına sıkı sıkıya bağlı kalmak, bir ürünün pazara sunulması açısından hayati öneme sahiptir. Geleneksel olarak testler, standartların düzenlediği endüstriler için gömülü sistemlerin geliştirilmesinde önemli bir rol oynamıştır. Ancak son yıllarda yerleşik test uygulamaları ve süreçleri, bunların bu tür projelerdeki yeri ve rolü önemli ölçüde değişti. Bu oyunun kurallarını değiştiren bir olaydı ve oyunun kuralları değiştiğinde kazanmak için siz de onlarla birlikte değişmek zorundasınız.

Yeni ve ileri teknolojilerin sürekli gelişmesiyle birlikte şirketlerin, hızla değişen teknolojik dünyada kaybolmamak için güvenilir, emniyetli, kullanımı kolay ve diğer sistemlerle uyumlu ürünleri hızla pazara sunmaları gerekiyor. Böyle bir durumda yazılım geliştirme sürecinin kesinlikle sıralı olduğu ve testlerin en sonunda yapıldığı geleneksel şelale modeli geçmişte kalıyor. DevOps ve Agile yöntemleri, mühendislerin daha önce birbirini takip eden görevleri eş zamanlı olarak tamamlamasına olanak tanıdığı için giderek daha popüler hale geliyor.

Performans testi

Performans testi aşamasında ilk adım, sistemin dış etkilere gerçek hayattaki çalışmaya yakın bir modda yeterince tepki verip vermeyeceğini kontrol etmek olan yük testidir.

Yük testine ek olarak, testler minimum donanım ve maksimum yük - stres testi koşulları altında ve ayrıca maksimum hacimde işlenmiş bilgi - hacimsel test koşulları altında testler gerçekleştirilir.

Başka bir test türü daha vardır: stabilite ve güvenilirlik testi, bir yazılım ürününün normal koşullar altında yalnızca uzun vadeli testini değil aynı zamanda kısa süreli stresli yüklerden sonra normal çalışmaya dönme yeteneğini de içerir.

Test için belgeler

Yukarıda belirtildiği gibi testler, GOST 34.603-92'ye uygun olarak geliştirilen program ve test metodolojisine uygun olarak gerçekleştirilir.

Testi gerçekleştirmek için, yazılım ürününün tüm çalışma modlarını test etmek için yeterli veri içermesi gereken bir test senaryosu geliştirilir. Tipik olarak, müşteri ve yüklenici tarafından gerçek verilere dayalı olarak ortak bir test senaryosu oluşturulur.

Her türlü performans testini gerçekleştirmek için, çoğunlukla veri oluşturucu adı verilen bir şey oluşturulur; otomatik mod Performansı değerlendirirken objektif bir sonuç elde etmek için yeterli miktarda veri oluşturun.

Test sırasında, tüm aşamaların tamamlanması ve testin adımları ve test sırasında alınan yorumlar hakkında bilgi içeren bir test protokolü hazırlanır.

Test sonucunun olumsuz olması durumunda eksiklikler düzeltilerek tekrar test yapılır.

Araştırma testi

Keşif testleri (özel amaçlı testler, fonksiyonel testlerin bir alt türüdür. Açık dokümantasyon ve gereksinimlerin bulunmadığı, esnek geliştirme yöntemleriyle hızlı büyüyen projelerde kullanılır. Keşif testi, yazılım testindeki en yüksek akrobasi testidir. Kalitatif testler, yüksek nitelikli uzmanlar ve neredeyse tamamen sanatçıya, onun deneyimine, bilgisine (hem konu alanında hem de test yöntemlerinde) ve hızla öze ulaşma yeteneğine bağlıdır.

Stres testi

Yük testi, test edilen sistemin yük altında performansını analiz etme işlemidir. Yük testinin amacı, uygulamanın dış yüklere dayanma yeteneğini belirlemektir. Tipik olarak testler birkaç aşamada gerçekleştirilir.

1. Test komut dosyalarının oluşturulması

Etkili analiz için senaryoların gerçek kullanım senaryolarına mümkün olduğunca yakın olması gerekir. İstisnaların her zaman mümkün olduğunu ve en ayrıntılı test planının bile tek bir durumu kapsamayabileceğini anlamak önemlidir.

2. Bir test konfigürasyonunun geliştirilmesi

Test senaryolarına sahip olmak, artan yükün sırasını dağıtmak önemlidir. Başarılı bir analiz için performans değerlendirme kriterlerinin (yanıt hızı, talep işleme süresi vb.) belirlenmesi gerekir.

3. Bir test testinin yapılması

Testleri gerçekleştirirken senaryoların yürütülmesini ve test edilen sistemin tepkisini zamanında izlemek önemlidir. Yüksek yükleri taklit etmek ciddi donanım ve yazılım altyapısı gerektirir. Bazı durumlarda işin maliyetini azaltmak için matematiksel modelleme yöntemlerinden yararlanılmaktadır. Düşük yüklerde elde edilen veriler esas alınır ve yaklaşık değerler alınır. Simüle edilen yük düzeyi ne kadar yüksek olursa, tahminin doğruluğu da o kadar düşük olur. Ancak bu yöntem maliyetleri önemli ölçüde azaltır.

Test otomasyonu

Otomatik testin ana özelliği, regresyon testlerini hızlı bir şekilde yürütme yeteneğidir. Otomasyonun ana avantajları (Worksoft'un bir raporuna göre) artan personel verimliliği, kusurların erken tespiti ve daha fazlasıdır. yüksek kalite iş süreçleri. Bu avantajlar önemli bir dezavantajla dengeleniyor: yüksek maliyet - test otomasyonunu uygulama ve destekleme maliyetinin yüksek olması nedeniyle şirketlerin yaklaşık %50'si hâlâ çoğunlukla manuel testleri kullanıyor.

Kullanılabilirlik testi

Herhangi bir uygulama kullanılmak üzere oluşturulur. Kullanım kolaylığı bir programın önemli bir kalite göstergesidir. BT sektörü, başarılı bir kullanılabilirlik düzeltmesinden sonra ortaya çıkan birçok proje örneğini biliyor. Hedef kitle ne kadar geniş olursa kullanılabilirlik faktörü de o kadar önemli olur. Kullanılabilirlik testi, kullanıcı davranışının ayrıntılı analizini içerir. Ergonomiyi değerlendirmek için yalnızca bir iş görevini tamamlama hızına ilişkin değil, aynı zamanda kullanıcının duygularına, yüz ifadelerine ve ses tonuna ilişkin verilere sahip olmak da önemlidir.

Yapılandırma testi

Konfigürasyon testi, uygulamanın farklı platformlarda ve dolayısıyla maksimum sayıda kullanıcı için çalışacağına dair güven verir. WEB uygulamaları için genellikle tarayıcılar arası test seçilir. Windows uygulamaları için - çeşitli uygulamalarda testler işletim sistemleri ve bit boyutları (x86, x64). Konfigürasyon testinin önemli bir bileşeni test altyapısıdır: testleri gerçekleştirmek için sürekli olarak bir test makinesi filosuna sahip olmanız gerekir. Sayıları 5 ile birkaç düzine arasında değişmektedir.

Entegrasyon testi

Projenizde birden fazla bileşen varsa entegrasyon testine ihtiyaç vardır. Karmaşık bir uygulama mimarisiyle kalite güvencesi için gerekli bir koşul, program parçalarının etkileşiminin kontrol edilmesidir. Test, “uçtan uca” vakaların geliştirilmesi ve yürütülmesi yoluyla gerçekleştirilir. Entegrasyon testi, bileşen testinden sonra gerçekleştirilir. Bu nedenle, test senaryolarının iş yönelimine saygı gösterirken bileşen testi deneyimini de hesaba katmak çok önemlidir.

Stres testi

Her sistemin bir sınırı vardır normal işleyiş. Limit aşıldığında sistem stres durumuna girer ve davranışını önemli ölçüde değiştirir. Stres testi, bir uygulamanın normal çalışma sınırlarını aşan koşullar altında çalışmasını test eder. Bu özellikle “kritik” programlar için önemlidir: bankacılık yazılımı, havacılık endüstrisi programları, tıp. Stres testi, yalnızca yazılım geliştirme aşamasında değil, aynı zamanda sistem davranış verilerinin uzun bir süre boyunca elde edilmesi ve işlenmesi amacıyla tüm çalışma döngüsü boyunca gerçekleştirilir.

Bir get-data fonksiyonu olduğunu varsayalım, geçen kullanıcı kimliğiyle ilgili bilgilerin bir haritasını döndürür. Artık bu işlev, üç farklı türde harita üretmek için kaynak-a, kaynak-b ve kaynak-c olmak üzere 3 işlevi kullanır. Şimdi tüm bu haritaları tek bir haritada birleştirip get-data'dan döneceğiz.

get-data'yı test ettiğimdeAnahtarlar için veri kullanılabilirliğini kontrol etmeli miyim? Source-a, source-b ve source-c'den biri başarısız olursa bu işlevin birim testlerinde başarısız olması mantıklı mı? Eğer bu fonksiyonun görevi veriyi birleştirmekse ki öyle de oluyor, bu yeterli olmalı, değil mi?

1

2 cevap

Aktarılan kullanıcı kimliğiyle ilgili bilgilerin haritasını döndüren bir get-data fonksiyonunun olduğunu varsayalım.

Harika. O zaman kontrol etmelisin. Belirli bir kimlik için doğru verileri mi döndürüyorsunuz?

artık bu işlev, üç farklı türde harita üretmek için kaynak-a, kaynak-b ve kaynak-c olmak üzere 3 işlevi kullanıyor.

Testte hangi uygulama ayrıntısını göz ardı etmelisiniz? Test ettiğiniz tek şey, iş biriminizin (bu yöntem) yapması gerekeni yapmasıdır (bir kimlik alın ve bu kimlik için XYZ verilerini döndürün). Nasıl bu yöntem gerçekten önemli değil - sonuçta, bu birim testinin en önemli yararı, yöntemin uygulamasını yeniden düzenleyebilmeniz ve testin bunu doğru yapıp yapmadığınızı kontrol etmesidir.

Ancak muhtemelen veri kaynaklarıyla dalga geçmeniz gerekecek, dolayısıyla bir noktada testin muhtemelen bu kodun nasıl çalıştığını bilmesi gerekecektir. Burada birbirine rakip üç hedefi dengelemeniz gerekiyor: testi izole etmek (verilerle alay ederek), testin gereksinimlere ve pragmatizme odaklanmasını sağlamak.

Sonuçta bu önemli bir kod. Gerçek kodu destekleyen testler var, çok zaman harcanıyor ve cilayı kontrol etme zorluğu testler kadar kullanışlı değil yapımı .

Birim testinde yalnızca bir sınıfın işlevselliğini test etmelisiniz, eğer kaynak-a, kaynak-b ve kaynak-c yöntemleriniz diğer sınıfları çağırıyorsa, onlarla alay etmelisiniz (bunlar kendi sınıflarında birim testine tabi tutulmalıdır).

Entegrasyon testinde, aralarında etkileşim kuran birden fazla sınıfın davranışını test ediyorsunuz; bu, get-data işlevinizin, alınan verilerin doğru olduğunu kontrol etmesi gerektiği anlamına gelir (kaynak-a, kaynak-b ve kaynak-c'nin doğru olduğunu ve Verilerin doğru şekilde bağlandığından emin olun).

Birim testleri daha basit ve daha odaklıdır ve geliştiriciler tarafından yazılmalıdır. Entegrasyon testleri genellikle nispeten hızlı bir şekilde güncelliğini yitirir (varsa) dahili bileşen değiştirilmiştir), bunların gerçekleştirilmesi daha zor hale gelmektedir. Bir QA profili tarafından oluşturulmalıdır.

Bir çökmeden sonra programı yarım saat içinde 18 kez yeniden başlatabilecek ve ancak bundan sonra monitörü doğrudan pencereye atabilecek kadar hoşgörülü olsanız bile, bu programla çalışmanın "çökmemesi" durumunda daha rahat olacağını kabul edeceksiniz. ” .

Geliştirdiğiniz programın çökmesi, donması veya gerekli eylemlerin gerçekleştirilememesi durumlarının çok nadir hale gelmesini nasıl sağlayabilirsiniz?

Bu sorunun kesin bir cevabı yok. Ancak yüzyıllar boyunca, en bilge bilim adamları bu konu hakkında yıllarca düşündüler ve tüm program hatalarını ortadan kaldırmazsa, en azından onları ortadan kaldıracak eylem yanılsamasını yaratan bir çare bulmayı başardılar.

Ve bu çarenin adı Yazılım ürününün TEST EDİLMESİ.

Bilge insanlara göre Test, yazılım geliştirmenin kalitesini sağlamanın en köklü yollarından biridir ve modern bir yazılım ürünü kalite güvence sisteminin etkili araçları arasında yer alır.

Bir yazılım ürününün kalitesi, ürünün müşterisi, sponsoru, son kullanıcısı, ürün geliştiricileri ve test uzmanları, destek mühendisleri, pazarlamacılar gibi paydaşların bakış açısından ne kadar "iyi" olduğunu belirleyen bir dizi özellik ile karakterize edilir. , eğitim ve satış personeli. Katılımcıların her biri ürünün ne kadar iyi ya da kötü olduğu, yani ürünün kalitesinin ne kadar yüksek olduğu konusunda farklı bir fikre sahip olabilir. Bu nedenle, ürün kalitesini sağlama sorununun belirlenmesi, paydaşların, onların kalite kriterlerinin belirlenmesi ve daha sonra bu kriterleri karşılayan en uygun çözümün bulunması göreviyle sonuçlanır.

Ne zaman ve kim?

Deneyimli geliştiricilere göre, bir yazılım ürününün testi, yaratıldığı andan itibaren gerçekleştirilmelidir. Ancak aynı zamanda deneyimli geliştiricilerin kendileri de testlerde yer almamalıdır çünkü bu kraliyet meselesi değildir. Yazılım ürününün test uzmanı adı verilen özel eğitimli çalışanlar tarafından test edilmesi gerekir, çünkü en deneyimli geliştirici bile en yeni optik cihazları kullansa bile hatasını göremeyecektir.

Ancak tüm geliştiriciler, bir yazılım ürününün amaca göre sınıflandırma açısından test edilmesinin iki sınıfa ayrılması gerektiği konusunda hemfikirdir:

• Fonksiyonel test
• İşlevsel olmayan testler

Fonksiyonel test

İşlevsel test, bir yazılım ürününün, bu ürünün oluşturulmasına ilişkin teknik özelliklerde belirtilen işlevsel gereksinimlere uygunluğunu kontrol etmek anlamına gelir. Basitçe ifade etmek gerekirse fonksiyonel test, yazılım ürününün yapması gereken tüm fonksiyonları yerine getirip getirmediğini kontrol eder.

Sonunda işlevsel testler yapmaya karar verdiniz. Teknik spesifikasyona bakarsınız, işlevsel gereklilikleri okursunuz ve en azından bunların testin yapılabileceği sırayla olmadığını anlarsınız. Başkalarının uzun zaman önce bu tutarsızlığı fark edip bunun nasıl üstesinden gelebileceklerini bulmalarına şaşıracaksınız.

İşlevsel testleri gerçekleştirmek için teknik kontrol departmanı personeli, uygulamanın (API) işlevselliğini test etmek için bir belge programı ve metodoloji geliştiriyor. PMI belgesi, adımların ayrıntılı bir açıklamasını içeren yazılım ürünü test senaryolarının (test senaryolarının) bir listesini içerir. Test senaryosunun her adımı, kullanıcının (test uzmanı) eylemleri ve beklenen sonuçlar (programın bu eylemlere verdiği yanıt) ile karakterize edilir. Test programı ve metodolojisi, yazılım ürününün çalışmasını gerçek modda simüle etmelidir. Bu, test senaryosunun, sistemin gelecekteki kullanıcılarının gerçekleştireceği işlemlerin analizi temelinde oluşturulması gerektiği ve yalnızca geliştiricinin anlayabileceği, yapay olarak derlenmiş bir manipülasyon dizisi olmaması gerektiği anlamına gelir.

Tipik olarak fonksiyonel testler iki seviyede gerçekleştirilir:

• Bileşen (birim) testi. Bir yazılım ürününün ayrı ayrı bileşenlerinin özelliklerine, amaçlarına ve işlevsel özelliklerine odaklanılarak test edilmesi.
• Entegrasyon testi. Bu tür testler, bileşen testinden sonra gerçekleştirilir ve çeşitli alt sistemlerin kontrol akışları ve veri alışverişi düzeyindeki etkileşimindeki kusurları tanımlamayı amaçlar.

İşlevsel olmayan testler

İşlevsel olmayan test, bir yazılım ürününün ergonomi veya performans gibi niteliklerini değerlendirir.

Bu tür testlerin öneminin açık olduğunu ve gerekçe gerektirmediğini düşünüyorum. Sonuçta herkes, örneğin sistem performansı yeterli değilse, kullanıcıların eylemlerine yanıt almak için yarım gün beklemeleri gerekeceğini ve bunun toplu hazırda bekletme moduna yol açabileceğini anlıyor.

Adından da anlaşılacağı gibi, işlevsel olmayan test, bir yazılım ürününün, oluşturulmasına ilişkin teknik özelliklerdeki işlevsel olmayan gereksinimlerle uyumluluğunu kontrol eder. Fonksiyonel testlerde olduğu gibi, fonksiyonel olmayan testler için de bir test programı ve metodolojisi geliştirilir.

Çevik Çağda Gömülü Yazılım Testi ve Uyumluluk

Endüstri standartlarına uyum, ihmal edebileceğiniz veya sonradan yapabileceğiniz bir şey değildir; gömülü yazılım (yazılım) geliştirme sürecinin ayrılmaz bir parçasıdır. Havacılık elektroniği, otomotiv ve sağlık hizmetleri gibi bazı endüstriler için, karmaşık ve sorunsuz gömülü sistemlerin geliştirilmesinde kalite standartlarına sıkı sıkıya bağlı kalmak, bir ürünün pazara sunulması açısından hayati öneme sahiptir. Geleneksel olarak testler, standartların düzenlediği endüstriler için gömülü sistemlerin geliştirilmesinde önemli bir rol oynamıştır. Ancak son yıllarda yerleşik test uygulamaları ve süreçleri, bunların bu tür projelerdeki yeri ve rolü önemli ölçüde değişti. Bu oyunun kurallarını değiştiren bir olaydı ve oyunun kuralları değiştiğinde kazanmak için siz de onlarla birlikte değişmek zorundasınız.

Yeni ve ileri teknolojilerin sürekli gelişmesiyle birlikte şirketlerin, hızla değişen teknolojik dünyada kaybolmamak için güvenilir, emniyetli, kullanımı kolay ve diğer sistemlerle uyumlu ürünleri hızla pazara sunmaları gerekiyor. Böyle bir durumda yazılım geliştirme sürecinin kesinlikle sıralı olduğu ve testlerin en sonunda yapıldığı geleneksel şelale modeli geçmişte kalıyor. DevOps ve Agile yöntemleri, mühendislerin daha önce birbirini takip eden görevleri eş zamanlı olarak tamamlamasına olanak tanıdığı için giderek daha popüler hale geliyor.

Performans testi

Performans testi aşamasında ilk adım, sistemin dış etkilere gerçek hayattaki çalışmaya yakın bir modda yeterince tepki verip vermeyeceğini kontrol etmek olan yük testidir.

Yük testine ek olarak, testler minimum donanım ve maksimum yük - stres testi koşulları altında ve ayrıca maksimum hacimde işlenmiş bilgi - hacimsel test koşulları altında testler gerçekleştirilir.

Başka bir test türü daha vardır: stabilite ve güvenilirlik testi, bir yazılım ürününün normal koşullar altında yalnızca uzun vadeli testini değil aynı zamanda kısa süreli stresli yüklerden sonra normal çalışmaya dönme yeteneğini de içerir.

Test için belgeler

Yukarıda belirtildiği gibi testler, GOST 34.603-92'ye uygun olarak geliştirilen program ve test metodolojisine uygun olarak gerçekleştirilir.

Testi gerçekleştirmek için, yazılım ürününün tüm çalışma modlarını test etmek için yeterli veri içermesi gereken bir test senaryosu geliştirilir. Tipik olarak, müşteri ve yüklenici tarafından gerçek verilere dayalı olarak ortak bir test senaryosu oluşturulur.

Her türlü performans testini gerçekleştirmek için, çoğunlukla, performansı değerlendirirken objektif bir sonuç elde etmek için yeterli miktarda veriyi otomatik olarak oluşturmanıza olanak tanıyan bir veri oluşturucu oluşturulur.

Test sırasında, tüm aşamaların tamamlanması ve testin adımları ve test sırasında alınan yorumlar hakkında bilgi içeren bir test protokolü hazırlanır.

Test sonucunun olumsuz olması durumunda eksiklikler düzeltilerek tekrar test yapılır.

Araştırma testi

Keşif testleri (özel amaçlı testler, fonksiyonel testlerin bir alt türüdür. Açık dokümantasyon ve gereksinimlerin bulunmadığı, esnek geliştirme yöntemleriyle hızlı büyüyen projelerde kullanılır. Keşif testi, yazılım testindeki en yüksek akrobasi testidir. Kalitatif testler, yüksek nitelikli uzmanlar ve neredeyse tamamen sanatçıya, onun deneyimine, bilgisine (hem konu alanında hem de test yöntemlerinde) ve hızla öze ulaşma yeteneğine bağlıdır.

Stres testi

Yük testi, test edilen sistemin yük altında performansını analiz etme işlemidir. Yük testinin amacı, uygulamanın dış yüklere dayanma yeteneğini belirlemektir. Tipik olarak testler birkaç aşamada gerçekleştirilir.

1. Test komut dosyalarının oluşturulması

Etkili analiz için senaryoların gerçek kullanım senaryolarına mümkün olduğunca yakın olması gerekir. İstisnaların her zaman mümkün olduğunu ve en ayrıntılı test planının bile tek bir durumu kapsamayabileceğini anlamak önemlidir.

2. Bir test konfigürasyonunun geliştirilmesi

Test senaryolarına sahip olmak, artan yükün sırasını dağıtmak önemlidir. Başarılı bir analiz için performans değerlendirme kriterlerinin (yanıt hızı, talep işleme süresi vb.) belirlenmesi gerekir.

3. Bir test testinin yapılması

Testleri gerçekleştirirken senaryoların yürütülmesini ve test edilen sistemin tepkisini zamanında izlemek önemlidir. Yüksek yükleri taklit etmek ciddi donanım ve yazılım altyapısı gerektirir. Bazı durumlarda işin maliyetini azaltmak için matematiksel modelleme yöntemlerinden yararlanılmaktadır. Düşük yüklerde elde edilen veriler esas alınır ve yaklaşık değerler alınır. Simüle edilen yük düzeyi ne kadar yüksek olursa, tahminin doğruluğu da o kadar düşük olur. Ancak bu yöntem maliyetleri önemli ölçüde azaltır.

Test otomasyonu

Otomatik testin ana özelliği, regresyon testlerini hızlı bir şekilde yürütme yeteneğidir. Otomasyonun ana avantajları (Worksoft'un bir raporuna göre) artan personel verimliliği, kusurların erken tespiti ve iş süreçlerinin daha yüksek kalitesidir. Bu avantajlar önemli bir dezavantajla dengeleniyor: yüksek maliyet - test otomasyonunu uygulama ve destekleme maliyetinin yüksek olması nedeniyle şirketlerin yaklaşık %50'si hâlâ çoğunlukla manuel testleri kullanıyor.

Kullanılabilirlik testi

Herhangi bir uygulama kullanılmak üzere oluşturulur. Kullanım kolaylığı bir programın önemli bir kalite göstergesidir. BT sektörü, başarılı bir kullanılabilirlik düzeltmesinden sonra ortaya çıkan birçok proje örneğini biliyor. Hedef kitle ne kadar geniş olursa kullanılabilirlik faktörü de o kadar önemli olur. Kullanılabilirlik testi, kullanıcı davranışının ayrıntılı analizini içerir. Ergonomiyi değerlendirmek için yalnızca bir iş görevini tamamlama hızına ilişkin değil, aynı zamanda kullanıcının duygularına, yüz ifadelerine ve ses tonuna ilişkin verilere sahip olmak da önemlidir.

Yapılandırma testi

Konfigürasyon testi, uygulamanın farklı platformlarda ve dolayısıyla maksimum sayıda kullanıcı için çalışacağına dair güven verir. WEB uygulamaları için genellikle tarayıcılar arası test seçilir. Windows uygulamaları için - çeşitli işletim sistemlerinde ve bit hızlarında (x86, x64) testler. Konfigürasyon testinin önemli bir bileşeni test altyapısıdır: testleri gerçekleştirmek için sürekli olarak bir test makinesi filosuna sahip olmanız gerekir. Sayıları 5 ile birkaç düzine arasında değişmektedir.

Entegrasyon testi

Projenizde birden fazla bileşen varsa entegrasyon testine ihtiyaç vardır. Karmaşık bir uygulama mimarisiyle kalite güvencesi için gerekli bir koşul, program parçalarının etkileşiminin kontrol edilmesidir. Test, “uçtan uca” vakaların geliştirilmesi ve yürütülmesi yoluyla gerçekleştirilir. Entegrasyon testi, bileşen testinden sonra gerçekleştirilir. Bu nedenle, test senaryolarının iş yönelimine saygı gösterirken bileşen testi deneyimini de hesaba katmak çok önemlidir.

Stres testi

Her sistemin normal işleyişinin bir sınırı vardır. Limit aşıldığında sistem stres durumuna girer ve davranışını önemli ölçüde değiştirir. Stres testi, bir uygulamanın normal çalışma sınırlarını aşan koşullar altında çalışmasını test eder. Bu özellikle “kritik” programlar için önemlidir: bankacılık yazılımı, havacılık endüstrisi programları, tıp. Stres testi, yalnızca yazılım geliştirme aşamasında değil, aynı zamanda sistem davranış verilerinin uzun bir süre boyunca elde edilmesi ve işlenmesi amacıyla tüm çalışma döngüsü boyunca gerçekleştirilir.

Tüm türler arasında işlevsel testler haklı olarak lider konumdadır, çünkü programın her şeyden önce doğru çalışması gerekir, aksi takdirde kullanım kolaylığı, güvenlik ve yeterli hız kesinlikle hiçbir işe yaramayacaktır. Her uzmanın, çeşitli test tekniklerine hakim olmanın yanı sıra, en etkili sonucu elde etmek için bir testin nasıl düzgün bir şekilde yürütüleceğini anlaması gerekir.

Fonksiyonel testler: Ana çabalar nereye yönlendirilmeli?

Birim ve sistem testleri için;

“Beyaz” veya “siyah” kutucuğu işaretlemek için;

Manuel test ve otomasyon için;

Yeni işlevselliği test etmek veya;

“Negatif” veya “pozitif” testler için.

Tüm bu faaliyet alanları arasında, her alanın avantajlarını maksimumda kullanarak çabaları dengelemek için “orta” olacak doğru yolu bulmak önemlidir.

Yazılım doğrulaması yapılıyor Farklı yollar Bunlardan biri kara kutu veya veriye dayalı testtir.

Bu durumda program bir "kara kutu" bakış açısından sunulur ve programın davranışının spesifikasyona uymayacağı koşulları belirlemek için test yapılır. Tüm hatalar, kapsamlı testlerle, yani mümkün olan tüm yöntemler kullanılarak gerçekleştirilen veri yönetimi yoluyla tanımlanır.

Bir program için bir komutun yürütülmesi kendisinden önceki olaylara bağlıysa, bu durumda tüm olası sıraların kontrol edilmesi gerekecektir. Çoğu durumda kapsamlı testler yapmanın imkansız olduğu oldukça açıktır, bu nedenle çoğu zaman programı tüm girdi verilerinin küçük bir alt kümesinde çalıştırmakla sınırlı olan kabul edilebilir veya makul bir seçeneği seçerler. Bu seçenek spesifikasyonlardan sapma olmayacağını tam olarak garanti eder.

Fonksiyonel testler doğru testi seçmeyi içerir. Aynı zamanda, onlar için set oluşturmak için aşağıdaki yöntemler arasında ayrım yapmak gelenekseldir:

Sınır değer analizi;

Eşdeğer bölüm;

Hata varsayımı;

Sebepler ve sonuçlar arasındaki bağlantıların analizi.

Her birini ayrı ayrı değerlendirebilirsiniz.

Sınır değer analizi. Sınır değerleri genellikle eşdeğerlik sınıflarının sınırlarında yer alan değerler olarak anlaşılır. Bu tür yerlerde hata bulma olasılığı yüksektir. Böyle bir yöntemin kullanılması, uzmanın belirli bir yaratıcılığının yanı sıra, söz konusu spesifik problemde uzmanlaşmasını da gerektirir.

Eşdeğer bölüm. Tüm olası giriş parametresi setleri çeşitli eşdeğerlik sınıflarına bölünmüştür. Veriler benzer hataların tespit edilmesi prensibine göre birleştirilir. Genel olarak, bir sınıftan oluşan bir kümenin bir hata göstermesi durumunda, eşdeğer olanların da bunu göstereceği kabul edilir. tarafından fonksiyonel testler Bu method iki aşamada gerçekleştirilir: ilkinde eşdeğerlik sınıfları belirlenir ve ikincisinde özel testler zaten oluşturulur.

Sebep-sonuç ilişkilerinin analizi. Sistem bu kontrolleri yaparak performansı yüksek testleri seçebilmektedir. Bu durumda ayrı bir giriş koşulu neden olarak alınır, çıkış koşulu ise sonuç olarak görülür. Yöntem, her türlü nedeni belirli sonuçlara bağlama fikrine, yani aynı neden-sonuç ilişkilerini açıklığa kavuşturmaya dayanmaktadır. Bir yazılım ürününün testi birkaç aşamada gerçekleştirilir ve bunun sonucunda nedenlerin ve sonuçların bir listesi ortaya çıkar.

• geliştiricilerin çalışma standartlarından veya uygulama planlarından kasıtsız sapmaları;
• işlevsel ve arayüz gereksinimlerinin spesifikasyonlarının geliştirme standartlarına uyulmadan yapılması, programların işleyişinin bozulmasına yol açar;
• geliştirme sürecinin organizasyonu - proje yöneticisinin kaynaklarının (insan, teknik, yazılım vb.) kusurlu veya yetersiz yönetimi ve proje öğelerinin test edilmesi ve entegrasyonu ile ilgili sorunlar.

ISO/IEC 12207 standardının tavsiyelerine dayanarak test sürecine bakalım ve her yaşam döngüsü sürecinde tespit edilen hata türlerini verelim.

Gereksinim Geliştirme Süreci. Analistler, sistemin başlangıç ​​konseptini ve sistemin başlangıç ​​gereksinimlerini belirlerken spesifikasyon hataları yaparlar. Üst düzey sistemler ve konu alanının kavramsal bir modelinin oluşturulması.

Bu süreçteki tipik hatalar şunlardır:

• son kullanıcılar için gereklilik spesifikasyonunun yetersizliği; - yazılımın işletim ortamı veya kullanıcılarla etkileşiminin yanlış spesifikasyonu;
• bireysel ve genel yazılım özelliklerine ilişkin müşteri gereksinimlerine uyulmaması;
• fonksiyonel özelliklerin yanlış tanımlanması;
• Müşteri gereksinimlerinin uygulanmasına ilişkin tüm hususlara yönelik araçların mevcut olmaması vb.

Dizayn süreci Algoritmalar, kontrol mantığı, veri yapıları, arayüzler, veri akışı modelleme mantığı, giriş-çıkış formatları vb. açıklanırken bileşenlerin tasarımında hatalar meydana gelebilir. Bu hatalar analist spesifikasyonlarındaki kusurlara ve tasarım kusurlarına dayanmaktadır. Bunlar aşağıdakilerle ilgili hataları içerir:

• kullanıcı arayüzünün çevre ile tanımlanmasıyla;
• işlevlerin bir açıklamasıyla (bir dizi bileşeni kontrol ederken keşfedilen bileşenlerin amaç ve hedeflerinin yetersizliği);
• bilgi işlem sürecinin tanımı ve süreçler arasındaki etkileşim (bileşenler ve süreçler arasındaki ilişkilerin yanlış belirlenmesi sonucu);
• bireysel bileşenleri ve bir bütün olarak yazılımı tanımlarken verilerin ve yapılarının yanlış belirtilmesi;
• modül algoritmalarının yanlış tanımlanmasıyla;
• meydana gelme koşullarının belirlenmesi ile olası hatalar bir programda;
• proje için benimsenen standartları ve teknolojileri ihlal ediyor.

Kodlama aşaması.Bu aşamada, sistemin geliştirilmesi ve hata ayıklaması sırasında tasarım kusurlarından, programcıların ve yöneticilerin hatalarından kaynaklanan hatalar ortaya çıkar. Hataların nedenleri şunlardır:

• giriş parametreleri, dizi indeksleri, döngü parametreleri, çıktı sonuçları, 0'a bölme vb. değerleri üzerinde kontrol eksikliği;
• çağrılan alt programlardan, işlevlerden vb. gelen dönüş kodlarını analiz ederken düzensiz durumların yanlış ele alınması;
• Kodlama standartlarının ihlali (kötü yorumlar, mantıksız modül tahsisi ve bileşen vb.);
• farklı nesneleri veya bir nesnenin farklı adlarını belirtmek için bir adın kullanılması, kötü ad anımsatıcıları; - farklı geliştiriciler tarafından programda yapılan tutarsız değişiklikler, vb.

Test süreci Bu süreçte programcılar ve testçiler tarafından montaj ve test teknolojisi uygulanırken, test setlerinin ve test senaryolarının seçilmesinde vb. hatalar yapılır. Bu tür hataların yazılımda neden olduğu hatalar belirlenmeli, ortadan kaldırılmalı ve bileşen ve bileşen istatistiklerini etkilememelidir. genel olarak yazılım hataları.

Bakım süreci.Bakım süreci sırasında, operasyonel dokümantasyondaki eksiklikler ve kusurlardan, değiştirilebilirlik ve okunabilirlik göstergelerinin yetersiz olmasından ve ayrıca yazılımın bakımı ve/veya geliştirilmesinden sorumlu kişilerin yetersizliğinden kaynaklanan hatalar keşfedilir. Yapılan değişikliklerin niteliğine bağlı olarak, daha önceki aşamalarda listelenen hatalara benzer hemen hemen her türlü hata bu aşamada ortaya çıkabilir.

Programlarda meydana gelen tüm hatalar genellikle aşağıdaki sınıflara ayrılır [7.12]:

• mantıksal ve işlevsel hatalar;
• hesaplama ve çalışma zamanı hataları;
• giriş/çıkış ve veri işleme hataları;
• arayüz hataları;
• veri hacmi hataları vb.

Mantıksal hatalar algoritmanın mantığının ihlalinin, değişkenlerin ve operatörlerin iç tutarsızlığının yanı sıra programlama kurallarının nedenidir. İşlevsel hatalar, yanlış tanımlanmış işlevlerin, uygulama sırasının ihlalinin veya uygulamalarının tam olmamasının vb. bir sonucudur.

Hesaplama hataları kaynak verilerin ve uygulanan formüllerin yanlışlığı, yöntem hataları, hesaplama işlemlerinin veya işlenenlerin yanlış uygulanması nedeniyle ortaya çıkar. Çalışma zamanı hataları, gerekli istek işleme hızının veya program kurtarma süresinin sağlanamamasıyla ilişkilidir.

G/Ç hataları ve veri manipülasyonu, programın yürütülmesi için verilerin düşük kalitede hazırlanmasının, bunları veritabanlarına girerken veya ondan alırken yaşanan hataların bir sonucudur.

Arayüz hataları bireysel elemanların birbirleriyle ilişkilerindeki, aralarında veri aktarımı sırasında ve ayrıca işletim ortamıyla etkileşim sırasında kendini gösteren hataları ifade eder.

Birim hataları verilerle ilgilidir ve uygulanan erişim yöntemlerinin ve veri tabanı boyutlarının, sistem bilgisinin gerçek hacimlerini veya bunların işlenmesinin yoğunluğunu karşılamamasının bir sonucudur.

Verilen ana hata sınıfları, farklı türdeki yazılım bileşenlerinin karakteristiğidir ve programlarda kendilerini farklı şekillerde gösterirler. Böylece bir veritabanıyla çalışırken veri sunumunda ve manipülasyonunda hatalar meydana gelir, mantıksal hatalar uygulanan veri işleme prosedürlerini vb. belirlerken. Hesaplamalı programlarda hesaplama hataları baskındır ve kontrol ve işleme programlarında mantıksal ve işlevsel hatalar baskındır. Farklı işlevleri uygulayan birçok farklı programdan oluşan yazılım, hatalar içerebilir. farklı şekiller. Arayüz hataları ve birim ihlalleri her tür sistem için tipiktir.

Programlardaki hata türlerinin analiz edilmesi, yazılımın doğruluğunu sağlamak amacıyla test planları ve test yöntemleri oluşturmanın ön koşuludur.

Yazılım geliştirme destek araçlarının (CASE teknolojileri, nesne yönelimli yöntemler ve model ve program tasarlama araçları) geliştirilmesinin mevcut aşamasında, yazılımın en yaygın hatalardan korunduğu ve böylece ortaya çıkmasını önleyen bir tasarım gerçekleştirilir. yazılım kusurları.

Hata ve başarısızlık arasındaki ilişki.Bir programda bir hatanın varlığı, kural olarak, yazılımın çalışması sırasında arızalanmasına yol açar. "Hata-başarısızlığın" neden-sonuç ilişkilerini analiz etmek için aşağıdaki eylemler gerçekleştirilir:

• tasarım ve programlama teknolojilerindeki kusurların belirlenmesi;
• tasarım sürecindeki kusurlarla insan hataları arasındaki ilişki;
• arızaların, kusurların ve olası hataların yanı sıra geliştirmenin her aşamasındaki kusurların sınıflandırılması; - belirli bir geliştirme sürecinde yapılan insan hatalarının ve proje spesifikasyonundaki, program modellerindeki hataların bir sonucu olarak nesnedeki kusurların karşılaştırılması;
• yaşam döngüsünün tüm aşamalarında doğrulama ve hata korumasının yanı sıra geliştirmenin her aşamasında kusurların tespiti;
• arızalar ve kusurlarla ilgili bilgilerin yerelleştirilmesi, toplanması ve analiz edilmesi için bir ara bağlantı sistemi ve yöntemleri geliştirmek amacıyla yazılımdaki kusurların ve arızaların karşılaştırılması;
• Yazılımın belgelenmesi ve test edilmesi süreçlerine yönelik yaklaşımların geliştirilmesi.

Hata-başarısızlık nedenselliğinin nihai amacı, belirli sınıfların hatalarını test etmek ve tespit etmek için yöntem ve araçların yanı sıra birden fazla veri kümesinde testi tamamlama kriterlerini tanımlamaktır; yazılım geliştirme, test etme ve bakım sürecinin organizasyonunu iyileştirmenin yollarını belirlemede.

Aşağıda arıza türlerinin sınıflandırılması verilmiştir:

• sistem çapındaki yazılımın çalışmadığı donanım;
• giriş verilerindeki ve iletişim kanalları aracılığıyla veri aktarımındaki hataların yanı sıra giriş cihazlarının arızasından (donanım arızalarının bir sonucu) kaynaklanan bilgilendirme amaçlı;
• operatörün makineyle etkileşimi sırasında yaptığı hatalardan kaynaklanan ergonomik (bu arıza ikincil bir arızadır ve bilgi veya işlevsel arızalara yol açabilir);
• yazılım, bileşenlerde hatalar vb. varsa.

Bazı hatalar gereksinim tanımı, tasarım, çıktı kodu oluşturma veya dokümantasyondaki eksikliklerin sonucu olabilir. Öte yandan, bir programın geliştirilmesi sırasında veya bireysel program öğelerinin arayüzlerinin geliştirilmesi sırasında üretilirler (parametre sırasının ihlali, daha az veya daha fazla parametre vb.).

Hata kaynakları.Projenin, bileşenlerin, kodun ve dokümantasyonun geliştirilmesi sırasında hatalar üretilebilir. Kural olarak, yazılımın yürütülmesi veya bakımı sırasında en beklenmedik ve farklı noktalarda keşfedilirler.

Bir programdaki bazı hatalar, gereksinim tanımı, tasarım, kod oluşturma veya dokümantasyondaki eksikliklerin sonucu olabilir. Öte yandan, bir programın veya öğelerinin arayüzlerinin geliştirilmesi sırasında hatalar üretilir (örneğin, iletişim parametrelerini ayarlama sırası ihlal edildiğinde - gerekenden daha az veya daha fazla vb.).

Hataların nedeni müşteri gereksinimlerinin anlaşılmamasıdır; proje belgelerinde gereksinimlerin yanlış belirtilmesi vb. Bu, müşteri tarafından önerildiği gibi çalışmayacak bazı sistem fonksiyonlarının uygulanmasına yol açar. Bu bağlamda, gereksinimlerin bazı ayrıntılarının açıklığa kavuşturulması için müşteri ile geliştirici arasında ortak bir tartışma yürütülür.

Sistem geliştirme ekibi ayrıca sistem açıklamasının sözdizimini ve anlambilimini de değiştirebilir. Ancak bazı hatalar tespit edilemeyebilir (örneğin bu ifadelerin indeksleri veya değişken değerleri yanlış ayarlanmış).