Entegrasyon testi. Testleri geçmek için bir yazılım ürününün geliştirilmesi

Dipnot: Ders, doğrulama sürecinin seviyelerini kapsayan üç dersten ikincisidir. Bu dersin konusu entegrasyon testi süreci, görevleri ve hedefleridir. Entegrasyon testinin organizasyonel yönleri dikkate alınır - entegrasyon testi yöntemlerinin yapısal ve zamansal sınıflandırmaları, entegrasyon testinin planlanması. Bu dersin amacı: Entegrasyon testi süreci, teknik ve organizasyonel bileşenleri hakkında fikir vermek

20.1. Entegrasyon testinin amaçları ve hedefleri

Yazılım sistemini oluşturan bireysel modüllerin test edilmesi ve doğrulanmasının sonucu, bu modüllerin kendi içinde tutarlı olduğu ve gereksinimlere uygun olduğu sonucuna varılmalıdır. Ancak bireysel modüller nadiren kendi başlarına çalışır, bu nedenle bireysel modülleri test ettikten sonraki görev, tek bir bütün halinde birleştirilen birkaç modülün doğru etkileşimini test etmektir. Bu tür testlere denir entegrasyon. Amacı doğruluğu sağlamaktır. işbirliği sistem bileşeni.

Entegrasyon testi ayrıca denir sistem mimarisi testi. Bir yandan bu isim, entegrasyon testlerinin yazılım modülleri ve sistem mimarisinde tanımlanan öğeler arasındaki olası tüm etkileşim türlerinin kontrollerini içermesinden kaynaklanmaktadır - dolayısıyla entegrasyon testleri kontrolü bütünlük test edilen sistem uygulamasındaki etkileşimler. Öte yandan entegrasyon testlerinin sonuçları, sistem mimarisinin, modüller arası ve bileşenler arası arayüzlerin iyileştirilmesi ve netleştirilmesi süreci için ana bilgi kaynaklarından biridir. Yani bu açıdan bakıldığında entegrasyon testleri kontrol edilmektedir. doğruluk Sistem bileşenlerinin etkileşimi.

Etkileşimin doğruluğunu kontrol etmenin bir örneği, biri alınan dosyalar hakkındaki protokol mesajlarını toplayan ve ikincisi bu protokolü ekranda görüntüleyen iki modül olabilir. Sistemin işlevsel gereksinimleri, mesajların ters kronolojik sırada görüntülenmesi gerektiğini belirtir. Bununla birlikte, mesaj depolama modülü bunları doğrudan sırayla saklar ve çıkış modülü, çıktı almak için yığını kullanır. ters sıra. Her modüle ayrı ayrı dokunan birim testlerinin burada hiçbir etkisi olmayacaktır; mesajların ters sırada saklandığı ve bir kuyruk kullanılarak çıktının alındığı tam tersi durum oldukça mümkündür. Potansiyel bir sorun ancak entegrasyon testleri kullanılarak modüllerin etkileşimi kontrol edilerek tespit edilebilir. Anahtar nokta burada sistem bir bütün olarak mesajları ters kronolojik sırayla yayınlar; yani çıkış modülünü kontrol edip mesajları ileri sırada çıkardığını tespit ettiğimizde, bir kusur tespit ettiğimizi garanti edemeyiz.

Entegrasyon testlerinin yapılması ve tespit edilen tüm kusurların giderilmesi sonucunda yazılım sisteminin tutarlı ve bütünsel bir mimarisi elde edilir; bunu varsayabiliriz entegrasyon testi mimariyi ve düşük seviyeli işlevsel gereksinimleri test ediyor.

Entegrasyon testi Kural olarak, giderek artan sayıda modül kümesinin işlevselliğinin test edildiği yinelemeli bir süreçtir.

20.2. Entegrasyon testinin organizasyonu

20.2.1. Entegrasyon test yöntemlerinin yapısal sınıflandırması

Kural olarak entegrasyon testi, tüm entegre modüller için birim testinin tamamlanmasından sonra gerçekleştirilir. Ancak bu her zaman böyle değildir. Entegrasyon testini gerçekleştirmenin birkaç yöntemi vardır:

• aşağıdan yukarıya test;
• monolitik test;
• yukarıdan aşağıya test.

Bu tekniklerin tümü, genellikle yapı diyagramları veya işlev çağrı diyagramları olarak gösterilen sistem mimarisi bilgisine dayanır. Böyle bir diyagramdaki her düğüm bir yazılım modülünü temsil eder ve aralarındaki oklar, modüller arasındaki çağrı bağımlılıklarını temsil eder. Entegrasyon test teknikleri arasındaki temel fark, bu diyagramlar boyunca hareketin yönü ve yineleme başına kapsamın genişliğidir.

Aşağıdan yukarıya test. Bu yöntemi kullanırken, sistemde bulunan tüm yazılım modüllerinin ilk önce test edildiği ve ancak daha sonra entegrasyon testi için birleştirildiği ima edilir. Bu yaklaşımla, hata lokalizasyonu büyük ölçüde basitleştirilmiştir: Modüller ayrı ayrı test edilirse, birlikte çalıştıklarında oluşan bir hata, arayüzlerinde bir sorun demektir. Bu yaklaşımla, test uzmanının sorun arama alanı oldukça dar olduğundan, bir kusuru doğru şekilde tespit etme olasılığı çok daha yüksektir.

