Otomatik testin dezavantajları nelerdir?

Bu sitede, otomatik testlerden kazanılabilecek faydalar hakkında bol miktarda bilgi veren birkaç soru var. Ancak madalyonun diğer tarafını temsil eden hiçbir şey görmedim: dezavantajları nelerdir? Hayattaki her şey bir tradeoff ve gümüş mermi yok, bu yüzden kesinlikle otomatik test yapmak için bazı geçerli nedenler olması gerekir. Onlar neler?

İşte geldiğim birkaç tane:

• Belirli bir özellik için daha fazla ilk geliştirici zamanı gerektirir
• Ekip üyelerinin daha yüksek bir beceri düzeyi gerektirir
• Takım gereksinimlerini arttırın (test rayları, çerçeveler vb.)
• Başarısız bir testle karşılaşıldığında gerekli olan karmaşık analiz - bu test benim değişikliğimden dolayı eski mi yoksa bir hata yaptığımı mı söylüyor?

Düzenleme
Ben otomatik test büyük bir savunucusu olduğumu söylemeliyim ve bunu yapmak için ikna olmak istemiyorum. Dezavantajların ne olduğunu anlamaya çalışıyorum, bu yüzden bir dava açmak için şirketime gittiğimde, bir sonraki hayali gümüş merminin etrafına atıyormuş gibi görünmüyorum.

Ayrıca, yukarıdaki örneklerime karşı çıkacak birisini aramayacağımı açıkça söylüyorum . Bazı dezavantajların olması gerektiğine (her şeyin değişmesi) doğru olduğunu kabul ediyorum ve bunların ne olduğunu anlamak istiyorum.

En önemlilerinden çok hoşlanıyordunuz. Birkaç küçük ilavelerim var, artı testlerin gerçekten dezavantajı - gerçekten istemediğiniz zamanlar (aşağıya bakınız).

• Geliştirme zamanı: Test odaklı geliştirme ile bu, birim testler için zaten hesaplanmıştır, ancak yine de otomasyon koduna ihtiyaç duyan entegrasyon ve sistem testlerine ihtiyacınız var. Bir kez yazılan kod genellikle daha sonraki birkaç aşamada test edilir.

• Beceri seviyesi: elbette araçlar desteklenmeli. Ama bu sadece kendi takımın değil. Daha büyük projelerde, ekibinizin ürünü ile diğer ürünler arasındaki arayüzleri kontrol etmek için testler yazan ayrı bir test ekibiniz olabilir. Çok fazla insanın daha fazla bilgiye sahip olması gerekiyor.

• Takım ihtiyacı: Orada bulunuyorsunuz. Buna eklenecek fazla bir şey yok.

• Başarısız olan testler: Bu gerçek bir gericidir (zaten benim için). Her biri bir dezavantaj olarak görülebilecek bir sürü farklı neden var. Ve en büyük dezavantaj, bu nedenlerden hangisinin başarısız testiniz için geçerli olduğuna karar vermek için gereken zamandır.

  • Gerçek bir hata nedeniyle başarısız oldu. (sadece bütünlüğü için, elbette avantajlı olduğu için)
  • başarısız oldu, çünkü test kodunuz geleneksel bir hatayla yazılmış.
  • Test kodunuz ürününüzün eski bir sürümü için yazılmış olduğundan ve artık uyumlu olmadığından başarısız oldu
  • başarısız oldu, çünkü gereksinimler değişti ve test edilen davranış şimdi 'doğru' kabul edildi

• Başarısız olmayan testler: Bunlar da bir dezavantajdır ve oldukça kötü olabilir. Bir şeyleri değiştirip Adam'ın cevapladığı şeye yaklaştığınızda çoğunlukla oluyor. Ürününüzün kodunda bir şey değiştirirseniz, ancak test bunu hesaba katmazsa, size bu "sahte güvenlik duygusunu" verir.

  Başarısız olan testlerin önemli bir yönü, bir gereksinim değişikliğinin daha erken davranışların geçersiz hale gelmesine neden olabileceğidir. İyi bir izlenebilirliğe sahipseniz, gereksinim değişikliği test kodunuzla eşleştirilebilmelidir ve artık bu teste güvenemeyeceğinizi biliyorsunuz. Tabii ki, bu izlenebilirliği sağlamak başka bir dezavantajdır. Ve eğer yapmazsanız, başarısız olmayan bir teste girersiniz, ancak aslında ürününüzün yanlış çalıştığını doğrularsınız . Yolun aşağısındaki bir yerde bu size isabet edecek .. genellikle en az beklediğiniz yerde.

• Ek dağıtım maliyetleri: Ünite testlerini yalnızca kendi makinenizde geliştirici olarak yapmazsınız. Otomatikleştirilmiş testler ile, birisinin çalışmanızı ne zaman bozduğunu öğrenmek için merkezi bir yerde başkalarının yaptıkları taahhütlerde bulunmak istersiniz. Bu güzel, ama aynı zamanda kurulması ve bakımı gerekiyor.

