Sürekli Teslimat pratikte nasıl çalışabilir?

Sürekli Teslimat kulağa hoş geliyor, ancak yıllardır süren yazılım geliştirme deneyimim pratikte çalışamayacağını gösteriyor.

(Düzenleme: Açıklığa kavuşturmak için, her zaman otomatik olarak çalışan birçok testim var. Benim sorum, CD’nin tam biçimi olduğunu anladığım her checkin için güvenimin nasıl sağlanacağıyla ilgili. Her hafta (bazıları doğru şekilde yapılırsa hala CD düşünebilir), iki hafta veya ay; her biri sonunda eski moda bir KG dahil olmak üzere, otomatikleştirilmiş testleri de içeren, yinelemelerdir.)

• Tam test kapsamı mümkün değildir. Her küçük şey için çok zaman harcamalısınız - ve zaman paradır -. Bu değerlidir, ancak kaliteye başka yollarla katkıda bulunmak için zaman harcanabilir.
• Bazı şeyleri otomatik olarak test etmek zordur. Örneğin, GUI. Selenyum bile GUI'nizin riskli olup olmadığını söylemez. Veritabanına erişim, büyük donanımlar olmadan test etmek zordur ve bu bile veri depolama alanınızdaki garip köşe vakalarını kapsamaz. Aynı şekilde güvenlik ve daha birçok şey. Yalnızca işletme katmanı kodu etkin bir şekilde test edilebilir.
• İş katmanında bile çoğu kod, argümanları ve dönüş değerleri test amacıyla kolayca izole edilebilecek basit fonksiyonlar yoktur. Gerçek uygulamalara karşılık gelmeyen sahte nesneler oluşturmak için çok zaman harcayabilirsiniz.
• Entegrasyon / fonksiyonel testler birim testlerini tamamlar, ancak bunların çalıştırılması çok zaman alır çünkü bunlar genellikle her testte tüm sistemi yeniden başlatmayı içerir. (Yeniden başlatmazsanız, test ortamı tutarsızdır.)
• Yeniden düzenleme veya diğer değişiklikler çok fazla testten geçer. Onları tamir etmek için çok zaman harcıyorsun. Anlamlı özellik değişikliklerini doğrulamakla ilgili bir sorun varsa, sorun değil, ancak gerçekten önemli bilgiler sağlayan şeyler değil, anlamsız düşük seviye uygulama ayrıntıları nedeniyle yapılan testler sık ​​sık. Genellikle ayarlamalar, test edilen işlevselliği gerçekten kontrol etmek yerine testin içindekileri yeniden işleme üzerine odaklanır.
• Hatalardaki saha raporları, kodun kesin mikro sürümüyle kolayca eşleştirilemez.

Yıllarca süren yazılım geliştirme tecrübem pratikte işe yaramadığını gösteriyor.

Bunu denediniz mi? Dave ve ben, hem kendimiz hem de ThoughtWorks'teki diğer üst düzey insanlar hakkında, aslında tartıştığımız şeyleri yaparak, uzun yıllar süren toplu deneyime dayanan kitabı yazdık. Kitaptaki hiçbir şey spekülatif değildir. Tartıştığımız her şey, büyük, dağıtılmış projelerde bile denendi ve test edildi. Ama inanca dayanmanı önermiyoruz. Elbette kendiniz denemelisiniz ve lütfen neyin işe yaradığını ve neyin işe yaramadığını, ilgili bağlam dahil, başkalarının deneyimlerinizden öğrenebileceklerini yazınız.

Sürekli Teslimat, otomatik testlere büyük önem vermektedir. Kitabın yaklaşık 1 / 3'ünü bunun hakkında konuşmak için harcıyoruz. Bunu yaptığımız için alternatif - manuel testler pahalı ve hataya açıktır ve aslında yüksek kaliteli yazılım oluşturmak için harika bir yol değildir (Deming'in dediği gibi, "Kaliteyi elde etmek için toplu muayeneye bağımlılıktan kurtulun. Süreci iyileştirin ve kaliteyi arttırın) ilk etapta ürün ")

