Bitmemiş cümleler. Psikolojik test

Başlangıç ​​savaşın yarısıdır. Bu kural hemen hemen her faaliyet alanı ve hatta yazılım testi için geçerlidir.

Genellikle bir projenin başlangıcında, test uzmanları dokümantasyon (test stratejisi, test planı veya test senaryoları) yazarak heyecan yayarlar.

Ancak gelecekte zorluklar sıklıkla ortaya çıkar. Testin ilk turunu tamamladıktan sonra, testçiler genellikle bir sürü hata bulur ve ardından ikinci tura biraz rahatlayarak yaklaşırlar. Sözde bir şey var tekrarlanan işlemleri yapmanın sıkıcı hale gelmesinde insan faktörü ve evrensel insan eğilimi.

Bu gibi durumlarda, birçok kişi monoton bir iş yaptıklarını hisseder ve sonuç olarak zaten tanıdık olan yazılımları test etmeye devam etme konusundaki ilgilerini kaybederler. Ve yaklaşık üçüncü turda, şu soru kaçınılmaz olarak testçinin aklında kalıyor: "Testi ne zaman bırakmalısınız?"

Her test uzmanı bu soruyu en az bir kez sormuştur; genişletilmiş versiyonu şu şekilde görünecektir:

Birçok test uzmanı hiçbir şeyin olmadığına inanıyor özel koşullar testin tamamlanması gerektiğini belirtir. Ancak bu soruyu cevaplamak için test etkinliğini baştan sona analiz etmeniz gerekecek.

Diyelim ki görev yeni bir projeyi test etmek.

İlk adımlar:

• Test ekibi gereksinimleri alır.
• Daha sonra planlama ve geliştirme gelir.
• Test dokümantasyonu hazırlanır ve gözden geçirilir .

Test, 1. tur)

Test ekibi, yeni oluşturulan yazılım ürünü kendisine teslim edilir edilmez teste başlar.

Test aşamasında, test uzmanları yazılımı kırmak ve kusurları keşfetmek amacıyla çeşitli senaryolar uygular. (Uygulama yeni olduğundan ve ilk kez değerlendirildiğinden dolayı bulunan kusur oranı nispeten yüksek olacaktır.)

Geliştiriciler kusurları düzeltir ve geliştirmeyi yeniden test edilmek üzere test uzmanlarına iade eder.

Test uzmanları kusurları kontrol eder ve ardından .

Ciddi kusurlar ortadan kaldırıldığında ve yazılım bunu gösterdiğinde istikrarlı çalışma geliştirme ekibi bir sonraki sürümü yayınlar.

Test, tur #2)

Test uzmanları testin ikinci turuna başlar ve ilk turda yapılanları tekrarlar.

Bu süreçte kural olarak bazı kusurlar daha keşfedilir.

Geliştiriciler kusurları giderir ve uygulama incelenmek üzere geri gönderilir.

Test uzmanları, geliştirmenin değişmeyen kısımları üzerinde tekrarlanan testler ve regresyon testleri gerçekleştirir.

Bu sonsuza kadar devam edebilir. 3., 4., 5. tur... ta ki yazılım hiçbir şekilde hatalardan arındırılmayacaktır.

Ancak teorik olarak kesinlikle tüm kusurları bulmak mümkün mü? Bu milyon dolarlık bir soru ama hadi cevaplamaya çalışalım.

Çoğu uygulama karmaşıktır, bu nedenle test kapsamları oldukça geniştir. Kesinlikle tüm kusurları tespit etmek tamamen imkansız değildir, ancak bu çok zaman alacaktır.

Yazılımdaki çoğu hatanın bulunmasından sonra bile hiç kimse uygulamanın kusursuz hale geldiğini güvenle söyleyemez.

Üstelik böyle bir göreve değmez. Yazılım testinin amacı, işlevsel olduğundan ve amaçlandığı gibi çalıştığından emin olmaktır. Bu, bilgisayar korsanlığı girişimleri veya beklenen davranıştan sapmaların araştırılması yoluyla gerçekleştirilir.

Uygulamalar olabilir sonsuz küme kusurlar ve tamamen ortadan kaldırılıncaya kadar gerçekleştirilmesi pratik değildir. Hangi böceğin son olacağını asla bilemezsiniz.

Ve eğer “kusurların tamamen ortadan kaldırılmasından sonra testi durdurmak” artık bir kriter değilse, o zaman nereden yola çıkmalıyız?

Hangi faktörlerin en önemli olarak kabul edilmesi gerektiğini bulmaya çalışalım?

Testi durdurma kararı genellikle zamana (mevcut), bütçeye ve gerekli süre test.

Çoğu zaman testi sonlandırma kararı, zaman/bütçe dolduğunda veya tüm test senaryoları tamamlandığında verilir. Ancak bu, kalite pahasına olabilecek uzlaşmacı bir çözümdür.

Örnek

Test Senaryosu:

Diyelim ki bir yazılım modülünü test etmeniz gerekiyor; bu iş için belli bir bütçe ayrıldı. Süre: 1 ay. Toplam miktar test senaryoları: 200.

Senaryo #1)

İlk hafta: Başardınız - ilk gün Show Stopper kusurunu buldunuz. Ancak testler 3 gün durduruldu. Bulunan hata düzeltilene kadar diğer senaryoları kontrol edemezsiniz. Zaman kaybettikten sonra işinize geri dönersiniz.

Hafta sonuna kadar 20 komut dosyası test edildi ve çok sayıda tehlikeli hata daha bulundu.

2. Hafta: Test etmeye başlarsınız, dikkatlice kusurları ararsınız. İkinci hafta boyunca 1., 2. ve 3. kritiklik seviyesindeki birkaç hatayı bulun. Bu süre zarfında 70 senaryoyu test etmeyi başardık.

3. Hafta: Üçüncü haftanın başında, tüm yüksek öncelikli kusurlar ortadan kaldırılmıştır, ancak artık mevcut senaryoların uygulanmasına ek olarak, önceden keşfedilen hataların yeniden kontrolü de eklenmiştir. Üçüncü haftada 120 senaryoyu incelediniz ve birkaç hata daha buldunuz. Artık geriye kalan tek şey üçüncü dereceden kusurları aramaktır.

4. Hafta: Dördüncü haftanın başında kusurların ve kalan 80 senaryonun yeniden kontrol edilmesi gerekmektedir. Haftanın sonunda 180 senaryoyu test ettiniz; Tüm yüksek öncelikli kusurlar düzeltildi ve yeniden test edildi.

Gerçekleştirilen testlere ilişkin veriler tabloya yerleştirilmiştir:

Belki bu zaten yeterlidir?

Test için ayrılan süre dolmuştur. Bir dizi 1. düzey kusuru buldunuz ve ortadan kaldırdınız. Burada durursak geliştirilen yazılım güvenilir sayılabilir mi? Pek değil, bazı nedenlerden dolayı:

• Komut dosyalarının tümü test edilmemiştir.
• Potansiyel olarak tehlikeli olan birçok kusur hiçbir zaman test edilmedi.
• Test edilen tüm senaryolar yalnızca bir kez test edildi.
• Yazılımın hala kusurları var.

Senaryo #2)

1. Hafta: Testin ilk gününde 1. düzey bir kusur bulursunuz. Ve testler 3 gün ertelendi. Üç gün kaybettikten sonra yeniden çalışmaya başlıyorsunuz.