Pirinç. 20.1.

Fakat, aşağıdan yukarıya yöntem testin önemli bir dezavantajı vardır - entegrasyon testini gerçekleştirmeden önce birim testi için bir sürücü ve saplamalar geliştirme ihtiyacı ve sistem modüllerinin bir kısmının entegrasyon testi sırasında bir sürücü ve saplamalar geliştirme ihtiyacı (Şekil 20.1)

Bir tarafta sürücüler ve fişler var - güçlü araçÖte yandan test edilmesi, özellikle entegre modüllerin bileşimi değiştiğinde, bunların geliştirilmesi önemli kaynaklar gerektirir; başka bir deyişle, her modülün birim testi için bir sürücü seti, entegrasyonun test edilmesi için ayrı bir sürücü ve taslaklar gerekebilir. setten iki modül, üç modülün entegrasyonunu test etmek için ayrı bir modül vb. Bunun temel nedeni, modül entegrasyonunun bazı taslaklara olan ihtiyacı ortadan kaldırması ve ayrıca birden fazla modülü etkileyen yeni testleri destekleyen bir sürücü değişikliği gerektirmesidir.

Monolitik test sistemin bireysel bileşenlerinin ciddi testlerden geçmediğini öne sürüyor. Ana avantaj bu yöntem- test ortamı, sürücüler ve taslaklar geliştirmeye gerek yok. Tüm modüller geliştirildikten sonra entegrasyonları gerçekleştirilir ve ardından sistem bir bütün olarak test edilir. Bu yaklaşım bir sonraki dersin konusu olan sistem testiyle karıştırılmamalıdır. Monolitik testin tüm sistemin çalışmasını bir bütün olarak kontrol etmesine rağmen, bu testin asıl görevi bireysel sistem modüllerinin etkileşimiyle ilgili sorunları belirlemektir. Sistem testinin görevi kaliteyi değerlendirmek ve niceliksel özellikler sistemlerin son kullanıcı tarafından kabul edilebilirliği açısından.

Monolitik testçok ciddi dezavantajları var.

• Hatanın kaynağını belirlemek (hatalı kod parçasını belirlemek) çok zordur. Çoğu modül bir hata olduğunu varsaymalıdır. Sorun, ilgili tüm modüllerdeki hatalardan hangisinin sonuca yol açtığını belirlemekle ilgilidir. Bu, hata etkilerine neden olabilir. Ayrıca bir modüldeki hata diğerinin test edilmesini engelleyebilir.
• Hata düzeltmelerini organize etmek zordur. Test sonucunda test uzmanı bulunan sorunu kaydeder. Bu soruna neden olan sistemdeki kusur geliştirici tarafından giderilecektir. Kural olarak test edilen modüller yazıldığı için farklı insanlar, bir sorun ortaya çıkıyor - kusurun bulunmasından ve ortadan kaldırılmasından hangisi sorumlu? Böyle bir "kolektif sorumsuzluk" ile kusurların giderilmesi oranı keskin bir şekilde düşebilir.
• Test süreci yeterince otomatikleştirilmemiştir. Avantaj (ek yok yazılım test sürecine eşlik etmesi) bir dezavantaj olarak ortaya çıkıyor. Yapılan her değişiklik tüm testlerin tekrarlanmasını gerektirir.

Yukarıdan aşağıya test Entegrasyon testi sürecinin gelişimi takip ettiğini varsayar. İlk olarak, sistemin yalnızca en üst kontrol seviyesi test edilir, daha fazla modül olmadan düşük seviye. Daha sonra yavaş yavaş alt seviyedekiler üst seviyedeki modüllerle bütünleştirilir. Bu yöntemin kullanılması sonucunda sürücülere gerek kalmaz (sürücünün rolü daha üst düzey bir sistem modülü tarafından gerçekleştirilir), ancak taslaklara olan ihtiyaç devam eder (Şekil 20.2).

Farklı test uzmanlarının, yazılım sistemlerinin gerçek testi için hangi yöntemin daha uygun olduğu konusunda farklı görüşleri vardır. Jordan bunu savunuyor yukarıdan aşağıya test içinde en kabul edilebilir gerçek durumlar Myers, her yaklaşımın kendine özgü avantajları ve dezavantajları olduğuna inanıyor ancak genel olarak aşağıdan yukarıya yöntem daha iyi.

Literatürde sıklıkla nesne yönelimli yazılım sistemlerinin entegrasyon testine yönelik bir yöntemden bahsedilmektedir; bu yöntem, birlikte bazı kapalı ve tam işlevselliğe sahip olan sınıf kümelerinin belirlenmesine dayanmaktadır. Özünde bu yaklaşım yeni bir tür entegrasyon testi değildir; yalnızca entegrasyondan kaynaklanan minimum unsuru değiştirir. Prosedürel programlama dillerinde modülleri entegre ederken, taslakların geliştirilmesi koşuluyla istediğiniz sayıda modülü entegre edebilirsiniz. Sınıfları kümelere entegre ederken küme işlevselliğinin bütünlüğü konusunda oldukça gevşek bir kısıtlama vardır. Ancak nesne yönelimli sistemlerde bile saplama sınıfları kullanılarak herhangi bir sayıda sınıfın entegrasyonu mümkündür.

