DBMSda birlik testlari - buni Sportmasterda qanday qilamiz, ikkinchi qism

Birinchi qism - shu yerda.

DBMSda birlik testlari - buni Sportmasterda qanday qilamiz, ikkinchi qism

Vaziyatni tasavvur qiling. Sizning oldingizda yangi funksiyalarni ishlab chiqish vazifasi turibdi. Sizda o'tmishdoshlaringizdan o'zgarishlar bor. Agar sizda axloqiy majburiyat yo'q deb hisoblasak, nima qilgan bo'lardingiz?

Ko'pincha, barcha eski o'zgarishlar unutiladi va hamma narsa qaytadan boshlanadi. Hech kim birovning kodini qazishni yoqtirmaydi, lekin agar vaqtingiz bo'lsa, nega o'z tizimingizni yaratishni boshlamaysiz? Bu odatiy yondashuv va u asosan to'g'ri. Ammo loyihamizda biz buni noto'g'ri qildik. Biz kelajakdagi avtomatik sinov tizimini utPLSQL-da o'tmishdoshlarimizdan birlik testlaridagi ishlanmalarga asosladik va keyin bir nechta parallel yo'nalishlarda ishlashga kirishdik.

  1. Eski birlik sinovlarini tiklash. Qayta tiklash testlarni sodiqlik tizimining mavjud holatiga moslashtirish va testlarni utPLSQL standartlariga moslashtirishni anglatadi.
  2. Avtotestlar bilan aniq nima, qanday usullar va jarayonlar qamrab olinganligini tushunish bilan muammoni hal qilish. Siz ushbu ma'lumotni boshingizda saqlashingiz yoki to'g'ridan-to'g'ri avtotest kodiga asoslangan xulosalar chiqarishingiz kerak. Shuning uchun biz katalog yaratishga qaror qildik. Biz har bir avtotestga noyob mnemonik kodni tayinladik, tavsifni yaratdik va sozlamalarni yozib oldik (masalan, uni qanday sharoitlarda ishga tushirish kerak yoki sinov ishga tushirilmasa nima bo'lishi kerak). Asosan, biz avtotestlar haqidagi metamaʼlumotlarni toʻldirdik va bu metamaʼlumotlarni standart utPLSQL sxema jadvallariga joylashtirdik.
  3. Kengayish strategiyasini belgilash, ya'ni. avtomatlashtirilgan testlar orqali tekshirilishi kerak bo'lgan funksionallikni tanlash. Biz uchta narsaga e'tibor berishga qaror qildik: yangi tizim yaxshilanishlari, ishlab chiqarish hodisalari va asosiy tizim jarayonlari. Shunday qilib, biz chiqarilish bilan parallel ravishda rivojlanmoqdamiz, uning yuqori sifatini ta'minlaymiz, bir vaqtning o'zida regressiya ko'lamini kengaytiramiz va muhim joylarda tizimning ishonchliligini ta'minlaymiz. Birinchi bunday darboğaz chekda chegirmalar va bonuslarni taqsimlash jarayoni edi.
  4. Tabiiyki, biz yangi avtotestlarni ishlab chiqishni boshladik. Birinchi chiqarish vazifalaridan biri sodiqlik tizimining oldindan belgilangan namunalarining ishlashini baholash edi. Bizning loyihamiz shartlar asosida mijozlarni tanlaydigan qat'iy belgilangan SQL so'rovlari blokiga ega. Misol uchun, oxirgi xaridi ma'lum bir shaharda bo'lgan barcha mijozlar ro'yxatini yoki o'rtacha xarid miqdori ma'lum bir qiymatdan yuqori bo'lgan mijozlar ro'yxatini oling. Yozma avtotestlardan so'ng biz oldindan belgilangan namunalarni tekshirdik, benchmark ishlash parametrlarini qayd etdik va qo'shimcha ravishda yuk sinovini o'tkazdik.
  5. Avtotestlar bilan ishlash qulay bo'lishi kerak. Eng keng tarqalgan ikkita harakat - bu avtotestlarni o'tkazish va test ma'lumotlarini yaratish. Shunday qilib, bizning tizimimizda ikkita yordamchi modul paydo bo'ldi: ishga tushirish moduli va ma'lumotlarni ishlab chiqarish moduli.

    Launcher bitta matn kiritish parametri bilan bitta universal protsedura sifatida taqdim etiladi. Parametr sifatida siz avtotest mnemonik kodini, paket nomini, test nomini, avtotest sozlamalarini yoki zaxiralangan kalit so'zni o'tkazishingiz mumkin. Jarayon shartlarga javob beradigan barcha avtotestlarni tanlaydi va o'tkazadi.

    Ma'lumotlarni ishlab chiqarish moduli sinovdan o'tkazilayotgan tizimning har bir ob'ekti (ma'lumotlar bazasidagi jadval) uchun u erga ma'lumotlarni kiritadigan maxsus protsedura yaratilgan paket ko'rinishida taqdim etiladi. Ushbu protsedurada standart qiymatlar iloji boricha to'ldiriladi, bu esa barmoqni bosish orqali ob'ektlarni yaratishni ta'minlaydi. Va foydalanish qulayligi uchun yaratilgan ma'lumotlar uchun shablonlar yaratilgan. Masalan, sinov telefoni va tugallangan xarid bilan ma'lum yoshdagi mijozni yarating.

  6. Avtotestlar tizimingiz uchun maqbul bo'lgan vaqtda boshlanishi va ishlashi kerak. Shu sababli, kunlik tungi ishga tushirish tashkil etildi, uning natijalariga ko'ra natijalar to'g'risida hisobot tuziladi va korporativ pochta orqali butun rivojlanish guruhiga yuboriladi. Eski avtotestlarni tiklash va yangilarini yaratishdan so'ng, umumiy ish vaqti 30 minutni tashkil etdi. Ushbu spektakl barchaga ma'qul keldi, chunki ishga tushirish ish vaqtidan tashqari bo'lib o'tdi.

    Ammo biz ish tezligini optimallashtirish ustida ishlashimiz kerak edi. Ishlab chiqarishdagi sodiqlik tizimi tungi vaqtda yangilanadi. Relizlarning bir qismi sifatida biz kechasi shoshilinch o'zgarishlar qilishimiz kerak edi. Ertalab soat uchda avtotestlar natijalarini yarim soat kutish ozod qilish uchun mas'ul bo'lgan shaxsni xursand qilmadi (Aleksey Vasyukovga qizg'in salomlar!), Ertasi kuni ertalab bizning tizimimizga nisbatan ko'plab yaxshi so'zlar aytildi. Ammo natijada ish uchun 5 daqiqalik standart o'rnatildi.

    Ishlashni tezlashtirish uchun biz ikkita usuldan foydalandik: avtotestlar uchta parallel ipda ishlay boshladi, xayriyatki, bu bizning sodiqlik tizimimizning arxitekturasi tufayli juda qulay. Va biz avtotest o'zi uchun test ma'lumotlarini yaratmaydigan, lekin tizimda mos keladigan narsani topishga harakat qiladigan yondashuvdan voz kechdik. O'zgartirishlar kiritilgandan so'ng, umumiy ish vaqti 3-4 daqiqagacha qisqartirildi.

  7. Avtomatik sinovlarga ega bo'lgan loyiha turli stendlarda joylashtirilishi kerak. Sayohatimizning boshida o'zimizning ommaviy fayllarimizni yozishga urinishlar bo'ldi, ammo o'z-o'zidan yozilgan avtomatlashtirilgan o'rnatish to'liq dahshat ekanligi ayon bo'ldi va biz sanoat echimlariga murojaat qildik. Loyihada juda ko'p to'g'ridan-to'g'ri kod (birinchi navbatda, biz avtotest kodini saqlaymiz) va juda kam ma'lumotlar (asosiy ma'lumotlar avtotestlar haqidagi metama'lumotlar) mavjudligi sababli Liquibase loyihasida amalga oshirish juda oddiy bo'lib chiqdi.

    Bu ma'lumotlar bazasi sxemasi o'zgarishlarini kuzatish, boshqarish va amalga oshirish uchun ochiq manbali, ma'lumotlar bazasidan mustaqil kutubxona. Buyruqlar qatori yoki Apache Maven kabi ramkalar orqali boshqariladi. Liquibase ning ishlash printsipi juda oddiy. Bizda maqsadli serverga chiqarilishi kerak bo'lgan o'zgarishlar yoki skriptlardan va ushbu o'zgarishlar qanday ketma-ketlikda va qanday parametrlar bilan o'rnatilishi kerakligini aniqlaydigan boshqaruv fayllaridan iborat bo'lgan loyihamiz ma'lum tarzda tashkil etilgan.

    DBMS darajasida maxsus jadval tuziladi, unda Liquibase rollover jurnalini saqlaydi. Har bir o'zgarish hisoblangan xeshga ega bo'lib, u har safar loyiha va ma'lumotlar bazasidagi holat o'rtasida taqqoslanadi. Liquibase tufayli biz tizimimizga o'zgartirishlarni istalgan sxemaga osongina kiritishimiz mumkin. Avtotestlar endi sinov va chiqarish sxemalarida, shuningdek konteynerlarda (ishlab chiquvchilarning shaxsiy sxemalarida) ishga tushiriladi.

