DBMS-də vahid testləri - biz bunu Sportmaster-də necə edirik, ikinci hissə

Birinci hissə - burada.

Vəziyyəti təsəvvür edin. Yeni funksionallıq inkişaf etdirmək vəzifəsi ilə qarşılaşırsınız. Sizdə sələflərinizdən inkişaflar var. Əgər fərz etsək ki, sizin heç bir mənəvi borcunuz yoxdur, nə edərdiniz?

Çox vaxt bütün köhnə inkişaflar unudulur və hər şey yenidən başlayır. Heç kim başqasının kodunu qazmağı sevmir, amma vaxtınız varsa, niyə öz sisteminizi yaratmağa başlamırsınız? Bu tipik bir yanaşmadır və əsasən düzgündür. Amma layihəmizdə bunu səhv etmişik. Biz gələcək avtomatik sınaq sistemini sələflərimizin utPLSQL-də vahid testlərindəki inkişaflara əsaslandırdıq və sonra bir neçə paralel istiqamətdə işə başladıq.

1. Köhnə vahid testlərinin bərpası. Bərpa testləri loyallıq sisteminin mövcud vəziyyətinə uyğunlaşdırmaq və testləri utPLSQL standartlarına uyğunlaşdırmaq deməkdir.
2. Avtotestlərlə dəqiq nəyin, hansı metodların və proseslərin əhatə olunduğunu anlamaqla problemin həlli. Siz ya bu məlumatı beyninizdə saxlamalı, ya da bilavasitə avtotest kodu əsasında nəticə çıxarmalısınız. Buna görə də biz kataloq yaratmağa qərar verdik. Biz hər bir avtotest üçün unikal mnemonik kod təyin etdik, təsvir yaratdıq və parametrləri qeyd etdik (məsələn, hansı şəraitdə işə salınmalı və ya testin işə salınması uğursuz olarsa nə baş verməlidir). Əsasən, biz avtotestlər haqqında metaməlumatları doldurduq və həmin metaməlumatları standart utPLSQL sxem cədvəllərinə yerləşdirdik.
3. Genişlənmə strategiyasının müəyyən edilməsi, yəni. avtomatlaşdırılmış testlərlə yoxlanılan funksionallığın seçilməsi. Biz üç şeyə diqqət yetirmək qərarına gəldik: yeni sistem təkmilləşdirmələri, istehsal hadisələri və əsas sistem prosesləri. Beləliklə, biz buraxılışa paralel olaraq inkişaf edirik, onun daha yüksək keyfiyyətini təmin edirik, eyni zamanda reqressiyanın əhatə dairəsini genişləndiririk və kritik yerlərdə sistemin etibarlılığını təmin edirik. İlk belə darboğaz çek üzərində endirimlərin və bonusların paylanması prosesi idi.
4. Təbii ki, biz yeni avtotestlər hazırlamağa başladıq. İlk buraxılış tapşırıqlarından biri loyallıq sisteminin əvvəlcədən müəyyən edilmiş nümunələrinin performansını qiymətləndirmək idi. Layihəmiz şərtlər əsasında müştəriləri seçən sərt şəkildə sabitlənmiş SQL sorğuları blokuna malikdir. Məsələn, son alışı müəyyən bir şəhərdə olan bütün müştərilərin siyahısını və ya orta alış məbləği müəyyən bir dəyərdən yuxarı olan müştərilərin siyahısını əldə edin. Yazılı avtotestlərdən sonra biz əvvəlcədən təyin edilmiş nümunələri yoxladıq, etalon performans parametrlərini qeyd etdik və əlavə olaraq yük testini keçirdik.
5. Avtotestlərlə işləmək rahat olmalıdır. Ən çox görülən iki hərəkət avtotestləri həyata keçirmək və test məlumatlarını yaratmaqdır. Sistemimizdə iki köməkçi modul belə meydana çıxdı: işə salma modulu və məlumat yaratma modulu.

   Başlatıcı bir mətn daxiletmə parametri ilə bir universal prosedur kimi təqdim olunur. Parametr olaraq siz avtotest mnemonic kodunu, paket adını, test adını, avtotest parametrini və ya qorunan açar sözü keçə bilərsiniz. Prosedur şərtlərə cavab verən bütün avtotestləri seçir və həyata keçirir.

   Məlumatların yaradılması modulu paket şəklində təqdim olunur ki, orada sınaqdan keçirilən sistemin hər bir obyekti (verilənlər bazasındakı cədvəl) üçün oraya məlumatları daxil edən xüsusi prosedur yaradılmışdır. Bu prosedurda standart dəyərlər mümkün qədər doldurulur ki, bu da barmağın kliklədiyi anda obyektlərin yaradılmasını təmin edir. Və istifadənin asanlığı üçün yaradılan məlumatlar üçün şablonlar yaradıldı. Məsələn, test telefonu və tamamlanmış satınalma ilə müəyyən bir yaşda bir müştəri yaradın.