Kullanılan entegrasyon testi yöntemi ne olursa olsun, entegrasyon testleri ile sistem işlevselliğinin kapsanma derecesinin dikkate alınması gerekir. Makalede, işlevler ve veri akışları arasındaki kontrol çağrılarına dayalı olarak kapsam derecesini değerlendirmek için bir yöntem önerildi. Bu değerlendirme ile sistem yapı şemasındaki tüm modüllerin kodu çalıştırılmalı (tüm düğümler kapsanmalıdır), tüm çağrılar en az bir kez yürütülmeli (yapı şemasındaki düğümler arasındaki tüm bağlantılar kapsanmalıdır), tüm çağrı dizileri en az bir kez yürütülmelidir (yapı şemasındaki tüm yollar kapsanmalıdır).

Yürütülebilir kodu test etmeden hiçbir yazılım geliştirme tamamlanmaz. Aslında toplam geliştirme süresinin yarısını ve proje maliyetinin yarısından fazlasını kaplıyor. Ancak bu, yeni uygulamalar, programlar ve sistemler oluşturma sürecinin ayrılmaz bir parçasıdır.

Büyük bir işin parçası olarak entegrasyon testi

Yazılım kalitesini kontrol etmenin yollarından biri, girdisinin önceki aşamada test edilen bireysel modüllerden alındığı entegrasyon testidir.

Her bir fonksiyon veya sınıfta yerelleştirilmiş hataları tanımlayan modüler seçeneğin aksine entegrasyon testi, arasındaki etkileşimin uygulanmasıyla ilişkili kusurların araştırılmasıdır. ayrı parçalar halindeürün oluşturdu. Entegrasyon fonksiyonel testi "beyaz kutu" yöntemini kullanır, yani kalite mühendisi her bir modülün metinlerine ve ayrıca bunlar arasındaki etkileşimin ilkelerine erişebilir ve bu metinler hakkında bilgi sahibi olabilir.

Modül montaj yöntemleri

Monolitik yöntem, gelecekte entegrasyon testine tabi tutulacak tüm modüllerin aynı anda bir araya getirilmesi anlamına gelir. Test edilen kompleksin bir kısmı henüz hazır olmadığında durumların ortaya çıkması neredeyse kesindir.

Bu durumda, ek olarak geliştirilmiş "taslaklar" veya sürücülerle değiştirilir.

Monolitik yöntemin yanı sıra, test edilen kodun hacmi kademeli olarak arttığından, tek tek parçalar arasındaki ilişkilerde kusurlu alanların lokalize edilmesini mümkün kılan artımlı bir yöntem de vardır (buna adım adım da denir).

Artımlı yöntem, modül eklemenin iki yolunu içerir:

• yukarıdan aşağıya veya artan,
• aşağıdan yukarıya - azalan.

Monolitik ve artımlı testlerin özellikleri

Monolitik montaj tipinin ana dezavantajı büyük sayı test edilen kompleksin eksik parçalarının simüle edilmesi için zaman ve işçilik maliyetleri harcanır. Taslakların oldukça kullanışlı bir test aracı olduğu anlaşılıyor, ancak süreçte programın simüle edilmiş bölümlerini yeniden oluşturmanın gerekli olduğu durumlar ortaya çıkıyor. Örneğin, test edilen modüllerin bileşimi değişirse. Ayrıca, iş gerçek bir ürünle değil, yalnızca hayali bir bileşenle yapıldığında kusur bulma verimliliği o kadar yüksek değildir. Aynı dezavantaj, aşağıdan yukarıya oluşturma yöntemiyle artan testlere de eşlik eder.

Aynı zamanda dezavantajlarından biri adım adım yöntem modüllerin belirli bir sırayla yürütülmesi için bir ortam düzenleme ve yaratma ihtiyacıdır. Üst ve alt seviyeleri paralel olarak geliştirmek de pratikte imkansızdır.

Elbette hem monolitik hem de artımlı montaj yöntemlerinin yalnızca dezavantajları değil aynı zamanda avantajları da vardır. İlk durumda, testte yer alan tüm sınıfların ve işlevlerin paralel olarak geliştirilmesi için mükemmel fırsatlar vardır. başlangıç ​​aşaması ve değişiklikten sonra. Adım adım yöntem daha az emek yoğundur: modüller yavaş yavaş eklenir ve hatalar ve kusurlar da yavaş yavaş keşfedilir. Bunun onları aramak için harcanan zamanı azalttığı biliniyor.

Entegrasyon Testinin Faydaları

Bu aşamada, tüm seviyelerdeki ilişkileri kontrol etmek için muazzam miktarda çalışma yürütülür ve bu olmadan daha fazla test elbette imkansızdır.

Yazılım entegrasyon testinin birçok avantajı vardır:

• bireysel program modülleri arasındaki etkileşim arayüzünün kontrol edilmesi;
• test edilen karmaşık ve üçüncü taraf yazılım çözümleri arasındaki ilişkilerin kontrolü;
• çözümün harici bileşenlerinin çalışmasının test edilmesi;
• bireysel modüllerin etkileşimi ile ilgili proje belgelerinin uyumluluğunun kontrolü.

Kusurların düzeltilmesi

Entegrasyon testi tamamlandı ancak hepsi bu değil. Bulunan hatalar kaydedilir ve düzeltilmesi için geliştiriciye gönderilir, ardından süreç yeniden başlar.