DBMSda birlik testlari - buni Sportmasterda qanday qilamiz, ikkinchi qism

Shunday qilib, keling, birlik test tizimimizdan foydalanish natijalari haqida gapiraylik.

  1. Albatta, birinchi navbatda, biz yaxshiroq dasturiy ta'minotni ishlab chiqishni boshlaganimizga amin bo'ldik. Avtotestlar har kuni ishga tushiriladi va har bir nashrda o'nlab xatolar topiladi. Bundan tashqari, ushbu xatolarning ba'zilari faqat bilvosita biz o'zgartirmoqchi bo'lgan funksionallik bilan bog'liq. Ushbu xatolar qo'lda test orqali topilganiga jiddiy shubhalar mavjud.
  2. Jamoa endi ma'lum bir funksiya to'g'ri ishlayotganiga ishonchi komil... Birinchi navbatda, bu bizning muhim jarayonlarimizga tegishli. Misol uchun, so'nggi olti oy ichida biz chegirma va chegirmalarni chegirmalarni taqsimlash bilan bog'liq muammolarga duch kelmadik, garchi relizlar o'zgarishiga qaramay, oldingi davrlarda ma'lum bir chastotada xatolar sodir bo'lgan.
  3. Biz sinov takrorlash sonini kamaytirishga muvaffaq bo'ldik. Avtotestlar yangi funksiyalar uchun yozilganligi sababli, tahlilchilar va yarim kunlik sinovchilar yuqori sifatli kodni olishadi, chunki u allaqachon tekshirilgan.
  4. Avtomatlashtirilgan testlardagi ba'zi ishlanmalar ishlab chiquvchilar tomonidan qo'llaniladi. Masalan, konteynerlar bo'yicha test ma'lumotlari ob'ektni yaratish moduli yordamida yaratiladi.
  5. Ishlab chiquvchilar tomonidan avtomatlashtirilgan test tizimini "qabul qilish" ni ishlab chiqqanimiz muhim. Bu muhim va foydali degan tushuncha mavjud. Ammo o'z tajribamdan shuni aytishim mumkinki, bu ishdan uzoqdir. Avtotestlarni yozish kerak, ularni qo'llab-quvvatlash va ishlab chiqish, natijalarni tahlil qilish kerak va ko'pincha bu vaqt xarajatlari bunga loyiq emas. Ishlab chiqarishga borish va u erda muammolarni hal qilish ancha oson. Bu erda ishlab chiquvchilar qatorga turishadi va bizdan ularning funksiyalarini avtotestlar bilan qoplashimizni so'rashadi.

