Хөөе Хабр!
Намайг Максим Пономаренко гэдэг, би Sportmaster-ийн хөгжүүлэгч. Би мэдээллийн технологийн чиглэлээр 10 жил ажилласан туршлагатай. Тэрээр ажлын гараагаа гарын авлагын тестээр эхлүүлж, дараа нь мэдээллийн сангийн хөгжүүлэлт рүү шилжсэн. Сүүлийн 4 жилийн турш би туршилт, хөгжүүлэлтийн чиглэлээр олж авсан мэдлэгээ хуримтлуулж, DBMS түвшинд тестийг автоматжуулж байна.
Би Sportmaster-ийн багт ажиллаад жил гаруй болж байгаа бөгөөд томоохон төслүүдийн нэг дээр автоматжуулсан туршилтыг боловсруулж байна. Дөрөвдүгээр сард Sportmaster Lab-ийн залуус бид хоёр Краснодар хотод болсон бага хурлын үеэр миний илтгэлийг "МБМС дахь нэгжийн туршилтууд" гэж нэрлэсэн бөгөөд одоо би та бүхэнтэй хуваалцахыг хүсч байна. Маш их бичвэр байх тул тайланг хоёр нийтлэл болгон хуваахаар шийдлээ. Эхнийх нь бид ерөнхийдөө автомат туршилт, туршилтын талаар ярих болно, хоёрдугаарт би нэгжийн туршилтын систем болон түүний хэрэглээний үр дүнгийн талаар илүү дэлгэрэнгүй ярих болно.
Нэгдүгээрт, жаахан уйтгартай онол. Автомат тест гэж юу вэ? Энэ бол програм хангамжаар хийгддэг туршилт бөгөөд орчин үеийн мэдээллийн технологид програм хангамж боловсруулахад улам бүр ашиглагдаж байна. Энэ нь компаниуд өсч, мэдээллийн систем нь хөгжиж, үүний дагуу турших шаардлагатай функцүүдийн хэмжээ нэмэгдэж байгаатай холбоотой юм. Гар аргаар туршилт хийх нь улам бүр үнэтэй болж байна.
Би хоёр сар тутамд нэг том компанид ажилладаг байсан. Үүний зэрэгцээ хэдэн арван шалгагчийг гараар шалгахад бүтэн сар зарцуулсан. Цөөн тооны хөгжүүлэгчдийн баг автоматжуулалтыг хэрэгжүүлсний ачаар бид туршилтын хугацааг жил хагасын дотор 2 долоо хоног болгон бууруулж чадсан. Бид туршилтын хурдыг нэмэгдүүлээд зогсохгүй чанарыг нь сайжруулсан. Автоматжуулсан туршилтыг тогтмол явуулдаг бөгөөд тэдгээр нь түүнд багтсан бүх шалгалтыг үргэлж хийдэг, өөрөөр хэлбэл бид хүний хүчин зүйлийг хасдаг.
Орчин үеийн мэдээллийн технологи нь хөгжүүлэгчээс зөвхөн бүтээгдэхүүний код бичихээс гадна энэ кодыг шалгадаг нэгжийн тест бичихийг шаарддаг гэдгээрээ онцлог юм.
Гэхдээ таны систем үндсэндээ серверийн логик дээр суурилсан бол яах вэ? Зах зээл дээр бүх нийтийн шийдэл, шилдэг туршлага байдаггүй. Дүрмээр бол компаниуд өөрсдөө бичсэн тестийн системийг бий болгосноор энэ асуудлыг шийддэг. Энэ бол манай төсөл дээр бүтээгдсэн бидний өөрөө бичсэн автоматжуулсан туршилтын систем бөгөөд би энэ тухай тайландаа ярих болно.
Үнэнч байдлыг шалгах
Эхлээд автоматжуулсан туршилтын системийг нэвтрүүлсэн төслийн талаар ярилцъя. Манай төсөл бол Sportmaster үнэнч байдлын систем юм (дашрамд хэлэхэд бид энэ тухай аль хэдийн бичсэн ).
Хэрэв танай компани хангалттай том бол таны үнэнч үйлчилгээний систем гурван стандарт шинж чанартай байх болно.
- Таны систем маш их ачаалалтай байх болно
- Таны систем нарийн төвөгтэй тооцоолох процессуудыг агуулна
- Таны систем идэвхтэй сайжирна.
Ингээд дарааллаар нь явцгаая... Нийтдээ бүх Sportmaster брэндийг авч үзвэл Орос, Украйн, Хятад, Казахстан, Беларусь улсад 1000 гаруй дэлгүүртэй. Эдгээр дэлгүүрээр өдөрт 300 мянга орчим худалдан авалт хийдэг. Өөрөөр хэлбэл, секунд тутамд 000-3 шалгалт манай системд ордог. Мэдээжийн хэрэг, манай үнэнч байдлын систем маш их ачаалалтай байдаг. Үүнийг идэвхтэй ашиглаж байгаа тул бид түүний чанарын хамгийн өндөр стандартыг хангах ёстой, учир нь програм хангамжийн аливаа алдаа нь их хэмжээний мөнгө, нэр хүнд болон бусад алдагдал гэсэн үг юм.
Үүний зэрэгцээ Sportmaster нь зуу гаруй төрлийн сурталчилгаа явуулдаг. Төрөл бүрийн урамшуулал байдаг: бүтээгдэхүүний урамшуулал байдаг, долоо хоногийн өдөр зориулагдсан байдаг, тодорхой дэлгүүртэй холбоотой байдаг, төлбөрийн баримтын хэмжээгээр, барааны тоогоор урамшуулал байдаг. Ерөнхийдөө муу биш. Үйлчлүүлэгчид худалдан авалт хийхдээ ашигладаг урамшуулал, сурталчилгааны кодтой байдаг. Энэ бүхэн нь аливаа захиалгыг тооцоолох нь маш энгийн ажил биш болоход хүргэдэг.
Захиалгын боловсруулалтыг хэрэгжүүлдэг алгоритм нь үнэхээр аймшигтай бөгөөд төвөгтэй юм. Мөн энэ алгоритмд өөрчлөлт оруулах нь нэлээд эрсдэлтэй. Хамгийн өчүүхэн мэт санагдах өөрчлөлтүүд нь урьдчилан таамаглах аргагүй үр дагаварт хүргэж болзошгүй юм шиг санагдсан. Гэхдээ яг ийм нарийн төвөгтэй тооцоолох процессууд, ялангуяа чухал функцуудыг хэрэгжүүлдэг процессууд нь автоматжуулалтад хамгийн сайн нэр дэвшигчид юм. Үүнтэй төстэй олон арван хэргийг гараар шалгах нь маш их цаг хугацаа шаарддаг. Процесс руу орох цэг өөрчлөгдөөгүй тул үүнийг нэг удаа тайлбарласны дараа та автомат тестийг хурдан үүсгэж, функц нь ажиллах болно гэдэгт итгэлтэй байж болно.
Манай системийг идэвхтэй ашиглаж байгаа тул бизнес танаас шинэ зүйлийг хүсч, цаг үетэйгээ нийцэж, хэрэглэгчдэд чиглэсэн байх болно. Манай үнэнч үйлчилгээний системд хувилбарууд хоёр сар тутамд гардаг. Энэ нь хоёр сар тутамд бид бүхэл бүтэн системийн регрессийг хийх шаардлагатай гэсэн үг юм. Үүний зэрэгцээ орчин үеийн мэдээллийн технологийн нэгэн адил хөгжил нь хөгжүүлэгчээс үйлдвэрлэл рүү шууд дамждаггүй. Энэ нь хөгжүүлэгчийн хэлхээнээс гаралтай бөгөөд дараа нь туршилтын тавцангаар дараалан дамжиж, суллаж, хүлээн авч, дараа нь үйлдвэрлэлд дуусдаг. Наад зах нь туршилт, суллах хэлхээн дээр бид бүхэл бүтэн системийн бүрэн регрессийг хийх хэрэгтэй.
Тайлбарласан шинж чанарууд нь бараг бүх үнэнч байдлын системийн стандарт юм. Төслийнхөө онцлогийн талаар ярилцъя.
Технологийн хувьд манай үнэнч байдлын системийн логикийн 90% нь серверт суурилсан бөгөөд Oracle дээр хэрэгждэг. Автоматжуулсан ажлын байрны администраторын үүргийг гүйцэтгэдэг Delphi-д нээлттэй үйлчлүүлэгч байдаг. Гадны хэрэглээний програмуудад зориулсан нээлттэй вэб үйлчилгээ байдаг (жишээ нь вэб сайт). Тиймээс, хэрэв бид автоматжуулсан туршилтын системийг байршуулбал үүнийг Oracle дээр хийх нь маш логик юм.
Sportmaster дахь үнэнч байдлын систем нь 7 жил гаруйн турш оршин тогтнож байгаа бөгөөд дан хөгжүүлэгчид бий болсон ... Энэ 7 жилийн хугацаанд манай төсөлд дунджаар 3-4 хүн ажилласан. Харин сүүлийн нэг жилийн хугацаанд манай хамт олон нэлээд томорч, одоо 10 хүн төсөл дээр ажиллаж байна. Өөрөөр хэлбэл, ердийн даалгавар, үйл явц, архитектурыг мэдэхгүй хүмүүс төсөлд ирдэг. Мөн бид алдаагаа алдах эрсдэл нэмэгддэг.
Төсөл нь ажилтнуудын нэгж болгон тусгай шалгагч байхгүй гэдгээрээ онцлог юм. Мэдээжийн хэрэг туршилт байдаг, гэхдээ туршилтыг шинжээчид бусад үндсэн үүргээс гадна гүйцэтгэдэг: бизнесийн үйлчлүүлэгчид, хэрэглэгчидтэй харилцах, системийн шаардлагыг боловсруулах гэх мэт. Гэх мэт... Туршилтыг маш өндөр чанартай хийж байгаа хэдий ч (энэ тайланд зарим шинжээчид анхаарал хандуулж магадгүй тул үүнийг дурдах нь зүйтэй болов уу) нэг зүйл дээр мэргэших, төвлөрөх үр нөлөөг цуцалсангүй. .
Дээр дурдсан бүх зүйлийг харгалзан, нийлүүлсэн бүтээгдэхүүний чанарыг сайжруулах, боловсруулах хугацааг багасгахын тулд төслийн туршилтыг автоматжуулах санаа нь маш логик юм. Үнэнч байдлын системийн оршин тогтнох янз бүрийн үе шатанд хувь хүний хөгжүүлэгчид өөрсдийн кодыг нэгжийн тестээр хамрахыг хичээсэн. Ерөнхийдөө энэ нь нэлээд салангид үйл явц байсан бөгөөд хүн бүр өөрийн архитектур, арга барилыг ашигладаг байсан. Эцсийн үр дүн нь нэгж тестүүдэд нийтлэг байсан: туршилтуудыг боловсруулж, хэсэг хугацаанд ашиглаж, хувилбартай файлын санд хадгалсан боловч зарим үед ажиллахаа больж, мартсан. Юуны өмнө, энэ нь туршилтыг төсөлтэй биш, харин тодорхой гүйцэтгэгчтэй илүү холбосонтой холбоотой байв.
utPLSQL аврах ажилд ирдэг
Та Стивен Фейерштейн талаар ямар нэгэн зүйл мэдэх үү?
Энэ бол карьерынхаа урт хэсгийг Oracle болон PL/SQL-тэй ажиллахад зориулж, энэ сэдвээр нэлээд олон бүтээл бичсэн ухаалаг залуу юм. Түүний алдартай номнуудын нэг нь: “Oracle PL/SQL. Мэргэжлийн хүмүүст зориулав." Энэ бол utPLSQL шийдэл буюу Oracle PL/SQL-д зориулсан Unit Testing framework-ийг бүтээсэн хүн нь Стивен байв. utPLSQL шийдэл нь 2016 онд бүтээгдсэн боловч идэвхтэй ажиллаж, шинэ хувилбарууд нь гарсаар байна. Мэдээллийн үеэр хамгийн сүүлийн хувилбар нь 24 оны 2019-р сарын XNUMX-нд гарсан.
Энэ юу вэ. Энэ бол тусдаа нээлттэй эхийн төсөл юм. Энэ нь жишээ, баримт бичгийг багтаасан хоёр мегабайт жинтэй. Бие махбодийн хувьд энэ нь нэгжийн туршилтыг зохион байгуулах багц, хүснэгт бүхий ORACLE мэдээллийн сан дахь тусдаа схем юм. Суулгахад хэдхэн секунд зарцуулагдана. utPLSQL-ийн нэг онцлог шинж чанар нь ашиглахад хялбар байдал юм.
Дэлхий даяар utPLSQL нь нэгж тестийг ажиллуулах механизм бөгөөд нэгж тестийг энгийн Oracle багц процедур гэж ойлгодог бөгөөд зохион байгуулалт нь тодорхой дүрмийг баримталдаг. Эхлэхээс гадна utPLSQL нь таны бүх туршилтын бүртгэлийг хадгалдаг бөгөөд дотоод тайлангийн системтэй.
Энэ техникийг ашиглан хэрэгжүүлсэн нэгжийн тестийн код ямар харагдах жишээг харцгаая.
Тиймээс дэлгэц нь ердийн багцын тодорхойлолтын кодыг нэгжийн туршилтаар харуулж байна. Заавал биелүүлэх шаардлага юу вэ? Пакет нь "utp_" гэсэн угтвартай байх ёстой. Туршилттай бүх процедур нь яг ижил угтвартай байх ёстой. Багц нь "utp_setup" болон "utp_teardown" гэсэн хоёр стандарт горимыг агуулсан байх ёстой. Эхний процедурыг нэгжийн туршилт бүрийг дахин эхлүүлэх замаар дууддаг, хоёр дахь нь - эхлүүлсний дараа.
"utp_setup" нь дүрмээр бол манай системийг нэгжийн тест хийх, жишээлбэл тестийн өгөгдөл үүсгэхэд бэлтгэдэг. "utp_teardown" - эсрэгээр бүх зүйл анхны тохиргоо руугаа буцаж, эхлүүлэх үр дүнг дахин тохируулна.
Манай үнэнч үйлчилгээний системийн стандарт маягт руу оруулсан хэрэглэгчийн утасны дугаарыг хэвийн болгох эсэхийг шалгадаг хамгийн энгийн нэгж тестийн жишээ энд байна. Нэгжийн тесттэй процедурыг хэрхэн бичих талаар заавал дагаж мөрдөх стандарт байдаггүй. Дүрмээр бол туршилтын системийн арга руу дуудлага хийх бөгөөд энэ аргаар буцаасан үр дүнг лавлагаатай харьцуулна. Лавлагааны үр дүн болон олж авсан үр дүнг харьцуулах нь стандарт utPLSQL аргуудаар явагдах нь чухал юм.
Нэгжийн тест нь хэдэн ч шалгалттай байж болно. Жишээнээс харахад бид шалгасан арга руу дараалан дөрвөн удаа залгаж утасны дугаарыг хэвийн болгож, дуудлага бүрийн дараа үр дүнг үнэлдэг. Нэгжийн тестийг боловсруулахдаа системд ямар нэгэн байдлаар нөлөөлөхгүй шалгалтууд байгааг анхаарч үзэх хэрэгтэй бөгөөд заримын дараа та системийн анхны төлөв рүү буцах хэрэгтэй.
Жишээлбэл, танилцуулсан нэгжийн тест дээр бид оролтын утасны дугаарыг зүгээр л форматалдаг бөгөөд энэ нь үнэнч байдлын системд ямар ч нөлөө үзүүлэхгүй.
Хэрэв бид шинэ үйлчлүүлэгч үүсгэх аргыг ашиглан нэгжийн тестийг бичих юм бол тест бүрийн дараа системд шинэ үйлчлүүлэгч бий болох бөгөөд энэ нь туршилтыг дараагийн эхлүүлэхэд нөлөөлж болзошгүй юм.
Нэгжийн туршилтыг ингэж явуулдаг. Хоёр боломжит эхлүүлэх сонголт байдаг: бүх нэгжийн тестийг тодорхой багцаас ажиллуулах эсвэл тодорхой багц дахь тодорхой нэгжийн тестийг ажиллуулах.
Дотоод тайлагналын системийн жишээ иймэрхүү харагдаж байна. Нэгжийн тестийн үр дүнд үндэслэн utPLSQL нь жижиг тайлан гаргадаг. Үүнд бид тодорхой шалгалт бүрийн үр дүн болон нэгжийн туршилтын ерөнхий үр дүнг хардаг.
Автомат шалгалтын 6 дүрэм
Үнэнч байдлын системийг автоматжуулсан туршилтын шинэ системийг бий болгож эхлэхийн өмнө бид менежментийн хамтаар ирээдүйн автоматжуулсан туршилтууд маань дагаж мөрдөх зарчмуудыг тодорхойлсон.
- Автотест нь үр дүнтэй бөгөөд ашигтай байх ёстой. Бидэнд гайхалтай хөгжүүлэгчид байгаа бөгөөд тэдгээрийг дурдах нь гарцаагүй, учир нь тэдний зарим нь энэ тайланг харж магадгүй бөгөөд тэд гайхалтай код бичдэг. Гэхдээ тэдний гайхалтай код ч төгс биш бөгөөд алдаатай, байгаа, агуулсаар байх болно. Эдгээр алдааг олохын тулд автомат тест хийх шаардлагатай. Хэрэв тийм биш бол бид муу автотест бичиж байна, эсвэл зарчмын хувьд боловсруулагдаагүй үхсэн газар ирлээ. Аль ч тохиолдолд бид буруу зүйл хийж байгаа бөгөөд бидний хандлага зүгээр л утгагүй юм.
- Автомат тестийг ашиглах хэрэгтэй. Програм хангамжийн бүтээгдэхүүн бичихийн тулд маш их цаг хугацаа, хүчин чармайлт гаргаж, түүнийг хадгалах санд хийж, мартах нь утгагүй юм. Туршилтыг аль болох тогтмол явуулж байх ёстой.
- Автотестууд тогтвортой ажиллах ёстой. Өдрийн цаг, хөөргөх зогсоол болон бусад системийн тохиргооноос үл хамааран туршилтын гүйлтүүд ижил үр дүнд хүргэх ёстой. Дүрмээр бол энэ нь автомат туршилтууд нь тогтмол системийн тохиргоотой тусгай туршилтын өгөгдөлтэй ажилладаг тул үүнийг баталгаажуулдаг.
- Автотест нь таны төсөлд тохирсон хурдаар ажиллах ёстой. Энэ хугацааг систем тус бүрээр тус тусад нь тодорхойлно. Зарим хүмүүс өдөржин ажиллах боломжтой байдаг бол зарим нь хэдхэн секундын дотор үүнийг хийх нь чухал гэж үздэг. Төсөлдөө бид ямар хурдны стандартад хүрсэн талаар жаахан дараа хэлье.
- Автотест хөгжүүлэлт нь уян хатан байх ёстой. Өмнө нь хийгээгүй эсвэл өөр шалтгаанаар аливаа функцийг туршихаас татгалзахыг зөвлөдөггүй. utPLSQL нь хөгжүүлэлтэд ямар нэгэн хязгаарлалт тавьдаггүй бөгөөд Oracle нь зарчмын хувьд танд янз бүрийн зүйлийг хэрэгжүүлэх боломжийг олгодог. Ихэнх асуудал шийдэлтэй байдаг, энэ нь зөвхөн цаг хугацаа, хүчин чармайлтын асуудал юм.
- Байрлуулах чадвар. Бидэнд туршилт явуулах шаардлагатай хэд хэдэн зогсоол бий. Стенд бүрт өгөгдөл овоолгыг хүссэн үедээ шинэчлэх боломжтой. Бүрэн эсвэл хэсэгчилсэн суурилуулалтыг өвдөлтгүй гүйцэтгэхийн тулд автомат туршилт бүхий төслийг хийх шаардлагатай.
Тэгээд хоёр дахь бичлэг дээрээ бид юу хийж, ямар үр дүнд хүрсэн тухайгаа хэд хоногийн дараа хэлэх болно.
Эх сурвалж: www.habr.com