Öncelikle tespit edilen kusurların giderilip giderilmediğinin kontrol edilmesi gerekir. İkincisi, kaynak kodu değiştirildiğinde programın çalışmasında ve üçüncü taraf yazılımlarla etkileşimde yeni hatalar ortaya çıkabilir.

Artık çok sayıda kalite kontrol yöntemi olmasına rağmen, hala çok sayıda kalite kontrol yöntemi bulunmaktadır. önemli rol Entegrasyon testi önemli bir rol oynar. Bu tür bir doğrulama örneği, yazılım geliştirme ve dokümantasyondaki darboğazları açıkça gösterebilir.

Test otomasyonu

hacmine bağlı olarak orijinal kompleks veriler ve geliştirme konusu, test süresi sorunu ve olayın bir bütün olarak karmaşıklığı ortaya çıkabilir.

Çoğu için etkili doğrulama geliştirme kullanılmalıdır büyük miktar"manuel olarak" başa çıkılması imkansız olan giriş verileri ve koşulları. Bu sorunu çözmek için test otomasyonu kullanılır. Diğer türler gibi entegrasyon testleri de otomatikleştirilebilir. Bu, genel geliştirme süresini azaltacak ve aynı zamanda hata tespit sürecinin verimliliğini artıracaktır.

Ancak test otomasyonu, kalite mühendisinin işinin tamamen yerini alamaz, yalnızca onu tamamlar.

Dolayısıyla entegrasyon testi, herhangi bir yazılımın geliştirilmesinin ayrılmaz bir parçası ve ürünün kalitesini kontrol etme sürecinin tüm aşamalarından biridir. Herhangi bir yöntem gibi, bir takım avantaj ve dezavantajlara sahiptir, ancak kullanılmadığı takdirde yüksek kaliteli yazılım geliştirme imkansız hale gelir.

Çeviri: Anna Radyonova

Birçok yazılım testi türü vardır. BDD uygulamaları testin herhangi bir yönüne uygulanabilir ancak BDD çerçeveleri tüm test türlerinde kullanılmaz. Davranış senaryoları aslında fonksiyonel testler - test edilen ürünün düzgün çalışıp çalışmadığını kontrol ederler. Araçlar performans testi için kullanılabilirken BDD çerçeveleri bu amaç için tasarlanmamıştır. Bu makalenin amacı esas olarak BDD otomasyonunun Test Piramidindeki rolünü açıklamaktır. BDD'nin manuel testte nasıl kullanıldığını anlamak için BDD 101: Manuel Test makalesini okuyun. (BDD ile ilgili tüm bilgilere Otomasyon Panda BDD sayfasından ulaşabilirsiniz)

Piramidin Test Edilmesi

Yine de, Birim testlerine BDD uygulamaları uygulanabilir. Her birim testi ana bileşene odaklanmalıdır: bir çağrı, tek bir varyasyon, belirli bir girdi kombinasyonu; Açık davranış.Daha fazla geliştirmede, özellik davranışı spesifikasyonu, birim testleri daha fazla testten açıkça ayırır. yüksek seviye. Özellik geliştiricisi aynı zamanda birim testlerinin yazılmasından da sorumluyken başka bir mühendis entegrasyon ve uçtan uca testlerden sorumludur. Davranış spesifikasyonu, birim testlerin ayrı bir varlık olacağına dair bir tür centilmenlik anlaşmasıdır.

Entegrasyon ve Uçtan Uca test

BDD test çerçeveleri kendilerini en açık şekilde entegrasyon ve uçtan uca test düzeylerinde gösterir..

Davranış spesifikasyonları, test senaryosunun tam olarak neyi hedeflediğini açık ve net bir şekilde tanımlar. Adımlar entegrasyon düzeyinde veya uçtan uca düzeyde yazılabilir. Hizmet testleri, Karate'de olduğu gibi davranışsal özellikler kullanılarak yazılabilir. Uçtan uca testler aslında çok adımlı entegrasyon testleridir. lütfen aklınızda bulundurun sonraki örnek ilk bakışta öyle görünüyor ki temel model kullanıcıyla etkileşim, ancak aslında uçtan uca büyük bir testtir:

Verilen bir kullanıcı sosyal medya sitesine giriş yaptı
Ne zaman kullanıcı yeni bir yazı yazar
Daha sonra kullanıcının ana sayfa akışı yeni gönderiyi görüntüler
Ve tüm arkadaşların ana sayfa akışları yeni gönderiyi gösteriyor

Kolay yayınlama sosyal ağ arayüzle etkileşim süreçlerini, arka uç hizmetlerine çağrıları ve veritabanında gerçek zamanlı değişiklik yapmayı içerir. Tanımlandı tam yol sistemden geçiyor. Otomatik adımlar bu seviyeleri açık veya örtülü olarak kapsayabilir ancak testin kapsamına mutlaka girerler.

Uzun Uçtan Uca testler

Terimler genellikle farklı kişiler tarafından farklı şekilde anlaşılır. İnsanlar "uçtan uca testler" derken uzun, sıralı testleri kastediyorlar: kapsayan testler farklı davranışürünler birbiri ardına. Bu ifade BDD taraftarlarını ürpertiyor çünkü BDD'nin temel kuralıyla çelişiyor: tek senaryo, tek davranış. Elbette BDD çerçevelerini kullanarak uzun uçtan uca testler oluşturabilirsiniz, ancak Bunu yapıp yapmayacağınızı ve nasıl yapacağınızı dikkatlice düşünmeniz gerekir.