6. Avtotestlər sisteminiz üçün məqbul olan vaxtda başlamalı və işləməlidir. Buna görə gündəlik gecə buraxılışı təşkil edildi, onun nəticələrinə əsasən nəticələr haqqında hesabat hazırlanır və korporativ poçt vasitəsilə bütün inkişaf komandasına göndərilir. Köhnə avtotestləri bərpa etdikdən və yenilərini yaratdıqdan sonra ümumi iş vaxtı 30 dəqiqə idi. Bu tamaşa hər kəsə yaraşırdı, çünki təqdimat iş saatları xaricində baş tutdu.

   Amma işin sürətini optimallaşdırmaq üzərində işləməli olduq. İstehsalda sadiqlik sistemi gecə yenilənir. Buraxılışlardan birinin bir hissəsi olaraq gecə təcili dəyişikliklər etməli olduq. Səhər saat üçdə avtotestlərin nəticələrini yarım saat gözləmək buraxılışa cavabdeh olan şəxsi sevindirmədi (Aleksey Vasyukova qızğın salamlar!), Səhəri gün sistemimizə qarşı çoxlu xoş sözlər deyildi. Ancaq nəticədə iş üçün 5 dəqiqəlik standart quruldu.

   Performansı sürətləndirmək üçün iki üsuldan istifadə etdik: avtotestlər üç paralel ipdə işləməyə başladı, xoşbəxtlikdən bu, sadiqlik sistemimizin arxitekturasına görə çox rahatdır. Avtotestin özü üçün test məlumatları yaratmadığı, lakin sistemdə uyğun bir şey tapmağa çalışdığı yanaşmadan imtina etdik. Dəyişikliklər edildikdən sonra ümumi iş vaxtı 3-4 dəqiqəyə endirildi.

7. Avtomatik sınaqları olan bir layihə müxtəlif stendlərdə yerləşdirilə bilməlidir. Səyahətimizin əvvəlində öz toplu fayllarımızı yazmağa cəhdlər oldu, lakin aydın oldu ki, öz-özünə yazılmış avtomatlaşdırılmış quraşdırma tam dəhşətdir və biz sənaye həllərinə üz tutduq. Layihədə çoxlu birbaşa kod (ilk növbədə, biz avtotest kodunu saxlayırıq) və çox az məlumat (əsas məlumatlar avtotestlər haqqında metadata) ehtiva etdiyinə görə Liquibase layihəsində həyata keçirmək çox sadə oldu.

   Bu, verilənlər bazası sxemindəki dəyişiklikləri izləmək, idarə etmək və tətbiq etmək üçün açıq mənbəli, verilənlər bazasından müstəqil kitabxanadır. Komanda xətti və ya Apache Maven kimi çərçivələr vasitəsilə idarə olunur. Liquibase-in iş prinsipi olduqca sadədir. Müəyyən bir şəkildə təşkil edilmiş layihəmiz var, o, hədəf serverə yayılmalı olan dəyişikliklərdən və ya skriptlərdən və bu dəyişikliklərin hansı ardıcıllıqla və hansı parametrlərlə quraşdırılmasını müəyyən edən nəzarət fayllarından ibarətdir.

   DBMS səviyyəsində Liquibase-in rollover jurnalını saxladığı xüsusi cədvəl yaradılır. Hər bir dəyişikliyin hesablanmış hashı var ki, bu da hər dəfə layihə ilə verilənlər bazasındakı vəziyyət arasında müqayisə edilir. Liquibase sayəsində sistemimizdəki dəyişiklikləri istənilən dövrəyə asanlıqla tətbiq edə bilərik. Avtotestlər indi sınaq və buraxma sxemlərində, eləcə də konteynerlərdə (inkişafçıların şəxsi sxemləri) işə salınır.