Tam test kapsamı mümkün değildir. Her küçük şey için çok zaman harcamalısınız - ve zaman paradır -. Bu değerlidir, ancak kaliteye başka yollarla katkıda bulunmak için zaman harcanabilir.

Tabii ki tam sınav kapsamı imkansız, ama alternatif nedir: sıfır sınav kapsamı mı? Bir takas var. Arada bir yerde projeniz için doğru cevap. Genel olarak, zamanınızın yaklaşık% 50'sini otomatik testler oluşturmak veya sürdürmek için harcamayı beklemeniz gerektiğini düşünüyoruz. Kapsamlı el ile test etme ve kullanıcılara yönelik hataların giderilmesinin maliyetini düşünene kadar bu pahalı görünebilir.

Bazı şeyleri otomatik olarak test etmek zordur. Örneğin, GUI. Selenyum bile GUI'nizin riskli olup olmadığını söylemez.

Tabii ki. Brian Marick'in test kadrosunu kontrol et. Hala keşif testi ve kullanılabilirlik testi el ile yapmanız gerekir. Fakat pahalı ve değerli insanlarınızı regresyon testi değil için kullanmanız gereken şey budur. Önemli olan, bir dağıtım boru hattını yerleştirmeniz gerektiğidir; böylece yalnızca kapsamlı bir otomatik test grubunu geçen yapılara karşı pahalı manuel doğrulamalar yapmaktan zahmete girersiniz. Bu nedenle, hem manuel testlere harcadığınız para miktarını hem de manuel test veya üretime iten böcek sayısını (bu zamana kadar tamir etmek çok pahalı). Doğru yapılan otomatik testler , ürünün kullanım ömrü boyunca çok daha ucuz olmakla birlikte, elbette zamanla kendini amorti eden sermaye harcamasıdır.

Veritabanına erişim, büyük donanımlar olmadan test etmek zordur ve bu bile veri depolama alanınızdaki garip köşe vakalarını kapsamaz. Aynı şekilde güvenlik ve daha birçok şey. Yalnızca işletme katmanı kodu etkin bir şekilde test edilebilir.

Veritabanına erişim, baştan sona senaryo tabanlı işlevsel kabul testleriniz tarafından örtük olarak test edilir. Güvenlik, arabellek taşmalarını bulmak için (örn.) Otomatik ve manuel test - otomatik penetrasyon testi ve statik analiz kombinasyonunu gerektirir.

İş katmanında bile çoğu kod, argümanları ve dönüş değerleri test amacıyla kolayca izole edilebilecek basit fonksiyonlar yoktur. Gerçek uygulamalara karşılık gelmeyen sahte nesneler oluşturmak için çok zaman harcayabilirsiniz.

Elbette, yazılımınızı ve testlerinizi kötü bir şekilde yaparsanız otomatik testler pahalıdır. Nasıl doğru yapılacağını anlamak için testler ve kodların zaman içinde korunabilmesi için “büyüyen nesne odaklı yazılımı testlerle yönlendiren” kitabını incelemenizi şiddetle tavsiye ederim.

Entegrasyon / fonksiyonel testler birim testlerini tamamlar, ancak bunların çalıştırılması çok zaman alır çünkü bunlar genellikle her testte tüm sistemi yeniden başlatmayı içerir. (Yeniden başlatmazsanız, test ortamı tutarsızdır.)

Çalıştığım ürünlerden birinde, çalışması 18 saat süren 3.500 uçtan uca kabul testi bulunuyor. Paralel olarak 70 kutudan oluşan bir ızgarada çalıştırıyoruz ve 45m'de geri bildirim alıyoruz. İdeal olandan hala daha uzun, bu yüzden, ünite testleri birkaç dakika içinde yapıldıktan sonra boru hattındaki ikinci aşama olarak çalıştırıyoruz, bu nedenle, bazı temel seviyeye sahip olmadığımız bir yapıya kaynaklarımızı boşa harcamıyoruz. güven.

