Стратэгія аўтаматызацыі выпрабаванняў для гнуткіх праектаў

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

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

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




Рэзюмэ

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

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


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



Для гэтага патрабуецца «перавярнуць піраміду аўтаматызацыі тэстаў», націснуўшы на тэсты графічнага інтэрфейсу, для выканання якіх патрабуецца шмат часу, каб знізіць узровень, напрыклад Пласт API, які можа працаваць адразу пасля модульных тэстаў у рамках зборкі, каб забяспечыць пачатковы ўзровень даверу.

Звязаныя:



Агляд стратэгіі аўтаматызацыі выпрабаванняў

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


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

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

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

Адзінкавыя тэсты ствараюць асновы для аўтаматызацыі выпрабаванняў на больш высокіх узроўнях.


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



Вызначэнне пакетаў рэгрэсіі

Аўтаматызаваныя рэгрэсійныя тэсты з'яўляюцца асновай Стратэгіі аўтаматызацыі выпрабаванняў.

Дым Рэгрэсія Pack

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

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


Пакет выпрабаванняў на дым працуе пры кожным разгортванні і можа быць сумессю тэстаў API і / або графічнага інтэрфейсу.

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

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

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


Паколькі гэтыя функцыянальныя тэсты больш падрабязныя, то для іх выканання спатрэбіцца больш часу, таму важна мець большасць функцыянальных тэстаў на ўзроўні API, дзе тэсты могуць выконвацца хутчэй, каб мы маглі знаходзіцца ў межах Ад 15 да 30 хвілін тэрмін.

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

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

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



Тэставанне стратэгіі аўтаматызацыі для некалькіх гнуткіх каманд

test_automation_strategy_agile

Аўтаматызаваныя адзінкавыя выпрабаванні

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

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

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

Адзінкавыя тэсты запускаюцца на машыне распрацоўшчыка, а таксама ў асяроддзі CI.

Аўтаматызаваная інтэграцыя / API або тэсты на абслугоўванне

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

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

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

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

Такія інструменты, як SoapUI, можна выкарыстоўваць для тэстаў на абслугоўванне.

Тэставанне прыкладанняў

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

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

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

Селен WebDriver можа быць выкарыстаны для запуску гэтых аўтаматызаваных тэстаў супраць браўзэра. Гэты інструмент з'яўляецца самым папулярным для тэстаў аўтаматызацыі браўзэра і забяспечвае багаты API, які дазваляе ажыццяўляць складаныя праверкі.

Сцэнарныя сцэнарныя выпрабаванні

Аўтаматызаваныя тэсты графічнага інтэрфейсу, якія запускаюцца супраць сістэмы, служаць тыповымі патокамі карыстальнікаў, падарожжамі і скразнымі сцэнарыямі. З-за праблем з гэтым тыпам выпрабаванняў (разгледжаных ніжэй) іх будзе зведзена да мінімуму. Сцэнарыі да канца ўключаны ў начны пакет рэгрэсіі.



Інвертаванне піраміды аўтаматызацыі выпрабаванняў

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

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

Далікатная

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

Абмежаваныя выпрабаванні

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

Павольна

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

Найменшая рэнтабельнасць

З-за вышэйзгаданых праблем аўтаматызаваныя тэсты графічнага інтэрфейсу забяспечваюць найменшую рэнтабельнасць.

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