BDD'de uzun süre çalışan uçtan uca komut dosyaları yazmak için beş temel ilke vardır:

1. Bu konuda endişelenmenize gerek yok. BDD süreci doğru şekilde kurulursa, her bir davranış zaten test senaryoları tarafından tamamen kapsanmaktadır. Her komut dosyası, giriş ve çıkış verilerinin tüm eşdeğerlik sınıflarını kapsamalıdır. Bu nedenle, uzun uçtan uca komut dosyaları esas olarak test kapsamının kopyalarından oluşacaktır. Geliştirme konusunda zaman kaybetmek yerine, çok fazla değer sağlamayan ve manuel ve keşifsel testlere daha fazla zaman harcayan uzun uçtan uca komut dosyalarının otomasyonundan vazgeçmek daha iyidir.
2. Mevcut komut dosyalarını yenileriyle birleştirin. Her Ne Zaman-Sonra çifti temsil eder bireysel davranış. Mevcut komut dosyalarındaki adımlar diğer komut dosyalarına yeniden tanımlanabilir ve yalnızca küçük bir yeniden düzenleme gerektirir. Bu, Gherkin'in iyi uygulamalarını bozar ve komut dosyalarının uzun süre çalışmasına neden olabilir, ancak kapsamlı uçtan uca komut dosyaları için adımları yeniden kullanmanın en pratik yoludur. Çoğu BDD çerçevesi desteklemiyor adım adım sipariş ve destekleniyorsa kodun çalışması için adımların yeniden yazılması gerekir. (Bu yaklaşım en pratik olanıdır ancak daha az gelenekseldir.)
3. Verilen ve Ne Zaman adımlarına kontroller oluşturun. Bu strateji, Ne Zaman-Sonra çiftlerinin kopyalanmasını önler ve kontrollerin yapılmasını sağlar. Her adımın doğruluğu, tüm süreç boyunca Gherkin metni kullanılarak kontrol edilir. Ancak bir dizi yeni adıma ihtiyaç duyulabilir.
4. Bir dizi davranışı benzersiz, bireysel davranışlar olarak ele alın.. Bu en iyi yol uzun vadeli uçtan uca senaryolar hakkında düşünmek, çünkü davranışsal düşünmeyi geliştirir. Uzun vadeli bir senaryo ancak benzersiz bir davranış olarak kabul edilirse değerlidir. Senaryo bu benzersizliği vurgulayacak şekilde yazılmalıdır. Aksi takdirde bu kullanmaya değer bir script değildir. Bu tür komut dosyaları genellikle bildirimsel ve üst düzeydir.
5. BDD çerçevelerini kullanmayın ve testleri yalnızca otomasyon araçlarını kullanarak yazmayın. Gherkin, davranışsal işbirliğini mümkün kılmak için tasarlanırken, uzun uçtan uca testler QA iş yoğunluğu sorunlarını çözer. Bir işletme davranışsal spesifikasyonlar sağlayabilir ancak asla uçtan uca testler yazmaz. Davranışsal özelliklerin uzun, uçtan uca komut dosyaları halinde yeniden yazılması, geliştirmeyi engelleyebilir. Fazla en iyi çözüm birlikte varoluştur: kabul testleri Gherkin kullanılarak yazılabilir ve uzun süren uçtan uca testler programlama araçları kullanılarak yazılabilir. Her iki test seti de aynı kod tabanını kullanarak otomatikleştirilebilir, aynı destek modüllerine ve hatta adımları tanımlamak için yöntemlere sahip olabilir.

Ekibinize en uygun yaklaşımı seçin.

Teknolojik açıdan bakıldığında, entegrasyon testi, birim testinin niceliksel bir gelişimidir; çünkü birim testi gibi, modüllerin ve alt sistemlerin arayüzleri üzerinde çalışır ve eksik modüllerin yerine Stub'lar dahil olmak üzere bir test ortamının oluşturulmasını gerektirir. Modüler ve arasındaki temel fark entegrasyon testi Hedeflerden, yani tespit edilecek hata türlerinden oluşur ve bunlar da girdi verilerinin ve analiz yöntemlerinin seçilmesine yönelik stratejiyi belirler. Özellikle entegrasyon testi düzeyinde, işlev veya yöntem çağrıları gibi arayüzlerin kapsanması veya arayüz nesnelerinin kullanımının analiz edilmesiyle ilgili teknikler, örneğin küresel kaynaklar, sağlanan iletişim araçları işletim sistemi.

Sorun bu yöntemle çözüldü entegrasyon testi, - K kompleksi yazılımının yürütülmesi sırasında uygulanan modüller arası bağlantıların testi, modüler düzeyde bir "beyaz kutu" modeli kullanır. Testi yapan kişi, teste tabi tutulan komplekste yer alan tüm modülleri çağırmadan önce program metnini ayrıntılı olarak bildiğinden, bu aşamada yapısal kriterlerin kullanılması mümkün ve haklıdır.