Hafta sonuna kadar 20 komut dosyası kontrol edildi ve çok sayıda tehlikeli kusur daha bulundu.

İlk haftanın sonuçları 1 numaralı örneğe benzer.

2. Hafta: İkinci hafta boyunca 1., 2. ve 3. kritiklik seviyesindeki çeşitli hataları bulacaksınız. Ancak şimdi zorluk mümkün olduğu kadar çok senaryoyu kapsamaktır. Sonuç olarak hafta sonuna kadar 120 senaryo ortaya çıktı.

3. Hafta: Üçüncü haftanın başında tüm öncelikli kusurlar ortadan kaldırılmıştır ve artık mevcut senaryolara ek olarak daha önce keşfedilen kusurların yeniden kontrol edilmesi gerekmektedir. Üçüncü haftada 200 senaryoyu ele aldınız ve çok sayıda hata daha buldunuz.

Artık yalnızca 2. ve 3. düzey kusurları bildirebilirsiniz.

Test verileri:

Bu yeterli mi?

Tüm test senaryolarını tamamen ele aldınız ve birkaç hata daha buldunuz. Burada durursak yazılım güvenilir sayılabilir mi?

Tam olarak değil:

• Tüm senaryolar yalnızca bir kez test edildi.
• Yazılımın hala kusurları var.
• Herhangi bir regresyon testi yapılmadı.

Gördüğünüz gibi her iki senaryo da kaliteyi garanti etmiyor. Böyle bir durumda yapılacak en iyi şey bulmaya çalışmaktır. altın ortalama, her şeyi hesaba katan bir yaklaşım kullanın en iyi özellikler Birinci ve ikinci senaryolardan. Bunu yapmak için bir dizi kriter tanımlamanız gerekecektir.

Tamamlama veya çıkış kriterleri

Çıkış kriteri, ne kadar testin yeterli kabul edilmesi gerektiğini belirlemenize olanak tanır. Test döngüsünün sonunda belirlenir ve plana dahil edilir. Bu, testin tamamlanmış olarak adlandırılması için karşılanması gereken bir dizi koşul veya aktivitedir.

Çıkış kriteri neleri içeriyor?

İdeal olarak, tüm projelere özgü çeşitli faktörlerin birleşimidir. Her şey belirli bir projenin gereksinimlerine bağlıdır. Bu nedenle planlama sırasında mümkün olduğu kadar çok parametrenin hesaplanması tavsiye edilir.

Aşağıda veya sırasında dikkate alınması gereken bazı nüanslar bulunmaktadır. Testin tam olarak ne zaman tamamlanacağını belirlemek için belirli bir kombinasyon oluşturabilir veya bu faktörlerin tümünü kullanabilirsiniz.

Test şu durumlarda tamamlanabilir:

• Gereksinimlerin tamamı %100 dikkate alınır.
• Tanımlanan kusurlar/tespit edilen kusurların beklenen sayısı.
• Gösteri Durdurucu veya Engelleyici olarak sınıflandırılan tüm kusurlar düzeltildi; kritik kusurların hiçbiri "açık" durumda değil.
• Tüm yüksek öncelikli kusurlar tespit edildi ve düzeltildi.
• Kusur Oranı belirlenen kabul edilebilir seviyenin altındadır.
• Çok az sayıda orta kritiklik kusuru “açıldı” ve analiz edildi.
• Sistemin kullanımını etkilemeyen "açık" orta seviye kusurların sayısı çok azdır.
• Tüm kusurlar yüksek seviyeöncelikler kapatılmış ve ilgili regresyon senaryoları başarıyla gerçekleştirilmiştir.

Test kapsamı:

• Test kapsamı %95 olmalıdır.
• Metin durumunun Geçiş Oranı da %95 olmalıdır. Bu yüzdeyi hesaplamak için formül kullanılır:

(Toplam başarılı metin vakası sayısı / toplam test vakası sayısı) * 100.

• Tüm kritik test senaryoları başarılı oldu
• Test senaryolarının %5'i başarısız olabilir ancak bu, düşük öncelikli vakalar için geçerlidir.
• Tam işlevsellik kapsamına ulaşıldı.
• Tüm önemli fonksiyonel kusurlar başarıyla ortadan kaldırıldı.

Tarihler:

Test için ayrılan süre dolmuştur.

Test belgeleri:

Teslim edilmesi gereken tüm test belgeleri (örneğin test raporu) hazırlanır, incelenir ve sunulur.

Bütçe:

• Test için ayrılan bütçenin tamamı harcandı.
• “Git/Gitme” formatında toplantılar yapıldı, ürünün piyasaya sürülmesi kararı alındı.

Son olarak lütfen birkaç soruyu yanıtlayın.

Cevapların çoğunluğu evet ise bu, testi tamamlayabileceğiniz anlamına gelir. Cevapların çoğu olumsuzsa, o zaman neyin kaçırıldığını aramanız gerekecektir.

• Tüm test senaryoları en az bir kez test edildi mi?
• Test senaryosu başarı oranı var mı (Test Senaryosu Geçişi)?
• Tam test kapsamına ulaşıldı mı?
• Tüm işlevsel/iş akışları en az bir kez test ediliyor mu?
• Belirtilen sayıda kusur bulundu mu?
• Tüm yüksek öncelikli kusurlar çözüldü ve “kapatıldı” mı?
• Tüm kusurlar yeniden test edildi ve "kapalı" olarak değerlendirildi mi?
• Tüm “açık” kusurlar üzerinde regresyon testi yapıldı mı?
• Test için ayrılan bütçe bitti mi?
• Test süresi doldu mu?
• Tüm test belgeleri incelendi ve yayınlandı mı?

Test ne zaman durdurulmalı ve durdurulmalı mı? Bilginin tamamı işlendi mi ve her şey dikkate alındı ​​mı? Ve genel olarak -? Bu sorular her testçi için geçerlidir. O halde bir dakika duralım ve düşünelim: Sonsuza uzanan sınama sürecini kesintiye uğratmak hangi noktada gerekli ve mümkün?

Durdurma nedeni: “Son tarihler doluyor! Vakit nakittir!”

Çoğu zaman, müşterinin her zaman harekete geçmeye hazır olmadığı bir proje için açıkça tanımlanmış son tarihler vardır. Bu durumda “testi bitir!” komutu verilir. tam olarak son teslim tarihlerine bağlıdır ve bu önemli bir kriterdir. Evet, böyle bir senaryoya en iyisi denemez (çünkü tam bir kontrol için her zaman çok az zaman vardır ve kalite çoğu zaman zarar görür), ancak bu da mümkündür.

Uygulamadan örnek. Teslim tarihlerinin kısıtlı olması nedeniyle ürünün kalitesinin düştüğü bir durumu hatırlıyorum. Çevrimiçi bir ev eşyaları mağazası test edildi ve yalnızca kayıtlı müşterilere yönelik yeni bir promosyon indiriminin yanı sıra bir hata ortaya çıktı: o sırada geçerli olan çeşitli promosyonların etkinleştirilememesi. Böylece sürüm, "bir sürüm artı birkaç gün daha yoğun hata düzeltmeye" dönüştü. Muhtemelen, katı sınırları bir veya iki günlüğüne değiştirmek ve yeni işlevselliği daha fazla test etme fırsatı vermek çok daha iyi olurdu... ancak hayatta farklı durumlar vardır.

