Тэставанне ў свеце DevOps

DevOps - гэта аб'яднанне практыкі распрацоўкі і эксплуатацыі праграмнага забеспячэння і дастаўкі.

Тэстары, якія ўдзельнічаюць у мадэлі дастаўкі DevOps, пачынаюць задаваць такія пытанні:

  • Дзе тэсціраванне ўкладваецца ў мадэль DevOps?
  • Чым тэставанне і кантроль якасці ў DevOps адрозніваюцца ад тэсціравання ў мадэлях Agile і waterfall?
  • Як дадатковы кантроль, якія дадатковыя навыкі я павінен ведаць?

У гэтым паведамленні разглядаюцца інструменты, стратэгіі і практыкі, якія мы павінны ўкараніць для эфектыўнага тэсціравання ў свеце DevOps, уключаючы аўтаматызацыю і пастаяннае тэсціраванне ў DevOps.




QA і тэставанне ў DevOps

Як тэставанне ператварылася з вадаспада ў спрытны ў DevOps?

Мадэль вадаспаду

Практыка тэсціравання і забеспячэння якасці значна пасунулася з часоў вадаспада Agile і DevOps. У мадэлі вадаспаду тэставанне разглядалася як этап жыццёвага цыкла распрацоўкі праграмнага забеспячэння. Тэстары і намаганні былі вельмі зацішныя, калі раней тэстары былі часткай групы тэсціравання і часта аддзяляліся ад каманды распрацоўшчыкаў.


Тэстэры валодалі стратэгія тэставання і разглядаліся як брамнікі якасці. Тэставанне было ў асноўным ручным і раней адбывалася пасля поўнай распрацоўкі праграмнага забеспячэння і непасрэдна перад выпускам у вытворчасць.

Таксама праграмнае забеспячэнне раней займала шмат часу. Асобная аперацыйная каманда адказвала за выпуск праграмнага забеспячэння для вытворчасці, што, у лепшым выпадку, адбывалася кожныя некалькі месяцаў. Адсутнічаў альбо нізкі ўзровень камунікацыі / супрацоўніцтва паміж камандай Ops і камандай распрацоўшчыкаў.

Спрытная мадэль

Agile мадэль стварыла зрухі ў прасторы распрацоўкі і выпрабаванняў, а таксама ў частаце выпуску. Праграмнае забеспячэнне было распрацавана паўторна і паступова. Scrum, які з'яўляецца метадалогіяй у мадэлі дастаўкі Agile, хутка стаў вельмі папулярным.

Намаганні па распрацоўцы былі разбіты на шэраг кароткіх паўтораў, якія звычайна доўжыліся 2-4 тыдні. Кожная ітэрацыя стварала б праграмнае забеспячэнне, якое можна паставіць, дадаўшы новыя альбо ўзмацніўшы існуючыя функцыі.


Тэстары сталі часткай каманды распрацоўшчыкаў, і тэставанне стала паралельным відам распрацоўкі праграмнага забеспячэння, а не этапам у канцы SDLC. Тэставанне стала агульнай адказнасцю, і якасць належала камандзе распрацоўшчыкаў.

Мадэль Agile аб'яднала практыку распрацоўкі і тэсціравання і адкрыла шлях да больш хуткай дастаўкі праграмнага забеспячэння, аднак фактычнае ўкараненне ў вытворчасць усё роўна было зроблена асобнай камандай TechOps.

Хоць каманда TechOps будзе ведаць серверы, сеткі і разгортванне, яны звычайна не звяртаюць увагі на дэталі кожнага выпуску. Зваротная сувязь з камандай распрацоўшчыкаў была павольнай. Калі ў рэлізе існавала памылка, камандзе распрацоўшчыкаў звычайна спатрэбілася б некалькі гадзін, каб даведацца пра праблему.

Мадэль DevOps

DevOps робіць мадэль Agile на крок далей, набліжаючы дзейнасць па выпуску і разгортванні да распрацоўкі і тэсціравання. Гэта азначае, што спрытная каманда самастойна нясе адказнасць за распрацоўку, тэставанне і выпуск праграмнага забеспячэння, якое яны ствараюць.