Entegrasyon testi, birim testli modüllerin tek bir kompleks halinde birleştirilmesi aşamasında kullanılır. Modülleri birleştirmenin bilinen iki yöntemi vardır:
Monolitik tüm modüllerin test edilmiş bir komplekse eşzamanlı entegrasyonu ile karakterize edilir
Artımlı, bir araya getirilmiş kompleksin adım adım test edilmesiyle bir dizi programın adım adım (modül modül) oluşturulmasıyla karakterize edilir. Artımlı yöntemde modül eklemek için iki strateji vardır:
o Yukarıdan aşağıya ve ilgili aşağıdan yukarıya testler.
o "Aşağıdan yukarıya" ve buna bağlı olarak yukarıdan aşağıya test.

Özellikler monolitik test Bunlar aşağıdaki gibidir: Test sırasında geliştirilmemiş modülleri değiştirmek için, en üstteki modül hariç, ek olarak sürücüleri (test sürücüleri) ve/veya taslakları (saplamaları) geliştirmek, eksik olan daha düşük seviyedeki modülleri değiştirmek gerekir. test oturumu sırasında.

Monolitik ve integral yaklaşımların karşılaştırılması aşağıdakileri verir:
Monolitik test sürücülerin ve taslakların ek olarak geliştirilmesi ve birleştirilmiş kod alanında ortaya çıkan hataları tanımlamanın zorluğu nedeniyle çok fazla emek gerektirir.
Adım adım test test edilen kodun hacmindeki kademeli artış ve buna bağlı olarak test edilen kodun eklenen alanının yerelleştirilmesi nedeniyle hataların belirlenmesinde daha az zahmet ile ilişkilidir.
Monolitik test sağlar harika fırsatlarözellikle testin ilk aşamasında işin paralelleştirilmesi.

Özellikler yukarıdan aşağıya test Bunlar şunlardır: test edilen modüllerin test edilen modülleri tarafından yürütülebilir çağrı kuyruğu için bir ortamın düzenlenmesi, taslakların sürekli geliştirilmesi ve kullanılması, ortam ile değişim işlemleri içeren modüllerin veya test edilen algoritma için kritik olan modüllerin öncelikli testlerinin organize edilmesi.

Kusurlar yukarıdan aşağıya test:
Yeterince "akıllı" taslaklar geliştirme sorunu, ör. test için gerekli olan kompleksin çeşitli çalışma modlarını simüle ederken kullanılabilen taslaklar
Modüllerin gerekli sırayla yürütülmesini sağlamak için bir ortam düzenlemenin ve geliştirmenin karmaşıklığı
Üst ve alt seviyedeki modüllerin paralel gelişimi, henüz test edilmemiş alt seviyedeki modüllerin halihazırda test edilmiş olan üst seviyedeki modüllere göre ayarlanması (uzmanlaşması) nedeniyle modüllerin her zaman etkili bir şekilde uygulanmasına yol açmaz.

Kusurlar aşağıdan yukarıya test:
Test edilen kompleksin kavramsal özelliklerinin kontrolünde gecikme
Sürücü geliştirme ve kullanma ihtiyacı

Prosedürel programlama için entegrasyon testinin özellikleri

Yapısal testler sırasında bir dizi test oluşturma süreci, Program Model Grafiğinin (GMP) yapısının dayandığı prensip tarafından belirlenir. Bu, test yolları kümesini ve test yollarına karşılık gelen testlerin oluşturulmasını belirler.

Yazılım geliştirmeye ilk yaklaşım prosedürel (modüler) programlamadır. Geleneksel prosedürel programlama, kaynak kodunun belirli bir komut yürütme sırasını öngören zorunlu bir tarzda yazılmasını ve ayrıca işlevsel ayrıştırma kullanarak bir yazılım projesini tanımlamayı içerir. Pascal ve C gibi diller zorunludur. Bunlarda, kodun kaynak satırlarının sırası, sıralı yürütme, koşulların seçimi ve program bölümlerinin tekrarlanan yürütülmesi dahil olmak üzere kontrolün aktarılma sırasını belirler. Her modülün birkaç giriş noktası (kod kesin olarak yazılmışsa - bir) ve birkaç çıkış noktası (kod kesin olarak yazılmışsa - bir) vardır. Karmaşık yazılım projeleri modüler hiyerarşik bir yapıya sahiptir ve modüllerin test edilmesi, yazılım test sürecinin ilk adımıdır. Bir modülün grafik modelini oluşturmak önemsiz bir iştir ve testler neredeyse her zaman C1 dal kapsamı kriterine göre gerçekleştirilir, yani. modül grafiğinin her yayı ve her köşesi test yollarından en az birinde bulunmalıdır.

Sınıflar ve test türleri.

İki ana test sınıfı vardır: geleneksel Ve geleneksel olmayan.

Test var kompozisyon, bütünlük Ve yapı. Şunlardan oluşur:

• atamalar;
• bunların uygulanmasına ilişkin kurallar;
• her görevi tamamlama notları;
• Test sonuçlarının yorumlanmasına yönelik öneriler.

Test bütünlüğü görevlerin ilişkisi, bunların ortak bir ölçülen faktöre ait olması anlamına gelir. Her test görevi kendisine atanan rolü yerine getirir ve bu nedenle hiçbiri ölçüm kalitesinde kayıp olmadan testten çıkarılamaz.

Test yapısı görevleri birbirine bağlamanın bir yolunu oluşturur. Temel olarak, bu sözde faktör yapısı her görevin diğerlerine bağlı olduğu genel içerik ve genel test puanı değişimi.

Geleneksel bir test en az üç sistemin birleşimidir:

