DBMS дахь нэгжийн туршилтууд - бид үүнийг Sportmaster дээр хэрхэн хийдэг вэ, хоёрдугаар хэсэг

Эхний хэсэг - энд.

Нөхцөл байдлыг төсөөлөөд үз дээ. Та шинэ функцийг хөгжүүлэх даалгавартай тулгарч байна. Танд өмнөх үеийнхнээсээ туршлага бий. Хэрэв та ямар ч ёс суртахууны үүрэг хүлээгээгүй гэж үзвэл та юу хийх вэ?

Ихэнх тохиолдолд хуучин бүх бүтээн байгуулалтууд мартагдаж, бүх зүйл дахин эхэлдэг. Хэн ч хэн нэгний кодыг ухах дургүй бөгөөд хэрэв танд цаг байгаа бол яагаад өөрийн системээ үүсгэж болохгүй гэж? Энэ бол ердийн хандлага бөгөөд олон талаараа зөв юм. Гэхдээ манай төсөлд бид өөрөөр ажилласан. Бид ирээдүйн автоматжуулсан туршилтын системийг өмнөх үеийнхээсээ utPLSQL дээрх нэгж тестийн хөгжүүлэлт дээр үндэслээд дараа нь хэд хэдэн зэрэгцээ чиглэлд ажиллахаар болсон.

1. Хуучин нэгжийн туршилтыг сэргээж байна. Сэргээх гэдэг нь тестийг үнэнч байдлын системийн одоо байгаа байдалд тохируулах, тестийг utPLSQL стандартад тохируулах гэсэн үг юм.
2. Асуудлыг ойлгож, яг юу, ямар арга, процессыг шийдэхийн тулд бид автотест шинжилгээнд хамрагдсан. Та энэ мэдээллийг толгойдоо хадгалах эсвэл автомат тестийн код дээр үндэслэн шууд дүгнэлт хийх ёстой. Тиймээс бид каталог хийхээр шийдсэн. Бид автомат тест бүрт өвөрмөц мнемоник код өгч, тайлбар үүсгэж, тохиргоог зассан (жишээ нь, үүнийг ямар нөхцөлд ажиллуулах, эсвэл туршилт амжилтгүй болвол яах вэ). Үндсэндээ бид автомат тестийн мета өгөгдлийг бөглөж, энэ мета өгөгдлийг utPLSQL схемийн стандарт хүснэгтэд байрлуулсан.
3. Өргөтгөх стратегийн тодорхойлолт, i.e. автомат туршилтаар баталгаажуулах функцийг сонгох. Бид системийн шинэ сайжруулалт, үйлдвэрлэлийн осол, системийн гол үйл явц гэсэн гурван зүйлд анхаарлаа хандуулахаар шийдсэн. Тиймээс бид хувилбартай зэрэгцэн хөгжиж, түүний өндөр чанарыг хангаж, регрессийн хамрах хүрээг нэгэн зэрэг өргөжүүлж, чухал газруудад системийн найдвартай байдлыг баталгаажуулдаг. Эхний ийм гацаа нь чекээр хөнгөлөлт, урамшуулал тараах үйл явц байв.
4. Мэдээжийн хэрэг, бид шинэ автомат туршилтуудыг боловсруулж эхэлсэн. Эхний хувилбарын нэг нь үнэнч байдлын системийн урьдчилан тодорхойлсон дээжийн гүйцэтгэлийг үнэлэх явдал байв. Манай төсөл нь нөхцөл байдлын дагуу үйлчлүүлэгчийг сонгодог хатуу тогтсон sql асуулгын блоктой. Жишээлбэл, хамгийн сүүлд тухайн хотод худалдан авалт хийсэн бүх худалдан авагчдын жагсаалтыг эсвэл худалдан авалтын дундаж дүн нь тодорхой хэмжээнээс давсан хэрэглэгчдийн жагсаалтыг аваарай. Автотест бичээд бид урьдчилан тодорхойлсон дээж, тогтмол жишиг гүйцэтгэлийн параметрүүдийг шалгаж, ачааллын туршилт хийсэн.
5. Автотесттэй ажиллах нь тохиромжтой байх ёстой. Хамгийн түгээмэл хоёр үйлдэл бол автомат тест хийх, туршилтын өгөгдөл үүсгэх явдал юм. Ийнхүү манай системд хоёр туслах модуль гарч ирэв: эхлүүлэх модуль ба өгөгдөл үүсгэх модуль.

   Эхлүүлэгч нь нэг текстийн оролтын параметр бүхий нэг ерөнхий процедур хэлбэрээр илэрхийлэгддэг. Параметрийн хувьд та автомат тестийн мнемоник код, багцын нэр, тестийн нэр, автомат тестийн тохиргоо эсвэл нөөцлөгдсөн түлхүүр үгийг дамжуулж болно. Уг процедур нь нөхцөлийг хангасан бүх автомат тестийг сонгон ажиллуулдаг.

   Өгөгдөл үүсгэх модулийг багц хэлбэрээр танилцуулсан бөгөөд үүнд туршиж буй системийн объект бүрт (мэдээллийн сан дахь хүснэгт) өгөгдөл оруулах тусгай процедурыг бий болгосон. Энэ процедурт анхдагч утгуудыг дээд зэргээр дүүргэдэг бөгөөд энэ нь хурууны товшилтоор шууд объект үүсгэх боломжийг олгодог. Мөн ашиглахад хялбар болгох үүднээс үүсгэсэн өгөгдлийн загваруудыг бий болгосон. Жишээлбэл, туршилтын утас, худалдан авалтыг дуусгасан тодорхой насны үйлчлүүлэгчийг бий болгох.