Стратэгія тэсціравання DevOps

Тэставанне ў DevOps ахоплівае ўвесь жыццёвы цыкл распрацоўкі і пастаўкі праграмнага забеспячэння. Тэстары больш не засяроджваюцца толькі на функцыянальным тэсціраванні і праверцы функцый.

Як тэсціроўшчыкі, мы павінны ўдзельнічаць у тэсціраванні аперацый, тэставанні прадукцыйнасці, базавым тэсціраванні бяспекі, а таксама мець магчымасць кантраляваць і аналізаваць вытворчыя дадзеныя і часопісы.

У Дэна Эшбі ёсць выдатны пост пра тэставанне ў DevOps, у якім ён апісвае

Вы можаце зразумець, чаму людзі з усіх сіл разумеюць, дзе тэставанне падыходзіць для мадэлі, якая пра яе наогул не згадвае. Для мяне тэставанне падыходзіць для кожнай кропкі гэтай мадэлі.


Сапраўды, тэставанне можа і павінна адбывацца на кожным этапе ў мадэлі DevOps. У Паведамленне пра стратэгію выпрабаванняў , мы апісалі, як тэставанне ўпісваецца ў мадэль Agile.

Стратэгія тэсціравання DevOps можа пашырыць гэта, дадаўшы наступныя раздзелы:

Аўтаматызацыя тэстаў і бесперапыннае тэсціраванне ў DevOps

Выбар інструментаў і тэхналогій становіцца ўсё больш важным у мадэлі DevOps. Выбар інструментаў дазваляе арганізацыі дастаўляць прыкладання і паслугі з вялікай хуткасцю.


У DevOps робіцца большы акцэнт на аўтаматызаваным тэставанні, бо мы хочам стварыць культуру, дзе мы зможам хутка і з упэўненасцю прасоўваць код па сістэмах.

Нараўне з аўтаматызаванымі функцыянальнымі тэстамі, мы таксама павінны мець набор тэстаў прадукцыйнасці, а таксама тэсты бяспекі / устойлівасці ў трубаправодзе пастаўкі.

Залішне казаць, што перад тым, як рэалізаваць любы з вышэйапісаных аўтаматызаваных тэстаў, перш за ўсё трэба пабудаваць аўтаматызаваны канвеер зборкі і дастаўкі ў інструменце бесперапыннай інтэграцыі, напрыклад, Джэнкінсе.

Тэставанне ў вытворчасці

Тэставанне ў вытворчасці не абавязкова азначае выкананне вашых сцэнарыяў тэсціравання функцыянальнасці / прадукцыйнасці супраць рэальнай сістэмы, дзе карыстальнікі выкарыстоўваюць прыкладанне.

Мы можам пачаць з аналізу тэндэнцый A / B або мультыварыянтных тэстаў. Мы таксама можам кантраляваць серверы на прадмет якіх-небудзь дзіўных паводзін, такіх як уцечка памяці, высокае выкарыстанне працэсара і г.д.



Уплыў DevOps на тэставанне

Як усё гэта змяніла ролю тэстараў і тэсціравання ў DevOps?

Цяпер ад тэсціроўшчыкаў чакаецца наяўнасць па меншай меры наступных ведаў і навыкаў для эфектыўнага правядзення тэставых мерапрыемстваў

  • Асноўныя сеткавыя веды
  • Асноўныя сцэнарыі Unix / Shell, напрыклад баш, пітон
  • Бесперапынная інтэграцыя / пастаянная дастаўка, напрыклад Джэнкінс,
  • Інструменты тэсціравання прадукцыйнасці, такія як JMeter або Gatling
  • Гатовы да аперацый і выпрабаванняў на ўстойлівасць
  • Веданне кантэйнераў, Docker, Kubernetes
  • Запыт інструментаў маніторынгу, такіх як Splunk
  • Паслугі аблокаў, напр. AWS, Azure