Hey Habr!
Mənim adım Maksim Ponomarenkodur və mən Sportmaster-də tərtibatçıyam. İT sahəsində 10 illik təcrübəm var. O, karyerasına manuel testlərlə başlayıb, sonra verilənlər bazası işinə keçib. Son 4 ildə test və inkişafda əldə etdiyim bilikləri toplayaraq DBMS səviyyəsində testləri avtomatlaşdırıram.
Mən cəmi bir ildən çoxdur ki, Sportmaster komandasındayam və əsas layihələrdən birində avtomatlaşdırılmış testlər hazırlayıram. Aprel ayında Sportmaster Lab-dan olan uşaqlar və mən Krasnodarda konfransda çıxış etdim, mənim məruzəm “DBMS-də vahid testləri” adlanırdı və indi bunu sizinlə bölüşmək istəyirəm. Mətn çox olacaq, ona görə də hesabatı iki yazıya bölmək qərarına gəldim. Birincidə biz avtotestlər və ümumən testlər haqqında danışacağıq, ikincidə isə vahid sınaq sistemimiz və onun tətbiqi nəticələri haqqında daha ətraflı danışacağam.
Birincisi, bir az darıxdırıcı nəzəriyyə. Avtomatlaşdırılmış sınaq nədir? Bu proqram təminatı tərəfindən həyata keçirilən sınaqdır və müasir İT-də proqram təminatının hazırlanmasında getdikcə daha çox istifadə olunur. Bu onunla bağlıdır ki, şirkətlər böyüyür, onların informasiya sistemləri böyüyür və müvafiq olaraq sınaqdan keçirilməli olan funksionallıqların həcmi də artır. Əl testinin aparılması getdikcə daha bahalı olur.
Relizləri iki aydan bir çıxan böyük bir şirkətdə işləyirdim. Eyni zamanda, bir çox testerin funksionallığı əl ilə yoxlamasına bir ay sərf olundu. Kiçik bir tərtibatçı komandası tərəfindən avtomatlaşdırmanın tətbiqi sayəsində biz il yarım ərzində sınaq müddətini 2 həftəyə qədər azalda bildik. Biz sınaqların sürətini artırmaqla yanaşı, keyfiyyətini də yaxşılaşdırmışıq. Avtomatlaşdırılmış testlər müntəzəm olaraq işə salınır və onlar həmişə onlara daxil olan bütün yoxlama kurslarını həyata keçirirlər, yəni insan amilini istisna edirik.
Müasir İT inkişaf etdiricidən yalnız məhsul kodunu yazmağı deyil, həm də bu kodu yoxlayan vahid testləri yazmağı tələb edə biləcəyi ilə xarakterizə olunur.
Bəs sisteminiz əsasən server məntiqinə əsaslanırsa nə olacaq? Bazarda universal həll və ya ən yaxşı təcrübə yoxdur. Bir qayda olaraq, şirkətlər bu problemi öz yazılı test sistemini yaratmaqla həll edirlər. Bu, bizim layihəmizdə yaradılmış özümüz tərəfindən yazılmış avtomatlaşdırılmış test sistemimizdir və mən bu barədə hesabatımda danışacağam.
Sadiqliyi sınamaq
Əvvəlcə avtomatlaşdırılmış sınaq sistemini yerləşdirdiyimiz layihə haqqında danışaq. Layihəmiz Sportmaster loyallıq sistemidir (yeri gəlmişkən, bu barədə artıq yazmışdıq ).
Əgər şirkətiniz kifayət qədər böyükdürsə, sadiqlik sisteminizin üç standart xüsusiyyəti olacaq:
- Sisteminiz çox yüklənəcək
- Sisteminizdə mürəkkəb hesablama prosesləri olacaq
- Sisteminiz aktiv şəkildə təkmilləşdiriləcək.
Gəlin sıra ilə gedək... Ümumilikdə bütün Sportmaster brendlərini nəzərə alsaq, Rusiya, Ukrayna, Çin, Qazaxıstan və Belarusda 1000-dən çox mağazamız var. Bu mağazalarda hər gün 300 minə yaxın alış-veriş edilir. Yəni hər saniyədə 000-3 çek sistemimizə daxil olur. Təbii ki, loyallıq sistemimiz çox yüklənmişdir. Və aktiv şəkildə istifadə edildiyi üçün biz onun keyfiyyətinin ən yüksək standartlarını təmin etməliyik, çünki proqram təminatında hər hansı bir səhv böyük pul, reputasiya və digər itkilər deməkdir.
Eyni zamanda, Sportmaster yüzdən çox müxtəlif promosyonlar keçirir. Müxtəlif promosyonlar var: məhsul promosyonları var, həftənin gününə həsr olunanlar var, müəyyən bir mağazaya bağlı olanlar var, qəbz məbləği üçün promosyonlar var, malların sayına görə. Ümumiyyətlə, pis deyil. Müştərilərin alış-veriş edərkən istifadə etdikləri bonuslar və promosyon kodları var. Bütün bunlar ona gətirib çıxarır ki, hər hansı bir sifarişin hesablanması çox qeyri-ciddi bir işdir.
Sifariş emalını həyata keçirən alqoritm həqiqətən dəhşətli və mürəkkəbdir. Və bu alqoritmdə hər hansı dəyişiklik olduqca risklidir. Görünürdü ki, ən əhəmiyyətsiz görünən dəyişikliklər olduqca gözlənilməz təsirlərə səbəb ola bilər. Lakin məhz belə mürəkkəb hesablama prosesləri, xüsusən də kritik funksionallığı həyata keçirən proseslər avtomatlaşdırma üçün ən yaxşı namizədlərdir. Onlarla oxşar işi əl ilə yoxlamaq çox vaxt aparır. Prosesə giriş nöqtəsi dəyişməz olduğundan, onu bir dəfə təsvir edərək, tez bir zamanda avtomatik testlər yarada və funksionallığın işləyəcəyinə əmin ola bilərsiniz.
Sistemimiz aktiv şəkildə istifadə olunduğu üçün biznes sizdən yeni bir şey istəyəcək, zamanla yaşayacaq və müştəri yönümlü olacaq. Sadiqlik sistemimizdə relizlər iki aydan bir çıxır. Bu o deməkdir ki, hər iki aydan bir bütün sistemin tam reqressiyasını həyata keçirməliyik. Eyni zamanda, təbii ki, hər hansı müasir İT-də olduğu kimi, inkişaf dərhal tərtibatçıdan istehsala keçmir. O, tərtibatçının dövrəsində yaranır, sonra ardıcıl olaraq sınaq stendindən keçir, buraxılır, qəbul edilir və yalnız bundan sonra istehsalda başa çatır. Ən azı, sınaq və buraxma sxemlərində bütün sistemin tam reqressiyasını həyata keçirməliyik.
Təsvir edilən xüsusiyyətlər demək olar ki, hər hansı bir sadiqlik sistemi üçün standartdır. Layihəmizin xüsusiyyətlərindən danışaq.
Texnoloji cəhətdən loyallıq sistemimizin məntiqinin 90%-i serverə əsaslanır və Oracle-da həyata keçirilir. Delphi-də iş yerinin avtomatlaşdırılmış administratoru funksiyasını yerinə yetirən müştəri ifşa olunur. Xarici tətbiqlər üçün açıq veb xidmətləri var (məsələn, veb-sayt). Ona görə də, biz avtomatlaşdırılmış test sistemini yerləşdirsək, bunu Oracle-da edəcəyik ki, çox məntiqlidir.
Sportmaster-də loyallıq sistemi 7 ildən artıqdır ki, mövcuddur və tək developerlər tərəfindən yaradılıb... Bu 7 il ərzində layihəmizdə tərtibatçıların orta sayı 3-4 nəfər olub. Amma son bir ildə komandamız xeyli böyüdü və hazırda layihədə 10 nəfər işləyir. Yəni, layihəyə tipik tapşırıqlar, proseslər və arxitektura ilə tanış olmayan insanlar gəlir. Səhvləri əldən vermə riskimiz də artır.
Layihə ştat vahidləri kimi xüsusi sınaqçıların olmaması ilə xarakterizə olunur. Əlbəttə ki, testlər var, lakin sınaq analitiklər tərəfindən həyata keçirilir, onların digər əsas vəzifələrindən əlavə: biznes müştəriləri, istifadəçiləri ilə ünsiyyət, sistem tələblərinin hazırlanması və s. Sınaqların çox yüksək keyfiyyətlə aparılmasına baxmayaraq (xüsusilə bunu qeyd etmək yerinə düşər, çünki bəzi analitiklər bu hesabatın diqqətini çəkə bilər), ixtisaslaşmanın və bir şeyə konsentrasiyanın effektivliyi ləğv edilməyib. .
Yuxarıda göstərilənlərin hamısını nəzərə alaraq, çatdırılan məhsulun keyfiyyətini yaxşılaşdırmaq və inkişaf müddətini azaltmaq üçün bir layihədə sınaqların avtomatlaşdırılması fikri çox məntiqli görünür. Sadiqlik sisteminin mövcudluğunun müxtəlif mərhələlərində fərdi tərtibatçılar kodlarını vahid testlərlə əhatə etmək üçün səy göstərdilər. Bütövlükdə bu, hər kəsin öz memarlıq və metodlarından istifadə etdiyi kifayət qədər ayrı bir proses idi. Yekun nəticələr vahid testlər üçün ümumi idi: testlər hazırlanmış, bir müddət istifadə edilmiş, versiyalı fayl anbarında saxlanılmış, lakin müəyyən bir anda onlar işləməyi dayandırmış və unudulmuşlar. Əvvəla, bu, testlərin layihəyə deyil, daha çox konkret ifaçıya bağlanması ilə bağlı idi.
utPLSQL köməyə gəlir
Stephen Feuerstein haqqında bir şey bilirsinizmi?
Bu, karyerasının uzun bir hissəsini Oracle və PL/SQL ilə işləməyə həsr etmiş və bu mövzuda kifayət qədər çox sayda əsər yazmış ağıllı oğlandır. Onun məşhur kitablarından biri belə adlanır: “Oracle PL/SQL. Peşəkarlar üçün." Məhz Stiven utPLSQL həllini və ya Oracle PL/SQL üçün Unit Testing çərçivəsini inkişaf etdirdi. utPLSQL həlli 2016-cı ildə yaradılıb, lakin onun üzərində fəal şəkildə işləmək davam edir və yeni versiyalar buraxılır. Hesabat zamanı ən son versiya 24 mart 2019-cu il tarixinə aiddir.
Bu nədir. Bu ayrı bir açıq mənbə layihəsidir. Nümunələr və sənədlər də daxil olmaqla bir neçə meqabayt ağırlığında. Fiziki olaraq, bu, vahid testinin təşkili üçün paketlər və cədvəllər dəsti ilə ORACLE verilənlər bazasında ayrıca bir sxemdir. Quraşdırma bir neçə saniyə çəkir. utPLSQL-in fərqləndirici xüsusiyyəti onun istifadəsi asanlığıdır.
Qlobal miqyasda, utPLSQL vahid testləri yerinə yetirmək üçün bir mexanizmdir, burada vahid testi adi Oracle toplu prosedurları kimi başa düşülür, onun təşkili müəyyən qaydalara əməl edir. Başlamağa əlavə olaraq, utPLSQL bütün sınaq işlərinizin jurnalını saxlayır və həmçinin daxili hesabat sisteminə malikdir.
Bu texnikadan istifadə edərək həyata keçirilən vahid test kodunun necə göründüyünə dair bir nümunəyə baxaq.
Beləliklə, ekran vahid testləri ilə tipik bir paket spesifikasiyası üçün kodu göstərir. Məcburi tələblər hansılardır? Paketə "utp_" prefiksi qoyulmalıdır. Testləri olan bütün prosedurlar eyni prefiksə malik olmalıdır. Paketdə iki standart prosedur olmalıdır: “utp_setup” və “utp_teardown”. Birinci prosedur hər bir vahid testini yenidən başlatmaqla çağırılır, ikincisi - işə salındıqdan sonra.
“utp_setup”, bir qayda olaraq, sistemimizi vahid testini həyata keçirməyə hazırlayır, məsələn, test məlumatları yaratmaq. "utp_teardown" - əksinə, hər şey orijinal parametrlərə qayıdır və başlanğıc nəticələrini sıfırlayır.
Budur, daxil edilmiş müştəri telefon nömrəsinin loyallıq sistemimiz üçün standart formaya normallaşdırılmasını yoxlayan ən sadə vahid testinin nümunəsi. Vahid testləri ilə prosedurların necə yazılmasına dair məcburi standartlar yoxdur. Bir qayda olaraq, sınaqdan keçirilən sistemin metoduna zəng edilir və bu üsulla qaytarılan nəticə istinad ilə müqayisə edilir. İstinad nəticəsi ilə əldə edilənin müqayisəsinin standart utPLSQL metodları vasitəsilə baş verməsi vacibdir.
Vahid testində istənilən sayda yoxlama ola bilər. Nümunədən göründüyü kimi, telefon nömrəsini normallaşdırmaq və hər zəngdən sonra nəticəni qiymətləndirmək üçün sınaqdan keçirilmiş üsula ardıcıl dörd zəng edirik. Bir vahid testini hazırlayarkən, sistemə heç bir şəkildə təsir etməyən yoxlamaların olduğunu nəzərə almalısınız və bir müddət sonra sistemin orijinal vəziyyətinə qayıtmaq lazımdır.
Məsələn, təqdim olunan vahid testində biz sadəcə olaraq daxil olan telefon nömrəsini formatlayırıq, bu da sadiqlik sisteminə heç bir şəkildə təsir etmir.
Yeni müştəri yaratmaq metodundan istifadə edərək vahid testlərini yazsaq, hər sınaqdan sonra sistemdə yeni bir müştəri yaradılacaq ki, bu da testin sonrakı işə salınmasına təsir göstərə bilər.
Vahid testləri belə aparılır. İki mümkün işə salma variantı var: xüsusi paketdən bütün vahid testlərini həyata keçirmək və ya xüsusi paketdə xüsusi vahid testini həyata keçirmək.
Daxili hesabat sisteminin nümunəsi belə görünür. Vahid testinin nəticələrinə əsasən, utPLSQL kiçik bir hesabat qurur. Orada hər bir xüsusi yoxlamanın nəticəsini və vahid testinin ümumi nəticəsini görürük.
Avtotestlərin 6 qaydası
Sadiqlik sisteminin avtomatlaşdırılmış testi üçün yeni sistem yaratmağa başlamazdan əvvəl rəhbərliklə birlikdə gələcək avtomatlaşdırılmış testlərimizin uyğun olması prinsiplərini müəyyən etdik.
- Avtotestlər effektiv olmalı və faydalı olmalıdır. Bizim gözəl tərtibatçılarımız var, onları mütləq qeyd etmək lazımdır, çünki onlardan bəziləri yəqin ki, bu hesabatı görəcəklər və onlar gözəl kod yazırlar. Ancaq hətta onların gözəl kodu mükəmməl deyil və xətalara malikdir, var və ehtiva etməyə davam edəcək. Bu səhvləri tapmaq üçün avtotestlər tələb olunur. Əgər belə deyilsə, deməli ya pis avtotestlər yazırıq, ya da prinsipcə inkişaf etdirilməyən ölü sahəyə gəlmişik. Hər iki halda biz nəyisə səhv edirik və yanaşmamızın sadəcə mənası yoxdur.
- Avtotestlərdən istifadə edilməlidir. Bir proqram məhsulu yazmaq üçün çox vaxt və səy sərf etmək, onu anbara qoymaq və unutmaq mənasızdır. Testlər aparılmalı və mümkün qədər müntəzəm olaraq aparılmalıdır.
- Avtotestlər sabit işləməlidir. Günün vaxtından, işə salma stendindən və digər sistem parametrlərindən asılı olmayaraq, sınaq qaçışları eyni nəticəyə gətirib çıxarmalıdır. Bir qayda olaraq, bu, avtotestlərin sabit sistem parametrləri ilə xüsusi test məlumatları ilə işləməsi ilə təmin edilir.
- Avtotestlər layihəniz üçün məqbul bir sürətlə işləməlidir. Bu müddət hər bir sistem üçün fərdi olaraq müəyyən edilir. Bəzi insanlar bütün günü işləməyi ödəyə bilirlər, bəziləri isə bunu saniyələr içində etməyi kritik hesab edir. Layihəmizdə hansı sürət standartlarına nail olduğumuzu bir az sonra sizə deyəcəyəm.
- Avtotestin inkişafı çevik olmalıdır. Sadəcə əvvəllər bunu etmədiyimizə görə və ya başqa səbəbə görə hər hansı funksionallığı sınaqdan keçirməkdən imtina etmək məsləhət deyil. utPLSQL inkişafa heç bir məhdudiyyət qoymur və Oracle, prinsipcə, müxtəlif şeyləri həyata keçirməyə imkan verir. Əksər problemlərin həlli var, bu sadəcə vaxt və səy məsələsidir.
- Yerləşdirmə qabiliyyəti. Testlər keçirməli olduğumuz bir neçə stendimiz var. Hər bir stenddə məlumat tullantıları istənilən vaxt yenilənə bilər. Avtomatik sınaqları olan bir layihəni elə aparmaq lazımdır ki, onun tam və ya qismən quraşdırılmasını ağrısız şəkildə həyata keçirə biləsiniz.
Və bir neçə gündən sonra ikinci postda sizə nə etdiyimizi və hansı nəticələr əldə etdiyimizi söyləyəcəyəm.
Mənbə: www.habr.com