Çözüm. Ana görev sınırlı süre koşullarında test uzmanının mümkün olduğu kadar çok şeyi kapsaması gerekir olası miktar kritik test senaryoları (yüksek ve orta öncelikli test senaryoları), bulunan tüm hataların kaydedilmesi (zaman ve görev değişiminden kaynaklanan kayıpları önlemek için) ve yapılan gerçek iş miktarı hakkında bir mesaj oluşturulması. Sonuç olarak, testçinin alması gerekenler tam resim kontrol edilmiş ve henüz kontrol edilmemiş olanların bir listesi (işin kapsamını daha ayrıntılı olarak belirlemek için).

Durdurma nedeni: “Bu son değil, ara bir çalışmadır”

Test sırasında, "bir şey" test edilen nesnenin optimal değerlendirmesini kritik bir şekilde engellediğinden ve bu nedenle tüm test sisteminin gelecekte "başarısız olabileceği" için zorla durmanın gerekli olduğu görülür. Bu durumda durup sorunun çözülmesini beklemek daha iyidir.

Uygulamadan örnek. Oldukça büyük tıbbi yazılımlar test edildi. Test tezgahında yeni işlevselliği tam olarak test etmek mümkün olmadı (formu ve verileri doldururken müşterilere mektup göndermek) kişisel hesap müşteri). Görev oldukça kapsamlıydı ve birçok hususu kapsıyordu: belgeler tamamen yüklendiğinde ayrı bölümlerin etkinleştirilmesi, belli bir dereceye kadar profilinizi ve diğerlerini doldurmak. Yayınlanmadan önceki soruya ise “Her şey test edildi mi ve testi bitirmek mümkün mü?” Kesin bir cevap vermek kesinlikle imkansızdı: Test ortamında bazı mektupların alındığının doğrulanamaması nedeniyle çek kısmen engellendi. Bunun sonucunda sürüm sırasında istemci tarafında kritik hatalar ortaya çıktı. Müşteri gerekli bildirim mektuplarını alamadı ve bu nedenle profiline tam erişim sağlayamadı. Bu tür durumların yaşanmaması için bulundu sonraki çözüm: değişiklikten sonra, test tezgahında mektup gönderme ve alma seçenekleri kullanıma sunuldu, bu da oldukça önemli işlevselliğin bu kısmının daha fazla test edilmesini mümkün kıldı. Bu kontrollerin sonraki tüm regresyon geçişlerine dahil edilmesi, ürünün müşteri tarafına sunulmadan önce hazır olup olmadığının en iyi şekilde değerlendirilmesini mümkün kıldı.

Çözüm. Hataların analizi, doğru sonuçlara varmamızı ve tüm engelleme sorunlarını ortadan kaldırmamızı sağladı. Ve yine de benzer durum Halihazırda tanımlanmış hatalara dayalı olarak test araçlarını ve araçlarını optimize etmeye yönelik çalışmalar pek dikkate alınamaz iyi seçenek. Kuşkusuz, istemci tarafında zaten kritik anların ortaya çıkmasını önlemek için test sürecini durdurmak ve test ortamının başlangıçta eksik olan işlevselliğini iyileştirmek çok daha uygun ve doğru olacaktır.

Durma nedeni: “Hareketsiz kalırsan ilerleyemezsin.” Virgül nereye konulmalı ve neden karışıklık var?

Kesintiye uğramayan test sırasında hataları doğrudan düzeltmek doğru mudur? Mantık, bir ayarlama yapıldıktan sonra sürecin durdurulması ve en baştan başlatılması gerektiğini belirtir, çünkü bir hatanın düzeltilmesi bir düzine yenisinin daha ortaya çıkmasına neden olabilir.

Uygulamadan örnek. Herhangi bir test uzmanının bildiği oldukça yaygın bir durum hemen akla gelir: test sırasında kritik hatalar keşfedilir ve test senaryolarının yarısı zaten kontrol edilmiştir ve bunların sonuçları kaydedilir. Bazen geliştiriciler bir hatayı o kadar hızlı düzeltmeye çalışırlar ki, planlanan tüm regresyon testi senaryolarını gözden geçirmek için acele eden çalışkan testçiye haber vermeyi "unuturlar". Sonuç olarak test, testi durdurup yeniden başlatmak yerine hata düzeltildikten sonra devam eder; Bazı hatalar artık algılanmayacak.

Çözüm. Bu tür durumlarda, geliştiricinin düzeltmelerini derhal test uzmanına bildirmesi önemlidir; böylece testi durdurabilir ve test senaryolarının tamamını veya yalnızca en kritik ve yüksek öncelikli olanları (çok fazla zaman kalmamışsa) yeniden geçebilir. ). Bu, gelecekte şu soruyla ilgili kafa karışıklığının önlenmesine yardımcı olacaktır: Üründeki yeni kusurlar nereden geldi ve bunlardan kim sorumlu?

Durma nedeni: “Geri çekilme emri geldi!”

Müşteri kelimenin tam anlamıyla son aşama taramayı duraklatır. Bunun pek çok nedeni olabilir: daha fazlasının ortaya çıkması önemli görev veya daha fazla açıklama gerektiren işlevsellik, sürüm önceliklerinin yeniden değerlendirilmesi, planın revizyonu şimdiki an. Görevimiz süreci duraklatmak ama hiçbir şeyi unutmamak!

Uygulamadan örnek. Neredeyse tamamen test edilmiş bir sürüm ertelendi. Görünüşe göre her şey hazır - tüm bloklar kapsamlı bir şekilde test edildi, tüm görevler tamamlandı - ve bitmiş ürünü kullanıcının zevkine bırakabilirsiniz, ancak müşteri aniden her şeyi tamamen yapmanın daha iyi olduğuna karar verir. farklı şekilde ve neredeyse hazır sürümün geçici olarak durdurulması gerekiyor. Bu durumun dezavantajı test uzmanının zaman kaybı, avantajı ise diğer yazılımların işlevselliğini test etmek için kullanılabilecek yazılı test senaryolarıdır.

Çözüm. Bu durumda, bir test uzmanının gelecekte benzer görevlerde veya (çalışmaya devam edilmesi durumunda) iptal edilen/ertelenen bir sürümde üzerinde çalışılabilecek yüksek kaliteli test senaryoları yazması önemlidir.

Durma nedeni: “İşte bu, yoruldum, bu kadar yeter!”

Gerginliğin zirveye ulaşması nedeniyle de durma meydana gelebilir. Mümkün olan en kısa sürede mümkün olduğunca çok şey yapma arzusu olası zaman bazen iş sonuçları üzerinde olumsuz etkisi vardır.

Uygulamadan örnek. Projelerimizden birinin piyasaya sürülmesi oldukça uzun sürdü; yoğun ve aktif bir şekilde test ettik. Kafamdaki testler uyurken bile durmadı. Ve o anda, hata kelimenin tam anlamıyla gözlerimin önünde belirdiğinde, günlüklerde bunu bana açıkça "sinyal ederek", onu görmedim. Böyle anlarda kendinize şunu söyleyebilmeniz gerekiyor: “Durun, biraz ara verin, yoksa hata yaparsınız, hatayı kaçırırsınız, dikkatiniz sıfır olur!” Ve dikkat, bir testçinin ana kalitesidir. Elbette sürecin kendisi basitçe durdurulamaz, ancak rahatlamak için kişisel zaman ayırmak gerekir!

