Otomatik Test: İş Değerini Açıklamak

Bunun olduğunu sanmıyorum başlatmak için tekrar ait diğer sorular üzerinde birim test . Yardım aradığım şey, değerini bir programcı, analist, yönetici ve test ekibine eklemektir. Otomatikleştirilmiş testler sayesinde, birim testleri (örn. JUnit), BDD (örn. JBehave, Fitness) ve UI (Selenium, Watir) arasında bir ayrım yapmam gerektiğini düşünmüyorum çünkü hepsinin benzer bir değer sağladığını düşünüyorum (ancak katılmıyorum bir cevap yaz :))

Aşağıda tanımladığım bir liste var; genişletmeye veya hassaslaştırmaya yardımcı olan cevapları arıyorum:

1. Zaman / Maliyet Tasarrufu : otomatik testler yazmak, yazılı test durumlarından daha fazla zaman alabilir. Bununla birlikte, testlerin birden çok kez yapıldığını göz önünde bulundurarak, otomatik testleri gerçekleştirmek için yapılan marjinal çalışma (yani maliyet / zaman) birkaç büyüklükten daha azdır. Otomatikleştirilmiş testlerin çalıştırılmasının ucuz olması sistemin zamanla değiştirilmesini kolaylaştırır .
2. Belgeleme : Bir sistemin testlerinden daha iyi çalıştığını bilmenin kesin bir yolu yoktur. Diğer tüm belgeler genellikle yazıldığı an eskidir, ancak testler (en azından başarılı olanlar) aslında işlerin nasıl yürüdüğünü gösterir. Bu, hem son kullanıcı hem de API dokümantasyonu için geçerlidir.
3. Kod Kalitesi : Test yazma sizi zorlar:
   • müşterileri düşünün çünkü testler bir müşteridir
   • Kodun test edilebilir hale getirilmesinin sıklıkla bağımlılıklara son verir; bu kodun başka bir büyük sisteme ihtiyaç duyulmasını gerektirmeyen kodun nasıl yapıldığını bulmak anlamına gelir.

Düşüncelerimin birkaçı:

1. Otomatikleştirilmiş testler yazmanın daha fazla zaman alacağı konusunda dürüst olun. Birim düzeyinde TDD yapıyorsanız (otomatik sınamaya yatırım yapacaksanız başlangıç ​​noktası olarak önereceğim), bir özelliği kodlamak için gereken yaklaşık% 30 ekstra zaman bekleyebilirsiniz. Buradaki kilit nokta, bu ekstra% 30’un (takımınız iyi testler yazmayı öğrendiğinde muhtemelen başlangıçta% 30’dan yüksek) zamanla maliyetten tasarruf etmek için yapılan bir yatırım olduğunu açıklamaktır. En az TDD biriminde olduğu gibi, sisteminizin tasarımı gevşek bir şekilde bağlanmıştır ve sisteminizi zaman içinde değişime uyarlanabilir kılar. Yeni gereksinimler ve beklenmedik hatalar her zaman sisteminizde değişiklik yapılmasını gerektirir,
2. Bu testleri yazmak için geçen süre, ne kadar sürdüğü ve ne kadar bakıma ihtiyaç duydukları göz önüne alındığında Kabul seviyesi ve UI seviyesi testlerinin değeri hakkında çok fazla tartışma vardır. Bu yazıyı James Shore tarafından bu konuda okumanızı tavsiye ederim .
3. Otomatik test dünyasında, bunu yapmanın iyi ve kötü yolları vardır. Yönetiminize otomatik testler uyguluyorsanız, ekibinizin iyi testler yazma konusunda eğitilmesini nasıl planladığınızı da düşünürüm. Roy Osherove tarafından Ünite Testi Sanatı, Michael Feathers'ın Eski Koduyla Etkili Çalışmak ve James Shore'den Çevik Gelişim Sanatı, doğrudan veya dolaylı olarak bu konularla ilgilenen harika kitaplardır. Ayrıca bir tür koç ya da resmi bir eğitime de bakmalısınız. Bu büyük bir değişiklik.
4. İş Değeri açısından, yukarıdaki puanlarınızın # 2 ve # 3'ü aslında ilk puanınızı veriyor, ben de # 1 numaralı noktayı eve vuracağım ve # 2 ve # 3'ün bu daha büyük noktaya nasıl hizmet ettiği hakkında konuşacağım. Belgelendirme sisteminizi daha anlaşılır kılar, bu da ekibinizin daha hızlı çalışmasını sağlar. Kod Kalitesi sisteminizi değişime uyarlar, bu da ekibinizin daha hızlı çalışmasını sağlar. İş adamları için, bir fikrin ortaya konduğu andan, fikrin çalışan yazılım olarak sunulduğu zamana kadar değer akışını en üst düzeye çıkarmakla ilgilidir.