Beləliklə, vahid test sistemimizdən istifadənin nəticələri haqqında danışaq.

1. Təbii ki, ilk növbədə, biz daha yaxşı proqram təminatı hazırlamağa başladığımıza əminik. Avtotestlər gündəlik işə salınır və hər buraxılışda onlarla səhv tapılır. Üstəlik, bu səhvlərdən bəziləri yalnız dolayı yolla bizim həqiqətən dəyişmək istədiyimiz funksionallıqla bağlıdır. Bu səhvlərin əllə sınaqdan keçirildiyinə dair ciddi şübhələr var.
2. Komanda indi xüsusi funksionallığın düzgün işlədiyinə əmindir... İlk növbədə, bu, bizim kritik proseslərimizə aiddir. Məsələn, son altı ay ərzində buraxılış dəyişikliklərinə baxmayaraq, qəbzlər üzrə endirimlərin və bonusların paylanması ilə bağlı heç bir problem yaşamamışıq, baxmayaraq ki, əvvəlki dövrlərdə müəyyən tezliklərdə səhvlər baş verib.
3. Biz sınaq iterasiyalarının sayını azaltmağı bacardıq. Avtotestlərin yeni funksionallıq üçün yazıldığına görə, analitiklər və part-time testerlər daha yüksək keyfiyyətli kod alırlar, çünki artıq yoxlanılıb.
4. Avtomatlaşdırılmış testlərdəki bəzi inkişaflar tərtibatçılar tərəfindən istifadə olunur. Məsələn, obyekt generasiya modulundan istifadə etməklə konteynerlər üzrə test məlumatları yaradılır.
5. Tərtibatçılar tərəfindən avtomatlaşdırılmış sınaq sisteminin "qəbulunu" hazırlamağımız vacibdir. Bunun vacib və faydalı olduğu anlayışı var. Amma öz təcrübəmdən deyə bilərəm ki, bu, çox uzaqdır. Avtotestlər yazılmalıdır, onları dəstəkləmək və inkişaf etdirmək, nəticələr təhlil etmək lazımdır və çox vaxt bu vaxt xərcləri sadəcə olaraq buna dəyməz. İstehsalata getmək və orada problemləri həll etmək daha asandır. Burada tərtibatçılar sıraya düzülür və bizdən onların funksionallığını avtotestlərlə əhatə etməyi xahiş edirlər.

Nədir?

Gəlin avtomatlaşdırılmış sınaq layihəsinin inkişaf planlarından danışaq.

Əlbəttə, nə qədər ki, Sportmaster-in loyallıq sistemi canlıdır və inkişaf etməkdə davam edir, avtotestləri demək olar ki, sonsuz şəkildə inkişaf etdirmək də mümkündür. Buna görə də inkişafın əsas istiqaməti əhatə dairəsinin genişləndirilməsidir.

Avtotestlərin sayı artdıqca, onların ümumi işləmə müddəti durmadan artacaq və biz yenidən performans məsələsinə qayıtmalı olacağıq. Çox güman ki, həll yolu paralel iplərin sayını artırmaq olacaq.

Ancaq bunlar aşkar inkişaf yollarıdır. Daha qeyri-ciddi bir şey haqqında danışsaq, aşağıdakıları vurğulayırıq:

1. Hazırda DBMS səviyyəsində avtotestin idarə edilməsi həyata keçirilir, yəni. uğurlu iş üçün PL/SQL biliyi tələb olunur. Lazım gələrsə, sistemin idarə edilməsi (məsələn, metadatanın işə salınması və ya yaradılması), Jenkins və ya buna bənzər bir şeydən istifadə edərək bir növ idarəetmə paneli yarada bilərsiniz.
2. Hər kəs kəmiyyət və keyfiyyət göstəricilərini sevir. Avtomatlaşdırılmış sınaq üçün belə bir universal göstərici Kod Əhatəsi və ya kodu əhatə etmə metrikidir. Bu göstəricidən istifadə edərək, sınaqdan keçirilən sistemimizin kodunun neçə faizinin avtotestlərlə əhatə olunduğunu müəyyən edə bilərik. 12.2 versiyasından başlayaraq Oracle bu metrikanı hesablamaq imkanı verir və standart DBMS_PLSQL_CODE_COVERAGE paketinin istifadəsini təklif edir.

   Avtotest sistemimizin bir ildən çox yaşı var və bəlkə də indi əhatə dairəmizi qiymətləndirməyin vaxtıdır. Son layihəmdə (Sportmaster layihəsi deyil) belə oldu. Avtotestlər üzərində işlədikdən bir il sonra rəhbərlik kodun neçə faizini əhatə etdiyimizi qiymətləndirmək vəzifəsini qoydu. 1%-dən çox əhatə dairəsi ilə rəhbərlik xoşbəxt olardı. Biz, tərtibatçılar, təxminən 10% nəticə gözləyirdik. Kod əhatə dairəsini quraşdırdıq, ölçdük və 20% aldıq. Qeyd etmək üçün biz mükafatı almağa getmişdik, amma onu almaq üçün necə getdiyimiz və sonra hara getdiyimiz tamam başqa hekayədir.

3. Avtotestlər açıq veb xidmətləri yoxlaya bilər. Oracle bizə bunu kifayət qədər yaxşı etməyə imkan verir və biz artıq bir sıra problemlərlə qarşılaşmayacağıq.
4. Və təbii ki, bizim avtomatlaşdırılmış test sistemimiz başqa bir layihəyə tətbiq oluna bilər. Aldığımız həll universaldır və yalnız Oracle istifadəsini tələb edir. Eşitdim ki, digər Sportmaster layihələri avtomatik sınaqlarla maraqlanır və bəlkə biz onlara gedərik.

Tapıntılar

Gəlin ümumiləşdirək. Sportmaster-də loyallıq sistemi layihəsində biz avtomatlaşdırılmış test sistemini tətbiq edə bildik. O, Stephen Feuerstein-in utPLSQL həllinə əsaslanır. UtPLSQL ətrafında avtotest kodu və köməkçi öz-özünə yazılmış modullar mövcuddur: işə salma modulu, məlumat yaratma modulu və s. Avtotestlər gündəlik işə salınır və ən əsası işləyir və faydalıdır. Əminik ki, biz daha yüksək keyfiyyətli proqram təminatı buraxmağa başlamışıq. Eyni zamanda, əldə edilən həll universaldır və Oracle DBMS-də avtomatlaşdırılmış testin təşkili zəruri olan istənilən layihəyə sərbəst şəkildə tətbiq oluna bilər.

P.S. Bu məqalə çox konkret deyil: çoxlu mətn var və praktiki olaraq heç bir texniki nümunə yoxdur. Əgər mövzu ümumiyyətlə maraqlıdırsa, biz onu davam etdirməyə və davamı ilə qayıtmağa hazırıq, burada son altı ayda nələrin dəyişdiyini sizə xəbər verəcəyik və kod nümunələri təqdim edəcəyik.

Gələcəkdə vurğulanmalı olan məqamlar və ya açıqlama tələb edən suallar varsa şərh yazın.

Sorğuda yalnız qeydiyyatdan keçmiş istifadəçilər iştirak edə bilər. Daxil olunxahiş edirəm.

Bu haqda daha çox yazaq?

• Əlbətdə

• Xeyr, təşəkkürlər

12 istifadəçi səs verib. 4 istifadəçi bitərəf qalıb.

Mənbə: www.habr.com