6. Автотест нь таны системд тохирсон хугацаанд ажиллах ёстой. Тиймээс өдөр бүр шөнийн нээлтийг зохион байгуулж, үр дүнгийн талаархи тайланг гаргаж, нийт хөгжлийн багт корпорацийн шуудангаар илгээдэг. Хуучин автомат тестийг сэргээж, шинээр үүсгэсний дараа нийт ажиллах хугацаа 30 минут болсон. Хөл хөөргөх нь ажлын бус цагаар явагдсан тул ийм үзүүлбэр нь хүн бүрт тохирсон байв.

   Гэхдээ бид ажлын хурдыг оновчтой болгохын төлөө ажиллах ёстой байсан. Үйлдвэрлэлийн үнэнч байдлын системийг шөнийн цагаар шинэчилдэг. Нэг хувилбарын нэг хэсэг болгон бид шөнийн цагаар яаралтай өөрчлөлт хийх шаардлагатай болсон. Шөнийн гурван цагт автомат туршилтын үр дүнг хагас цаг хүлээсэн нь суллагдсан хүнийг баярлуулсангүй (Алексей Васюковт халуун мэндчилгээ дэвшүүлье!), Маргааш өглөө нь манай системийн талаар олон халуун үгс хэлсэн. Гэвч үүний үр дүнд ажлын 5 минутын стандарт тогтоосон.

   Гүйцэтгэлийг хурдасгахын тулд бид хоёр аргыг ашигласан: бид гурван зэрэгцээ хэлхээнд автомат тестийг ажиллуулж эхэлсэн, учир нь энэ нь манай үнэнч байдлын системийн архитектурын ачаар маш тохиромжтой юм. Автотест нь өөрөө туршилтын өгөгдлийг үүсгэхгүй, харин системд тохирох зүйлийг олохыг оролдох үед бид хандлагыг орхисон. Өөрчлөлт хийсний дараа нийт ажиллах хугацаа 3-4 минут болж буурсан.

7. Автомат тест бүхий төслийг янз бүрийн стенд дээр байрлуулах боломжтой байх ёстой. Аялалын эхэнд өөрсдийн багц файлуудыг бичих оролдлого гарч байсан ч өөрөө бичсэн автомат суурилуулалт нь үнэхээр аймшигтай зүйл болох нь тодорхой болж, бид үйлдвэрлэлийн шийдлүүд рүү хандсан. Төсөл нь шууд маш олон кодтой (юуны түрүүнд бид автомат тестийн кодыг хадгалдаг) ба маш бага өгөгдөлтэй (үндсэн өгөгдөл нь автомат тестийн мета өгөгдөл) тул үүнийг нэгтгэхэд маш хялбар болсон. Liquibase төсөл.

   Энэ нь өгөгдлийн сангийн схемийн өөрчлөлтийг хянах, удирдах, хэрэглэхэд зориулагдсан нээлттэй эхийн мэдээллийн сангийн бие даасан номын сан юм. Apache Maven гэх мэт командын мөр эсвэл фреймворкоор удирддаг. Liquibase-ийн ажиллах зарчим нь маш энгийн. Бид зорилтот серверт оруулах шаардлагатай өөрчлөлтүүд эсвэл скриптүүдээс бүрдсэн тодорхой зохион байгуулалттай төсөлтэй бөгөөд эдгээр өөрчлөлтүүдийг ямар дарааллаар, ямар параметрээр суулгахыг тодорхойлдог хяналтын файлуудаас бүрддэг.

   DBMS түвшинд Liquibase нь буцаах бүртгэлийг хадгалдаг тусгай хүснэгтийг үүсгэдэг. Өөрчлөлт бүр нь өгөгдлийн сан дахь төсөл болон төлөвийн хооронд харьцуулсан тооцоолсон хэштэй байдаг. Liquibase-ийн ачаар бид системийнхээ өөрчлөлтийг дурын хэлхээнд хялбархан нэвтрүүлэх боломжтой. Автотестийг одоо туршилт, суллах гогцоо, түүнчлэн контейнер (хөгжүүлэгчдийн хувийн гогцоо) дээр ажиллуулдаг.

