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