Günlük blog | Geliştirmeden teste yedi yıl, test stratejisinden test mimarisine geçtim
Programcılar arasında bir jingle var: Bazı insanlar dünyayı yaratmayı severler, onlar geliştiricidir; bazıları geliştiricileri sever, onlar test edicidir. Yazılım testi nedir? Yazılım testi, kullanıcıların önünde meydana gelmesi gereken bir felaketin önceden önlerinde meydana gelmesidir, bu onlara kendilerini kurtarıcı gibi hissettirecek, kullanıcıları kurtaracak ve yazılımı kurtaracak, kaldırılmanın kaderini ortadan kaldıracak.
Bu yıl yazılım testinde 7. yılım ... Yazılım geliştirmeden yazılım testine geçtiğimde bu alanda bu kadar uzun süre kalabileceğimi hiç düşünmemiştim. Son 7 yılda yazılım testi alanındaydım.Otomatik testten başladım ve yavaş yavaş çeşitli yazılım test alanlarıyla tanıştım: çeşitli test yöntemleri (eşdeğer sınıflar, tam eşleştirme, vb.), Test teknikleri (birim testi, Fonksiyonel test, performans testi, keşif testi vb.), Otomatik test araçları (JUnit, Selenium, Gatling, ZAP, vb.), Test prosedürleri (geleneksel test prosedürleri, çevik test prosedürleri, vb.) Ve test stratejileri (test kadranları ve test piramitleri, vb.).
Bunların arasında, "test stratejisi" test endüstrisinde daha az tartışılır, çünkü çoğu insanın işi test senaryoları tasarlamaya, testleri yürütmeye veya otomatikleştirilmiş testleri geliştirmeye ve sürdürmeye odaklanır ve test stratejilerinin çalışmasına yalnızca az sayıda kişi dahil olur, bu nedenle Sonuç olarak, birçok test uzmanının aslında test stratejileri hakkında sistematik bir anlayışa sahip olmaması.
Bu yüzden, daha iyi testler elde etmek, hataları azaltmak ve kaliteyi artırmak için test stratejisini anlamanıza biraz yardımcı olmayı umarak, son birkaç yıldaki deneyimlerimi, özetimi ve test stratejileri üzerine düşüncelerimi bir dizi makale şeklinde yazacağım.
Test stratejisi
Test Stratejisinin ilk amacı "kusurların görünümünü ve serbest bırakılmasını azaltmaktır." Bunlar arasında, "kusurların görünümünü azaltmak" ileri test edilerek ve diğer yöntemlerle çözülebilir ve yazılım gereksinimleri analizi ve mimari tasarımı sırasında kusurlar bulunurken, "kusur yayılmasını azaltma", kodlamanın tamamlanmasını doğrulamak ve test etmek için çeşitli test yöntemlerini ve teknolojilerini kullanabilir. (Bu iki nokta ilerideki makalelerde farklı örneklerle daha detaylı anlatılacaktır).
"Test stratejisi" nin sadece test uzmanları tarafından özelleştirilmediği, yazılımın kalitesinin sağlanması ve kusurların azaltılması amacıyla bir ekibin çeşitli rolleri tarafından formüle edildiği ve oluşturulduğu görülmektedir.
Test stratejisini uygulamak için "test planı" kullanılır. Yalnızca test stratejisinin amacını ve uygulamasını tam olarak anlayarak, test stratejisini, neden bir test stratejisi yapmanız gerektiğini, ne tür bir test stratejisinin daha anlamlı ve daha iyi olduğunu ve daha etkili bir şekilde nasıl uygulanacağını tam olarak anlayabilirsiniz.
Test planı
Bir test planı yapmak, test stratejisinin etkili bir şekilde yürütülebilmesini sağlamanın bir yoludur. Ekibe, test stratejisinde hangi aşamada, ne tür bir rol ne tür bir test teknolojisi ve test yöntemini gerçekleştirmesi gerektiğini söyler. Esas olarak test uzmanları tarafından yazılır, ancak tüm ekip tarafından gözden geçirilmelidir, çünkü geliştiriciler, ürün yöneticileri, iş analistleri ve hatta kullanıcılar test planının yürütülmesine dahil olabilir.
Test planı, projenin gerçek ilerlemesine göre ayarlanabilir, bu nedenle statik değildir.
Test mimarisi
1960'larda ve 1970'lerde, yazılım sistemleri hala küçük ölçekte iken, yazılım geliştirme mimariden bahsetmiyordu ve yazılım testi için hiçbir strateji yoktu. Bununla birlikte, yazılım ölçeğindeki hızlı artışla birlikte karmaşıklık da katlanarak artmış ve profesyonel yazılım mimarisi ortaya çıkmıştır.
Karmaşık yazılım sistemlerinin testini belirtilen süre içinde etkin bir şekilde tamamlamak için, ekibin çok sayıda testi anlamasına, seçmesine ve düzenlemesine yardımcı olacak, böylece yazılım test stratejilerinin ortaya çıkmasına yardımcı olacak bir yol gösterici strateji olmalıdır. Test stratejisi, genellikle bazı küçük ve orta ölçekli projeler için yeterli olabilecek yüksek düzeyli bir rehberliktir, ancak modern ve giderek karmaşıklaşan yazılım sistemleriyle başa çıkmak için yeterli değildir.
Çünkü mikro hizmetlerin, mobil İnternetin, Nesnelerin İnterneti'nin, büyük veri analiz sistemlerinin, yapay zeka sistemlerinin vb. Ortaya çıkmasıyla birlikte, çeşitli teknolojileri, harici bağımlılıkları veya bağımsız alt sistemleri içeren karmaşık bir sistemi test etmek, yalnızca test stratejilerine dayalı değildir. Farklı seviyelerde farklı testler yapmak, ancak çeşitli testler arasındaki karşılıklı ilişkileri ve kısıtlamaları netleştirmek ve ardından testleri çeşitli boyutlarda etkili bir şekilde ilişkilendirmek ve yazılım sistemi mimarisi düşüncesi ile bütünü düşünmek yeterlidir. Deneme sistemi.
Lütfen bunun, tüm sistemin tüm testlerini tamamlamak için tam otomatik bir test sistemi tasarlamak değil, çeşitli testleri makul ve etkili bir şekilde çeşitli etkili yöntemlerle (manuel veya otomatik) birbirine bağlamak olduğunu unutmayın. Tam bir yapıya sahip bir test sistemi, tüm sistemin çeşitli testlerini daha görünür ve anlaşılır hale getirebilir, tüm sistemin çeşitli testlerini daha etkili hale getirebilir, tekrarlanan testlerden kaçınabilir ve maliyet tasarrufu sağlayabilir.
Örneğin, ön uç ve arka uç ayrımına sahip bir web işletme sistemi, yalnızca ön uç kullanıcı arabirimine ve büyük miktarda JavaScirpt koduna sahip olmakla kalmaz, aynı zamanda arka uç API'lerine, üçüncü tarafa bağlı sistemlere ve veritabanı sistemlerine de sahiptir.Çeşitli test katmanlarının etkili bir şekilde nasıl bağlanacağı, çözülmesi gereken test mimarisidir. Sorun.
İlk olarak, ön uç, arka uç API'ler, üçüncü taraf bağımlı sistemler ve veritabanı sistemlerinin kendi birim testleri, entegrasyon testleri vb. Bulunur ve ardından birleşik ön uç ve arka uç API'leri test etmek için sözleşme testleri kullanılabilir ve ardından Stub'lar üçüncü taraf bağımlı sistemlere sözleşmeler eklemek için kullanılabilir. Test veya izleme testi için, sistem parametrelerini oluşturmak için test verilerini kullanmak ve sözleşme testini desteklemek için çeşitli test verilerini veritabanı sisteminde depolamak da gereklidir.
Yazılım testi, arayüz testi, otomatik test, performans testi, LR komut dosyası geliştirme ve görüşmelerde deneyim alışverişinde bulunmak istiyorsanız. Eğer ilgileniyorsanız, 175317069 yapabilirsiniz. Grup zaman zaman ücretsiz bilgi bağlantıları yayınlayacaktır. Bu bilgiler çeşitli teknik web sitelerinden toplanır ve sıralanır.İyi öğrenme materyalleriniz varsa, benimle özel olarak sohbet edebilirsiniz, ben kaynağı belirteceğim. Daha sonra herkesle paylaşın.
Farklı yazılım sistemleri için mimarileri genellikle iş gereksinimleri ve teknik yetenekler gibi çeşitli koşullara göre tasarlanır. Yazılım mimarisi gibi, test stratejisi ve test mimarisi de farklı projelerdedir ve yazılım sistemi mimarisi, teknoloji yığını, iş gereksinimleri, personel becerileri ve diğer faktörlere göre özelleştirilmeleri ve tasarlanması gerekir.
Stratejiyi tekrar test etme hakkında konuşun
Endüstride popüler olan test piramitleri ve test kadranları, pratik çalışabilirliğe sahip olmayan ve yalnızca üst düzey rehberlik ve referansa sahip, sadece iki yüksek düzeyde soyut ve basitleştirilmiş test stratejisi modelidir. Doğrudan bu iki model üzerinde çalışmak verimsizdir ve hatta olumsuz etkiler getirebilir. Bu nedenle test piramidi ve test kadranı kör olarak kullanılamaz, bunun yerine projenin fiili durumuna göre (projenin test mimarisine ihtiyaç duymaz) projenize uygun bir test stratejisi ve test mimarisi oluşturmanız ve bu temelde gerçek test çalışması yapmanız gerekir.
Blogun yazarı: Q programı alması gereken maymun
Günlük blog sütunu, her gün sizin için mükemmel blog yazarlarından yüksek kaliteli teknik makaleler önerir. Aynı zamanda, kullanıcılar katkıda bulunabilirler.Makale resmi hesaba dahil edildikten sonra, web sitesinin ana sayfasında önereceğiz. Dikkat Açık kaynak Çin OSC Her gün yüksek kaliteli itin, tıklayın " daha fazlasını anla "Orijinal makaleyi okuyun.