Ингээд нэгж тестийн системээ хэрэглэсний үр дүнгийн талаар ярилцъя.

1. Мэдээжийн хэрэг, хамгийн түрүүнд бид илүү сайн програм хангамж хөгжүүлж эхэлсэн гэдэгт итгэлтэй байна. Автомат туршилтууд өдөр бүр явагддаг бөгөөд хувилбар болгонд олон арван алдаа олдог. Түүнээс гадна эдгээр алдааны зарим нь бидний өөрчлөхийг үнэхээр хүсч байсан функцтэй шууд бусаар холбоотой байдаг. Эдгээр алдааг гар аргаар шалгах замаар илрүүлсэн гэдэгт эргэлзэж байна.
2. Тус баг нь тодорхой функцууд зөв ажилладаг гэдэгт итгэлтэй болсон ... Юуны өмнө энэ нь бидний чухал үйл явцтай холбоотой юм. Тухайлбал, өнгөрсөн зургаан сарын хугацаанд бид хөнгөлөлт, урамшууллыг чекээр хуваарилахад ямар ч асуудал гараагүй, хэдийгээр хувилбар бүрт өөрчлөлт орсон ч өмнөх үед тодорхой давтамжтай алдаа гардаг байсан.
3. Бид туршилтын давталтын тоог бууруулж чадсан. Автотестийг шинэ функцэд зориулж бичсэн тул шинжээчид болон цагийн туршигчид илүү чанартай код авдаг. Энэ нь аль хэдийн баталгаажсан.
4. Автомат туршилтын хөгжүүлэлтийн нэг хэсгийг хөгжүүлэгчид ашигладаг. Жишээлбэл, объект үүсгэх модулийг ашиглан контейнер дээрх тестийн өгөгдлийг үүсгэдэг.
5. Бид автоматжуулсан туршилтын системийг хөгжүүлэгчид "хүлээн зөвшөөрсөн" нь чухал юм. Энэ нь чухал, хэрэгтэй гэсэн ойлголт байдаг. Мөн өөрийн туршлагаас харахад энэ нь тийм ч хол байна гэж би хэлж чадна. Автотестийг бичих шаардлагатай, тэдгээрийг хадгалах, хөгжүүлэх, үр дүнд дүн шинжилгээ хийх шаардлагатай байдаг бөгөөд ихэнхдээ эдгээр хугацааны зардал нь үнэ цэнэтэй зүйл биш юм. Үйлдвэрлэл рүүгээ явж, тэнд асуудал шийдэх нь хамаагүй хялбар байдаг. Манай улсад хөгжүүлэгчид жагсаж, өөрсдийн үйл ажиллагааг автомат тестээр хамруулахыг хүсдэг.

Дараа нь юу юм

Автоматжуулсан туршилтын төслийн хөгжлийн төлөвлөгөөний талаар ярилцъя.

Мэдээжийн хэрэг, Sportmaster-ийн үнэнч байдлын систем амьд байгаа бөгөөд үргэлжлүүлэн хөгжиж байгаа цагт автомат тестийг бараг төгсгөлгүй хөгжүүлэх боломжтой. Тиймээс хөгжлийн гол чиглэл нь хамрах хүрээг тэлэх явдал юм.

Автомат туршилтын тоо нэмэгдэхийн хэрээр тэдний ажлын нийт хугацаа тогтмол нэмэгдэх бөгөөд бид гүйцэтгэлийн асуудал руу дахин эргэж орох шаардлагатай болно. Хамгийн магадлалтай нь шийдэл нь зэрэгцээ утаснуудын тоог нэмэгдүүлэх явдал юм.

Гэхдээ эдгээр нь хөгжлийн тодорхой арга замууд юм. Хэрэв бид илүү ач холбогдолгүй зүйлийн талаар ярих юм бол дараахь зүйлийг онцолж болно.