Keyin nima

DBMSda birlik testlari - buni Sportmasterda qanday qilamiz, ikkinchi qism

Keling, avtomatlashtirilgan sinov loyihasini ishlab chiqish rejalari haqida gapiraylik.

Albatta, Sportmasterning sodiqlik tizimi tirik va rivojlanishda davom etar ekan, avtotestlarni deyarli cheksiz ishlab chiqish ham mumkin. Shuning uchun rivojlanishning asosiy yo'nalishi qamrov zonasini kengaytirishdir.

Avtotestlar soni ortishi bilan ularning umumiy ish vaqti doimiy ravishda oshib boradi va biz yana ishlash masalasiga qaytishimiz kerak bo'ladi. Ehtimol, yechim parallel iplar sonini ko'paytirish bo'ladi.

Ammo bu rivojlanishning aniq yo'llari. Agar biz ahamiyatsizroq narsa haqida gapiradigan bo'lsak, biz quyidagilarni ta'kidlaymiz:

  1. Hozirgi vaqtda avtotestlarni boshqarish DBMS darajasida amalga oshiriladi, ya'ni. muvaffaqiyatli ishlash uchun PL/SQL bilimi talab qilinadi. Agar kerak bo'lsa, tizimni boshqarish (masalan, metama'lumotlarni ishga tushirish yoki yaratish), siz Jenkins yoki shunga o'xshash narsalar yordamida qandaydir boshqaruv panelini yaratishingiz mumkin.
  2. Har bir inson miqdoriy va sifat ko'rsatkichlarini yaxshi ko'radi. Avtomatlashtirilgan test uchun bunday universal ko'rsatkich Code Coverage yoki kodni qamrab olish ko'rsatkichidir. Ushbu ko'rsatkichdan foydalanib, biz sinovdan o'tayotgan tizimimiz kodining necha foizi avtotestlar bilan qoplanganligini aniqlashimiz mumkin. 12.2 versiyasidan boshlab Oracle ushbu ko'rsatkichni hisoblash imkoniyatini beradi va standart DBMS_PLSQL_CODE_COVERAGE paketidan foydalanishni taklif qiladi.

    Bizning avtotest tizimimiz bir yildan oshgan va endi qamrovimizni baholash vaqti keldi. Mening oxirgi loyihamda (Sportmaster loyihasi emas) shunday bo'ldi. Avtotestlar ustida ishlagandan bir yil o'tgach, rahbariyat biz kodning necha foizini qamrab olishimizni baholash vazifasini qo'ydi. 1% dan ortiq qamrov bilan boshqaruv xursand bo'ladi. Biz, ishlab chiquvchilar, taxminan 10% natija kutgandik. Biz kod qoplamasini o'rnatdik, uni o'lchadik va 20% ni oldik. Bayramni nishonlash uchun biz sovrinni olishga bordik, lekin uni olish uchun qanday borganimiz va keyin qayerga borganimiz butunlay boshqa voqea.

  3. Avtotestlar ochiq veb-xizmatlarni tekshirishi mumkin. Oracle bizga buni juda yaxshi bajarishga imkon beradi va biz endi bir qator muammolarga duch kelmaymiz.
  4. Va, albatta, bizning avtomatlashtirilgan test tizimimiz boshqa loyihaga qo'llanilishi mumkin. Biz qabul qilgan yechim universaldir va faqat Oracle-dan foydalanishni talab qiladi. Boshqa Sportmaster loyihalari avtomatik sinovlarga qiziqish bildirishini eshitdim va ehtimol biz ularga boramiz.

topilmalar

Keling, xulosa qilaylik. Sportmaster-dagi sodiqlik tizimi loyihasida biz avtomatlashtirilgan test tizimini joriy etishga muvaffaq bo'ldik. U Stiven Feyershteynning utPLSQL yechimiga asoslangan. UtPLSQL atrofida avtotest kodi va o'z-o'zidan yoziladigan yordamchi modullar mavjud: ishga tushirish moduli, ma'lumotlarni ishlab chiqarish moduli va boshqalar. Avtotestlar har kuni ishga tushiriladi va eng muhimi, ular ishlaydi va foydalidir. Ishonchimiz komilki, biz yuqori sifatli dasturiy ta'minotni chiqarishni boshladik. Shu bilan birga, natijada olingan yechim universal bo'lib, Oracle DBMSda avtomatlashtirilgan testlarni tashkil qilish zarur bo'lgan har qanday loyihaga erkin qo'llanilishi mumkin.

PS Ushbu maqola unchalik aniq emas: matn juda ko'p va texnik misollar deyarli yo'q. Agar mavzu umuman qiziqarli bo'lsa, biz uni davom ettirishga va davomi bilan qaytishga tayyormiz, u erda biz so'nggi olti oy ichida nima o'zgarganligini aytib beramiz va kodli misollar keltiramiz.

Kelajakda ta'kidlanishi kerak bo'lgan fikrlar yoki oshkor qilishni talab qiladigan savollar bo'lsa, sharhlar yozing.

So'rovda faqat ro'yxatdan o'tgan foydalanuvchilar ishtirok etishlari mumkin. tizimga kirishiltimos.

Bu haqda ko'proq yozamizmi?

  • Ha albatta

  • Yo'q rahmat

12 nafar foydalanuvchi ovoz berdi. 4 nafar foydalanuvchi betaraf qolgan.

Manba: www.habr.com

a Izoh qo'shish