Çözüm.İÇİNDE benzer vakalar Testte durmak zorunludur ve önemli nokta test cihazı için. İşi bitirirken, "gözlerinizin bulanıklaşmasını" önlemek için dinlenmeniz ve dikkatinizin dağılması (örneğin başka bir şey yapmanız) gerekir.

Durdurma nedeni: “Herhangi bir şüpheniz var mı? Durmak!"

Her sürümün yayınlanmasından önce, yapılan işi ve tamamlanan test senaryolarını değerlendiren test uzmanı şunları özetliyor: her şey test edildi mi? Kesinlikle, doğal durum Her zaman zaman faktörüne uymayan doğrulama sürecine devam etme isteği olacaktır. Yine de en azından makul şüphelerin dile getirilmesi gerekiyor. Hata son aşamada "yakalanmış" olsa ve düzeltilmesi tüm yayınlanma sürecini geciktirecek olsa bile, hiçbir durumda hatanın gözetimsiz bırakılmaması gerekir; çalışan mekanizmayı durdurmak ve düzeltme için zaman vermek daha iyidir.

Uygulamadan örnek. Deneyimlerime göre, hatanın zaten son adımlarda fark edildiği durumlar vardı (hatta son dakikalar) regresyon testi. Bu bir test uzmanının hatası mıydı (yani benim)? Evet ve bu benim için iyi bir vuruştu. daha fazla çalışma hataların üzerinden. Ancak hatanın ortadan kaldırılması gerekiyordu. Sorun, iyileştirme amacıyla sürümden "çıkarıldı", ancak sürümün kendisi oldukça başarılıydı. Unutmayın: Müşteri, kaliteyi korumadan teslim tarihlerine uymak yerine denetimin kalitesini takdir etmeyi tercih eder.

Çözüm. Test sürecinin her adımı önemlidir. Materyalin yanlış geliştirilmesi veya görevin test senaryolarıyla eksik kapsanması, test uzmanının önemli ve kritik bir hatayı kaçırmasına neden olabilir. Bu durum testin hangi aşamasında keşfedilirse fark edilsin, bu gibi durumlarda durmanın, durumu değerlendirmenin ve bir karar vermenin gerekli olduğunu anlamak önemlidir. ileri plançalışıyor!

Durma nedeni: “İsteğime göre dur!”

Testte önemli rol uzmanın üretilen ürünün önemini anlamasında rol oynar. Bir kişinin nihai ürüne kayıtsız kalması kötüdür. Bu durumda, testi yapan kişi sürecin kendisinden yorulduğu için test durabilir (“zaten öyle olacak!”).

Bu sefer aklıma eski bir fıkra geliyor:
“Adam stüdyoda bir takım elbise dikti. Eve gelip onu giydim. Karısı dehşete kapılmış:
-Ne diktin? Bakın: Bir kol daha uzun, diğeri daha kısa. Ceketin paçaları ve pantolon paçaları farklıdır. Hepsini geri getir!
Kocası geri döndü:
-Benim için ne diktin? Bakmak! Farklı uzunluklarda pantolonlar!
– Ve bir bacağınızı dizinizden büküyorsunuz çünkü düz bacaklar üzerinde yürümüyorsunuz. Ve her şey yoluna girecek.
– Bakın, kolların uzunlukları farklı!
- Ne olmuş? Ellerini yanlarında tutmuyorsun. Dirseklerinizi bükün. Burada! Müthiş!
- Peki ya zeminler? Onlarla ne yapmalı?
- Sen de biraz yana eğiliyorsun. Her şey yolunda!
Adam yeni bir takım elbiseyle çıktı. Otobüs durağındakiler:
- Bak, ne ucube! Ve takım elbise ne kadar da iyi uyuyor!

Bir test uzmanı için sürece yönelik ihmalkar bir tutum kesinlikle kabul edilemez. Tüm eksiklikler eninde sonunda ortaya çıkar ve bu da sonuçta feci sonuçlara yol açar.

Uygulamadan örnek. Neyse ki meslektaşlarım ve ben bu tür durumlarla hiç karşılaşmadık: işimizi seviyoruz ve son kullanıcılara saygı duyuyoruz (sonuçta hatalarımız onların ürünle etkileşim deneyimlerini etkiliyor). Umarım böyle bir şey asla yaşanmaz. Önemli olan bunun mümkün olduğunu unutmamak ve bu gibi durumlardan kaçınmaktır.

Çözüm. Testi yalnızca test uzmanının talebi üzerine durdurmak mümkün değildir; her durdurmanın gerekçesi olmalıdır. Süreci durdurma kararı, yalnızca bir dizi parametrenin en iyi şekilde ve olumlu bir şekilde tamamlanması ve kapsamlı bir şekilde çalışılması durumunda mantıklı olacaktır: göreve ilişkin test senaryolarının tam kapsamı yazıldı, olası durumlarda süreyi tahmin etmek için öncelikler doğru bir şekilde belirlendi. Acil veya hızlı kontroller için tüm görevler tam olarak analiz edilmiş ve teknik gerekliliklerle doğrulanmıştır. başlangıç ​​aşamaları alışma, sürüm planlama aşamasında her şey dikkate alınır.

Ve son olarak... Davul sesi... Durmanın son ama en çok arzu edilen nedeni: "Hazır, onu alabilirsin!"

Yeni bir sürümün planlanması başladığında özel bir test planı, öncelikler ve kapsam belirlenir. Doğru planlama olumlu sonuçlara yol açar kaliteli sonuçlar. Tüm test sonuçları kalite kriterlerini tam olarak karşıladığında, kendinize güvenle şunu söyleyebilirsiniz: "Durun, burada elimizden gelen her şeyi yaptık!" Ancak bunun için bulunan tüm hataların düzeltilmesi, planlanan tüm test senaryolarının geçilmesi (ve küçükten büyük tek bir hatanın bulunmaması), gerekli tüm düzenlemelerin yapılması ve kabul testi sonucunun tamamen olumlu olması gerekir. Ve bu aslında oluyor! Bu durumda müşteri memnun olur ve testçi kendisine güvenli bir şekilde "madalya" verebilir. aferin. Ve bu sizi daha fazla “istismara” nasıl hazırlıyor!

Uygulamadan örnek.Örneğin bir süre önce ev aletlerine yönelik web sitesini güncellemeyi test etmiştik. Site oldukça popülerdi ve olmaya devam ediyor ve ürünün sorumluluğu oldukça yüksekti. Sürümün sonucu, olumlu dinamikler ve İnternet üzerinden sipariş veren kullanıcı sayısına ilişkin gelişmiş istatistiklerdi. Bu elbette müşteri için çok büyük bir artı. Test uzmanları için başarılı bir sürümün ana göstergesi, müşteriye maksimum düzeyde uyarlanmış ve aşağıdakileri içeren bir üründür: minimum miktar hatalar (ya da belki orada hiç kalmadı mı ?!!!). Bu durumda testin durdurulması oldukça doğaldır, çünkü gerekli tüm kriterler dikkate alınarak açıkça belirlenmiş bir zaman dilimi içerisinde belirlenmektedir.

Çözüm. Almak için iyi sonuçÇalışmanızda tüm faktörleri dikkate almanız önemlidir. Bir görevi değerlendirmek ve analiz etmek, onu kapsayacak test senaryoları yazmak, süreyi hesaplamak ve maksimum özen, işinizde olumlu sonuçları garanti eder.

Final

