DBMS'de birim testleri - bunu Sportmaster'da nasıl yapıyoruz, ikinci bölüm

İlk kısım - burada.

Durumu hayal edin. Yeni işlevsellik geliştirme göreviyle karşı karşıyasınız. Sizden öncekilerden gelişmeler var. Hiçbir ahlaki yükümlülüğünüzün olmadığını varsayarsak ne yaparsınız?

Çoğu zaman tüm eski gelişmeler unutulur ve her şey yeniden başlar. Kimse başkasının kodunu araştırmaktan hoşlanmaz ama vaktiniz varsa neden kendi sisteminizi oluşturmaya başlamıyorsunuz? Bu tipik bir yaklaşımdır ve büyük ölçüde doğrudur. Ancak projemizde yanlış yaptık. Geleceğin otomatik test sistemini, öncüllerimizin utPLSQL üzerinde birim testlerindeki gelişmelere dayandırdık ve ardından birkaç paralel yönde çalışmaya başladık.

1. Eski birim testlerini geri yükleme. Kurtarma, testleri sadakat sisteminin mevcut durumuna uyarlamak ve testleri utPLSQL standartlarına uyarlamak anlamına gelir.
2. Otomatik testlerin tam olarak neleri, hangi yöntem ve süreçleri kapsadığını anlayarak bir problemi çözmek. Ya bu bilgiyi kafanızda tutmalısınız ya da doğrudan otomatik test koduna dayanarak sonuçlar çıkarmalısınız. Bu nedenle bir katalog oluşturmaya karar verdik. Her otomatik teste benzersiz bir anımsatıcı kod atadık, bir açıklama oluşturduk ve ayarları kaydettik (örneğin, hangi koşullar altında başlatılması gerektiği veya testin başlatılması başarısız olursa ne olması gerektiği). Temel olarak, otomatik testlerle ilgili meta verileri doldurduk ve bu meta verileri standart utPLSQL şema tablolarına yerleştirdik.
3. Genişleme stratejisinin tanımlanması, yani. otomatik testlerle doğrulanmaya tabi olan işlevlerin seçimi. Üç şeye dikkat etmeye karar verdik: yeni sistem iyileştirmeleri, üretim olayları ve temel sistem süreçleri. Böylece sürüme paralel olarak gelişiyor, daha yüksek kalitesini sağlıyor, eş zamanlı olarak regresyon kapsamını genişletiyor ve kritik yerlerde sistem güvenilirliğini sağlıyoruz. Bu tür darboğazlardan ilki, çek üzerinden indirim ve ikramiye dağıtma süreciydi.
4. Doğal olarak yeni otomatik testler geliştirmeye başladık. İlk sürüm görevlerinden biri, sadakat sisteminin önceden tanımlanmış örneklerinin performansını değerlendirmekti. Projemiz, istemcileri koşullara göre seçen, katı bir şekilde sabitlenmiş bir SQL sorguları bloğuna sahiptir. Örneğin, son alışverişini belirli bir şehirde gerçekleştiren tüm müşterilerin listesini veya ortalama satın alma tutarı belirli bir değerin üzerinde olan müşterilerin listesini alın. Otomatik testler yazarak önceden tanımlanmış örnekleri kontrol ettik, kıyaslama performans parametrelerini kaydettik ve ek olarak yük testi yaptık.
5. Otomatik testlerle çalışmak uygun olmalı. En yaygın iki eylem, otomatik testleri çalıştırmak ve test verileri oluşturmaktır. Sistemimizde iki yardımcı modül bu şekilde ortaya çıktı: bir fırlatma modülü ve bir veri oluşturma modülü.

   Başlatıcı, bir metin giriş parametresine sahip tek bir evrensel prosedür olarak temsil edilir. Parametre olarak otomatik test anımsatıcı kodunu, paket adını, test adını, otomatik test ayarını veya ayrılmış bir anahtar kelimeyi iletebilirsiniz. Prosedür, koşulları karşılayan tüm otomatik testleri seçer ve çalıştırır.

   Veri oluşturma modülü, test edilen sistemin her nesnesi için (veritabanındaki bir tablo), oraya veri ekleyen özel bir prosedürün oluşturulduğu bir paket biçiminde sunulur. Bu prosedürde, varsayılan değerler mümkün olduğu kadar doldurulur, bu da nesnelerin kelimenin tam anlamıyla bir parmak tıklamasıyla oluşturulmasını sağlar. Kullanım kolaylığı sağlamak amacıyla oluşturulan verilere yönelik şablonlar oluşturuldu. Örneğin, bir test telefonu ve tamamlanmış bir satın alma işlemiyle belirli bir yaşta bir müşteri oluşturun.