1. Одоо автомат тестийг DBMS түвшинд удирддаг, өөрөөр хэлбэл. Амжилттай ажиллахын тулд PL/SQL-ийн мэдлэг шаардлагатай. Шаардлагатай бол системийн удирдлагыг (жишээлбэл, мета өгөгдлийг эхлүүлэх эсвэл үүсгэх) Женкинс эсвэл үүнтэй төстэй зүйлийг ашиглан админ самбараас гаргаж авч болно.
2. Хүн бүр тоон болон чанарын үзүүлэлтүүдэд дуртай. Автомат туршилтын хувьд ийм бүх нийтийн үзүүлэлт нь Кодын хамрах хүрээ эсвэл кодын хамрах хэмжүүр юм. Энэ үзүүлэлтийг ашиглан бид шалгаж буй системийн кодын хэдэн хувь нь авто тестэд хамрагдаж байгааг тодорхойлох боломжтой. 12.2 хувилбараас эхлэн Oracle нь энэхүү хэмжигдэхүүнийг тооцоолох боломжийг олгож, стандарт DBMS_PLSQL_CODE_COVERAGE багцыг ашиглахыг санал болгож байна.

   Манай автотест систем нь нэг жил гаруйн настай бөгөөд хамрах хүрээг үнэлэх цаг болжээ. Миний сүүлчийн төсөлд (Sportmaster биш төсөл) ийм зүйл тохиолдсон. Автотест дээр ажилласнаас хойш нэг жилийн дараа удирдлага нь бид кодын хэдэн хувийг хамруулсан бэ гэдгийг үнэлэх даалгавар тавьсан. 1% -иас дээш хамрах хүрээтэй бол удирдлага баяртай байх болно. Хөгжүүлэгчид бид 10 орчим хувийн үр дүнг хүлээж байсан. Бид кодын хамрах хүрээг устгаж, хэмжиж, 20% авсан. Баяраа тэмдэглэхийн тулд бид шагналын төлөө явсан, гэхдээ бид яаж шагналын төлөө явсан, дараа нь хаашаа явсан нь огт өөр түүх юм.

3. Автотест нь ил гарсан вэб үйлчилгээг туршиж үзэх боломжтой. Oracle танд үүнийг хийхийг зөвшөөрдөг бөгөөд бид цаашид олон асуудалтай тулгарахгүй.
4. Мэдээжийн хэрэг, манай автоматжуулсан туршилтын системийг өөр төсөлд ашиглаж болно. Бидний хүлээн авсан шийдэл нь бүх нийтийнх бөгөөд зөвхөн Oracle ашиглахыг шаарддаг. Sportmaster-ийн бусад төслүүдэд автоматжуулсан туршилт хийх сонирхолтой байгаа бөгөөд магадгүй бид тэдэн рүү очих болно гэж би сонссон.

үр дүн нь

Дахин дүгнэж үзье. Sportmaster дахь үнэнч байдлын системийн төсөл дээр бид автоматжуулсан туршилтын системийг нэвтрүүлж чадсан. Үүний үндэс нь Stephen Feuerstein-ийн utPLSQL шийдэл юм. utPLSQL-ийн эргэн тойронд автомат тест болон туслах өөрөө бичсэн модулиудын код байдаг: эхлүүлэгч, өгөгдөл үүсгэх модуль болон бусад. Автотест нь өдөр бүр ажилладаг бөгөөд хамгийн чухал нь ажиллаж, ашиг тусаа өгдөг. Бид илүү чанартай програм хангамж гаргаж эхэлсэн гэдэгт итгэлтэй байна. Үүний зэрэгцээ, үүссэн шийдэл нь бүх нийтийнх бөгөөд Oracle DBMS дээр автоматжуулсан туршилтыг зохион байгуулах шаардлагатай аливаа төсөлд чөлөөтэй ашиглаж болно.

Жич Энэ нийтлэл нь тийм ч тодорхой биш байсан: маш олон текст байгаа бөгөөд техникийн жишээ бараг байхгүй. Хэрэв энэ сэдэв дэлхийн хэмжээнд сонирхолтой байгаа бол бид үүнийг үргэлжлүүлж, сүүлийн зургаан сарын хугацаанд юу өөрчлөгдсөнийг танд хэлж, код жишээнүүдийн дагуу үргэлжлүүлэхэд бэлэн байна.

Цаашид онцлон анхаарах зүйл, тодруулах шаардлагатай асуулт байвал сэтгэгдэл бичээрэй.

Зөвхөн бүртгэлтэй хэрэглэгчид санал асуулгад оролцох боломжтой. Нэвтрэх, гуйя.

Энэ талаар дэлгэрэнгүй бичих үү?

• Мэдээжийн хэрэг

• Үгүй ээ баярлалаа

12 хэрэглэгч санал өгсөн. 4 хэрэглэгч түдгэлзсэн.

Эх сурвалж: www.habr.com