Test Bilgisayar Yazılımlarının çoğunu 25 yıl önce yazdım. O zamandan beri kitabın eski ya da sadece yanlış olduğunu düşündüğüm birkaç bölümüne işaret ettim. Bkz. Http://www.kaner.com/pdfs/TheOngoingRevolution.pdf
Kara Kutu Yazılım Test Kursu (videolar ve slaytlar ücretsiz olarak kullanılabilir) için sitemde daha fazla (mevcut görünümler, ancak TCS'ye açık işaretçiler olmadan) görebilirsiniz, www.testingeducation.org/BBST
O zamanlar test kültürü büyük ölçüde doğrulayıcıydı.
Modern testlerde, birim test yaklaşımı büyük ölçüde doğrulayıcıdır - yazılımın istendiği gibi çalışmaya devam ettiğini doğrulayan büyük otomatik test koleksiyonları yazıyoruz. Testler değişiklik dedektörleri olarak hizmet eder - eğer kodun diğer kısımlarında bir şey varsa ve bu kısımda şimdi problemler varsa veya gerçek dünyada imkansız olan veri değerleri artık uygulamaya ulaşıyorsa, değişiklik dedektörleri tetiklenir ve bir bakım problemi.
Doğrulayıcı zihniyet birim testi için uygun olduğunu düşünüyorum, ancak tüm sistem testlerinin doğrulayıcı olduğu bir dünya hayal edin (ayrım yapan insanlar için lütfen sistem hakkındaki yorumlarımda yer alan "sistem entegrasyon testi" ve "kabul testi" ni yorumlayın Testin amacı, programın özelliklerini karşıladığını doğrulamaktı ve baskın yaklaşım, özelliğin parçalarını programın davranışlarıyla eşleştiren bir milyon (veya en az birkaç yüz) sistem düzeyinde regresyon testi oluşturmaktı. (Bence davranışa uygunluk teyidi yararlıdır, ancak daha büyük bir hedefin küçük bir kısmı olduğunu düşünüyorum.)
Hala bu şekilde çalışan test grupları var, ama artık baskın görüş değil. O zamanlar öyleydi. Kesin bir şekilde yazdım ve bu zihniyette sürekli olarak eğitilen insanlara bir nokta koymak için keskin kontrastlar çizdim. Bugün, bazı keskin kontrastlar (burada alıntılananlar dahil) modası geçmiş. Yanlış görüşlere saldırı olarak yanlış yorumlanıyorlar.
Gördüğüm gibi, yazılım testi, bir yazılım ürünü veya hizmeti hakkında kalite ile ilgili bilgileri öğrenmek için ampirik bir süreçtir.
Yararlı bilgileri ortaya çıkarmak için bir test tasarlanmalıdır.
O zamanlar, bu arada, hiç kimse "bilgi" yi ortaya çıkarmak için bir yöntem olarak testten bahsetmedi. O zamanlar testler, hataların (bazı sürümleri) bulunması ya da programın spesifikasyonlara göre doğrulanması (kontrol edilmesi) içindi. Testlerin yararlı bilgileri ortaya koyma iddiasının bu yüzyıla kadar test kelime dağarcığına geldiğini düşünmüyorum.
Bilgi değerlerine göre derecelendirme testlerini hayal edin. Bize yazılım hakkında bilmediğimiz bir şeyi öğretme olasılığı yüksek olan bir testin çok yüksek bir bilgi değeri olacaktır. Beklediğimiz bir şeyi teyit etme olasılığı yüksek olan ve daha önce defalarca gösterilmiş olan bir test, düşük bir bilgi değerine sahip olacaktır. Testlere öncelik vermenin bir yolu, daha düşük bilgi değeri testlerinden önce daha yüksek bilgi değeri testleri yapmaktır.
Bu önceliklendirmeyi, yazılım testi hakkında clueless olan bir programcı, proje yöneticisi veya süreç yöneticisinin dikkatini çekecek şekilde basitleştirecek olsaydım, "Bir HATAYI GEREKTİRMEK İÇİN TASARLANMAYAN BİR TEST ZAMANIN ZAMANI ." Mükemmel bir çeviri değil, ancak herhangi bir inceliği veya niteliği anlayamayan veya anlayamayan okuyucular için, bu elde edilebilecek kadar yakın.
O zamanlar burada tekrar görüyorum ki, testi anlamayan bazı insanlar, köşe vakalarını bulmak için tasarlanan bir testin, büyük bir fonksiyonun büyük bir kullanım testine kıyasla zaman kaybı olduğunu yanıtlayacaktır. İki şeyi anlamıyorlar. İlk olarak, test kullanıcıları sınır değerlerini kontrol etmek için zaman bulduğunda, ana fonksiyonların ana kullanımları zaten birkaç kez uygulanmıştır. (Evet, istisnalar vardır ve çoğu test grubu bu istisnalara dikkat eder.) İkincisi, aşırı değerlerle test etmenin nedeni, programın aşırı değerlerle başarısız olma olasılığının daha yüksek olmasıdır. Aşırı derecede başarısız olmazsa, başka bir şey test edersiniz. Bu etkili bir kuraldır. Öte yandan, aşırı bir değerde başarısız olursa, test cihazı durup bir hata rapor edebilir veya test cihazı daha fazla sorun giderebilir, daha normal değerlerde programın aynı şekilde başarısız olup olmadığını görmek için. Bu sorun gidermeyi kim yapıyor (test eden veya programlayan) kurum kültürü meselesidir. Bazı şirketler test edenin bunun için zaman ayırmasını sağlarken, bazıları programcıların bütçesini, bazıları ise programcıların genelleştirilebilir olup olmadıklarını ya da sorun gidermenin uygun olmaması için köşe kutusu hatalarını düzeltmelerini bekler. Yaygın yanlış testler - test uzmanlarının aşırı değerleri test ederek (verimliliği en üst düzeye çıkarmak yerine) zaman kaybettiklerinin bir diğer nedeni de "Bir hatayı ortaya çıkarmak için tasarlanmamış bir test zaman kaybıdır" test kullanıcıları için uygun bir mesajdır. Bu, bazı programcıların (aslında) asla programa meydan okuyabilecek testler yapmaya teşvik edilmesinin bir karşılığıdır. İleti aşırı basitleştirildi, ancak tüm tartışma aşırı basitleştirildi.
Bu arada, "bilgi değeri" tek önceliklendirme sistemi olamaz. Birim test takımları tasarlarken benim kuralım değil. İnşa doğrulama testleri (akıl sağlığı kontrolleri olarak da adlandırılır) tasarladığımda bu benim kuralım değil. Her iki durumda da, münferit testlerin gücünden ziyade kapsam türleri ile ilgileniyorum. Bireysel testlerin gücünün tasarımımla alakasız olduğu diğer durumlar (örn. Kurulumu, çalıştırılması ve izlenmesi ucuz olan yüksek hacimli otomatik testler) vardır. Eminim ek örnekler düşünebilirsiniz.
Ancak genel bir kural olarak, sadece bir kuralı belirleyebilseydim (örneğin, başı birden fazla cümleyi işlemeye çalışırsa patlayan bir yöneticiye konuşmak), düşük bir bilgi-değer testinin genellikle zaman kaybı olduğu anlamına gelir.