Özetlemek gerekirse şunu söyleyebiliriz son senaryo- Bu ideal seçenek Test durakları: Uygun planlamayı, ayrıntılı testleri ve nihai olumlu kabul bölümünü birleştirir. Diğer durumlarda, test cihazının hataları, müşterinin talebi üzerine, yeterince düşünülmemiş bir test planı, yanlış zamanlama veya sadece tembellik (bu arada, mesleğimizde kabul edilemez kalite) nedeniyle kesintiler meydana gelir.

Dolayısıyla bu tür durumlardaki duraklamalar, nihai olumlu sonuç her zaman ulaşmak istediğin şey. Bu durumda doğru sonuçları çıkarmak ve ana hatanın nedenini belirlemek önemlidir. Kural olarak, bu yanlış zaman planlaması, geliştiriciye düzeltmelerin hazır olup olmadığı konusunda soru sorma korkusu (yani geliştirici ile test uzmanı arasındaki zayıf iletişim) ve spesifikasyonlara ve gereksinimlere tam olarak aşina olunmaması nedeniyle test senaryolarının ihmalkar yazılmasıdır. Tanımladıktan sonra zayıf noktalar Bir proje üzerinde veya kişisel olarak daha etkili bir çalışma için bir plan geliştirmeye başlayabilirsiniz.

Bunu yapmak için her zaman şunları dikkate almak gerekir: müşterinin koşulları ve istekleri, belirlenen zaman çerçevesi ve test senaryolarının görevde belirtilen ve açıklanan gereksinimleri karşılama derecesi. Her nokta açıkça üzerinde çalışılmalı ve hem müşteri hem de geliştirici ile tartışılmalıdır. Testi yapan kişinin işin kapsamını hayal etmesi gerekir: belirtilen zaman çerçevesinde ne tür bir testin tamamlanabileceği, kaç test senaryosunun gerekli olacağı, hangi noktaya kadar hata düzeltmelerine izin verildiği, kodun dondurulmasının ne zaman başlayacağı ve kaç tane test senaryosunun gerekli olacağı. Bulunan hatalar ürünün kendisinin serbest bırakılmasına olanak sağlar.

Elbette her projenin kendine has özellikleri var. Tek bir doğru referans çözüm yöntemi bulmak mümkün değildir. Yine de yukarıdaki temel kriterlerin dikkate alınması, üretilen ürünün gereksinimleri en iyi şekilde karşılayacağı ve test sürecinin ve durdurulmasının açık ve mantıklı olacağı gerçeğine yol açacaktır.

Test sürecinin organizasyonu. Yazılım geliştirme büyük ölçüde nihai program hakkındaki bilgilerin iletilmesi ve bu bilgilerin bir formdan diğerine çevrilmesi sürecidir. Ek olarak, çok sayıda yazılım hatası, işin organizasyonundaki kusurlardan, yetersiz karşılıklı anlayıştan ve bilgilerin iletilmesi ve çevrilmesi sürecindeki çarpıklıklardan kaynaklanmaktadır.

Geliştirme sürecinin netliğini artırarak birçok hatadan kaçınılabilir. Bu, her aşamanın sonunda yerelleştirmeyi amaçlayan ayrı bir doğrulama adımının dahil edilmesinin gerekli olduğu gerçeğine yol açmaktadır. en büyük sayı Bir sonraki adıma geçmeden önce hatalar. Örneğin, spesifikasyon bir önceki aşamanın çıktısıyla karşılaştırılarak kontrol edilir ve bulunan her hata, düzeltilmesi için spesifikasyon geliştirme sürecine geri gönderilir.

Ek olarak, spesifik test süreçlerine odaklanılmalıdır. belirli aşamalar gelişim. Bu, her test sürecini bir çeviri adımına odaklayarak belirli bir hata sınıfının kaydedilmesine neden olur.

Geliştirme ve test süreçleri arasındaki ilişki.

Gerçek test süreci kaynak kodunun kontrol edilmesiyle başlar. Bu amaçla statik test yöntemleri kullanılmaktadır.

Bunu, modül arayüzünün spesifikasyonlarına uygunluğun kontrol edilmesine odaklanan modüllerin test edilmesinin yanı sıra, sistem tasarımına ve/veya tasarımına uygunluğu kontrol etmeye odaklanan modüler yapının arayüz ve montaj sonuçlarının test edilmesi takip eder. ayrı bir programın yapısı.

Bundan sonra, program ile harici özellikleri arasındaki farkları bulmayı içeren işlev testi gelir. Fonksiyonları test ederken genellikle fonksiyonel test teknikleri kullanılır. Modüllerin test edilmesinin daha erken bir aşamasında, yöntemlerin gerekli mantık kapsamı kriterinin karakteristiği olduğu varsayılmaktadır. yapısal testler, memnun.

Geliştirme sonuçlarını orijinal hedeflerle karşılaştırmak için, tüm yazılımın tek bir bütün olarak test edildiği kapsamlı bir test süreci veya aynı zamanda sistem testi olarak da adlandırıldığı gibi ortaya çıkar. Elde edilen sonuçlar ile yazılım geliştirmenin orijinal hedefleri arasındaki farklar dikkate alındığında en büyük dikkat Harici bir spesifikasyonun geliştirilmesi sırasında ortaya çıkan çeviri hatalarının belirlenmesine odaklanır. Bu, kapsamlı testleri hayati önem taşıyor çünkü en ciddi hataların keşfedildiği aşama bu aşamada.

Test süreci yazılım testiyle sona erer. Testler çözümün eksiksizliğini kontrol etmenizi sağlar fonksiyonel görevler, kaliteleri ve yazılım ve teknik belgelere uygunluğu.

Sistem testi.Özellik testinden farklı olarak harici bir spesifikasyon, sistem testlerinin türetilmesi için bir temel olarak kullanılamaz çünkü bu, bu tür testlerin amacına aykırıdır. Öte yandan, sistemin hedeflerini bu şekilde yansıtan bir belge (bizim durumumuzda bu teknik bir spesifikasyondur), tanımı gereği doğru açıklamalar içermediğinden testlerini formüle etmek için kullanılamaz.

Sorun, operasyonel kullanıcı belgeleri kullanılarak çözülür. Sistem testleri, kullanıcı belgelerinin incelenmesinin sonuçlarına dayanarak hedeflerinin analizine dayanarak tasarlanmıştır. Bu uygulama, yalnızca programı kaynak belgeyle değil, aynı zamanda çalışma sonuçlarını kullanıcı belgeleriyle ve kullanıcı belgelerini kaynak belgeyle karşılaştırmanıza olanak tanır.

Her biri belirli amaçları test etmeyi amaçlayan çeşitli test kategorileri vardır. Bunlar arasında uygulama tamlık testi, hacim sınırı testi, yük sınırı testi, kullanılabilirlik testi, güvenlik testi, donanım yapılandırma testi, uyumluluk testi, güvenilirlik testi, kurtarma testi, bakım yapılabilirlik testi, kurulum kullanılabilirlik testi ve belge testi yer alır.

Uygulamanın eksiksizliğinin test edilmesi, kaynak belgenin her noktasının uygulanmasının kontrol edilmesini içeren en belirgin sistem testi türüdür. Doğrulama prosedürü, kaynak belgenin cümle cümle sırayla incelenmesinden oluşur. Cümle şunları içeriyorsa özel görev, ardından programın bu görevi gerçekleştirip gerçekleştirmediğini belirleyin.