• test edilen akademik disiplinin dilinde açıklanan anlamlı bir bilgi sistemi;
• giderek zorlaşan resmi bir görev sistemi;
• istatistiksel özellikler görevler ve test sonuçları.

Geleneksel pedagojik teste iki önemli açıdan bakılmalıdır: Pedagojik ölçüm yöntemi ve test uygulaması sonucu.

onlar st, en iyi metodolojik bütünlüğü oluşturan bir görevler sistemidir. Testin bütünlüğü, gelişen bir sistem olarak testi oluşturan görevlerin istikrarlı etkileşimidir.

Homojen testler

Geleneksel testler testleri içerir homojen Ve heterojen.

Homojen test temsil etmek artan zorluk, özel biçim ve özel içerikli bir görevler sistemi - nesnel, niteliksel ve belirli bir amaç için oluşturulmuş bir sistem etkili yöntem Bir akademik disiplindeki yapının değerlendirilmesi ve öğrencilerin hazırlık düzeyinin ölçülmesi.

Homojen testler diğerlerine göre daha yaygındır. Pedagojide, bir akademik disiplindeki veya bunun bir bölümündeki, örneğin fizik gibi çok geniş bir akademik disiplindeki bilgiyi kontrol etmek için yaratılırlar. Homojen bir pedagojik testte diğer özellikleri ortaya çıkaran görevlerin kullanılmasına izin verilmez.İkincisinin varlığı, pedagojik testin disiplin saflığı gerekliliğini ihlal etmektedir. Sonuçta her test önceden belirlenmiş bir şeyi ölçer.

Heterojen testler

Heterojen test temsil etmek artan zorluk, spesifik biçim ve spesifik içerikli bir görev sistemi - çeşitli akademik disiplinlerdeki öğrencilerin hazırlık düzeyini ölçmek ve yapıyı değerlendirmek için objektif, yüksek kaliteli ve etkili bir yöntem amacıyla oluşturulmuş bir sistem.

Çoğu zaman bu tür testler şunları da içerir: psikolojik görevler Entelektüel gelişim düzeyini değerlendirmek.

Tipik olarak heterojen testler, okul mezunlarının kapsamlı bir değerlendirmesi, bir işe başvururken kişilik değerlendirmesi ve üniversitelere kabul için en hazırlıklı adayların seçilmesi için kullanılır. Her heterojen test homojen testlerden oluştuğundan, test sonuçlarının yorumlanması her testin görevlerine verilen cevaplara (burada bunlara ölçek denir) ve ayrıca çeşitli yöntemler puanların toplanması verilmeye çalışılıyor genel değerlendirme test deneğinin hazırlığı.

Test sonuçlarının yorumlanması, esas olarak testoloji dilinde, aritmetik ortalamaya, mod veya medyana ve sınava girenlerin yüzde kaçının sınava girdiğini gösteren yüzdelik normlara dayalı olarak gerçekleştirilir. test sonucu test puanıyla analize alınan herhangi bir denekten daha kötü. Bu yoruma denir normatif odaklı.

Bütünleştirici testler

bütünleştirici oluşan bir test olarak adlandırılabilir bütünleştirici içerik gereksinimlerini karşılayan görev sistemleri, test formu, bir eğitim kurumu mezununun hazırlıklılığının genelleştirilmiş nihai teşhisini amaçlayan görevlerin artan zorluğu.

Teşhis, iki alanda entegre (genelleştirilmiş, açıkça birbiriyle ilişkili) bilgi gerektiren doğru cevapları olan bu tür görevlerin sunulmasıyla gerçekleştirilir ve Daha akademik disiplinler. Bu tür testlerin oluşturulması yalnızca çeşitli akademik disiplinler hakkında bilgi sahibi olan, disiplinler arası bağlantıların öğrenmedeki önemli rolünü anlayan ve doğru cevapları öğrencilerin çeşitli konularda bilgi sahibi olmasını gerektiren görevler oluşturabilen öğretmenlere verilir. disiplinler ve bu bilgileri uygulama becerisi.

Bütünleştirici testlerden önce organizasyon gelir bütünleştirici öğrenme. Ne yazık ki, ders yürütmenin mevcut sınıf-ders biçimi, akademik disiplinlerin aşırı parçalanması ve öğretim geleneğiyle birleşiyor. bireysel disiplinler(ve genelleştirilmiş kurslar değil), eğitim ve hazırlıklılığın izlenmesi süreçlerinde bütünleştirici bir yaklaşımın uygulanmasını uzun süre engelleyecektir.

Bütünleştirici testlerin heterojen testlere göre avantajı, her görevin daha fazla bilgilendirici içeriğinde ve daha az sayıda görevde yatmaktadır.

Uyarlanabilir testler

Uyarlanabilir kontrolün uygulanabilirliği, geleneksel testlerin rasyonelleştirilmesi ihtiyacından kaynaklanmaktadır.

Her öğretmen, iyi hazırlanmış bir öğrenciye kolay ve çok kolay görevler vermenin gerekli olmadığını bilir; doğru karar. Ayrıca hafif malzemelerin gözle görülür bir gelişme potansiyeli yoktur. Simetrik olarak, yanlış karar verme ihtimalinin yüksek olması nedeniyle zayıf bir öğrenciye zor görevler vermenin bir anlamı yoktur. Zor ve çok zor görevlerin azaldığı bilinmektedir. öğrenme motivasyonu birçok öğrenci.