Kesin değerlerden biri, otomatikleştirme testlerinin sürekli olarak gerçekleştirilebilmesidir; Her saat yeniden inşa veya benzeri gibi. Bunu yapmak, rahatsız edici kod üzerinde çalışan bir programcının saatleri veya günleri içinde herhangi bir hata veya gerilemeyi hızla açmaya zorlar, bu bağlam bağlamında geçiş yapmayı çok daha kolaylaştırır. Sürekli sınamanın ikinci faydası sizi sınamaları çalışma durumunda tutmaya zorlamasıdır; hiçbir şey, bir test döngüsünün ilk haftasını, tüm eski testleri sabitleyerek geçirmekten daha sıkıcı değildir. Bunları otomatik hale getirebilirseniz, istediğiniz zaman çalıştırabilir ve düzenli olarak çalıştırarak testlerinizde veya kodlarınızda hızlıca hata yakalayabilirsiniz.

Test Masrafı

Otomatik bir test yazıldıktan sonra, bir bilgisayar tarafından birkaç joule pahasına çalıştırılabilir. Eşdeğer manuel test, bordroda çalışan bir kişinin bir talimatlar listesini incelemesini gerektirir.

Test Güvenilirliği

Her seferinde aynı test prosedürünü tam olarak yerine getirmek için bilgisayara güvenilebilir. İnsan hata yapmak ve tembelleşmek için uygundur.

Bilgisayarın test hatası modları da çok daha belirgindir - çöktü (test raporları görünmüyor), yanlış bir test sonucuna neden olan bir bit hatası oldu (tekrar deterministik bir test uygulayın ve sonuç farklılık gösterir). Bir insan bir adımı kaçırır ve "Tamam" ı işaretlerse, nasıl söyleyebiliriz?

Test Dayanıklılığı

Otomatik bir testin çalıştırılabilmesi için somut bir eser (örneğin bir kod parçası) olması ve doğal olarak diğer yazılım geliştirme eserleri olan kaynak havuzuna dahil edilmesi gerekir. Bir not kağıdı kağıdına bir test cihazı tarafından manuel test geliştirilebilir ve asla resmileştirilemez. İşletmenin, bunun gerçekleşmemesi için süreçlere ihtiyaç duyması daha olası.

Test Değeri

Bilgisayar, test sonuçlarını tutarlı ve kolay analiz edilen bir şekilde vermek üzere programlanabilir. Kişi, aynı şeyi oluşturmak için veri girişi yapıyor veya bir analist, geliştirici veya sindirimi gerektiren bir yöneticinin serbest formdaki notlarını kaydediyor.

Çoğunlukla (test kapsamınıza bağlı olarak) hatasız kod ve en büyük argümanlardan birinin yöneticinize keşfedilen bir hata için bir test yazabileceğinizi söyleyerek ileride her zaman bilmenizi sağlayacak olduğunu söylerim. bu böcek geri geliyor :)

Benim görüşüme göre, birim / entegrasyon testlerinin en önemli olduğu, MVC gibi bir UI modeli uygularsanız çoğu proje için yeterlidir. Genelde denetleyicilerim / sunum yapan kişilerimdeki tüm eylemleri test ederim ve Görünümler'e veri tabanını bırakırım.

Elbette, otomatik testler eski ve iyi noktaların yerini almaz ve kullanıcınızın yapabileceği en çılgınca şeyleri bulmaya çalışırken uygulamanızdaki maceraları tıklar.

Sürekli Entegrasyonun bir noktası da var .

Bir şey daha var - bir kişi kod kalitesinin ürün kalitesine, işletme değerine ve sürdürülebilirliğine yol açması için çaba sarf etmelidir - aksi halde yapmanın bir anlamı yoktur.

