Ey Habr!
Adım Maxim Ponomarenko ve Sportmaster'da geliştiriciyim. Bilişim alanında 10 yıllık tecrübem var. Kariyerine manuel testlerle başladı, ardından veritabanı geliştirmeye geçti. Son 4 yıldır test ve geliştirmede edindiğim bilgileri biriktirerek DBMS düzeyinde testleri otomatikleştiriyorum.
Bir yılı aşkın bir süredir Sportmaster ekibindeyim ve büyük projelerden birinde otomatik testler geliştiriyorum. Nisan ayında Sportmaster Lab'den arkadaşlar ve ben Krasnodar'daki bir konferansta konuştuk, raporumun adı "DBMS'de birim testleri" idi ve şimdi bunu sizinle paylaşmak istiyorum. Çok fazla metin olacak, bu yüzden raporu iki gönderiye ayırmaya karar verdim. İlkinde genel olarak ototestlerden ve testlerden bahsedeceğiz, ikincisinde ise birim test sistemimiz ve uygulamasının sonuçları üzerinde daha detaylı duracağım.
İlk olarak, biraz sıkıcı bir teori. Otomatik test nedir? Bu, yazılım kullanılarak gerçekleştirilen testtir ve modern BT'de yazılım geliştirmede giderek daha fazla kullanılmaktadır. Bunun nedeni şirketlerin büyümesi, bilgi sistemlerinin büyümesi ve buna bağlı olarak test edilmesi gereken işlevsellik miktarının artmasıdır. Manuel test yapmak giderek daha pahalı hale geliyor.
Her iki ayda bir yayınları çıkan büyük bir şirkette çalışıyordum. Aynı zamanda, bir düzine test uzmanının işlevselliği manuel olarak kontrol etmesi için tam bir ay harcandı. Otomasyonun küçük bir geliştirici ekibi tarafından uygulanması sayesinde test süresini bir buçuk yılda 2 haftaya indirmeyi başardık. Test hızını artırmanın yanı sıra kalitesini de artırdık. Otomatik testler düzenli olarak başlatılıyor ve her zaman içerdikleri kontrol sürecinin tamamını gerçekleştiriyorlar, yani insan faktörünü hariç tutuyoruz.
Modern BT, bir geliştiricinin yalnızca ürün kodunu yazması değil, aynı zamanda bu kodu kontrol eden birim testleri yazması gerekebileceği gerçeğiyle karakterize edilir.
Peki ya sisteminiz öncelikle sunucu mantığına dayanıyorsa? Piyasada evrensel bir çözüm veya en iyi uygulamalar yoktur. Kural olarak şirketler bu sorunu kendi yazdıkları test sistemlerini oluşturarak çözerler. Bu, projemizde oluşturulan, kendi yazdığımız otomatik test sistemimizdir ve raporumda bundan bahsedeceğim.
Sadakat testi
Öncelikle otomatik test sistemini kurduğumuz projemizden bahsedelim. Projemiz Sportmaster sadakat sistemidir (bu arada bunun hakkında zaten yazmıştık) ).
Şirketiniz yeterince büyükse sadakat sisteminiz üç standart özelliğe sahip olacaktır:
- Sisteminiz oldukça yüklenecek
- Sisteminiz karmaşık bilgi işlem süreçlerini içerecektir
- Sisteminiz aktif olarak geliştirilecektir.
Sırayla gidelim... Toplamda tüm Sportmaster markalarını düşünürsek Rusya, Ukrayna, Çin, Kazakistan ve Belarus'ta 1000'den fazla mağazamız var. Bu mağazalardan her gün yaklaşık 300 alışveriş yapılıyor. Yani her saniyede 000-3 kontrol giriyor sistemimize. Doğal olarak sadakat sistemimiz oldukça yüklü. Aktif olarak kullanıldığı için kalitesinin en yüksek standartlarını sağlamalıyız çünkü yazılımdaki herhangi bir hata büyük maddi, itibar ve diğer kayıplar anlamına gelir.
Aynı zamanda Sportmaster yüzden fazla farklı promosyon yürütmektedir. Çeşitli promosyonlar var: ürün promosyonları var, haftanın gününe özel promosyonlar var, belirli bir mağazaya bağlı promosyonlar var, makbuz miktarına göre promosyonlar var, ürün sayısına göre promosyonlar var. Genel olarak fena değil. Müşterilerin alışveriş yaparken kullandıkları bonuslar ve promosyon kodları vardır. Bütün bunlar, herhangi bir siparişin hesaplanmasının çok önemsiz bir görev olduğu gerçeğine yol açmaktadır.
Sipariş işlemeyi uygulayan algoritma gerçekten berbat ve karmaşıktır. Ve bu algoritmada yapılacak herhangi bir değişiklik oldukça risklidir. En önemsiz görünen değişikliklerin bile oldukça öngörülemeyen etkilere yol açabileceği görülüyordu. Ancak otomasyon için en iyi adaylar tam da bu tür karmaşık bilgi işlem süreçleridir, özellikle de kritik işlevleri uygulayanlar. Onlarca benzer vakayı elle kontrol etmek çok zaman alıcıdır. Ve sürece giriş noktası değişmediğinden, bunu bir kez tanımladıktan sonra hızlı bir şekilde otomatik testler oluşturabilir ve işlevselliğin çalışacağından emin olabilirsiniz.
Sistemimiz aktif olarak kullanıldığı için işletme sizden yeni bir şeyler isteyecek, çağa ayak uyduracak ve müşteri odaklı olacaktır. Sadakat sistemimizde sürümler iki ayda bir yayınlanır. Bu, her iki ayda bir tüm sistemin tamamen gerilemesini yapmamız gerektiği anlamına gelir. Aynı zamanda doğal olarak herhangi bir modern BT'de olduğu gibi geliştirme, geliştiriciden üretime hemen geçmez. Geliştiricinin devresinden kaynaklanır, ardından sırasıyla test tezgahından geçer, serbest bırakılır, kabul edilir ve ancak bundan sonra üretime geçer. En azından test ve serbest bırakma devrelerinde tüm sistemin tam bir regresyonunu gerçekleştirmemiz gerekiyor.
Açıklanan özellikler hemen hemen her sadakat sistemi için standarttır. Projemizin özelliklerinden bahsedelim.
Teknolojik olarak sadakat sistemimizin mantığının %90'ı sunucu tabanlı olup Oracle üzerinde uygulanmaktadır. Delphi'de otomatikleştirilmiş bir işyeri yöneticisinin işlevini yerine getiren bir istemci bulunmaktadır. Harici uygulamalara (örneğin bir web sitesi) yönelik açık web hizmetleri vardır. Dolayısıyla eğer otomatik bir test sistemi konuşlandıracaksak bunu Oracle üzerinde yapmamız çok mantıklı.
Sportmaster'daki sadakat sistemi 7 yılı aşkın süredir var ve tek geliştiriciler tarafından oluşturuldu... Bu 7 yıl boyunca projemizdeki ortalama geliştirici sayısı 3-4 kişiydi. Ancak geçen yıl ekibimiz önemli ölçüde büyüdü ve şu anda projede 10 kişi çalışıyor. Yani projeye tipik görevlere, süreçlere ve mimariye aşina olmayan insanlar gelir. Ayrıca hataları gözden kaçırma riski de artıyor.
Proje, personel birimleri olarak özel test uzmanlarının bulunmaması ile karakterize edilmektedir. Elbette testler var, ancak testler diğer ana sorumluluklarına ek olarak analistler tarafından yürütülüyor: ticari müşterilerle, kullanıcılarla iletişim kurmak, sistem gereksinimlerinin geliştirilmesi vb. vb... Testlerin çok yüksek kalitede yapılmasına rağmen (bazı analistler bu raporun dikkatini çekebileceğinden bunu özellikle belirtmek yerinde olur), uzmanlaşmanın ve tek bir şey üzerinde yoğunlaşmanın etkinliği iptal edilmedi .
Yukarıdakilerin tümü göz önüne alındığında, teslim edilen ürünün kalitesini artırmak ve geliştirme süresini kısaltmak için bir projede testlerin otomatikleştirilmesi fikri çok mantıklı görünüyor. Sadakat sisteminin farklı aşamalarında bireysel geliştiriciler, kodlarını birim testlerle doldurmaya çalıştı. Genel olarak herkesin kendi mimarisini ve yöntemlerini kullandığı oldukça dağınık bir süreçti. Nihai sonuçlar birim testlerinde ortaktı: testler geliştirildi, bir süre kullanıldı, sürümlendirilmiş bir dosya deposunda saklandı, ancak bir noktada çalışmayı bıraktılar ve unutuldular. Her şeyden önce bunun nedeni, testlerin projeye değil, belirli bir sanatçıya bağlı olmasıdır.
utPLSQL kurtarmaya geliyor
Stephen Feuerstein hakkında bir şey biliyor musun?
Bu, kariyerinin uzun bir bölümünü Oracle ve PL/SQL ile çalışmaya adayan ve bu konuda oldukça fazla eser yazmış akıllı bir adam. Ünlü kitaplarından birinin adı: “Oracle PL/SQL. Profesyoneller için." UtPLSQL çözümünü veya diğer adıyla Oracle PL/SQL için Birim Test çerçevesini geliştiren kişi Stephen'dı. UtPLSQL çözümü 2016 yılında oluşturuldu ancak üzerinde aktif olarak çalışılmaya devam ediliyor ve yeni versiyonlar yayınlanıyor. Raporlama sırasında en son sürüm 24 Mart 2019'a kadar uzanıyor.
Nedir. Bu ayrı bir açık kaynak projesidir. Örnekler ve belgeler de dahil olmak üzere birkaç megabayt ağırlığındadır. Fiziksel olarak, ORACLE veritabanında birim testini düzenlemek için bir dizi paket ve tablo içeren ayrı bir şemadır. Kurulum birkaç saniye sürer. UtPLSQL'in ayırt edici özelliği kullanım kolaylığıdır.
Küresel olarak utPLSQL, birim testinin, organizasyonu belirli kuralları takip eden sıradan Oracle toplu prosedürleri olarak anlaşıldığı birim testlerini çalıştırmaya yönelik bir mekanizmadır. UtPLSQL, başlatmanın yanı sıra tüm test çalıştırmalarınızın günlüğünü de saklar ve ayrıca dahili bir raporlama sistemine sahiptir.
Bu teknik kullanılarak uygulanan birim test kodunun neye benzediğine dair bir örneğe bakalım.
Böylece ekran, birim testleriyle birlikte tipik bir paket spesifikasyonunun kodunu gösterir. Zorunlu gereksinimler nelerdir? Paketin önüne "utp_" eklenmelidir. Testleri içeren tüm prosedürler tam olarak aynı öneke sahip olmalıdır. Paket iki standart prosedür içermelidir: “utp_setup” ve “utp_teardown”. İlk prosedür, her ünite testinin yeniden başlatılmasıyla, ikincisi ise lansmandan sonra çağrılır.
“utp_setup” kural olarak sistemimizi bir birim testi çalıştırmaya, örneğin test verileri oluşturmaya hazırlar. “utp_teardown” - aksine, her şey orijinal ayarlara döner ve başlatma sonuçlarını sıfırlar.
Burada, girilen müşteri telefon numarasının sadakat sistemimiz için standart forma normalizasyonunu kontrol eden en basit birim testine bir örnek verilmiştir. Birim testleriyle prosedürlerin nasıl yazılacağına ilişkin zorunlu standartlar yoktur. Kural olarak, test edilen sistemin bir yöntemine çağrı yapılır ve bu yöntemin döndürdüğü sonuç, referans olanla karşılaştırılır. Referans sonucu ile elde edilen sonucun karşılaştırılmasının standart utPLSQL yöntemleriyle gerçekleşmesi önemlidir.
Birim testinde herhangi bir sayıda kontrol bulunabilir. Örnekte görüldüğü gibi telefon numarasını normalleştirmek için test edilen yönteme ardı ardına dört çağrı yapıyoruz ve her çağrı sonrasında sonucu değerlendiriyoruz. Unit test geliştirirken sistemi hiçbir şekilde etkilemeyen kontrollerin olduğunu ve bazılarının ardından sistemi orijinal durumuna geri döndürmeniz gerektiğini dikkate almalısınız.
Örneğin, sunulan birim testinde, sadakat sistemini hiçbir şekilde etkilemeyen, girilen telefon numarasını basitçe biçimlendiriyoruz.
Ve yeni bir müşteri oluşturma yöntemini kullanarak birim testleri yazarsak, her testten sonra sistemde yeni bir müşteri oluşturulacak ve bu, testin sonraki başlatılmasını etkileyebilir.
Birim testleri bu şekilde yapılır. İki olası başlatma seçeneği vardır: tüm birim testlerini belirli bir paketten çalıştırmak veya belirli bir birim testini belirli bir pakette çalıştırmak.
Dahili raporlama sisteminin bir örneği böyle görünüyor. Birim testinin sonuçlarına göre utPLSQL küçük bir rapor oluşturur. İçinde her bir kontrolün sonucunu ve birim testinin genel sonucunu görüyoruz.
Otomatik testlerin 6 kuralı
Sadakat sisteminin otomatik testi için yeni bir sistem oluşturmaya başlamadan önce yönetimle birlikte gelecekteki otomatik testlerimizin uyması gereken ilkeleri belirledik.
- Otomatik testler etkili ve faydalı olmalıdır. Kesinlikle bahsetmemiz gereken harika geliştiricilerimiz var, çünkü bazıları muhtemelen bu raporu görecek ve harika kodlar yazıyorlar. Ancak onların harika kodları bile mükemmel değil ve hatalar içeriyor, içeriyor ve içermeye devam edecek. Bu hataları bulmak için otomatik testler gereklidir. Durum böyle değilse, o zaman ya kötü otomatik testler yazıyoruz ya da prensipte geliştirilmeyen ölü bir alana geldik. Her iki durumda da bir şeyleri yanlış yapıyoruz ve yaklaşımımız kesinlikle mantıklı değil.
- Otomatik testler kullanılmalıdır. Bir yazılım ürününü yazmak için çok fazla zaman ve çaba harcamanın, onu bir depoya koyup unutmanın bir anlamı yok. Testler yapılmalı ve mümkün olduğunca düzenli olarak çalıştırılmalıdır.
- Otomatik testler istikrarlı bir şekilde çalışmalıdır. Günün saati, fırlatma standı ve diğer sistem ayarları ne olursa olsun, test çalıştırmaları aynı sonuca yol açmalıdır. Kural olarak bu, otomatik testlerin sabit sistem ayarlarına sahip özel test verileriyle çalışmasıyla sağlanır.
- Otomatik testler projeniz için kabul edilebilir bir hızda çalışmalıdır. Bu süre her sistem için ayrı ayrı belirlenir. Bazı insanlar tüm gün çalışmayı göze alabilirken, diğerleri bunu saniyeler içinde yapmanın kritik olduğunu düşünüyor. Projemizde hangi hız standartlarını yakaladığımızı biraz sonra anlatacağım.
- Otomatik test geliştirme esnek olmalıdır. Daha önce yapmadığımız için veya başka bir nedenden dolayı herhangi bir işlevi test etmeyi reddetmeniz tavsiye edilmez. utPLSQL, geliştirme konusunda herhangi bir kısıtlama getirmez ve Oracle, prensip olarak çeşitli şeyleri uygulamanıza izin verir. Çoğu sorunun bir çözümü vardır; bu sadece zaman ve çaba meselesidir.
- Konuşlandırılabilirlik. Test yapmamız gereken birkaç standımız var. Her standta bir veri dökümü istenildiği zaman güncellenebilir. Tam veya kısmi kurulumunu ağrısız bir şekilde gerçekleştirebileceğiniz şekilde otomatik testlerle bir proje yürütmek gerekir.
Birkaç gün sonra ikinci yazımda size ne yaptığımızı ve hangi sonuçları elde ettiğimizi anlatacağım.
Kaynak: habr.com