Limit testi programın çalıştırılmasından oluşur. büyük hacimler tercihen önerilen operasyonel hacmi aşan veriler. Örneğin büyük bir kaynak program derleyicinin girişine test olarak beslenir, bin modül içeren bir program bağlantı düzenleyicinin girişine beslenir ve bir simülasyon programı girişe beslenir. elektronik devreler- binlerce bileşen içeren bir devre. Kapasite testinin amacı, programın orijinal hedeflerinde belirtilen miktarda veriyi işleyemediğini göstermektir.

Maksimum yüklerde test yapmak, bilgisayardaki bir sorunu çözme sürecinde bellek kaynaklarına olan ihtiyacın ve hızın, kaynak veri hacminin bileşimine bağlı olarak önemli ölçüde değişmesinden kaynaklanmaktadır. Giriş verilerinin yoğunluğu yüksek olduğunda, bir dizi yazılım problemini gerçek zamanlı olarak çözme süresi ile bu problemleri çözmedeki gerçek bilgisayar performansı arasındaki zaman dengesi bozulabilir. Aşırı yük testinin amacı, yazılımın performans hedeflerini karşılamadığını göstermektir.

Kullanılabilirlik testi, çalışma sırasında ortaya çıkan psikolojik (kullanıcı) sorunların tanımlanmasını içerir. Bu test en azından aşağıdakileri sağlamalıdır:

1. Geliştirilen arayüzün son kullanıcıyı bilgilendirmek ve eğitmek, aynı zamanda çalışmasını sağlamak için uyarlanması mümkün mü? gerçek koşullar?
2. Programın çıktı mesajları anlamlı, açık ve rahatsız edici değil mi?
3. Hata tanısı açık mı?
4. Tüm kullanıcı arayüzleri sözdizimi, kurallar, anlambilim, format, stil ve kısaltmalar açısından tutarlılık ve tekdüzelik sergiliyor mu?
5. Sistem aşırı veya kullanılması pek mümkün olmayan seçenekler içeriyor mu?
6. Sistem tüm giriş mesajları için herhangi bir onay sağlıyor mu?
7. Yazılımın kullanımı kolay ve keyifli mi?

Güvenlik testi, bilgilerin yetkisiz erişime karşı korunup korunmadığının kontrol edilmesinden oluşur. Güvenliği test etmek için yazılım güvenliğini ihlal eden testler oluşturmak önemlidir. Bu tür testleri geliştirmenin bir yolu, bilinen sorunlar böyle bir koruma mevcut sistemler ve test edilen sistemde benzer sorunların nasıl çözüldüğünü kontrol etmenize olanak tanıyan testler oluşturma.

Donanım yapılandırma testi, işletim sistemlerinin, veritabanı yönetim sistemlerinin ve iletişim sistemlerinin birden fazla donanım yapılandırmasını desteklemesi gerektiği gerçeğinden kaynaklanır (örneğin, çeşitli türler ve giriş/çıkış aygıtlarının ve iletişim hatlarının sayısı, çeşitli bellek miktarları vb.). Genellikle olası konfigürasyonların sayısı, yazılımın her birinde test edilemeyecek kadar fazladır. Ancak programın en azından her donanım türüyle minimum ve maksimum konfigürasyonlarda test edilmesi gerekir. Yazılımın konfigürasyonunu değiştirebiliyorsanız, olası tüm konfigürasyonları test etmeniz gerekir.

Uyumluluk testi, geliştirilmekte olan yazılımların çoğunun tamamen yeni olmamasından kaynaklanmaktadır. Genellikle kusurlu, güncelliğini yitirmiş bilgi işleme sistemlerinin veya manuel süreçlerin yerini alır. Bu nedenle yazılım geliştirirken değiştirilen sistemlerin çalıştığı ortamla uyumluluğun sağlanması ve gerekiyorsa bir veri işleme yönteminden diğerine geçişi sağlayacak dönüştürme prosedürlerinin oluşturulması gerekir. Bu durumda, diğer test türlerinde olduğu gibi, testler de dönüştürme prosedürünün uyumluluğunun ve işleyişinin sağlanmasına odaklanmalıdır.

Her türlü testin amacı yazılımın güvenilirliğini arttırmaktır, ancak projenin hedeflerini yansıtan kaynak belge özel talimatlar içeriyorsa, örneğin belirli zaman MTBF veya izin verilen hata sayısı belirtilirse, bu gereksinimleri karşılamak için test edilen yazılım üzerinde bir çalışma yapılması gerekir. Bu, güvenilirlik testi yoluyla yapılır. Bu tür testler için birkaç gün vardır. matematiksel modeller güvenilirlik. Daha sonra, test tamamlama kriterleri bölümünde iki güvenilirlik modeli ele alınacaktır: Mills modeli ve basit sezgisel model.

İçin işletim sistemi DBMS ve telekomünikasyon genellikle sistemin yazılım hatalarından, donanım arızalarından ve veri hatalarından nasıl kurtarılması gerektiğini tanımlar. Sistemi test ederken bu fonksiyonların yerine getirilmediğini göstermek gerekir. Kurtarma testi bunun için kullanılır. Bunu yapmak için, yazılım hatalarını kasıtlı olarak sisteme dahil ederek, bunlar ortadan kaldırıldıktan sonra düzelip düzelmeyeceğini görebilirsiniz. Donanım arızaları simüle edilebilir. Verilerdeki hatalar (iletişim hatlarına müdahale veya veritabanındaki işaretçilerin hatalı değerleri) kasıtlı olarak oluşturulabilir veya simüle edilebilir.

Bazen kaynak belge şunları içerir: özel amaçlar bakım veya yazılım bakımı kolaylığı. Yazılımın sağlanması gereken bakım araçlarını (örneğin, bellek dökümü programları, teşhis programları vb.), bir hatayı bulmak için ortalama süreyi, bakımla ilgili prosedürleri ve dahili yazılımla ilgili dokümantasyonun kalitesini tanımlayabilirler. programın mantığı. Doğal olarak tüm bu hedeflerin test edilmesi gerekiyor. Bu amaçla kullanılabilirlik testlerinden yararlanılır.

Kurulum kolaylığı testinin amacı, yazılımı belirli çalışma koşulları için özelleştirme hedeflerinin karşılanmadığını göstermektir.

Sistem kontrolü aynı zamanda kullanıcı belgelerinin doğruluğunun kontrol edilmesini de içerir. En Bu kontrol önceki sistem testlerinin doğruluğunu belirlerken gerçekleşir. Ayrıca kullanıcı belgeleri de denetimlere benzer şekilde doğruluk ve netlik açısından incelenmelidir. kaynak metin. Dokümantasyonda verilen örnekler bir test olarak tasarlanmalı ve yazılım üzerinde test edilmelidir.

Test tamamlama kriterleri. Test yapılırken, belirlenen hatanın son hata olup olmadığını belirlemek mümkün olmadığından program testinin ne zaman tamamlanması gerektiği sorusu ortaya çıkar.

Pratikte temel olarak aşağıdaki iki kritere uyulur: Çalışma programına göre test için ayrılan süre dolduğunda; tüm testler başarısız olduğunda, yani hatalar belirlenmeden gerçekleştirildi.

Bu kriterlerin her ikisi de doğru ve yeterince mantıklı değil çünkü ilk kriter testin kalitesine ilişkin bir değerlendirme içermiyor ve hiçbir şey yapmadan karşılanabiliyor, ikincisi ise test veri setlerinin kalitesine bağlı değil.