Bence "düşük Maliyetli" ve "daha fazla Özellik / birim zaman" / daha küçük çevrim süresi gibi sihirli noktalara öncülük etmelisiniz.

Ancak bir dava açmadan önce durumunuzu düşünmenizi tavsiye ederim. Sorunuz , otomatik testlerin olası eksilerini hakkında bir blog yazısı yazmamı sağladı .

Refactoring kolaylığı burada büyük bir faktördür. Hoş ve okunabilir (!!!) birim testlerle iyi bir şekilde kapsanan, mevcut işlevselliği tehlikeye atma konusunda gergin olmadan sisteminizi yeniden canlandırabilirsiniz.

Kavramı satmak zorundasın - onlara kodu geliştireceğini söylemekten kaçınmalısın. Koda herhangi bir yatırım yapacaklarsa, bunları hemen size / otomatik test etmeye zorlayacaklardır. Eğer herhangi bir iyiyse, GIGO'yu da anlayacaklar, bu yüzden neden geçerli olmadığını düşündüğünüzü anlamayacaklar.

Ben de onu belgeleme olarak satmayı bıraktım, Fitnesse gibi şeyler iyi yapabilirdi, ancak deneyimlemeleri zor hale gelinceye kadar zor olabilir.

Ben onu satırken şans olabileceğini düşünüyorum alanlar

1. Birim Testleri birçok geliştirici demetinin yerine geçebilir - burada sadece tüm oturum açma / menülere girmeden hata ayıklama / test etme alanı elde etmek için uygulama oluşturursunuz.

2. Testler, problem durumlarını kolayca ayarlamanıza ve tekrar etmenize olanak sağlar - test verilerini ayarlamak için çok fazla zaman harcamadan (özellikle alaycı bir sistem kullanarak)

3. BDD ve UI testlerinin süitlerini oluştururken, test cihazının bir dahaki sefere bakmasını beklemekten daha basit aralar varsa daha hızlı yanıt alırsınız

4. BDD ve UI testleri, değişiklikten etkilenmiş olabilecek tüm yönleri kontrol etmek ve düğmelere basmaktan kaçınmak için düğmelere tekrar tekrar basılmasını önleyebilir ve her alanı hatırlamanıza neden olabilir.

5. Otomatik oluşturma, birisinin kodu girmeyi unuttuğunu unutması üzerine sık sık vurgulanır.

6. Testler böceklerin tekrar ortaya çıkmasını önlemenize yardımcı olur.

7. Birim Testleri ve iyi alay etmek daha az birbirine bağlı kod anlamına gelir ve çözülmesi daha kolay olur

Unutmayın, satmaya çalıştığınızı, onları bir dine dönüştürmeyeceğinizi unutmayın - bu yüzden küçük adımları kabul edin ve onları size karşı almamaya çalışın. Ayrıca, iyi testler yazmaları ve öğrenmeleri de zaman alacaktır.

Birisi, bu soruna önerilen bir çözümü kabul etmeden önce bir sorun olduğuna inanmalıdır.

Otomatikleştirilmiş testler hata düzeltme maliyetlerini azaltabilir, bu nedenle iş arkadaşlarınız hata düzeltme maliyetlerinin büyük veya aşırı olduğuna inanmazlarsa, ikna etmek zor olacaktır. Bu maliyetler yüksek veya çok yüksekse ancak insanlar kendilerine inanmıyorsa, öncelikle bu maliyetler hakkında ikna edici veriler elde etmeniz gerekebilir.

İşletmelerin sevdiği değer artıyor ve maliyeti düşürüyor. Ekstra maliyet eklediğinden, otomatik testlerin değeri nasıl artıracağını açıklamalısınız.

Eğer kodunuz modüler ise, onu tekrar kullanmak mümkün olacaktır. Bu, testlerin tekrar tekrar yazmak zorunda olmadığı ve mevcut kodun üzerinde çalışabileceğiniz anlamına gelir.

Eski projeler varsa, otomatik sınama yeniden yapılandırmayı çok daha kolaylaştırır. Teknik borcun bir noktada ödenmesi gerekiyor.

Sağladığınız dokümantasyon argümanı çok iyi değil. Testlerin güncel tutulması ile dokümantasyonun güncel tutulması arasındaki fark sadece bir alışkanlıktır.

