Hey Xabr!
Mening ismim Maksim Ponomarenko va men Sportmasterda dasturchiman. IT sohasida 10 yillik tajribam bor. U o'z karerasini qo'lda test qilishdan boshladi, keyin ma'lumotlar bazasini ishlab chiqishga o'tdi. So'nggi 4 yil davomida test va ishlab chiqishda olingan bilimlarni to'plagan holda, men DBMS darajasida testlarni avtomatlashtirdim.
Men Sportmaster jamoasida bir yildan ko'proq vaqt davomida ishlayapman va yirik loyihalardan birida avtomatlashtirilgan testlarni ishlab chiqyapman. Aprel oyida Sportmaster Laboratoriyasining yigitlari va men Krasnodardagi konferentsiyada nutq so'zladik, mening hisobotim "DBMSda birlik testlari" deb nomlangan va endi men uni siz bilan baham ko'rmoqchiman. Ko'p matn bo'ladi, shuning uchun men hisobotni ikkita postga bo'lishga qaror qildim. Birinchisida biz avtotestlar va umuman testlar haqida gapiramiz, ikkinchisida men birlik test tizimimiz va uni qo'llash natijalari haqida batafsilroq to'xtalib o'taman.
Birinchidan, biroz zerikarli nazariya. Avtomatlashtirilgan test nima? Bu dasturiy ta'minot yordamida amalga oshiriladigan test va zamonaviy ITda dasturiy ta'minotni ishlab chiqishda tobora ko'proq foydalanilmoqda. Buning sababi shundaki, kompaniyalar o'sib bormoqda, ularning axborot tizimlari o'sib bormoqda va shunga mos ravishda sinovdan o'tishi kerak bo'lgan funksionallik hajmi ham o'sib bormoqda. Qo'lda test o'tkazish tobora qimmatlashib bormoqda.
Men har ikki oyda bir marta chiqadigan yirik kompaniyada ishladim. Shu bilan birga, butun bir oy o'nlab testerlarning funksionallikni qo'lda tekshirishiga sarflandi. Kichik ishlab chiquvchilar jamoasi tomonidan avtomatlashtirishni amalga oshirish tufayli biz bir yarim yil ichida sinov vaqtini 2 haftagacha qisqartira oldik. Biz nafaqat sinov tezligini oshirdik, balki uning sifatini ham oshirdik. Avtomatlashtirilgan testlar muntazam ravishda ishga tushiriladi va ular har doim ularga kiritilgan tekshirishlarning butun kursini amalga oshiradilar, ya'ni biz inson omilini istisno qilamiz.
Zamonaviy IT ishlab chiquvchidan nafaqat mahsulot kodini yozishni, balki ushbu kodni tekshiradigan birlik testlarini yozishni ham talab qilishi mumkinligi bilan tavsiflanadi.
Ammo sizning tizimingiz asosan server mantig'iga asoslangan bo'lsa-chi? Bozorda universal yechim yoki eng yaxshi amaliyotlar mavjud emas. Qoida tariqasida, kompaniyalar ushbu muammoni o'zlarining yozma test tizimini yaratish orqali hal qilishadi. Bu bizning loyihamizda yaratilgan o'zimiz yozgan avtomatlashtirilgan test tizimimiz va men bu haqda hisobotimda gapirib beraman.
Sodiqlikni tekshirish
Birinchidan, biz avtomatlashtirilgan test tizimini o'rnatgan loyiha haqida gapiraylik. Bizning loyihamiz - bu Sportmaster sodiqlik tizimi (Aytgancha, biz bu haqda allaqachon yozgan edik ).
Agar sizning kompaniyangiz etarlicha katta bo'lsa, sizning sodiqlik tizimingiz uchta standart xususiyatga ega bo'ladi:
- Tizimingiz juda yuklangan bo'ladi
- Sizning tizimingiz murakkab hisoblash jarayonlarini o'z ichiga oladi
- Sizning tizimingiz faol ravishda takomillashtiriladi.
Keling, tartib bilan boraylik... Umuman olganda, barcha Sportmaster brendlarini hisobga olsak, Rossiya, Ukraina, Xitoy, Qozog'iston va Belorussiyada 1000 dan ortiq do'konlarimiz bor. Ushbu do'konlarda har kuni 300 000 ga yaqin xaridlar amalga oshiriladi. Ya'ni, har soniyada 3-4 ta tekshiruv tizimimizga kiradi. Tabiiyki, bizning sodiqlik tizimimiz juda yuklangan. Va u faol ishlatilganligi sababli, biz uning sifatining eng yuqori standartlarini ta'minlashimiz kerak, chunki dasturiy ta'minotdagi har qanday xato katta pul, obro' va boshqa yo'qotishlarni anglatadi.
Shu bilan birga, Sportmaster yuzdan ortiq turli aksiyalarni o'tkazadi. Aksiyalarning xilma-xilligi mavjud: mahsulotning reklama aktsiyalari bor, haftaning kuniga bag'ishlanganlari bor, ma'lum bir do'konga bog'langanlar bor, kvitansiya miqdori uchun aktsiyalar mavjud, tovarlar soni bo'yicha. Umuman olganda, yomon emas. Mijozlarda xarid qilishda foydalaniladigan bonuslar va promo-kodlar mavjud. Bularning barchasi har qanday buyurtmani hisoblash juda ahamiyatsiz ish ekanligiga olib keladi.
Buyurtmani qayta ishlashni amalga oshiradigan algoritm haqiqatan ham dahshatli va murakkab. Va bu algoritmdagi har qanday o'zgarishlar juda xavflidir. Aftidan, eng ahamiyatsiz o'zgarishlar oldindan aytib bo'lmaydigan oqibatlarga olib kelishi mumkin edi. Lekin aynan shunday murakkab hisoblash jarayonlari, ayniqsa muhim funksiyalarni amalga oshiradigan jarayonlar avtomatlashtirish uchun eng yaxshi nomzodlardir. O'nlab shunga o'xshash holatlarni qo'lda tekshirish juda ko'p vaqt talab etadi. Jarayonga kirish nuqtasi o'zgarmaganligi sababli, uni bir marta tasvirlab, siz tezda avtomatik testlarni yaratishingiz va funksionallik ishlashiga amin bo'lishingiz mumkin.
Tizimimiz faol ishlatilganligi sababli, biznes sizdan yangi narsalarni xohlaydi, zamon bilan yashaydi va mijozlarga yo'naltirilgan bo'ladi. Bizning sodiqlik tizimimizda relizlar har ikki oyda chiqadi. Bu shuni anglatadiki, har ikki oyda biz butun tizimning to'liq regressiyasini amalga oshirishimiz kerak. Shu bilan birga, tabiiyki, har qanday zamonaviy IT-da bo'lgani kabi, rivojlanish darhol ishlab chiqaruvchidan ishlab chiqarishga o'tmaydi. U ishlab chiqaruvchining sxemasidan kelib chiqadi, keyin ketma-ket sinov stendidan o'tadi, bo'shatiladi, qabul qilinadi va shundan keyingina ishlab chiqarishda tugaydi. Hech bo'lmaganda, sinov va bo'shatish davrlarida biz butun tizimning to'liq regressiyasini amalga oshirishimiz kerak.
Ta'riflangan xususiyatlar deyarli har qanday sodiqlik tizimi uchun standartdir. Keling, loyihamizning xususiyatlari haqida gapiraylik.
Texnologik jihatdan sodiqlik tizimimizning 90% mantig'i serverga asoslangan va Oracle'da amalga oshirilgan. Delphi-da ish joyining avtomatlashtirilgan ma'muri funktsiyasini bajaradigan mijoz mavjud. Tashqi ilovalar uchun ochiq veb-xizmatlar mavjud (masalan, veb-sayt). Shuning uchun, agar biz avtomatlashtirilgan test tizimini o'rnatadigan bo'lsak, buni Oracle'da qilishimiz juda mantiqiy.
Sportmaster-da sodiqlik tizimi 7 yildan ortiq vaqtdan beri mavjud bo'lib, yagona ishlab chiquvchilar tomonidan yaratilgan... Ushbu 7 yil davomida loyihamizdagi o'rtacha ishlab chiquvchilar soni 3-4 kishini tashkil etdi. Ammo so‘nggi bir yil ichida jamoamiz sezilarli darajada o‘sdi va hozirda loyihada 10 kishi ishlamoqda. Ya'ni, loyihaga odatiy vazifalar, jarayonlar va arxitektura bilan tanish bo'lmagan odamlar keladi. Va xatolarni o'tkazib yuborish xavfi ortadi.
Loyiha shtat birliklari sifatida maxsus sinovchilarning yo'qligi bilan tavsiflanadi. Albatta, test mavjud, ammo test boshqa asosiy vazifalaridan tashqari, tahlilchilar tomonidan amalga oshiriladi: biznes mijozlari, foydalanuvchilar bilan muloqot qilish, tizim talablarini ishlab chiqish va hk. va hokazo... Sinovlar juda yuqori sifatda o'tkazilishiga qaramay (ayniqsa, buni alohida ta'kidlash o'rinlidir, chunki ba'zi tahlilchilar ushbu hisobotga e'tibor qaratishlari mumkin), bir narsaga ixtisoslashish va diqqatni jamlash samaradorligi bekor qilinmagan. .
Yuqorida aytilganlarning barchasini hisobga olgan holda, etkazib beriladigan mahsulot sifatini yaxshilash va ishlab chiqish vaqtini qisqartirish uchun loyihada sinovni avtomatlashtirish g'oyasi juda mantiqiy ko'rinadi. Va sodiqlik tizimining mavjudligining turli bosqichlarida individual ishlab chiquvchilar o'zlarining kodlarini birlik testlari bilan qoplashga harakat qilishdi. Umuman olganda, har bir kishi o'z arxitekturasi va usullaridan foydalangan holda, bu juda noaniq jarayon edi. Yakuniy natijalar birlik testlari uchun umumiy edi: testlar ishlab chiqildi, bir muncha vaqt foydalanildi, versiyali fayllar xotirasida saqlangan, ammo bir nuqtada ular ishlashni to'xtatdi va unutildi. Avvalo, bu testlar loyihaga emas, balki aniq bir ijrochiga ko'proq bog'langanligi bilan bog'liq edi.
utPLSQL yordamga keladi
Stiven Feyershteyn haqida biror narsa bilasizmi?
Bu o'z karerasining uzoq qismini Oracle va PL/SQL bilan ishlashga bag'ishlagan va ushbu mavzu bo'yicha juda ko'p asarlar yozgan aqlli yigit. Uning mashhur kitoblaridan biri: “Oracle PL/SQL. Professionallar uchun." Aynan Stiven utPLSQL yechimini yoki, yaʼni, Oracle PL/SQL uchun Unit Testing ramkasini ishlab chiqqan. utPLSQL yechimi 2016 yilda yaratilgan, biroq u ustida faol ish olib borilmoqda va yangi versiyalari chiqarilmoqda. Hisobot paytida so'nggi versiya 24 yil 2019 martga to'g'ri keladi.
Bu nima. Bu alohida ochiq kodli loyiha. U misollar va hujjatlarni o'z ichiga olgan holda bir necha megabaytni tashkil qiladi. Jismoniy jihatdan, bu ORACLE ma'lumotlar bazasidagi alohida sxema bo'lib, birlik testini tashkil qilish uchun paketlar va jadvallar to'plamidir. O'rnatish bir necha soniya davom etadi. UtPLSQL ning o'ziga xos xususiyati uning foydalanish qulayligidir.
Global miqyosda utPLSQL birlik testlarini bajarish mexanizmi bo'lib, unda birlik testi oddiy Oracle ommaviy protseduralari sifatida tushuniladi, ularning tashkil etilishi ma'lum qoidalarga amal qiladi. Ishga tushirishdan tashqari, utPLSQL barcha test sinovlari jurnalini saqlaydi va ichki hisobot tizimiga ega.
Keling, ushbu texnika yordamida amalga oshirilgan birlik test kodi qanday ko'rinishini misol qilib ko'rib chiqaylik.
Shunday qilib, ekran birlik sinovlari bilan odatdagi paket spetsifikatsiyasi uchun kodni ko'rsatadi. Majburiy talablar qanday? Paketga "utp_" prefiksi qo'shilishi kerak. Sinovlar bilan barcha protseduralar aynan bir xil prefiksga ega bo'lishi kerak. Paket ikkita standart protsedurani o'z ichiga olishi kerak: "utp_setup" va "utp_teardown". Birinchi protsedura har bir birlik sinovini qayta ishga tushirish orqali chaqiriladi, ikkinchisi - ishga tushirilgandan keyin.
"utp_setup", qoida tariqasida, tizimimizni birlik testini o'tkazishga tayyorlaydi, masalan, test ma'lumotlarini yaratish. "utp_teardown" - aksincha, hamma narsa asl sozlamalarga qaytadi va ishga tushirish natijalarini tiklaydi.
Kiritilgan mijoz telefon raqamini bizning sodiqlik tizimimiz uchun standart shaklga normallashtirishni tekshiradigan eng oddiy birlik testiga misol. Birlik testlari bilan protseduralarni yozish bo'yicha majburiy standartlar yo'q. Qoida tariqasida, tekshirilayotgan tizimning usuliga qo'ng'iroq qilinadi va bu usul bilan qaytarilgan natija mos yozuvlar bilan taqqoslanadi. Muhimi, mos yozuvlar natijasi va olingan natijani taqqoslash standart utPLSQL usullari orqali amalga oshiriladi.
Birlik testida har qanday miqdordagi tekshiruvlar bo'lishi mumkin. Misoldan ko'rinib turibdiki, telefon raqamini normallashtirish va har bir qo'ng'iroqdan keyin natijani baholash uchun sinovdan o'tgan usulga to'rtta ketma-ket qo'ng'iroq qilamiz. Birlik testini ishlab chiqishda siz tizimga hech qanday ta'sir qilmaydigan tekshiruvlar mavjudligini hisobga olishingiz kerak va ba'zilaridan keyin tizimning asl holatiga qaytishingiz kerak.
Misol uchun, taqdim etilgan birlik testida biz kirish telefon raqamini oddiygina formatlaymiz, bu esa sodiqlik tizimiga hech qanday ta'sir qilmaydi.
Va agar biz yangi mijozni yaratish usulidan foydalangan holda birlik testlarini yozadigan bo'lsak, unda har bir testdan so'ng tizimda yangi mijoz yaratiladi, bu testning keyingi boshlanishiga ta'sir qilishi mumkin.
Birlik testlari shu tarzda amalga oshiriladi. Ikkita mumkin bo'lgan ishga tushirish opsiyasi mavjud: ma'lum bir paketdan barcha birlik testlarini o'tkazish yoki ma'lum bir paketda ma'lum birlik testini o'tkazish.
Ichki hisobot tizimining namunasi shunday ko'rinadi. Birlik testi natijalariga ko'ra, utPLSQL kichik hisobot tuzadi. Unda biz har bir aniq tekshirish uchun natijani va birlik testining umumiy natijasini ko'ramiz.
Avtotestlarning 6 ta qoidalari
Sodiqlik tizimini avtomatlashtirilgan sinovdan o'tkazish uchun yangi tizimni yaratishni boshlashdan oldin, menejment bilan birgalikda biz kelajakdagi avtomatlashtirilgan testlarimiz mos kelishi kerak bo'lgan tamoyillarni aniqladik.
- Avtotestlar samarali bo'lishi va foydali bo'lishi kerak. Bizda ajoyib ishlab chiquvchilar bor, ularni albatta aytib o'tish kerak, chunki ulardan ba'zilari bu hisobotni ko'rishlari mumkin va ular ajoyib kod yozishadi. Ammo ularning ajoyib kodi ham mukammal emas va xatolarga ega, bor va mavjud bo'lib qoladi. Ushbu xatolarni aniqlash uchun avtotestlar talab qilinadi. Agar bunday bo'lmasa, biz yomon avtotestlar yozyapmiz yoki biz printsipial jihatdan ishlab chiqilmagan o'lik hududga keldik. Ikkala holatda ham biz noto'g'ri ish qilyapmiz va bizning yondashuvimiz mantiqiy emas.
- Avtotestlardan foydalanish kerak. Dasturiy ta'minot mahsulotini yozish uchun ko'p vaqt va kuch sarflash, uni omborga qo'yish va uni unutish mantiqiy emas. Sinovlar o'tkazilishi va iloji boricha muntazam ravishda o'tkazilishi kerak.
- Avtotestlar barqaror ishlashi kerak. Kunning vaqtidan, ishga tushirish stendidan va boshqa tizim sozlamalaridan qat'i nazar, test sinovlari bir xil natijaga olib kelishi kerak. Qoida tariqasida, bu avtotestlarning qattiq tizim sozlamalari bilan maxsus test ma'lumotlari bilan ishlashi bilan ta'minlanadi.
- Avtotestlar loyihangiz uchun maqbul tezlikda ishlashi kerak. Bu vaqt har bir tizim uchun alohida belgilanadi. Ba'zi odamlar kun bo'yi ishlashga qodir, boshqalari buni bir necha soniya ichida qilish juda muhim deb hisoblaydi. Loyihamizda qanday tezlik standartlariga erishganimizni biroz keyinroq aytib beraman.
- Avtotestni ishlab chiqish moslashuvchan bo'lishi kerak. Har qanday funktsiyani sinab ko'rishdan bosh tortish tavsiya etilmaydi, chunki biz buni oldin qilmaganmiz yoki boshqa sabablarga ko'ra. utPLSQL rivojlanishga hech qanday cheklovlar qo'ymaydi va Oracle, asosan, turli xil narsalarni amalga oshirishga imkon beradi. Ko'pgina muammolarning echimi bor, bu faqat vaqt va kuch masalasidir.
- Joylashtirish imkoniyati. Sinovlarni o'tkazishimiz kerak bo'lgan bir nechta stendlarimiz bor. Har bir stendda ma'lumotlar to'plami istalgan vaqtda yangilanishi mumkin. Avtomatik sinovlar bilan loyihani to'liq yoki qisman o'rnatishni og'riqsiz bajarishingiz kerak.
Bir necha kundan keyin ikkinchi postda men nima qilganimizni va qanday natijalarga erishganimizni aytib beraman.
Manba: www.habr.com