Ancak ikinci kriter belirli test tasarım metodolojilerine odaklanılarak geliştirilebilir. Örneğin, iki şekilde elde edilen testleri kullanarak modül testi için sonlandırma koşulunu belirleyebilirsiniz: koşulların kombinatoryal kapsamının karşılanması ve modül arayüzü spesifikasyonuna göre sınır değer analizi yöntemi. Sonuçta ortaya çıkan tüm testler eninde sonunda başarısız olacaktır.

Fonksiyon testinin tamamlandığı çalıştırılarak belirlenebilir. aşağıdaki koşullar: fonksiyonel diyagram yöntemleriyle elde edilen testler; eşdeğer bölümleme ve sınır değeri analizi başarısız olmalıdır.

Ancak bu kriterler öncelikle test aşamasında işe yaramaz. belirli yöntemlerörneğin sistem test aşamasında kullanılamaz hale gelmesi; ikinci olarak böyle bir ölçüm subjektiftir çünkü uzmanın gerekli metodolojiyi doğru ve doğru kullandığının garantisi yoktur; üçüncüsü, bir hedef belirlemek ve ona ulaşmanın en uygun yolunun seçilmesini sağlamak için, dikkate alınan kriterler belirli yöntemlerin kullanımını öngörür, ancak hedefler belirlemez.

Bazen büyük ölçüde sağduyuya ve test sırasında elde edilen hataların sayısına ilişkin bilgilere dayanan bir kriter kullanılır. Bunu yapmak için, hata sayısının ve bunların ortaya çıkma zamanının bağımlılığını çizin. Ortaya çıkan eğrinin şekli, teste devam etmeye değip değmeyeceğini belirler. Şekilde test süresine bağlı olarak hata sayısının grafik örnekleri gösterilmektedir.

Hata sayısının test süresine bağımlılığı.

Örnek, test süresi uzunsa ve test süresi arttıkça hata sayısı da artıyorsa doğal olarak teste devam edilmesi gerektiğini göstermektedir. Test sürecinde belli bir noktada tespit edilen hata sayısında azalma oluyorsa, tespit edilen hata sayısı giderek sıfıra yaklaşıyor veya sıfıra ulaşıyorsa test sürecinin tamamlanabileceği açıktır.

Ancak bu kriter de yeterince etkili değildir çünkü bunun kesinliği yoktur. ikinci durum Tespit edilen hataların sayısında daha fazla artış olmayacak.

Testin tamamlanma kriterini belirlemeye yönelik başka bir yaklaşım da mümkündür. Testin amacı hataları bulmak olduğundan, beklenen toplam hata sayısının belirli bir kısmına karşılık gelen, önceden belirlenmiş belirli sayıda hata kriter olarak seçilebilir. Ancak bu kriterin kullanılmasında bazı sorunlar bulunmaktadır. Öncelikle programdaki toplam hata sayısını tahmin etmek gerekir. İkinci olarak bu hataların yüzde kaçının test yapılarak belirlenebileceğini bulmak gerekir. Son olarak, hataların hangi kısmının tasarım sürecinde ortaya çıktığını ve hangi test aşamalarında tespit edilmesinin önerildiğini belirlemek gerekir.

Toplam hata sayısını tahmin etmek ve test yoluyla tespit edilebilecek hataların olası yüzdesini belirlemek için, güvenilirlik göstergelerinin (güvenilirlik modelleri) belirlenmesinde kullanılan yöntemleri, örneğin Mills modelini veya basit bir sezgisel modeli kullanabilirsiniz. biraz sonra değerlendireceğim.

Böyle bir tahmin elde etmenin başka bir yolu da endüstride yaygın olarak kullanılan statik ortalamalara dayanmaktadır. Örneğin, tipik programlarda kodlama tamamlanana kadar (gözden geçirme veya incelemeden önce) mevcut olan hataların sayısı, 100 program bildirimi başına yaklaşık 4 ila 8'dir.

Mills modeli, test sırasında programda gerçekte bulunan artık hataların sayısını tahmin etmek için programa hatalar eklemeye dayanmaktadır. Programı bir süre kontrol ederek ve programda mevcut olan hataları ayıklayarak, başlangıçta programda bulunan hataların sayısını ve değerlendirme sırasında kalan hataların sayısını tahmin edebilirsiniz.

Programa rastgele S hataları eklenirse, test sırasında n+V hata bulunur (n, bulunan hataların sayısıdır) kendi hataları; V, bulunan, ortaya çıkan hataların sayısıdır), o zaman programda başlangıçta bulunan kendi hataların tahmini sayısı şu formül kullanılarak hesaplanabilir: .

Örneğin, başlangıçta ortaya çıkan hataların toplam sayısı 25'e eşit olacak şekilde 20 adet kendi ve 10 adet kaynaklı hata tespit edilirse, değer N=25*20/10 = 50; onlar. Bu aşamada programın kendine ait 50 hatası olduğu varsayılarak testlere devam edilmesi gerekmektedir.

Her yeni hata tespitinden sonra N sayısı tahmin edilebilir.

Tüm tanıtılan hatalar tespit edilene kadar programda hata ayıklama yapılmalıdır. Ortaya çıkan hatalar tespit edildiğinde, tahminin doğru olma olasılığını gösteren bir güven düzeyi C belirlenebilir:

burada k, kendi hatalarının tahmini sayısıdır, S, ortaya çıkan hataların sayısıdır, n, tespit edilen kendi hatalarının sayısıdır.

Örneğin programda hiçbir hata olmadığını (k = 0) iddia edersek ve programa 6 hata eklendiğinde hepsi tespit edildi ancak kendi hatası tespit edilmediyse, o zaman C = 6/(6 + 0 + 1) = 0, 86. Öte yandan 0,98'lik bir güven düzeyine ulaşmak için programa 39 hatanın dahil edilmesi gerekir: C=39/(39 + 0 + 1)=0,98.

Mills modelinin bir takım eksiklikleri yok değil; bunların en önemlileri, yapay hatalar ekleme ihtiyacı (bu süreç yeterince resmileştirilmemiştir) ve k değerinin (kendi hatalarının sayısı) oldukça gevşek bir varsayımıdır. yalnızca değerlendirmeyi yapan kişinin sezgisine bağlıdır; itiraf ediyor büyük etki subjektif faktör.

Basit bir sezgisel model, iki grup programcının birbirinden bağımsız olarak bağımsız test takımları kullanarak test etmesini içerir.

Test sürecinde her grup bulduğu tüm hataları kaydeder. Programda kalan hata sayısını değerlendirirken her iki grubun test sonuçları toplanır ve karşılaştırılır.

İlk grubun N 1 hata keşfettiği, ikinci N 2 hatanın ve N 12'nin her iki grup tarafından keşfedilen hatalar olduğu ortaya çıktı.

Test başlamadan önce programda mevcut olan bilinmeyen hata sayısını N ile belirtirsek, her grubun test verimliliği şu şekilde belirlenebilir:

Tüm hataları tespit etme yeteneğinin her iki grup için de aynı olduğu varsayılırsa, ilk grubun tüm hataların belirli bir sayısını bulması durumunda, rastgele seçilen herhangi bir alt kümenin aynı sayısını belirleyebileceği varsayılabilir.

Özellikle, şu varsayılabilir:

N 12'nin değeri bilinmektedir ve E 1 ve E 2, N 12/N 1 ve N 12/N 2 olarak tanımlanabilir. Böylece programdaki bilinmeyen hata sayısı aşağıdaki formülle belirlenebilir:

Bu modeli daha da ileri götürerek ve her iki test grubunun da sahip olduğu varsayımlara dayanarak eşit olasılık"genel" hataların tespiti, şu şekilde hesaplanabilir: aşağıdaki formül:

burada P(N12i), iki bağımsız grup tarafından program testinde N 12 "ortak" hataların tespit edilme olasılığıdır.

Tasarım sürecinde ortaya çıkan hataların belirlenmesinde, büyük yazılımlarda tüm hataların yaklaşık %40'ının mantık tasarımı ve kodlama hataları olduğunu, geri kalanının ise daha fazla kişi tarafından yapıldığını belirten veriler kullanılır. erken aşamalar tasarım.

Buna dayanarak bir örneğe bakalım. Diyelim ki 1000 ifade büyüklüğünde bir program test ediliyor; Kaynak kodunun incelenmesinden sonra kalan hata sayısının 100 ifade başına 5 olduğu tahmin edilmektedir. Testin amacı kodlama ve mantık hatalarının %98'ini, tasarım hatalarının ise %95'ini tespit etmektir.

Toplam hata sayısı 500'dür. Bunlardan 200'ünün kodlama ve mantık hatası, 300'ünün ise tasarım hatası olduğu varsayılmaktadır. Bu nedenle 196 adet kodlama ve mantık hatası ile 285 adet tasarım hatasının bulunması gerekmektedir.

nedenlerden dolayı sağduyu Bulunan hataların yüzdesini tabloda gösterildiği gibi test aşamalarına dağıtmak mantıklıdır.

Yüzde Test aşamalarında bulunan hatalar.

Bu sayılara dayanarak aşağıdaki kriterler belirlenebilir.

1. Modül test aşamasında 130 hatanın bulunması ve düzeltilmesi gerekir (tahmini 200 kodlama ve mantık hatasının %65'i).
2. Sistem test aşamasında 6 hatayı ve 105'i (200'ün %3'ü ve 300'ün %35'i) bulup düzeltmek gerekiyor.

Bu tür kriterlerle ilgili bir diğer bariz sorun, aşırı tahmin sorunudur. Peki ya özellik kontrolü başladığında yukarıdaki örnekte 240'tan az hata kaldıysa? Bu kritere göre özellik test aşamasını tamamlamak hiçbir zaman mümkün değildir. Böyle bir durumdan kaçınmak için, hata sayısına ilişkin kriterin, bunların tespit edilmesi gereken süre ile desteklenmesi gerekmektedir. Bu durumda hatalar hızlı bir şekilde bulunursa belirli bir aşamadaki testlere, belirlenen zaman aralığının sonuna kadar devam edilmelidir. Aşırı tahmin meydana gelirse, ör. zaman geçti ve belirtilen miktar hiçbir hata bulunamadıysa, sorunun nedenleri hakkında fikrini ifade edecek ilgisiz bir uzmanı davet etmelisiniz: ya testler etkili değil ya da testler başarılı, ancak programda gerçekten çok az hata var.

Testi tamamlamanın en iyi kriteri, dikkate alınan üç yaklaşımın birleşimidir. Modüllerin test edilmesi için dikkate alınan ilk kriter optimal olacaktır çünkü çoğu projede bu aşamada tespit edilen hataların sayısı izlenmez; burada belirli bir dizi test tasarım yönteminin kullanılması önemlidir. Fonksiyon ve sistem testi aşamalarında, sonlandırma kriteri ulaşıldığında durdurulabilir. verilen numara Tespit edilen hatalar veya noktaya gelinmesi, programa göre belirlenir hata sayısının test süresine bağımlılığının analizinin üretkenlikte bir azalma göstermesi koşuluyla çalışma.

) hızlı stres testini göstermek için bir video kaydetti. Onun örneğinde yaklaşım, uygulama sihirbazına büyük miktarda veri beslemek ve esasen uygulamayı kendisini yüklemeye zorlamaktı.

Video neredeyse altı dakika sürüyor. Yaklaşık yarısına gelindiğinde James şunu soruyor: “Neden şimdi durmak istemediğimi merak ediyor olabilirsiniz. Bunun nedeni, durumun giderek kötüleştiğini görmemizdir. Şimdi durabiliriz ama devam edersek daha kötü şeyler görebiliriz." Böylece teste devam etti. Ve kısa bir süre sonra James, durmak için bir buluşsal yöntem önerdi: Şu durumlarda dururuz: 1) yeterince keşfettiğimizde ciddi sorun veya 2) programın davranışında belirgin bir değişiklik yok - program bir bütün olarak istikrarlı bir şekilde çalışıyor veya 3) teste devam etmenin değeri maliyeti haklı çıkarmıyor. Bunlar testi durdurmak için kullanılan buluşsal yöntemlerdi.

Bu videoyu ilk gördüğümden yaklaşık bir yıl sonra, Better Software dergisindeki bir sütunda testi durdurmaya yönelik buluşsal yöntemleri daha ayrıntılı olarak açıklamaya karar verdim. James ve ben bu konuda ileriye dönük bir konuşma yaptık. Sütunu bulabilirsiniz. Bir yıl sonra bu köşe yazısı, birçok yerde verdiğim resmi olmayan bir konferansa dönüştü.

Bundan yaklaşık altı ay sonra ikimiz de testi durdurmak için daha fazla buluşsal yöntem bulduk. Bunları STAR East 2009'da tartıştık ve o sırada oradan geçmekte olan Dale Emery ve James Lyndsay de tartışmaya katıldı. Dale özellikle, bir savaş sırasında ateşin birkaç durumda durdurulabileceğini öne sürdü: geçici bir sessizlik, "ateşi durdurma" emri, taraflar arasında ateşkes konusunda anlaşma, tarafların geri çekilmesi. başlangıç ​​pozisyonları, düşmanın silahsızlandırılması. Bunu ilginç buldum.

Genel olarak şimdi size bulduğumuz tüm buluşsal yöntemleri anlatacağım. Durdurmaya yönelik bu buluşsal yöntemlerin tam olarak buluşsal yöntem. Buluşsal yöntemler hızlı ve ucuz yöntemlerdir problem çözme veya karar verme. Buluşsal yöntem hataya açık yani çalışabilirler veya çalışmayabilirler. Buluşsal yöntemler yeterince soyut değildir, birbirleriyle örtüşebilir ve kesişebilirler. Ayrıca buluşsal yöntemler bağlama bağlı Dolayısıyla bunları akıllıca kullanabilecek bilgi ve beceriye sahip kişiler tarafından kullanılması beklenir. Aşağıda buluşsal yöntemleri listeledim ve her biri için kullanımının geçerliliğini kontrol edebileceğiniz bazı sorular belirttim.

1. Sezgisel"Zamanortaya çıktı!» . Birçok test profesyoneli için bu en yaygın buluşsal yöntemdir: kendisine ayrılan süre dolduğunda testi durdururuz.

Ürün hakkında bilmemiz gereken bilgileri aldık mı? Testi durdurma riski çok mu yüksek? Olumsuzöyleydiikisinden biriterimyapay, keyfi? İradeikisinden birigerçekleştirilmekek olarakgelişim, Hangigerektirecekek olaraktest?