“Yardım aradığım şey, değerini bir programcı ekibine, analistlere, yöneticilere ve test ekibine eklemektir. Otomatik testler yaparak, birim testleri (örn. JUnit), BDD arasında bir ayrım yapmam gerektiğini düşünmüyorum. örneğin, JBehave, Fitness) ve UI (Selenyum, Watir) çünkü hepsinin benzer bir değer sağladığını düşünüyorum (ama aynı fikirde olmayan bir cevap yazmaktan çekinmeyin :)) "

Tamam ben bu meydan okuma alacağım;)

Çoğunlukla programcılar ve KG ile çalışıyorum ve aletlerim yakut, raylar, test üniteleri, rspec, yasemin ve selenyumdur.

Rspec ve testunitin BDD / TDD araçları programlamanın bir parçasıdır. Onları parçalara ayırmaz ve onlardan ayrı olarak yönetime konuşmazsınız, zaman yetersizliğinden dolayı ertelemezsiniz, tüm zaman tahminlerinize dahil edersiniz. Gerçekten zorlanırsa, insanların size bilgisayar bilimi ve programlamayı açıklamak için ne kadar zamanları olduğunu sordu. Bu testleri ön uç için kullanmıyorum

GUI / UI / Yasemin / Selenyum. Bunlar farklı. Bunları programcı geçmişine sahip olan KG çalışanları tarafından yaptım. Testlerin mümkün olduğunca sağlam ve mizanpaja dayalı olmayan içeriğe dayanarak yazıldığından emin oluruz. Bunun (muhtemelen yeni) maliyeti, değişen bir maliyet olarak açıklanmalıdır . Arızalı yazılımla ödeme yapmak, müşterileri kaybetmek ve daha sonra pahalı düzeltmeleri yapmak yerine, şimdi birkaç basit uygulama ile çok daha az (nispeten) ödersiniz.

Bence, kilit nokta, bir bütün olarak 'otomatik testler' değil, yaratacağınız belirli test kategorileri hakkında konuşmak. İkincisi biraz titiz ve endişe verici olabilir ve zaman kaybına neden olacağı örnekleri bulmak çok kolaydır.

Testlerinizi her zaman 4 gruba ayırmanızı öneririm ( burada daha fazla ayrıntı ). Benimle buraya geçin, bunun bir anda diğerlerine test satmanıza nasıl yardımcı olacağını anladım.

1. Çekirdek işlevselliğinizin testleri . Yani, bir web sitesi izleme aracı için bu, izlemekte olduğunuz web siteleri için ateşlenmesi gereken uyarıların testi olacaktır. Bu testler, bu şeylerin asla kırılmamasını sağlar.
2. Tüm uygulamanızın duman testleri . Örneğin, bir web uygulamasındaki tüm bağlantılarda / düğmelerde gezinmek ve sunucuda hata olmadığından emin olmak için Selenyum kullanmak. Bu testler, test cihazlarının zamanını açık bir şekilde kırılmış yapılarla harcamanızı önler.
3. Herhangi bir kırılgan kodun testleri . Yani, o eski modül için hiç kimse dokunmak istemez, ya da içinde her zaman hatalar gibi görünen karmaşık kod parçası.
4. Devs, çalışmalarını desteklemek için yazmak istediği testler . Çünkü bazen testler bir şeyler yazarken faydalıdır, ancak yukarıdaki kategorilere girmeyin.

Testlerinizi bu kategorilere ayırarak şimdi farklı bir tartışma yapabilirsiniz. İlk üç gruba katılın (dördüncü kişi kendi takdirine bağlı olarak) ve insanlara bu kod parçaları için testlerin faydalı olacağını mı düşünüyorsunuz? Anlaşamıyorsanız, belki de şu anda bu testleri dahil etmiyorsunuz. Yapabiliyorsanız, yani insanlar her bir taahhütte yerine getirilen çekirdek işlevsellik testlerinin faydalı olacağına katılıyorlarsa, bunları eklemeye başlayın.

Yararlı olabilecek diğer grup ise elle yapılması zor veya zaman alıcı testlerdir . Manuel test zamanından tasarruf etme veya zaman yetersizliği nedeniyle atlanan testlerden geçme açısından yararı açıklamak oldukça kolay olmalı.