Yeniden düzenleme veya diğer değişiklikler çok fazla testten geçer. Onları tamir etmek için çok zaman harcıyorsun. Anlamlı özellik değişikliklerini doğrulamakla ilgili bir sorun varsa, sorun değil, ancak gerçekten önemli bilgiler sağlayan şeyler değil, anlamsız düşük seviye uygulama ayrıntıları nedeniyle yapılan testler sık ​​sık. Genellikle ayarlamalar, test edilen işlevselliği gerçekten kontrol etmek yerine testin içindekileri yeniden işleme üzerine odaklanır.

Kodunuz ve testleriniz iyi bir şekilde kapsüllenmiş ve gevşek bir şekilde bağlanmışsa yeniden yapılanma, çok sayıda testi bozmaz. Kitabımızda, fonksiyonel testler için de aynı şeyi nasıl yapacağımızı açıklıyoruz. Kabul testleriniz bozulursa, bu bir veya daha fazla ünite testinin eksik olduğuna dair bir işarettir, bu nedenle CD'nin bir kısmı, testlerin daha iyi tanımlı olduğu teslimat sürecinde daha önce hataları denemek ve bulmak için test kapsamınızı sürekli olarak iyileştirmeyi içerir. böcek düzeltmek için ucuzdur.

Hatalardaki saha raporları, kodun kesin mikro sürümüyle kolayca eşleştirilemez.

Konum test ve daha sık salan (CD'nin noktasının parçası) Eğer, o zaman olduğu açığa neden değişikliğini tespit etmek nispeten kolay. CD'nin tüm amacı, geri besleme döngüsünü optimize etmektir, böylece sürüm kontrolünde kontrol edildikten sonra en kısa sürede hataları tanımlayabilirsiniz - ve gerçekten de, kontrol edilmeden önce (bu nedenle, derleme ve ünite testlerini çalıştırmamızın nedeni budur). giriş yapmadan önce).

İlk olarak, CD büyük bir zihinsel düzenlemeyi alır - ne yaparsanız yapın bazen işlerin kopacağını kabul etmek zorundasınız. Günün sonunda, negatif kanıtlayamazsınız.

Bunu aştığınızda, a) bu hataları çok hızlı bir şekilde yakalamak için araçlara ve prosedürlere ihtiyacınız olduğunu fark edersiniz ve b) güncellemeyi çok verimli bir şekilde geri alır veya dağıtırsınız. Ayrıca, gerçekten CD kokteyli içiyorsanız, geri dönüşü kolay olan ve uygulamada büyük hatalara yol açmaması gereken çok sayıda küçük, sivri değişiklik yapıyorsunuz. Gerçekten CD uygulayan çocuklar bile büyük değişimleri daha geleneksel bir şekilde ele alıyorlar.

Her sistemin riskleri vardır ve her riskin potansiyel maliyetleri vardır. Kapsamlı testlerde ve QA'da aylar veya yıllar alabilecek türden küçük bir riskin maliyeti yeterince yüksekse (kalp pilinizdeki yazılım), dondurulmuş salıverme. Başarısızlığın maliyeti yeterince küçükse, belki sürekli olarak sıfır testle (kedinizin Facebook sayfası) gönderilir.

Tam test kapsamı mümkün değildir. Her küçük şey için çok zaman harcamalısınız - ve zaman paradır -. Bu değerlidir, ancak kaliteye başka yollarla katkıda bulunmak için zaman harcanabilir.

% 100 kapsama ihtiyacınız yok, sisteminizde güvende olmak için yeterince ihtiyacınız var, bir yerdeki değişikliklerin daha önce çalışmış olduğunuz şeyleri bozmayacağı konusunda.