Ekibimizde otomatik testleri denemeye yeni başlamamdan sonra, gördüğüm en büyük dezavantaj, otomatik testler göz önünde bulundurularak tasarlanmamış eski kodlara başvurmanın çok zor olmasıdır. Kuşkusuz uzun vadede kodumuzu geliştirecekti, ancak akıl sağlığımızı koruyarak otomatik testler için gerekli refactoring seviyesi kısa vadede giriş için çok yüksek bir engel teşkil ediyor, bu da otomatik hale getirme konusunda çok seçici olmamız gerektiği anlamına geliyor. kısa vadeli taahhütlerimizi yerine getirmek için birim testi. Başka bir deyişle, zaten teknik borçta olduğunuzda kredi kartlarını ödemek çok daha zordur.

Belki de en önemli dezavantajı ... testler üretim kodudur . Yazdığınız her test, kod tabanınıza sürdürülmesi ve desteklenmesi gereken bir kod ekler. Bunu yapmamak, sonuçlarına inanmadığınız testlere yol açar, bu nedenle başka seçeneğiniz yoktur. Beni yanlış anlama - Ben otomatik testlerin büyük bir savunucusuyum. Ama her şeyin bir bedeli var ve bu büyük bir tanesi.

Bunların tamamen uygulanabilir dezavantajlar olduğunu söyleyemem, ama en çok çarptığım birkaç kişi:

• Karmaşık bir kurumsal uygulamada testin kurulması için geçen süre.
• Yanlış yapılan eski testlerin ele alınması, başka bir deyişle, sistem gelişti ve şimdi testler yanlış.
• Yamalı veya bilinmeyen test kapsamından yapılan yanlış güven.

Düzensiz olan test kapsamı yanlış bir güvenlik hissine yol açabilir. Bir yeniden düzenleyici yapar ve testin geçerliliğini kanıtlamak için kullanırsanız, testlerinizin bunu kanıtlayabildiğini ispatlayan şey nedir?

Testi oluşturmak için geçen süre bazen bizim için bir sorundur. Otomatikleştirilmiş testlerimiz sadece birim testlerini değil aynı zamanda vaka testlerini de kullanır. Bunlar daha geniş olma ve içerik gerektirme eğilimindedir.

Tabii ki, bakış açım, birim testlerinden daha eski olan bir uygulamadan.

Onlarla ilgili temel sorun, yanlış bir güvenlik hissi sağlayabileceklerini söyleyebilirim . Sırf testleriniz olduğu için, aslında bir şey yaptıkları anlamına gelmez ve bu gereksinimlerin uygun şekilde test edilmesini içerir.

Buna ek olarak, otomatik testler kendileri de içerebilir , böylece birim testlerin kendilerini test etmeleri gerekip gerekmediği sorusu gündeme gelir, bu nedenle mutlaka bir şey başaramazsınız.

Otomasyon testinin birçok avantajı olmasına rağmen, kendi dezavantajları da vardır. Dezavantajların bazıları:

• Otomasyon test senaryolarını yazmak için yeterlilik gereklidir.
• Test komut dosyasını hata ayıklamak büyük bir konudur. Test komut dosyasında herhangi bir hata varsa, bazen ölümcül sonuçlara neden olabilir.
• Oynatma yöntemleri durumunda test bakımı maliyetlidir. GUI'de küçük bir değişiklik olmasına rağmen, test komut dosyasının yeniden kaydedilmesi veya yeni bir test komut dosyası ile değiştirilmesi gerekir.
• Test komut dosyası daha fazla ekran test ediyorsa test veri dosyalarının bakımı zordur.

Yukarıdaki dezavantajların bazıları çoğu zaman otomatikleştirilmiş komut dosyalarından kazanılan faydadan kaynaklanmaktadır. Otomasyon testinin artıları ve mısırları olsa da, tüm dünyada yaygın olarak uyarlanmaktadır.

Geçenlerde oyun geliştirme testleriyle ilgili bir soru sordum - bu BTW'yi bunun hakkında nasıl bildiğimi biliyor. Buradaki cevaplar bazı ilginç, dezavantajlara işaret etti:

1. Kodunuzun yüksek oranda bağlanması gerektiğinde yapılması maliyetlidir .
2. Çeşitli donanım platformlarının farkında olmanız gerektiğinde, kullanıcıya çıktıyı analiz etmeniz gerektiğinde ve kod sonucunun yalnızca daha geniş bir bağlamda mantıklı olması durumunda yapmak zordur .
3. UI ve UX testi çok zor .
4. Ve özellikle, otomatikleştirilmiş testler bir grup çok düşük maliyetli (veya ücretsiz) beta test cihazından daha pahalı ve daha az etkili olabilir .

Dördüncü nokta, bazı deneyimlerimi hatırlamama neden oluyor. Birim testlerinin şiddetle tavsiye edildiği, çok eğilimli, XP odaklı, Scrum tarafından yönetilen bir şirkette çalıştım. Ancak, daha yalın, daha az bürokratik bir tarza giden yolda, şirket QA ekibinin yapımını ihmal etti - test etmedik. Sık sık müşteriler,% 95'ten fazla test kapsamına sahip olsa bile, bazı sistemleri kullanarak önemsiz hatalar buldular. Bu yüzden başka bir nokta eklemek istiyorum:

• Otomatik testler , KG ve testlerin önemli olmadığını düşünmenize neden olabilir .

Ayrıca, o günlerde belgelendirme hakkında düşünüyordum ve iki test için geçerli olabilecek (daha az bir ölçüde) bir hipotez kurdum. Kodun o kadar çabuk geliştiğini hissettim, böylesi bir hızı izleyen dokümantasyon yapmak oldukça zor, bu yüzden zaman harcayarak kodun okunması zor, kolayca eski dokümantasyon yazmaktan daha değerli. (Elbette bu , API'ler için geçerli değildir , ancak yalnızca dahili uygulama için geçerlidir.) Test aynı sorundan biraz muzdariptir: test edilen kodla karşılaştırıldığında yazmak çok yavaş olabilir. OTOH, daha az sorun yaratıyor çünkü testler eski oldukları konusunda uyarıyor, belgeleriniz çok dikkatli bir şekilde yeniden okumadığınız sürece sessiz kalacak .

Son olarak, bazen bulduğum bir sorun: otomatik testler araçlara bağlı olabilir ve bu araçlar kötü yazılmış olabilir. Bir süre önce XUL kullanarak bir projeye başladım ve bu tür bir platform için birim testleri yazmak çok acı verici. Objective-C, Cocoa ve Xcode 3 kullanarak başka bir uygulamaya başladım ve test modeli temelde bir sürü geçici çözümdü.

Otomatik testin dezavantajları hakkında başka deneyimlerim var, ancak çoğu diğer cevaplarda listeleniyor. Yine de, otomatik testlerin zorlu bir savunucusuyum. Bu, çok fazla iş ve baş ağrısından kurtardı ve her zaman varsayılan olarak tavsiye ederim. Bu dezavantajların, otomatik testlerin yararları ile karşılaştırıldığında sadece ayrıntı olduğunu düşünüyorum. (Otomatik karar vermemek için herşeyi yorumladıktan sonra her zaman inancınızı ilan etmeniz önemlidir.)

Bahsetilmeyen iki tanesi:

• Büyük bir test takımının çalışması için geçen süre

Testleri yavaşlattığı için testlerin yarım gün sürdüğü otomatik KG çalışmalarının bir parçası oldum. Testlerinizi yazmakta dikkatli değilseniz, test takımınız da bu şekilde ortaya çıkabilir. Şimdi o zamanı yönetene kadar bu büyük bir sorun gibi görünmüyor, "Ah, sadece bir düzeltme yaptım, ancak doğruluğu ispatlamak 4 saat sürecek".

• Bazı test yazma yöntemlerinin zayıflığı

Bazı test yöntemlerinin (kullanıcı arayüzünü otomatikleştirme gibi), her geri döndüğünüzde kırıldığı görülüyor. Özellikle eğer senaryonuz, bir düğmenin görünmesini beklediği için test sürecini askıda bırakıyorsa acı vericidir - ancak düğme yeniden adlandırılmıştır.

Bunlar, iyi bir test uygulamasıyla birlikte çalışabileceğiniz her şeydir: Test takımınızı hızlı tutmanın yollarını bulun (test çalışmalarını makinelere / CPU'lara dağıtma gibi işlemler yapmanız gerekse bile). Aynı şekilde, zayıf yazma testleri yöntemlerinden de kaçınmaya çalışmak için özen gösterilebilir.

Bir tane daha, yanlış bir güvenlik hissi eklemek istiyorum.

Çok küçük iyi tanımlanmış problem kümelerinin ötesinde, kapsamlı testler oluşturmak mümkün değildir. Yazılımımızda otomatik testlerin basitçe test edemediği hatalar olabilir ve sık sık yine de olacaktır. Otomatikleştirilmiş testler başarılı olduğunda, hepimiz çok sık kodda bir hata olmadığını varsayıyoruz.

Yönetimi / girişim kapitalistini ikna etmek zor

• testautomation önceden belirlenmiş maliyeti arttırır.
• testautomation pazara çıkış süresini arttırır.
• testautomasyonun yararı orta ve logtermde gelir. şiddetli rekabet, kısa vadeli faydalara daha fazla odaklanır.

bkz Pazar Unit Test Driven detaylar için.

Başlıca dezavantajlardan biri kendi kendine öğrenme testleri kullanılarak aşılabilir. Bu durumda, beklenen sonuçların tümü veri olarak saklanır ve kendi kendine öğrenme modunda test paketi kullanıcısı tarafından minimal inceleme ile güncellenebilir (eski tuşuna basıldığında beklenen sonuç ile yeni gerçek sonuç arasındaki farkları gösterir). Bu testsuite öğrenme modu dikkatli kullanılmalıdır, bu yüzden buggy davranışı kabul edilebilir olarak öğrenilmez.