6. Otomatik testler, sisteminiz için kabul edilebilir bir zamanda başlamalı ve çalışmalıdır. Bu nedenle, sonuçlara göre bir rapor oluşturularak tüm geliştirme ekibine kurumsal posta yoluyla gönderilen günlük bir gece lansmanı düzenlendi. Eski otomatik testleri geri yükledikten ve yenilerini oluşturduktan sonra toplam çalışma süresi 30 dakikaydı. Lansman mesai saatleri dışında gerçekleştiği için bu performans herkese uygun oldu.

   Ancak iş hızını optimize etmek için çalışmamız gerekiyordu. Üretimdeki sadakat sistemi geceleri güncellenmektedir. Sürümlerden birinin bir parçası olarak geceleri acil değişiklikler yapmak zorunda kaldık. Sabah üçte otomatik testlerin sonuçlarını yarım saat beklemek, tahliyeden sorumlu kişiyi mutlu etmedi (Alexey Vasyukov'a hararetli selamlar!) ve ertesi sabah sistemimize yönelik pek çok güzel söz söylendi. Ancak bunun sonucunda 5 dakikalık çalışma standardı oluşturuldu.

   Performansı hızlandırmak için iki yöntem kullandık: otomatik testler üç paralel iş parçacığında çalışmaya başladı; neyse ki bu, sadakat sistemimizin mimarisi nedeniyle çok kullanışlı. Otomatik testin kendisi için test verisi oluşturmadığı, sistemde uygun bir şey bulmaya çalıştığı yaklaşımı da terk ettik. Değişiklikler yapıldıktan sonra toplam çalışma süresi 3-4 dakikaya düşürüldü.

7. Otomatik testleri olan bir proje çeşitli stantlarda uygulanabilmelidir. Yolculuğumuzun başında kendi toplu dosyalarımızı yazma girişimleri oldu, ancak kendi kendine yazılan otomatik kurulumun tam bir dehşet olduğu anlaşıldı ve endüstriyel çözümlere yöneldik. Projenin çok fazla doğrudan kod içermesi (her şeyden önce otomatik test kodunu saklıyoruz) ve çok az veri (ana veriler otomatik testlerle ilgili meta verilerdir) içermesi nedeniyle, Liquibase projesinde uygulamanın çok basit olduğu ortaya çıktı.

   Veritabanı şeması değişikliklerini izlemek, yönetmek ve uygulamak için kullanılan açık kaynaklı, veritabanından bağımsız bir kitaplıktır. Komut satırı veya Apache Maven gibi çerçeveler aracılığıyla yönetilir. Liquibase'in çalışma prensibi oldukça basittir. Hedef sunucuya dağıtılması gereken değişiklikler veya scriptlerden oluşan, belirli bir şekilde organize edilmiş bir projemiz ve bu değişikliklerin hangi sırayla ve hangi parametrelerle yüklenmesi gerektiğini belirleyen kontrol dosyalarımız var.

   DBMS düzeyinde, Liquibase'in rollover günlüğünü sakladığı özel bir tablo oluşturulur. Her değişikliğin, proje ile veritabanındaki durum arasında her seferinde karşılaştırılan hesaplanmış bir karması vardır. Liquibase sayesinde sistemimizdeki değişiklikleri herhangi bir devreye kolaylıkla aktarabiliyoruz. Otomatik testler artık test ve sürüm devrelerinin yanı sıra konteynerlerde (geliştiricilerin kişisel devreleri) başlatılıyor.

Şimdi birim test sistemimizi kullanmanın sonuçlarından bahsedelim.

1. Tabi ki öncelikle daha iyi yazılımlar geliştirmeye başladığımıza inanıyoruz. Otomatik testler günlük olarak başlatılır ve her sürümde onlarca hata bulunur. Üstelik bu hataların bazıları gerçekten değiştirmek istediğimiz işlevsellikle yalnızca dolaylı olarak ilgilidir. Bu hataların manuel testlerle bulunduğuna dair ciddi şüpheler var.
2. Ekip artık belirli işlevlerin doğru çalıştığına inanıyor... Her şeyden önce bu, kritik süreçlerimizi ilgilendiriyor. Örneğin, geçtiğimiz altı ayda, sürüm değişikliklerine rağmen indirimlerin ve ikramiyelerin makbuzlara dağıtımında herhangi bir sorun yaşamadık, ancak önceki dönemlerde hatalar belirli aralıklarla meydana geldi
3. Test yinelemelerinin sayısını azaltmayı başardık. Otomatik testlerin yeni işlevsellik için yazılması nedeniyle analistler ve yarı zamanlı test uzmanları daha yüksek kalitede kod alırlar, çünkü zaten kontrol edildi.
4. Otomatik testlerdeki bazı gelişmeler geliştiriciler tarafından kullanılmaktadır. Örneğin, konteynerler üzerindeki test verileri, nesne oluşturma modülü kullanılarak oluşturulur.
5. Geliştiriciler açısından otomatik test sisteminin "kabulünü" geliştirmiş olmamız önemlidir. Bunun önemli ve faydalı olduğuna dair bir anlayış var. Ancak kendi tecrübelerime dayanarak bunun durumdan çok uzak olduğunu söyleyebilirim. Otomatik testlerin yazılması, desteklenmesi ve geliştirilmesi gerekir, sonuçların analiz edilmesi gerekir ve çoğu zaman bu zaman maliyetlerine değmez. Üretime gidip oradaki sorunlarla uğraşmak çok daha kolay. Burada geliştiriciler sıraya giriyor ve bizden işlevlerini otomatik testlerle karşılamamızı istiyorlar.

sonra ne

Otomatik test projesinin geliştirme planlarından bahsedelim.

Elbette Sportmaster'ın sadakat sistemi canlı olduğu ve gelişmeye devam ettiği sürece, ototestlerin neredeyse sonsuz şekilde geliştirilmesi de mümkün. Bu nedenle, gelişmenin ana yönü kapsama alanını genişletmektir.

Otomatik testlerin sayısı arttıkça toplam çalışma süreleri de giderek artacak ve tekrar performans konusuna dönmemiz gerekecek. Büyük ihtimalle çözüm paralel iş parçacıklarının sayısını artırmak olacaktır.

Ancak bunlar bariz gelişme yollarıdır. Daha önemsiz olmayan bir şeyden bahsedersek, aşağıdakileri vurgularız:

1. Şu anda otomatik test yönetimi DBMS düzeyinde gerçekleştirilmektedir; Başarılı bir çalışma için PL/SQL bilgisi gereklidir. Gerekirse sistem yönetimi (örneğin, meta verileri başlatmak veya oluşturmak), Jenkins veya benzeri bir şeyi kullanarak bir tür yönetici paneli oluşturabilirsiniz.
2. Herkes niceliksel ve niteliksel göstergeleri sever. Otomatik testler için böyle bir evrensel gösterge, Kod Kapsamı veya kod kapsamı metriğidir. Bu göstergeyi kullanarak, test edilen sistemimizin kodunun yüzde kaçının otomatik testlerin kapsamında olduğunu belirleyebiliriz. Oracle, 12.2 sürümünden itibaren bu ölçümü hesaplama olanağı sağlıyor ve standart DBMS_PLSQL_CODE_COVERAGE paketinin kullanımını sunuyor.

   Otomatik test sistemimiz bir yıldan biraz daha eski ve belki de şimdi kapsamımızı değerlendirmenin zamanıdır. Son projemde (Sportmaster projesi değil) böyle oldu. Otomatik testler üzerinde çalıştıktan bir yıl sonra yönetim, kodun yüzde kaçını kapsadığımızı değerlendirme görevini belirledi. Yüzde 1'den fazla kapsama alanıyla yönetim mutlu olacaktır. Biz geliştiriciler yaklaşık %10'luk bir sonuç bekliyorduk. Kod kapsamını kurduk, ölçtük ve %20 elde ettik. Kutlamak için ödülü almaya gittik ama onu nasıl aldığımız ve daha sonra nereye gittiğimiz tamamen farklı bir hikaye.

3. Otomatik testler, açığa çıkan web hizmetlerini kontrol edebilir. Oracle bunu oldukça iyi yapmamıza izin veriyor ve artık bir takım sorunlarla karşılaşmayacağız.
4. Ve elbette otomatik test sistemimiz başka bir projeye de uygulanabilir. Aldığımız çözüm evrenseldir ve yalnızca Oracle kullanımını gerektirir. Diğer Sportmaster projelerinin otomatik testlerle ilgilendiğini, belki onlara da gideceğimizi duydum.

Bulgular

Özetleyelim. Sportmaster'daki sadakat sistemi projesinde otomatik test sistemini hayata geçirmeyi başardık. Stephen Feuerstein'ın utPLSQL çözümüne dayanmaktadır. UtPLSQL çevresinde otomatik test kodu ve kendi kendine yazılan yardımcı modüller bulunur: başlatma modülü, veri oluşturma modülü ve diğerleri. Otomatik testler günlük olarak başlatılır ve en önemlisi çalışır ve faydalıdır. Daha kaliteli yazılımlar yayınlamaya başladığımızdan eminiz. Aynı zamanda ortaya çıkan çözüm evrenseldir ve Oracle DBMS üzerinde otomatik testlerin organize edilmesinin gerekli olduğu her projeye serbestçe uygulanabilir.

Not: Bu makale çok spesifik değil: çok fazla metin var ve neredeyse hiç teknik örnek yok. Konu genel olarak ilginçse, devam etmeye ve son altı ayda nelerin değiştiğini size anlatacağımız ve kod örnekleri sunacağımız bir devamla geri dönmeye hazırız.

İleride vurgulanması gereken noktalar veya açıklanması gereken sorular varsa yorum olarak yazın.

Ankete sadece kayıtlı kullanıcılar katılabilir. Giriş yapLütfen.

Bu konuda daha fazla yazalım mı?

• Evet elbette

• Hayır teşekkürler

12 kullanıcı oy kullandı. 4 kullanıcı çekimser kaldı.

Kaynak: habr.com