Bazı şeyleri otomatik olarak test etmek zordur. Örneğin, GUI. Selenyum bile
GUI'nizin riskli olup olmadığını söylemez. Veritabanına erişim, büyük donanımlar olmadan test etmek zordur ve bu bile veri depolamanızdaki garip köşe vakalarını kapsamaz.

Ancak, veritabanı erişimi yazmak çok önemlidir. Veri katmanınız üzerinde pek çok teste ihtiyacınız olmamalı çünkü sadece veri alıyor ve ayarlıyor. En önemli şey, başarısız olduğu zaman geri almasını ve sorunu günlüğe koyabilmesi için günlüğe kaydetmesini sağlamaktır.

Aynı şekilde güvenlik ve daha birçok şey. Yalnızca işletme katmanı kodu etkin bir şekilde test edilebilir. İş katmanında bile çoğu kod, argümanları ve dönüş değerleri test amacıyla kolayca izole edilebilecek basit fonksiyonlar yoktur.

O zaman işlevlerin / sınıfların çoğu çok büyük. Test edilebilir olmak için yazılmalıdır.

Gerçek uygulamalara karşılık gelmeyen sahte nesneler oluşturmak için çok zaman harcayabilirsiniz.

Sahte nesnenin G / Ç ancak beklendiği gibi eşleşmelidir. İçinde ne olduğu önemli değil.

Entegrasyon / fonksiyonel testler birim testlerini tamamlar, ancak bunların çalıştırılması çok zaman alır çünkü bunlar genellikle her testte tüm sistemi yeniden başlatmayı içerir. (Yeniden başlatmazsanız, test ortamı tutarsızdır.)

Bunlar her zaman çalıştırılmamalıdır. Sadece gerektiği gibi.

Yeniden düzenleme veya diğer değişiklikler çok fazla testten geçer. Onları tamir etmek için çok zaman harcıyorsun. Anlamlı özellik değişikliklerini doğrulamakla ilgili bir sorun varsa, sorun değil, ancak gerçekten önemli bilgiler sağlayan şeyler değil, anlamsız düşük seviye uygulama ayrıntıları nedeniyle yapılan testler sık ​​sık. Genellikle ayarlamalar, test edilen işlevselliği gerçekten kontrol etmek yerine testin içindekileri yeniden işleme üzerine odaklanır.

O zaman kodunuz çok sıkı bir şekilde bağlanmış ve testleriniz zayıf yazılmıştır.

Hatalardaki saha raporları, kodun kesin mikro sürümüyle kolayca eşleştirilemez.

Burada ne elde ettiğinden emin değil misin? Bir hata varsa, onun varlığını göstermek için bir test yazın, sonra düzeltin.

Bizim için iyi çalışıyor, ancak müşterilerimiz çoğunlukla iç. Gün içinde yapılan birden çok yapı, bozuk yapılara tolerans gösterilmez, web başlatma mekanizması kullanılır, böylece kullanıcılar her lansmanda en son sürümü alırlar. Bir şey, CD'nin birçok sorunu ortadan kaldırmasıdır. Evet, her zaman uyumluluk endişeleriniz var, ancak her seferinde yalnızca küçük değişiklikler uyguladığınız için endişelerinizi halletmek gerçekten kolaydır. CD'nin stres seviyesi, büyük güncellemeler yaptığımızdan çok daha düşük ve bir kırılma durumunda gözden geçirilecek çok fazla kod olacağından her şeyin doğru olduğunu ummak zorunda kaldık.

Dürüst olmak gerekirse, TÜM yazılımlar sürekli teslimatta! En önemli şey onu kapıdan çıkarmak! Kullanıcılarınızı kullanın ve bundan sonra özellik isteklerine ve hata ezmeye öncelik verin.

"Gerçek sanatçılar gemi"
- Steve Jobs.