En çok ana karakteristik uyarlanabilir test görevleri, ampirik olarak elde edilen zorluk seviyeleridir; bu şu anlama gelir: bankaya ulaşmadan önce her görev, yeterli düzeyde ampirik teste tabi tutulur. büyük sayı ilgilenilen popülasyonun tipik öğrencileri. "İlgiye bağlı" kelimelerinin burada bilimde bilinen daha kesin bir kavram olan "genel nüfus" kavramının anlamını temsil etmesi amaçlanmaktadır.

Testin diğer yöntemlere göre aşağıdaki avantajları vardır: pedagojik kontrol:

· öğrenciler tarafından edinilen bilgi ve becerilerin kalitesinin kontrol edilme hızının arttırılması;

· yüzeysel de olsa her şeyin tam olarak kapsanmasının uygulanması eğitim materyali;

· etkinin azaltılması olumsuz etki Belirli bir öğretmenin ruh hali, nitelik düzeyi ve diğer özellikleri gibi faktörlerin test edilmesinin sonuçlarına ilişkin; minimizasyon öznel faktör Cevapları değerlendirirken;

· Yüksek objektiflik ve bunun sonucunda daha büyük pozitif uyarıcı etki bilişsel aktiviteöğrenci;

· modernliğe odaklanmak teknik araçlar bilgisayar eğitimi ve izleme sistemleri ortamında kullanım için;

· Kontrol sonuçlarının matematiksel ve istatistiksel olarak işlenmesi olasılığı ve bunun sonucunda pedagojik kontrolün nesnelliğinin arttırılması;

· Uyarlanabilir testlerin kullanılması yoluyla eğitimin bireyselleştirilmesi ve farklılaştırılması ilkesinin uygulanması;

· Görevleri tamamlamak için gereken süreyi azaltarak ve denetimi otomatikleştirerek kontrolün sıklığını ve düzenliliğini artırma yeteneği;

· Ülkenin eğitim sisteminin Avrupa sistemine entegrasyon sürecini kolaylaştırmak.

Testler aşağıdaki esaslara göre sınıflandırılabilir:

1. Konu alanı testlerin uygulanması: tek konu, çok konu, bütünleştirici.
bütünleştirici Doğru cevapları iki veya daha fazla akademik disiplinin entegre (birbiriyle ilişkili, genelleştirilmiş) bilgisini gerektiren bu tür görevlerden oluşan bir test olarak adlandırılabilir. Bu tür testlerin okulda hem izleme hem de eğitim amacıyla kullanılması, öğretimde disiplinler arası bağlantıların uygulanmasının mükemmel bir yoludur.

2. Test tasarımının genel yönelimi: normatif odaklı veya kriter odaklı (konu odaklı).
Şu tarihte: normatif odaklı yaklaşım, konuları seviyeye göre karşılaştırmak için testler geliştirilir eğitimsel başarılar.
Ana ayırt edici özellik konuya özgü test etme, test performansının anlamsal içeriği açısından yorumlanmasıdır. Vurgu, diğerleriyle karşılaştırıldığında nasıl göründükleri değil, kesin olarak tanımlanmış bir içerik alanıdır (sınava katılanların neler bildiği ve bildiği).

3.Didaktik-psikolojik test yönelimi: teori bilgisini kontrol etmek için başarı testi; belirli bir konudaki değişen karmaşıklık derecelerindeki yetenekleri ve becerileri izlemek için bir başarı testi, bir öğrenme yeteneği testi (belirli bir konu aralığında veya döngüsel bilgide - matematiksel, dilsel vb. gerçek eğitim yeteneklerinin teşhisi).

4.Belirli bir kontrol aşamasına yönlendirme: ön kontrol testleri, testler akım kontrolü, son kontrol testleri.

5. Testler yapılırken deneğin baskın aktivitesi– sözlü, yazılı, bilgisayar.

6. Kontrol nesnelerinin sayısı: bir kontrol nesnesi (örneğin, uygun düzeyde gerçekleştirilen işlem sayısı) veya birkaç (kalite, nicelik, hız, katı sıra, aynı operasyonların farkındalığı).

7. Homojenlik derecesi test görevleri : homojen veya heterojen inşaat görevleri biçimleriyle yapılan testler.

8. Hız faktörü: yüksek hızlı (yürütme süresinin zorunlu olarak kaydedilmesiyle) ve hızlı olmayan.

9. Test organizasyon formu: Kitle, birey, grup.

Ayrı ayrı, sözde var uyarlanabilirÖğrenmenin bireyselleştirilmesi ilkesine dayalı testler. Her öğretmen, tıpkı zayıf bir öğrenciye zor görevler vermenin bir anlamı olmadığı gibi, iyi bir öğrenciye de kolay ve çok kolay görevler vermenin bir anlamı olmadığını bilir. Teorik olarak pedagojik boyutlar Görev zorluğu ölçüsü ile bilgi düzeyi ölçüsünün tek bir ölçekte karşılaştırılabilir olduğu bulunmuştur. Bilgisayarların ortaya çıkışından sonra bu önlem, sunulan görevlerin zorluğunun ve sayısının öğrencilerin cevaplarına göre düzenlendiği uyarlanabilir bilgi kontrolü yönteminin temelini oluşturdu.